svn commit: r673011 - /tomcat/tc6.0.x/trunk/webapps/docs/ssl-howto.xml
Author: jfclere Date: Tue Jul 1 00:06:54 2008 New Revision: 673011 URL: http://svn.apache.org/viewvc?rev=673011&view=rev Log: Just a note about PKCS12 key format. Modified: tomcat/tc6.0.x/trunk/webapps/docs/ssl-howto.xml Modified: tomcat/tc6.0.x/trunk/webapps/docs/ssl-howto.xml URL: http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/webapps/docs/ssl-howto.xml?rev=673011&r1=673010&r2=673011&view=diff == --- tomcat/tc6.0.x/trunk/webapps/docs/ssl-howto.xml (original) +++ tomcat/tc6.0.x/trunk/webapps/docs/ssl-howto.xml Tue Jul 1 00:06:54 2008 @@ -450,7 +450,8 @@ keystoreType Add this element if using a keystore type other than -JKS. +JKS. For example the *.p12 files from openssl can be +used using PKCS12 sslProtocol - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release tc-native 1.1.14
On Wed, 2008-06-25 at 13:34 +0200, jean-frederic clere wrote: > The candidates binaries are available here: > http://people.apache.org/~jfclere/tcnative/v1.1.14/ > > According to the release process, the 1.1.14 tag is: > [ ] Broken > [ ] Alpha > [ ] Beta > [X] Stable Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release tc-native 1.1.14
>> [X] Stable - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 45315] Wine support for building
https://issues.apache.org/bugzilla/show_bug.cgi?id=45315 Remy Maucherat <[EMAIL PROTECTED]> changed: What|Removed |Added Attachment #22199|0 |1 is obsolete|| --- Comment #1 from Remy Maucherat <[EMAIL PROTECTED]> 2008-07-01 03:05:13 PST --- Created an attachment (id=22200) --> (https://issues.apache.org/bugzilla/attachment.cgi?id=22200) Improved patch Improved patch (download NSIS zip during download, fix properties). -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r673044 - /tomcat/tc6.0.x/trunk/STATUS.txt
Author: remm Date: Tue Jul 1 03:11:11 2008 New Revision: 673044 URL: http://svn.apache.org/viewvc?rev=673044&view=rev Log: - Propose NSIS patch. Modified: tomcat/tc6.0.x/trunk/STATUS.txt Modified: tomcat/tc6.0.x/trunk/STATUS.txt URL: http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/STATUS.txt?rev=673044&r1=673043&r2=673044&view=diff == --- tomcat/tc6.0.x/trunk/STATUS.txt (original) +++ tomcat/tc6.0.x/trunk/STATUS.txt Tue Jul 1 03:11:11 2008 @@ -59,7 +59,14 @@ http://svn.apache.org/viewvc?rev=672454&view=rev +1: billbarker -1: remm: No, this gets called all the time, and we're trying to fix a small issue. The real - solution would be to recycle the fields (when exiting the process method of the processors) - since as mentioned here it is the cause of the problem (the "local" fields will often never - change, but there's no real guarantee overall): + solution would be to recycle the fields since as mentioned here it is the cause of + the problem (the "local" fields will often never change, but there's no real + guarantee overall - it mostly breaks down if there are multiple connectors, with AJP, + and seems impossible to anticipate): https://issues.apache.org/bugzilla/show_bug.cgi?id=36155#c17 + +* Add Unix support for NSIS (unfortunately, I do not have any Windows computer left, so I need this + for 6.0.17) + https://issues.apache.org/bugzilla/show_bug.cgi?id=45315 + +1: remm + -1: - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r673047 - /tomcat/tc6.0.x/trunk/STATUS.txt
Author: jfclere Date: Tue Jul 1 03:17:17 2008 New Revision: 673047 URL: http://svn.apache.org/viewvc?rev=673047&view=rev Log: My votes ;-) Modified: tomcat/tc6.0.x/trunk/STATUS.txt Modified: tomcat/tc6.0.x/trunk/STATUS.txt URL: http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/STATUS.txt?rev=673047&r1=673046&r2=673047&view=diff == --- tomcat/tc6.0.x/trunk/STATUS.txt (original) +++ tomcat/tc6.0.x/trunk/STATUS.txt Tue Jul 1 03:17:17 2008 @@ -51,7 +51,7 @@ * Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=45277 Correct typo http://svn.apache.org/viewvc?rev=672399&view=rev - +1: markt, fhanik + +1: markt, fhanik, jfclere -1: * Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=36155 @@ -68,5 +68,5 @@ * Add Unix support for NSIS (unfortunately, I do not have any Windows computer left, so I need this for 6.0.17) https://issues.apache.org/bugzilla/show_bug.cgi?id=45315 - +1: remm + +1: remm, jfclere -1: - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r673061 - /tomcat/trunk/webapps/docs/ssl-howto.xml
Author: jfclere Date: Tue Jul 1 04:34:06 2008 New Revision: 673061 URL: http://svn.apache.org/viewvc?rev=673061&view=rev Log: Add some extra info on keystore type. Modified: tomcat/trunk/webapps/docs/ssl-howto.xml Modified: tomcat/trunk/webapps/docs/ssl-howto.xml URL: http://svn.apache.org/viewvc/tomcat/trunk/webapps/docs/ssl-howto.xml?rev=673061&r1=673060&r2=673061&view=diff == --- tomcat/trunk/webapps/docs/ssl-howto.xml (original) +++ tomcat/trunk/webapps/docs/ssl-howto.xml Tue Jul 1 04:34:06 2008 @@ -449,8 +449,8 @@ keystoreType -Add this element if using a keystore type other than -JKS. +Add this element if using a keystore type other than JKS. +For example the *.p12 files from openssl can be used using PKCS12. sslProtocol - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Some potential data races in tomcat
Could anyone here have a look on these races we found? Any comments are highly appreciated. On 6/18/08, Yao Qi <[EMAIL PROTECTED]> wrote: >We have been working on a tool (MTRAT, Multi-Thread Runtime Analysis > Tool) for finding potential data races and deadlocks in java programs > and I tried it out on Tomcat 6.0.13. I found some that look like > problems; you might be interested in fixing them, and I would like to > know if my results are correct or not. > > 1. accessCount in class org.apache.naming.resources.ResourceCache > ** Two threads' backtrace to show how race happens, > Thread http-8081-1 id: 23 : WRITE > > [org.apache.naming.resources.ResourceCache : lookup : 294] > [org.apache.naming.resources.ProxyDirContext : cacheLookup : 1444] > [org.apache.naming.resources.ProxyDirContext : lookup : 283] > [org.apache.tomcat.util.http.mapper.Mapper : internalMapWrapper : 736] > [org.apache.tomcat.util.http.mapper.Mapper : internalMap : 626] > [org.apache.tomcat.util.http.mapper.Mapper : map : 516] > [org.apache.catalina.connector.CoyoteAdapter : postParseRequest : 419] > [org.apache.catalina.connector.CoyoteAdapter : service : 259] > [org.apache.coyote.http11.Http11Processor : process : 844] > [org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler > : process : 581] > [org.apache.tomcat.util.net.JIoEndpoint$Worker : run : 447] > [java.lang.Thread : run : 735] > > Thread http-8081-3 id: 25 : WRITE > > [org.apache.naming.resources.ResourceCache : lookup : 294] > [org.apache.naming.resources.ProxyDirContext : cacheLookup : 1444] > [org.apache.naming.resources.ProxyDirContext : lookup : 283] > [org.apache.tomcat.util.http.mapper.Mapper : internalMapWrapper : 782] > [org.apache.tomcat.util.http.mapper.Mapper : internalMap : 626] > [org.apache.tomcat.util.http.mapper.Mapper : map : 516] > [org.apache.catalina.connector.CoyoteAdapter : postParseRequest : 419] > > ** Initial analysis: Since two threads invoke > org.apache.naming.resources.ResourceCache::lookup(), in which > accessCount is incremented, there should be a lock to prevent > concurrent increment to accessCount. > > 2. countAllocated in org.apache.catalina.core.StandardWrapper > ** Two threads' backtrace to show how race happens, > > Thread http-8081-1 id: 23 : READ > [org.apache.catalina.core.StandardWrapper : allocate : 820] > [org.apache.catalina.core.StandardWrapperValve : invoke : 129] > [org.apache.catalina.core.StandardContextValve : invoke : 175] > [org.apache.catalina.core.StandardHostValve : invoke : 128] > [org.apache.catalina.valves.ErrorReportValve : invoke : 104] > [org.apache.catalina.core.StandardEngineValve : invoke : 109] > [org.apache.catalina.connector.CoyoteAdapter : service : 261] > [org.apache.coyote.http11.Http11Processor : process : 844] > [org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler > : process : 581] > [org.apache.tomcat.util.net.JIoEndpoint$Worker : run : 447] > [java.lang.Thread : run : 735] > > Thread http-8081-4 id: 26 : WRITE > > [org.apache.catalina.core.StandardWrapper : deallocate : 871] > [org.apache.catalina.core.StandardWrapperValve : invoke : 298] > [org.apache.catalina.core.StandardContextValve : invoke : 175] > [org.apache.catalina.core.StandardHostValve : invoke : 128] > [org.apache.catalina.valves.ErrorReportValve : invoke : 104] > [org.apache.catalina.core.StandardEngineValve : invoke : 109] > [org.apache.catalina.connector.CoyoteAdapter : service : 261] > [org.apache.coyote.http11.Http11Processor : process : 844] > [org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler > : process : 581] > [org.apache.tomcat.util.net.JIoEndpoint$Worker : run : 447] > [java.lang.Thread : run : 735] > > ** Initial analysis: increment and decrement are performed in > allocate() and deallocate respectively. Since increment and decrement > are *not* atomic, they may involve problems. > > 3. hitsCount of class org.apache.naming.resources.ResourceCache, > > ** Two threads' stack backtrace, > Thread http-8081-1 id: 23 : WRITE > Lock Set : [ ] > [org.apache.naming.resources.ResourceCache : lookup : 307] > [org.apache.naming.resources.ProxyDirContext : cacheLookup : 1444] > [org.apache.naming.resources.ProxyDirContext : lookupCache : 1377] > [org.apache.catalina.servlets.DefaultServlet : serveResource : 643] > [org.apache.catalina.servlets.DefaultServlet : doGet : 325] > [javax.servlet.http.HttpServlet : service : 690] > [javax.servlet.http.HttpServlet : service : 803] > [org.apache.catalina.core.ApplicationFilterChain : internalDoFilter : > 290] > [org.apache.catalina.core.ApplicationFilterChain : doFilter : 206] > [org.apache.catalina.core.StandardWrap
DO NOT REPLY [Bug 45317] New: DeltaManager always reports default timeout value for receiving session state on startup
https://issues.apache.org/bugzilla/show_bug.cgi?id=45317
Summary: DeltaManager always reports default timeout value for
receiving session state on startup
Product: Tomcat 6
Version: 6.0.16
Platform: PC
OS/Version: Linux
Status: NEW
Severity: trivial
Priority: P5
Component: Cluster
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
Hi there,
If I override the state transfer timeout:
DeltaManager continues to log the default timeout value (ie: "This operation
will timeout if no session state has been received within 60 seconds."):
2008-07-01 14:31:30,419 WARN [org.apache.catalina.ha.session.DeltaManager] -
Manager [localhost#/manager], requesting session state from
org.apache.catalina.tribes.membership.MemberImpl[tcp://{10, -64, 104,
-55}:15000,{10, -64, 104, -55},15000, alive=18586,id={-62 91 -70 -63 -111 50 70
-33 -104 41 -48 -32 91 34 -83 -55 }, payload={}, command={}, domain={}, ]. This
operation will timeout if no session state has been received within 60 seconds.
2008-07-01 14:31:35,310 WARN [org.apache.catalina.ha.ClusterListener] - Context
manager doesn't exist:localhost#/host-manager
But it actually uses the correct timeout value (ie: "timing out after 10,100
ms"):
2008-07-01 14:31:40,518 ERROR [org.apache.catalina.ha.session.DeltaManager] -
Manager [localhost#/manager]: No session state send at 01/07/08 14:31 received,
timing out after 10,100 ms.
This is only an incorrect message, but it is quite annoying especially coupled
with the fact that the above configuration is only documented for tomcat 5
(where syntax is subtly different).
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 43191] compressableMimeType attribute ignored
https://issues.apache.org/bugzilla/show_bug.cgi?id=43191 Jonathan Leech <[EMAIL PROTECTED]> changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Comment #11 from Jonathan Leech <[EMAIL PROTECTED]> 2008-07-01 10:11:24 PST --- For such a simple concept, every compression filter I have ever seen has serious problems. Mostly the problems are not addressed, and instead all kinds of finely grained mechanisms are created to more selectively apply compression. For example, if a response sets the content-length header, I have seen compression filters break. The browser either hangs waiting for the rest of the response, or the response is truncated to the length set. I don't remember if Tomcat's compression filter is guilty of this behavior or not, but I suspect the latter due to the existence of the compressionThreshold setting. I have created my own GZIPFilter which addresses all the problems I have seen in various other compression filter implementations. I am posting it as an attachment to this bug, feel free to use it, or not. Its advantages are captured in the comments, in summary, it streams rather than makes a copy, it handles content-length correctly, it detects client support of gzip compression, and it doesn't double compress. It is not problem-free, the known problems and limitations are also captured in the comments. My theory on filter mapping is to keep it simple. So my filter doesn't care about mime-types, or any other qualification other compression filters use to decide whether to compress or not. As I stated before, it is my experience that these features exist to "fix" other problems in the filters. The original poster can use my GZIPFilter in one of a few ways: 1) Use filter-mapping to selectively compress content. 2) Extend GZIPFilter, look at the mime-type header, and compress or not by calling super.doFilter(). 3) Modify my GZIPFilter to look at mime-types. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 43191] compressableMimeType attribute ignored
https://issues.apache.org/bugzilla/show_bug.cgi?id=43191 --- Comment #12 from Jonathan Leech <[EMAIL PROTECTED]> 2008-07-01 10:12:26 PST --- Created an attachment (id=22203) --> (https://issues.apache.org/bugzilla/attachment.cgi?id=22203) GZIP compression filter -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 44494] Requests greater than 8k being truncated.
https://issues.apache.org/bugzilla/show_bug.cgi?id=44494 Paul Ryan <[EMAIL PROTECTED]> changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Comment #54 from Paul Ryan <[EMAIL PROTECTED]> 2008-07-01 11:49:57 PST --- I hate to make a post like this but as it has not been decided, is there a plan for releasing this as it has caught a number of teams off guard? I agree with the poster from 53 that this is a major issue as requests can't be trusted. Please update the homepage with this issue and pull 6.0.16 and 5.5.26 from public release at the very least. Thanks for the fix and I look forward to the changed release. (In reply to comment #53) > Since this bug effectively means tomcat 6.0.16 is unable to reliably handle > requests, perhaps it should be publicised more widely, and the 6.0.16 release > pulled (or replaced with 6.0.16.1)? > -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release tc-native 1.1.14
Hi Jean-Frederic,
jean-frederic clere schrieb:
The candidates binaries are available here:
http://people.apache.org/~jfclere/tcnative/v1.1.14/
According to the release process, the 1.1.14 tag is:
[ ] Broken
[ ] Alpha
[ ] Beta
[X] Stable
Tested on Solaris 8. Library loads, threads show that it gets used,
manager status shows extended OS information. Nevertheless see some
minor comments below. I didn't test with OpenSSL or under high load though.
On Windows I wasn't successful in building, because the build needs
apr_arch_misc.h, which is not included in the binary download, and
building apr 1.3.2 was broken with errors in that file (apr_arch_misc.h).
Thanks for doing the tcnative release.
Detailed Comments
=
Signature of Tarball is OK.
Changelog looks a little strange, because it ends at 1_1.12 (or 1_1.13,
but there's no headline for that version).
README.txt:
It says "This directory contains both the native and java-side code for
Tomcat Native Library.". But in fact there is only the jni directory
included. So also the other comments about ant and about test examples
are not applicable.
Instead of "To build the native part see native/BUILDING" maybe we
should use the path jni/native/BUILDING.
File BUILDING:
Before talking about buildconf, it might first list the usual procedure
(configure, make, make install).
There is a block
===
Build the jar containing the example by
cd ..
ant jar
Run the example:
ant example-basic
===
which doesn't apply, because no build.xml and no examples and JavaFiles
are included in the tarball.
The NOTE: "configure --without-ssl : Configure without ssl support." is
unclear, because there is also a --disable-openssl.
configure:
--enable-openssl and --disable-openssl both disable OpenSSl
You should apply the following patch to configure.in:
===
% diff -u configure.in.orig configure.in before the next release
--- configure.in.orig 2007-09-20 22:36:05.0 +0200
+++ configure.in2008-07-01 22:23:55.0 +0200
@@ -141,10 +141,14 @@
use_openssl=true;
AC_ARG_ENABLE(openssl,
-[ --disable-openssl avoid using OpenSSL toolkit],
+[AS_HELP_STRING([--disable-openssl],[avoid using OpenSSL toolkit])],
[
- use_openssl=false;
- AC_MSG_RESULT([Disabling SSL support...])
+ case "${enableval}" in
+no )
+use_openssl=false;
+AC_MSG_RESULT([Disabling SSL support...])
+;;
+ esac
])
if $use_openssl ; then
===
The recreated configure then behaves as wanted (disables disables,
enable enables (default) and enable-openssl=no disables).
configure seems not to be in sync with configure.in. If I recreate it,
one message chánges:
% diff configure.orig configure
1257,1258c1257,1258
< --with-apr=PATH prefix for installed APR, path to APR build
tree,
< or the full path to apr-config
---
> --with-apr=PATH prefix for installed APR or the full path to
> apr-config
Compile warnings:
src/poll.c: In function 'Java_org_apache_tomcat_jni_Poll_poll':
src/poll.c:284: warning: 'now' may be used uninitialized in this function
src/ssl.c: In function 'ssl_rand_make':
src/ssl.c:364: warning: value computed is not used
src/network.c: In function 'Java_org_apache_tomcat_jni_Socket_sendv':
src/network.c:667: warning: pointer targets in assignment differ in
signedness
src/network.c:673: warning: pointer targets in passing argument 3 of
'(*e)->ReleaseByteArrayElements' differ in signedness
src/network.c: In function 'Java_org_apache_tomcat_jni_Socket_sendfile':
src/network.c:1217: warning: pointer targets in assignment differ in
signedness
src/network.c:1222: warning: pointer targets in assignment differ in
signedness
src/network.c:1240: warning: pointer targets in passing argument 3 of
'(*e)->ReleaseByteArrayElements' differ in signedness
src/network.c:1244: warning: pointer targets in passing argument 3 of
'(*e)->ReleaseByteArrayElements' differ in signedness
src/file.c: In function 'Java_org_apache_tomcat_jni_File_writev':
src/file.c:384: warning: pointer targets in assignment differ in signedness
src/file.c:390: warning: pointer targets in passing argument 3 of
'(*e)->ReleaseByteArrayElements' differ in signedness
src/file.c: In function 'Java_org_apache_tomcat_jni_File_writevFull':
src/file.c:418: warning: pointer targets in assignment differ in signedness
src/file.c:428: warning: pointer targets in passing argument 3 of
'(*e)->ReleaseByteArrayElements' differ in signedness
Regards,
Rainer
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 45323] New: Documentation doesn' t specify that each context.xml may only contain one element
https://issues.apache.org/bugzilla/show_bug.cgi?id=45323 Summary: Documentation doesn't specify that each context.xml may only contain one element Product: Tomcat 5 Version: Unknown Platform: PC URL: http://tomcat.apache.org/tomcat-5.5- doc/config/context.html OS/Version: Linux Status: NEW Severity: minor Priority: P2 Component: Webapps:Documentation AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] The documentation for configuring contexts (http://tomcat.apache.org/tomcat-5.5-doc/config/context.html) states that "You may define as many Context elements as you wish." However, it doesn't say that each context has to be defined in a different file. This is especially confusing as putting more that one element in a single context.xml file will give the error message "SEVERE: Parse error in context.xml" for each webapp with the exception message " The markup in the document following the root element must be well-formed." This indicates that the problem is with the XML syntax instead of the semantics of context definitions. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
