Re: 7.0.6 plans
On 03.01.2011 17:49, Mark Thomas wrote: Hope everyone had a good holiday. Thanks, hope you had good holidays too! I think it is time for another 7.0.x release. I'll start going through the open bugs this week and depending on how long that takes probably get to the point where 7.0.6 is tagged end of this week / beginning of next. +1 On related news, I managed to spend some time over the holidays setting up a new Jira installation for the ASF that we'll be able to use to test Tomcat 7. There are a few things still to do before that goes live but we should have the ASF Jira running on Tomcat 7.0.latest in a month or two. Great! Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Time for 6.0.30?
On 04.01.2011 11:44, Mark Thomas wrote: It has been a while since 6.0.29 and there have been a few requests for this on the users list. Jean-Frederic, do you have any plans for 6.0.30 at this point? I think a 6.0.30 is kind of overdue. If Jean-Frederic can't start the release process during the next 2 weeks or so, I can volunteer. It looks like releasing TC 6 isn't very complicated and the more people can do it the better. If Jean-Frederic is willing to do it, I would nevertheless prefer him to do it. Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1055776 - /tomcat/native/branches/1.1.x/xdocs/miscellaneous/changelog.xml
On 06.01.2011 08:42, jfcl...@apache.org wrote: Author: jfclere Date: Thu Jan 6 07:42:48 2011 New Revision: 1055776 URL: http://svn.apache.org/viewvc?rev=1055776view=rev Log: Add missing information. Modified: tomcat/native/branches/1.1.x/xdocs/miscellaneous/changelog.xml Modified: tomcat/native/branches/1.1.x/xdocs/miscellaneous/changelog.xml URL: http://svn.apache.org/viewvc/tomcat/native/branches/1.1.x/xdocs/miscellaneous/changelog.xml?rev=1055776r1=1055775r2=1055776view=diff == --- tomcat/native/branches/1.1.x/xdocs/miscellaneous/changelog.xml (original) +++ tomcat/native/branches/1.1.x/xdocs/miscellaneous/changelog.xml Thu Jan 6 07:42:48 2011 @@ -39,6 +39,15 @@ section name=Changes between 1.1.20 and 1.1.21 changelog update + Update copyright year. (rjung) +/update It's up to you, but I think it is not common to mention such formal trivialities in the changelog. Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: DO NOT REPLY [Bug 50333] IllegalArgumentException occurs when setting maxActive to smaller than 1.
Hi Filip, On 10.01.2011 17:41, bugzi...@apache.org wrote: https://issues.apache.org/bugzilla/show_bug.cgi?id=50333 Filip Hanikfha...@apache.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from Filip Hanikfha...@apache.org 2011-01-10 11:41:53 EST --- svn r 1057268 if you write it as r1057268 a regexp that I think Mark added sometime to Bugzilla will detect it and provide a nice link to the viewvc revision entry in the HTML view of the ticket. It does not work when whitespace is between the r and the revision number. Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release build 6.0.30
On 10.01.2011 18:18, jean-frederic clere wrote: The candidates binaries are available here: http://people.apache.org/~jfclere/tomcat-6/v6.0.30/ According to the release process, the 6.0.30 build corresponding to the tag TOMCAT_6_0_30 is: [ ] Broken [ ] Alpha [ ] Beta [X] Stable - MD5 OK - signatures OK - key in KEYS file - gz and zip for src and bin consistent - src consistent with svn tag - builds fine - build result looks consistent with binaries Some javadoc warnings but AFAIK TC6 was never 100% clean w.r.t. javadoc. Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 7.0.6
On 10.01.2011 19:54, Mark Thomas wrote:
The proposed Apache Tomcat 7.0.6 release is now available for voting.
It can be obtained from:
http://people.apache.org/~markt/dev/tomcat-7/v7.0.6/
The svn tag is:
http://svn.apache.org/repos/asf/tomcat/tc7.0.x/tags/TOMCAT_7_0_6/
The proposed 7.0.6 release is:
[ ] Broken - do not release
[ ] Alpha - go ahead and release as 7.0.6 Alpha
[ ] Beta - go ahead and release as 7.0.6 Beta
[X] Stable - go ahead and release as 7.0.6 Stable
- MD5 OK
- signatures OK
- key in KEYS file
- gz and zip for src and bin consistent
- src consistent with svn tag
- builds fine
- build result looks consistent with binaries
- no checkstyle complaints
- Unit tests run OK except for one failures (see below).
Tests have been run on Solaris 10 Sparc with 2 CPUs
using Java 1.6.0_17.
- few Javadoc warning (see below)
Looks we finally have a TC 7 stable. Good work!
1 unit test failing (not a problem)
---
Testsuite: org.apache.catalina.connector.TestMaxConnections
Tests run: 1, Failures: 1, Errors: 0, Time elapsed: 6.869 sec
...
Testcase: testConnector took 6.857 sec
FAILED
The number of successful requests should have been 4-5, actual 6
junit.framework.AssertionFailedError: The number of successful requests
should have been 4-5, actual 6
at
org.apache.catalina.connector.TestMaxConnections.testConnector(TestMaxConnections.java:58)
I instrumented the test client and the servlet a bit and one sees, that
in fact 6 client connects return quickly after each other
(reproducible), but the servlet is only started for the first 4 and only
after those finished does the servlet start for the other two. So it's
very likely, that the accept of 1 leads to Solaris/Java accepting 2
additional connections. I don't have the time right now to check (snoop)
and look at JVM code, but on the short hand it might be OK to just
increase the acceptable limit for the test from 5 to 6, which has still
enough headroom to the tested 10 connections.
Few javadoc warnings (minor)
org/apache/catalina/authenticator/AuthenticatorBase.java:175: warning -
Tag @link: reference not found: java.secure.SecureRandom
org/apache/catalina/authenticator/AuthenticatorBase.java:186: warning -
Tag @link: reference not found: java.secure.SecureRandom
org/apache/catalina/authenticator/AuthenticatorBase.java:196: warning -
Tag @link: reference not found: java.secure.SecureRandom
org/apache/catalina/filters/RequestFilter.java:131: warning - @param
argument allow is not a parameter name.
org/apache/catalina/Host.java:153: warning - Tag @link: can't find
appBase in org.apache.catalina.Host
org/apache/catalina/Host.java:161: warning - Tag @link: can't find
appBase in org.apache.catalina.Host
org/apache/catalina/session/ManagerBase.java:114: warning - Tag @link:
reference not found: java.secure.SecureRandom
org/apache/catalina/session/ManagerBase.java:125: warning - Tag @link:
reference not found: java.secure.SecureRandom
org/apache/catalina/session/ManagerBase.java:135: warning - Tag @link:
reference not found: java.secure.SecureRandom
org/apache/catalina/valves/RequestFilterValve.java:144: warning - @param
argument allow is not a parameter name.
org/apache/tomcat/util/net/AbstractEndpoint.java:319: warning - Tag
@link: reference not found: ProtocolHandler
org/apache/tomcat/util/net/AbstractEndpoint.java:327: warning - Tag
@link: reference not found: ProtocolHandler
org/apache/tomcat/util/threads/CounterLatch.java:128: warning - @return
tag has no arguments.
org/apache/tomcat/util/threads/CounterLatch.java:157: warning - @return
tag has no arguments.
org/apache/tomcat/util/threads/CounterLatch.java:167: warning - Tag
@see: reference not found: {...@link #releaseAll()}
org/apache/tomcat/util/threads/CounterLatch.java:167: warning - Tag
@see:illegal character: 123 in {...@link #releaseAll()}
org/apache/tomcat/util/threads/CounterLatch.java:167: warning - Tag
@see:illegal character: 64 in {...@link #releaseAll()}
org/apache/tomcat/util/threads/DedicatedThreadExecutor.java:104: warning
- @return tag has no arguments.
org/apache/tomcat/util/threads/DedicatedThreadExecutor.java:49: warning
- @return tag has no arguments.
Regards,
Rainer
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: DO NOT REPLY [Bug 22405] warn if not deploy with umask 0077 or if deployed as root and provide tutorial URL Secure deployment
On 19.01.2011 20:00, Mark Thomas wrote: On 19/01/2011 18:53, Ian Darwin wrote: On 01/19/11 13:47, Mark Thomas wrote: On 19/01/2011 18:45, bugzi...@apache.org wrote: https://issues.apache.org/bugzilla/show_bug.cgi?id=22405 --- Comment #5 from Mark Thomasma...@apache.org 2011-01-19 13:45:40 EST --- Created an attachment (id=26519) -- (https://issues.apache.org/bugzilla/attachment.cgi?id=26519) Proposed patch for Tomcat 7 This patch adds a new listener that checks the user Tomcat is running as and the umask being used. I didn't apply this directly as it stops Tomcat from starting (not on Windows) as root or if the umask is not at least as restrictive as 0007. WDYT? I'd like that to be a warning, not a fatal error. It is a fine line. Some things are sufficiently dangerous that the user should have to actively choose to do them. Running as root is probably one of them but then again jsvc is designed to run as root to use privileged ports. Maybe there is a way to tell the difference such as move the check until the point where jsvc would have changed to a lower privileged user. Not tested with Java 6, but at least for Java 5 user.name still seems to return the real uid, not the effective one. So I expect under jsvc you will still get root as the result. See: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4290712 But it should be verified using jsvc. Not sure whether my simple perl+Java bsed test is valid. Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Tomcat 7.0.x. still CTR?
On 19.01.2011 18:23, Filip Hanik - Dev Lists wrote: I'd prefer to stay CTR for a while. Chances are there are still much to be fixed given all the changes that have taken place. +1 On 1/18/2011 11:41 AM, Christopher Schultz wrote: All, Since Tomcat 7.0.x went stable, does that change the commit policy, or are we still doing commit-them-review? Thanks, -chris - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release build 6.0.31
On 24.01.2011 22:51, jean-frederic clere wrote: The candidates binaries are available here: http://people.apache.org/~jfclere/tomcat-6/v6.0.31/ According to the release process, the 6.0.31 build corresponding to the tag TOMCAT_6_0_31 is: [ ] Broken [ ] Alpha [ ] Beta [X] Stable - MD5 OK - signatures OK - key in KEYS file - gz and zip for src and bin consistent - src consistent with svn tag - builds fine - build result looks consistent with binaries Some javadoc warnings but AFAIK TC6 was never 100% clean w.r.t. javadoc. Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Tomcat 5.5.32 Build
On 22.01.2011 19:01, Jim Jagielski wrote: The builds for Tomcat 5.5.32 are ready for testing and approval. The candidates binaries are available here: http://people.apache.org/~jim/tomcat-5.5/ According to the release process, the 5.5.32 build corresponding to the tag TOMCAT_5_5_32 [1] is: [ ] Broken [ ] Alpha [ ] Beta [X] Stable - MD5 OK - signatures OK - key in KEYS file - gz and zip for src and bin consistent - src consistent with svn tag - builds fine - build result looks consistent with binaries - Minor things: - bin/version.sh doesn_t have execute permissions in bin tarball - additional build.xml included in top-level src tar and zip which is a duplicate of the one in the build directory. - STATUS.txt in svn, but not in src tar and zip (I guess that's expected) - 4 errors in run-tester, but I vaguely remember those are not regressions (details see below) - Some javadoc warnings but AFAIK TC 5.5 was never 100% clean w.r.t. javadoc. Details for run-tester: [tester] FAIL [GET /tester/ErrorPage08?type=Arithmetic HTTP/1.0] Expected data 'ErrorPage06 PASSED - SERVLET', got data 'ErrorPage06 FAILED - message is not correct' [tester] FAIL [GET /tester/WrappedErrorPage08?type=Arithmetic HTTP/1.0] Expected data 'ErrorPage06 PASSED - SERVLET', got data 'ErrorPage06 FAILED - message is not correct' [tester] FAIL [GET /tester/ErrorPage08?type=Array HTTP/1.0] Expected data 'ErrorPage06 PASSED - JSP', got data 'ErrorPage06 FAILED - message is not correct' [tester] FAIL [GET /tester/WrappedErrorPage08?type=Array HTTP/1.0] Expected data 'ErrorPage06 PASSED - JSP', got data 'ErrorPage06 FAILED - message is not correct' Excerpt from catalina.out just in case it helps: Jan 27, 2011 12:00:43 PM org.apache.catalina.core.ApplicationContext log INFO: RequestListener01: requestInitialized() Jan 27, 2011 12:00:43 PM org.apache.catalina.core.ApplicationContext log INFO: RequestListener01: attributeAdded(org.apache.catalina.jsp_file,/ErrorPage08.jsp) Jan 27, 2011 12:00:43 PM org.apache.catalina.core.ApplicationContext log INFO: SessionListener01: sessionCreated(F404B825FBC270339EBB36A0E2303A50) Jan 27, 2011 12:00:43 PM org.apache.catalina.core.ApplicationContext log INFO: RequestListener01: attributeRemoved(org.apache.catalina.jsp_file,/ErrorPage08.jsp) Jan 27, 2011 12:00:43 PM org.apache.catalina.core.StandardWrapperValve invoke SEVERE: Servlet.service() for servlet ErrorPage08 threw exception java.lang.ArithmeticException: ErrorPage08 Threw ArithmeticException »···at org.apache.jsp.ErrorPage08_jsp._jspService(ErrorPage08_jsp.java:50) »···at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:98) »···at javax.servlet.http.HttpServlet.service(HttpServlet.java:729) »···at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:369) »···at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:308) »···at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:259) »···at javax.servlet.http.HttpServlet.service(HttpServlet.java:729) »···at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:269) »···at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188) »···at org.apache.tester.StaticFilter.doFilter(StaticFilter.java:72) »···at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215) »···at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188) »···at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) »···at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:172) »···at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:470) »···at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) »···at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117) »···at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:108) »···at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:174) »···at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:879) »···at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:665) »···at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:528) »···at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:81) »···at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:689) »···at java.lang.Thread.run(Thread.java:534) Jan 27, 2011 12:00:43 PM org.apache.catalina.core.ApplicationContext log INFO: RequestListener01:
Re: [VOTE] Release build 6.0.31
On 27.01.2011 21:39, Konstantin Kolinko wrote: 2011/1/27 jean-frederic clerejfcl...@gmail.com: On 01/27/2011 10:30 AM, Konstantin Kolinko wrote: 2011/1/25 jean-frederic clerejfcl...@gmail.com: The candidates binaries are available here: http://people.apache.org/~jfclere/tomcat-6/v6.0.31/ According to the release process, the 6.0.31 build corresponding to the tag TOMCAT_6_0_31 is: [x] Beta That is because of issue observed with Nio connector. https://issues.apache.org/bugzilla/show_bug.cgi?id=50651 I am not saying broken, because other connectors run OK for me. Though, as 6.0.31 goal was to resolve regression with Nio it does not quite serve that purpose. The above mentioned issue is present in 6.0.30 as well. Ok then we should go for a 6.0.32 once it is solved. Regarding the status for 6.0.32: 1. The fix for the above mentioned regression has been applied. 2. Of the currently open issues the following one is of concern: https://issues.apache.org/bugzilla/show_bug.cgi?id=50631 InternalNioInputBuffer should honor maxHttpHeadSize It affects 6.0 and 7.0. So if fixing NIO is close, should we really release 6.0.31 shortly after the NIO broken 6.0.30 just to release 6.0.32 shortly after? If it doesn't take more than say 2-3 weeks to release 6.0.32, I would suggest we skip 6.0.31. The reason for 6.0.31 was fixing a NIO regression, so IMHO we shouldn't release it if it contains another serious NIO issue already known. Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1065767 - in /tomcat/sandbox/tomcat-oacc/trunk: docs/changelog.xml src/share/org/apache/catalina/cluster/session/DeltaManager.java
On 01.02.2011 02:05, sebb wrote: On 31 January 2011 20:45,rj...@apache.org wrote: Author: rjung Date: Mon Jan 31 20:45:31 2011 New Revision: 1065767 URL: http://svn.apache.org/viewvc?rev=1065767view=rev Log: Add session creation / expiration rate statistics to the session managers. Backport of r1036595 from trunk, resp. r1061433 from TC6. Modified: tomcat/sandbox/tomcat-oacc/trunk/docs/changelog.xml tomcat/sandbox/tomcat-oacc/trunk/src/share/org/apache/catalina/cluster/session/DeltaManager.java Modified: tomcat/sandbox/tomcat-oacc/trunk/src/share/org/apache/catalina/cluster/session/DeltaManager.java URL: http://svn.apache.org/viewvc/tomcat/sandbox/tomcat-oacc/trunk/src/share/org/apache/catalina/cluster/session/DeltaManager.java?rev=1065767r1=1065766r2=1065767view=diff == --- tomcat/sandbox/tomcat-oacc/trunk/src/share/org/apache/catalina/cluster/session/DeltaManager.java (original) +++ tomcat/sandbox/tomcat-oacc/trunk/src/share/org/apache/catalina/cluster/session/DeltaManager.java Mon Jan 31 20:45:31 2011 @@ -140,6 +142,7 @@ public class DeltaManager extends Cluste private boolean receiverQueue = false ; private boolean stateTimestampDrop = true ; private long stateTransferCreateSendTime; +private boolean hasSessionCreateStatistics = false; Could/should be made final? Done in r1065949. Thanks for the heads-up. Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Tagging 7.0.7
+1 On 02.02.2011 16:53, Konstantin Kolinko wrote: 2011/2/2 Mark Thomasma...@apache.org: I'd like to stick to my plan to release Tomcat 7 every month or so. The last release was ~ 3 weeks ago so that suggests next week. However, I have some commitments next week that would make tagging and rolling a release difficult so I intend to tag later today. There are plenty of fixes in the changelog, particularly for Comet, that I think makes this worthwhile. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release build 6.0.32
On 02.02.2011 20:37, jean-frederic clere wrote: The candidates binaries are available here: http://people.apache.org/~jfclere/tomcat-6/v6.0.32/ According to the release process, the 6.0.32 build corresponding to the tag TOMCAT_6_0_32 is: [ ] Broken [ ] Alpha [ ] Beta [X] Stable - MD5 OK - signatures OK - key in KEYS file - gz and zip for src and bin consistent - src consistent with svn tag - builds fine - build result looks consistent with binaries Some javadoc warnings as normal for TC6. Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 7.0.7
On 03.02.2011 14:32, Mark Thomas wrote: The proposed Apache Tomcat 7.0.7 release is now available for voting. It can be obtained from: http://people.apache.org/~markt/dev/tomcat-7/v7.0.7/ The svn tag is: http://svn.apache.org/repos/asf/tomcat/tc7.0.x/tags/TOMCAT_7_0_7/ The proposed 7.0.7 release is: [ ] Broken - do not release [ ] Alpha - go ahead and release as 7.0.7 Alpha [ ] Beta - go ahead and release as 7.0.7 Beta [X] Stable - go ahead and release as 7.0.7 Stable - MD5 OK - signatures OK - key in KEYS file - gz and zip for src and bin consistent - src consistent with svn tag - builds fine - build result looks consistent with binaries - no checkstyle complaints - Unit tests run OK except for one failure (see below, same as for 7.0.6). Tests have been run on Solaris 10 Sparc with 2 CPUs using Java 1.6.0_17. 1 unit test failing (not a problem) --- Testsuite: org.apache.catalina.connector.TestMaxConnections [junit] Tests run: 1, Failures: 1, Errors: 0, Time elapsed: 6.88 sec - Standard Error - Feb 3, 2011 8:52:06 PM org.apache.coyote.AbstractProtocolHandler init INFO: Initializing ProtocolHandler [http-bio-8080] Feb 3, 2011 8:52:06 PM org.apache.catalina.core.StandardService startInternal INFO: Starting service Tomcat Feb 3, 2011 8:52:06 PM org.apache.catalina.core.StandardEngine startInternal INFO: Starting Servlet Engine: Apache Tomcat/7.0.7 Feb 3, 2011 8:52:07 PM org.apache.coyote.AbstractProtocolHandler start INFO: Starting ProtocolHandler [http-bio-8080] Feb 3, 2011 8:52:09 PM org.apache.catalina.connector.TestMaxConnections$ConnectThread run SEVERE: ConnectThread[6] Error:connect timed out Feb 3, 2011 8:52:09 PM org.apache.catalina.connector.TestMaxConnections$ConnectThread run SEVERE: ConnectThread[7] Error:connect timed out Feb 3, 2011 8:52:09 PM org.apache.catalina.connector.TestMaxConnections$ConnectThread run SEVERE: ConnectThread[8] Error:connect timed out Feb 3, 2011 8:52:09 PM org.apache.catalina.connector.TestMaxConnections$ConnectThread run SEVERE: ConnectThread[9] Error:connect timed out Feb 3, 2011 8:52:09 PM org.apache.catalina.connector.TestMaxConnections$TestClient doHttp10Request INFO: ConnectThread[0] Request complete:1690 ms. Feb 3, 2011 8:52:09 PM org.apache.catalina.connector.TestMaxConnections$TestClient doHttp10Request INFO: ConnectThread[1] Request complete:1638 ms. Feb 3, 2011 8:52:09 PM org.apache.catalina.connector.TestMaxConnections$TestClient doHttp10Request INFO: ConnectThread[2] Request complete:1529 ms. Feb 3, 2011 8:52:09 PM org.apache.catalina.connector.TestMaxConnections$TestClient doHttp10Request INFO: ConnectThread[3] Request complete:1504 ms. Feb 3, 2011 8:52:10 PM org.apache.catalina.connector.TestMaxConnections$TestClient doHttp10Request INFO: ConnectThread[5] Request complete:2885 ms. Feb 3, 2011 8:52:10 PM org.apache.catalina.connector.TestMaxConnections$TestClient doHttp10Request INFO: ConnectThread[4] Request complete:2935 ms. Feb 3, 2011 8:52:10 PM org.apache.coyote.AbstractProtocolHandler pause INFO: Pausing ProtocolHandler [http-bio-8080] Feb 3, 2011 8:52:11 PM org.apache.catalina.core.StandardService stopInternal INFO: Stopping service Tomcat Feb 3, 2011 8:52:11 PM org.apache.coyote.AbstractProtocolHandler stop INFO: Stopping ProtocolHandler [http-bio-8080] Feb 3, 2011 8:52:11 PM org.apache.coyote.AbstractProtocolHandler destroy INFO: Destroying ProtocolHandler [http-bio-8080] - --- Testcase: testConnector took 6.867 sec FAILED The number of successful requests should have been 4-5, actual 6 junit.framework.AssertionFailedError: The number of successful requests should have been 4-5, actual 6 at org.apache.catalina.connector.TestMaxConnections.testConnector(TestMaxConnections.java:58) I expect the analysis I wrote when voting for 7.0.6 is still correct. Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 7.0.8
On 04.02.2011 14:52, Mark Thomas wrote: The proposed Apache Tomcat 7.0.8 release is now available for voting. It can be obtained from: http://people.apache.org/~markt/dev/tomcat-7/v7.0.8/ The svn tag is: http://svn.apache.org/repos/asf/tomcat/tc7.0.x/tags/TOMCAT_7_0_8/ The proposed 7.0.8 release is: [ ] Broken - do not release [ ] Alpha - go ahead and release as 7.0.8 Alpha [ ] Beta - go ahead and release as 7.0.8 Beta [X] Stable - go ahead and release as 7.0.8 Stable +1 just for the records, I saw that you are already proceeding. Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Tomcat 5.5.33 Build
On 07.02.2011 21:17, Jim Jagielski wrote: The builds for Tomcat 5.5.33 are ready for testing and approval. The candidates binaries are available here: http://people.apache.org/~jim/tomcat-5.5/ According to the release process, the 5.5.33 build corresponding to the tag TOMCAT_5_5_33 [1] is: [ ] Broken [ ] Alpha [ ] Beta [ ] Stable +++ 1. http://svn.apache.org/viewvc/tomcat/tc5.5.x/tags/TOMCAT_5_5_33/ version in build.properties.default wasn't updated (still 5.5.32), but the compiled properties file contains the right version 5.5.33. So I would say it's acceptable. I'm voting later, because tests still run. Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Tomcat 5.5.33 Build
On 07.02.2011 21:17, Jim Jagielski wrote: The builds for Tomcat 5.5.33 are ready for testing and approval. The candidates binaries are available here: http://people.apache.org/~jim/tomcat-5.5/ According to the release process, the 5.5.33 build corresponding to the tag TOMCAT_5_5_33 [1] is: [ ] Broken [ ] Alpha [ ] Beta [X] Stable +++ 1. http://svn.apache.org/viewvc/tomcat/tc5.5.x/tags/TOMCAT_5_5_33/ Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Tomcat 5.5.33 Build
On 07.02.2011 21:17, Jim Jagielski wrote: The builds for Tomcat 5.5.33 are ready for testing and approval. The candidates binaries are available here: http://people.apache.org/~jim/tomcat-5.5/ According to the release process, the 5.5.33 build corresponding to the tag TOMCAT_5_5_33 [1] is: [ ] Broken [ ] Alpha [ ] Beta [X] Stable +++ 1. http://svn.apache.org/viewvc/tomcat/tc5.5.x/tags/TOMCAT_5_5_33/ +1 for the new tarballs. Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Connection draining when upload to large
Servlet 3 standardizes file uploads. It contains the ability to limit on request size, pretty much the same as commons fileupload supported for many years. It seems when this conditions triggers the rest of the request inout stream is still drained at the end of the request. swallowInput is not being set to false. It seems there's still no server-side prevention against huge uploads possible. The upload is not put into memory, but the thread is only freed once the whole request body is read. Shouldn't Tomcat ignore the rest of data and close the connection in this case? Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Connection draining when upload to large
On 10.02.2011 18:00, Filip Hanik - Dev Lists wrote: On 2/10/2011 6:04 AM, Rainer Jung wrote: Servlet 3 standardizes file uploads. It contains the ability to limit on request size, pretty much the same as commons fileupload supported for many years. It seems when this conditions triggers the rest of the request inout stream is still drained at the end of the request. swallowInput is not being set to false. It seems there's still no server-side prevention against huge uploads possible. The upload is not put into memory, but the thread is only freed once the whole request body is read. Shouldn't Tomcat ignore the rest of data and close the connection in this case? standard soTimeout (read timeout) should apply. Meaning, if the client stops sending data, it should eventually result in an IOException and back out the thread. Right, but this is more about clients sending huge uploads you don't want to consume. There should be a clean way of signalling to the container, that the rest of the upload should be discarded in the sense of please do not read it and do no longer read from the connection (e.g. for Keep-Alive). Clients might not react well-behaved to that. E.g. if I change TC code a bit and allow it to close the connection instead of draining it before, then firefox will still try to upload, finally receive a few resets form the server and display an error message - even if the server send out a valid HTTP response before closing the reading side of the connection. So it won't actually help in transferring an abort message reliably to the client, but at least the containr thread would get freed more quickly. Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Connection draining when upload to large
On 10.02.2011 18:44, Mark Thomas wrote: On 10/02/2011 13:04, Rainer Jung wrote: Servlet 3 standardizes file uploads. It contains the ability to limit on request size, pretty much the same as commons fileupload supported for many years. It seems when this conditions triggers the rest of the request inout stream is still drained at the end of the request. swallowInput is not being set to false. It seems there's still no server-side prevention against huge uploads possible. The upload is not put into memory, but the thread is only freed once the whole request body is read. Shouldn't Tomcat ignore the rest of data and close the connection in this case? Yep. Because of Bill's remark about HTTP compliance and the result of my browser tests, I think the default behaviour at least for TC before 7 should stay as is. I implemented a simple patch for the TC 7 HTTP connectors using a custom request property to allow the application to signal to the container, that it should drop the connection and not drain it: http://people.apache.org/~rjung/patches/tomcat-trunk-upload-abort.patch Default: unchanged behaviour. Since there's no universally correct setting and the correct behaviour depends on the application use case a request attribute sounded OK. A connector configuration or system property doesn't sound right and a context configuration might be nasty to get pushed down to the connector code, though I didn't check that (although I could likely again use a request attribute to push the info down to the connector). I still need to experiment with the AJP connectors. It wasn't obvious from the impl how it handles the situation. Any hints about where to add stuff to the docs? Are people fine with making it controllable via the request attribute? Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Connection draining when upload to large
On 17.02.2011 11:58, Mark Thomas wrote: On 17/02/2011 10:41, Mark Thomas wrote: On 17/02/2011 10:30, Rainer Jung wrote: On 10.02.2011 18:44, Mark Thomas wrote: On 10/02/2011 13:04, Rainer Jung wrote: Servlet 3 standardizes file uploads. It contains the ability to limit on request size, pretty much the same as commons fileupload supported for many years. It seems when this conditions triggers the rest of the request inout stream is still drained at the end of the request. swallowInput is not being set to false. It seems there's still no server-side prevention against huge uploads possible. The upload is not put into memory, but the thread is only freed once the whole request body is read. Shouldn't Tomcat ignore the rest of data and close the connection in this case? Yep. Because of Bill's remark about HTTP compliance and the result of my browser tests, I think the default behaviour at least for TC before 7 should stay as is. I'd be happy to address the original issue and not swallow the input when a user attempts to upload too large a file. I also need to read through the HTTP spec and see what exactly we are breaking by not reading the entire input stream. Just read section 8.2 of RFC 2616. There are a fair number of SHOULDs in this section for both the client and the server. The requirement that server read all input and not close the connection (on the basis that the client will stop sending data when it receives an error status code) is SHOULD NOT rather than MUST NOT. Further, the spec explicitly allows the server to close the connection for DOS protection. Given this, I am leaning even more towards just fixing the original issue that the connection is not dropped when the request exceeds the upload limit and leaving the rest of the behaviour unchanged. Just one more data point: with Firefox the browser doesn't read the response from the connection if the server closes his side of the connection before reading all data. Firefox tries to proceed sending until the TCP/IP stack of the server starts responding with reset packets. A that time it is to late to read the response. If you read all data from the connection, then the browser will start reading the response and display it, even if the response was alread send much earlier. But nowadays uploads are more often handled by JavaScript or Flash etc. solutions running inside the browser which actually do not expect real answer. Closing the connection here results i an error status that the calling JavaScript code might be able to handle and reflect in the UI. Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Test suite failures for TC 7 (MBeanUtils, host null)
I get test suite failures for TC 7 right now. I'm not sure whether it is because I changed my testing environment, but the failure seems to be pretty special, namely a NullPointerException in MBeanUtils.createObjectName() line 532. I added some logging and the reason is, that the host returned by Container host = context.getParent(); is null. Feb 17, 2011 11:56:48 AM org.apache.catalina.deploy.NamingResources destroyInternal WARNING: namingResources.mbeanDestroyFail java.lang.NullPointerException at org.apache.catalina.mbeans.MBeanUtils.createObjectName(MBeanUtils.java:532) at org.apache.catalina.mbeans.MBeanUtils.destroyMBean(MBeanUtils.java:1154) at org.apache.catalina.deploy.NamingResources.destroyInternal(NamingResources.java:976) at org.apache.catalina.util.LifecycleBase.destroy(LifecycleBase.java:277) at org.apache.catalina.core.StandardContext.destroyInternal(StandardContext.java:5484) at org.apache.catalina.util.LifecycleBase.destroy(LifecycleBase.java:277) at org.apache.catalina.core.ContainerBase.removeChild(ContainerBase.java:969) at org.apache.catalina.core.ContainerBase.destroyInternal(ContainerBase.java:1108) at org.apache.catalina.util.LifecycleBase.destroy(LifecycleBase.java:277) at org.apache.catalina.core.ContainerBase.removeChild(ContainerBase.java:969) at org.apache.catalina.core.ContainerBase.destroyInternal(ContainerBase.java:1108) at org.apache.catalina.util.LifecycleBase.destroy(LifecycleBase.java:277) at org.apache.catalina.core.StandardService.destroyInternal(StandardService.java:593) at org.apache.catalina.util.LifecycleBase.destroy(LifecycleBase.java:277) at org.apache.catalina.core.StandardServer.destroyInternal(StandardServer.java:788) at org.apache.catalina.util.LifecycleBase.destroy(LifecycleBase.java:277) at org.apache.catalina.startup.Tomcat.destroy(Tomcat.java:323) The MBean name for the first failure is Catalina:type=Environment,resourcetype=Context,context=/examples,host=NULL,name=name3 (I replaced host.getName() with NULL when host is null) but there are many such failures during the test run. Not sure, but because it always seems to happen on destroy, it might be a lifecycle issue? Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Response.getWriter(), getOutputStream(), setContentLength() spec issues
On 25.02.2011 13:01, Mark Thomas wrote: So, the questions we need to decide: 1. Is the fix for bug 50748 correct? I think it is. +0 2. Should Tomcat try and handle this situation (e.g. if any bytes have been written by a filter, commit the response). This could be tricky to get right when forwards are involved and the response is meant to have been cleared. I'm leaning towards not doing this. TC should not try to handle it. 3. Is any filter that writes to the response without wrapping it so any calls to setContentLength() can be intercepted and adjusted as necessary broken? I think it is. It is. Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Connection draining when upload to large
On 17.02.2011 11:58, Mark Thomas wrote: Given this, I am leaning even more towards just fixing the original issue that the connection is not dropped when the request exceeds the upload limit and leaving the rest of the behaviour unchanged. Getting back to this (and sorry for the pause): What's the exact situation we want to skip swallowing the rest of the request and close the connection? - only if Servlet 3 Uploads reach their max POST size? - also if other uploads or more generally reading the request input is aborted? In the later case: how do we detect abort? Possibilities: - if the app called close() on the servlet input stream or the reader. This doesn't necessary indicate an abort. - if the app sets status 413 (request entity too large). Should be possible since it is unlikely that the response was already committed when the app detected that the reuest data is to big. - any other reliable mechanism? It's easy to make it configurable (e.g. connector attribute swallowAbortedUploads or swallowInput passed down to the processor the same way like disableUploadTimeout). Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 7.0.10
On 05.03.2011 15:32, Mark Thomas wrote: The proposed Apache Tomcat 7.0.10 release is now available for voting. It can be obtained from: http://people.apache.org/~markt/dev/tomcat-7/v7.0.10/ The svn tag is: http://svn.apache.org/repos/asf/tomcat/tc7.0.x/tags/TOMCAT_7_0_10/ The proposed 7.0.10 release is: [ ] Broken - do not release [ ] Alpha - go ahead and release as 7.0.10 Alpha [ ] Beta - go ahead and release as 7.0.10 Beta [X] Stable - go ahead and release as 7.0.10 Stable - MD5 OK - signatures OK - key in KEYS file - gz and zip for src and bin consistent - src consistent with svn tag - builds fine - build result looks consistent with binaries - no checkstyle complaints - Unit tests run OK except for one failure (TestMaxConnections, same as for 7.0.6 and 7.0.8). Tests have been run on Solaris 10 Sparc with 2 CPUs using Java 1.6.0_24. Remark: Two SSL tests fail when tested with older 1.6.0_17, likely because of missing secure reneg support in that JDK: [junit] Test org.apache.tomcat.util.net.TestClientCert FAILED [junit] Test org.apache.tomcat.util.net.TestSsl FAILED Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1078805 - in /tomcat/jk/trunk: native/apache-1.3/ native/apache-2.0/ native/common/ native/iis/ native/netscape/ xdocs/generic_howto/ xdocs/miscellaneous/ xdocs/reference/
On 07.03.2011 22:56, Konstantin Kolinko wrote: 2011/3/7rj...@apache.org: In jk_nsapi_plugin.c: --- tomcat/jk/trunk/native/iis/jk_isapi_plugin.c (original) +++ tomcat/jk/trunk/native/iis/jk_isapi_plugin.c Mon Mar 7 15:17:11 2011 @@ -3011,7 +3011,7 @@ static int init_ws_service(isapi_private GET_SERVER_VARIABLE_VALUE(REMOTE_USER, s-remote_user); GET_SERVER_VARIABLE_VALUE(SERVER_PROTOCOL, s-protocol); GET_SERVER_VARIABLE_VALUE(REMOTE_HOST, s-remote_host); -GET_SERVER_VARIABLE_VALUE(REMOTE_ADDR, s-remote_addr); +GET_SERVER_VARIABLE_VALUE(REMOTE_PORT, s-remote_port); GET_SERVER_VARIABLE_VALUE(SERVER_NAME, s-server_name); GET_SERVER_VARIABLE_VALUE_INT(SERVER_PORT, s-server_port, 80); GET_SERVER_VARIABLE_VALUE(SERVER_SOFTWARE, s-server_software); Was removal of REMOTE_ADDR line above intentional? Oups, no. Fixed in r1078987. Thanks for your review. Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1079444 - in /tomcat/trunk: java/org/apache/catalina/ java/org/apache/catalina/connector/ java/org/apache/catalina/core/ java/org/apache/coyote/ java/org/apache/coyote/ajp/ java/org/
On 08.03.2011 22:09, sebb wrote: On 8 March 2011 17:18,rj...@apache.org wrote: Author: rjung Date: Tue Mar 8 17:18:16 2011 New Revision: 1079444 URL: http://svn.apache.org/viewvc?rev=1079444view=rev Log: New context attribute swallowAbortedUploads allows to make request data swallowing configurable for requests that are too large. ... --- tomcat/trunk/java/org/apache/catalina/core/StandardContext.java (original) +++ tomcat/trunk/java/org/apache/catalina/core/StandardContext.java Tue Mar 8 17:18:16 2011 @@ -197,6 +197,12 @@ public class StandardContext extends Con protected boolean allowCasualMultipartParsing = false; /** + * Control whether remaining request data will be read + * (swallowed) even if the request violates a data size constraint. + */ +public boolean swallowAbortedUploads = true; This should surely be private - there are public [gs]etters already. Sure, fixed in r1079584, thanks. Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1079444 - in /tomcat/trunk: java/org/apache/catalina/ java/org/apache/catalina/connector/ java/org/apache/catalina/core/ java/org/apache/coyote/ java/org/apache/coyote/ajp/ java/org/
On 08.03.2011 23:37, Mark Thomas wrote:
On 08/03/2011 17:18, rj...@apache.org wrote:
snip/
Modified: tomcat/trunk/java/org/apache/catalina/connector/Request.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/connector/Request.java?rev=1079444r1=1079443r2=1079444view=diff
==
--- tomcat/trunk/java/org/apache/catalina/connector/Request.java (original)
+++ tomcat/trunk/java/org/apache/catalina/connector/Request.java Tue Mar 8
17:18:16 2011
snip/
@@ -2450,6 +2453,16 @@ public class Request
return (inputBuffer.available() 0);
}
+/**
+ * Disable swallowing of remaining input if configured
+ */
+protected void disableSwallowInput() {
+Context context = getContext();
+if (context != null !context.getSwallowAbortedUploads()) {
+coyoteRequest.action(ActionCode.DISABLE_SWALLOW_INPUT, null);
+}
+}
+
snip/
This method name confused me the first time I read the code.
checkSwallowInput() might be a better name
Done in r1079665.
Rainer
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Some remarks and observations from implementing disable swallowAbortedUploads
Hi all, some things I noticed while implementing the new switch: - o.a.c.connector.Request and Response hav methods finishRequest() resp. finishResponse(). The mehod in the request seems not to be called. Although that's not a big issue, because the omplementation is empty, one would run into trouble when starting to add code to it (at least I wondered why it wasn't working) - Should we keep the swallow default in TC 7 (default is do swallow, i.e. read all of the remaining bytes, thereby keeping the thread busy for a possibly long time but also keeping browsers happy which will otherwise most likely not read the response). I'd say keep swallowing but had the impression that Mark is more concerned about it and prefers the do not swallow default. - Domain and path of the session cookie are listed in config/context.xml as configurable per context. The name is not listed, although the setter is there and the value is respected in ApplicationSessionCookieConfig. Is this an oversight? Should I add the name to the context parameter list in the docs? Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Some remarks and observations from implementing disable swallowAbortedUploads
On 09.03.2011 14:46, Mark Thomas wrote: On 09/03/2011 05:41, Rainer Jung wrote: Hi all, some things I noticed while implementing the new switch: - o.a.c.connector.Request and Response hav methods finishRequest() resp. finishResponse(). The mehod in the request seems not to be called. Although that's not a big issue, because the omplementation is empty, one would run into trouble when starting to add code to it (at least I wondered why it wasn't working) That looks like an oversight. Any idea about a good place from where to call? finishResponse is called from CoyoteAdapter and CometEventImpl. At least we could call request.finishRequest() form inside response.finishResponse(). - Should we keep the swallow default in TC 7 (default is do swallow, i.e. read all of the remaining bytes, thereby keeping the thread busy for a possibly long time but also keeping browsers happy which will otherwise most likely not read the response). I'd say keep swallowing but had the impression that Mark is more concerned about it and prefers the do not swallow default. I thought the default was do not swallow. The important thing is that this patch doesn't change the default. Terminology: AbstractInputBuffer has a flag called swallowInput, which is true by default. True means: read additional data after the end of the response (drain the connection). This default is not changed. Our new config item is called swallowAbortedUploads, again default is true, i.e. drain the connection until no more data. Unchanged from before the patch. From a performance point of view, I think do not swallow and close the connection is the right thing to do. OK, so that's something the admin or dev has to enable explicitely via the config. - Domain and path of the session cookie are listed in config/context.xml as configurable per context. The name is not listed, although the setter is there and the value is respected in ApplicationSessionCookieConfig. Is this an oversight? Should I add the name to the context parameter list in the docs? Yep, that is an oversight. If you could add it that would be great. Will do. Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 7.0.11
On 10.03.2011 13:03, Mark Thomas wrote: The proposed Apache Tomcat 7.0.11 release is now available for voting. It can be obtained from: http://people.apache.org/~markt/dev/tomcat-7/v7.0.11/ The svn tag is: http://svn.apache.org/repos/asf/tomcat/tc7.0.x/tags/TOMCAT_7_0_11/ The proposed 7.0.11 release is: [ ] Broken - do not release [ ] Alpha - go ahead and release as 7.0.11 Alpha [ ] Beta - go ahead and release as 7.0.11 Beta [X] Stable - go ahead and release as 7.0.11 Stable - MD5 OK - signatures OK - key in KEYS file - gz and zip for src and bin consistent - src consistent with svn tag - builds fine - build result looks consistent with binaries - no checkstyle complaints - Unit tests run OK for BIO and NIO using Java 1.6.0_24 (yes, all of them) Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [GUMP@vmgump]: Project tomcat-trunk-test (in module tomcat-trunk) failed
On 02.04.2011 01:20, Konstantin Kolinko wrote: 2011/4/1 Konstantin Kolinkoknst.koli...@gmail.com: In the recent run: [junit] Apr 1, 2011 9:53:27 PM org.apache.catalina.util.SessionIdGenerator createSecureRandom [junit] INFO: Creation of SecureRandom instance fo [junit] r session ID generation using [SHA1PRNG] took [69,367] milliseconds. and so on in the next runs. That explains the slowness. It is good that we have this logging now. I know there was some related discussion on the users list, but just in case it didn't become clear from that. There is a bug in the Oracle JVM. Initialization of random number generation on Linux can block for a long time, because even if configured for using /dev/urandom it will use /dev/random. 1.6.0_24 even seems to be preconfigured for using /dev/urandom on Linux, but it dows not work due to an implementation bug. Workaround: You can still use the system property java.security.egd to switch to /dev/urandom, but you have to use a value that is semantically equivalent to /dev/urandom but not stringwise identical. So instead of the value proposed usually: -Djava.security.egd=file:/dev/urandom You can use -Djava.security.egd=file:/dev//urandom or -Djava.security.egd=file:/dev/./urandom Looking at the JVM sources one can see the reason. On Linux, when configuring exactly for /dev/random or /dev/urandom, the JVM prefers to use a so-called native random number generator. It initializes the native generator with the default constructor, that always uses /dev/random. When switching from file:/dev/urandom to something equivalent but not identical, you finally get what you were looking for. Oracle thinks it is not a bug, but from the bug report comments it seems they haven’t actually looked at their code and are still only arguing about /dev/urandom not being secure. Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 7.0.12
On 01.04.2011 20:09, Mark Thomas wrote: The proposed Apache Tomcat 7.0.12 release is now available for voting. It can be obtained from: http://people.apache.org/~markt/dev/tomcat-7/v7.0.12/ The svn tag is: http://svn.apache.org/repos/asf/tomcat/tc7.0.x/tags/TOMCAT_7_0_12/ The proposed 7.0.12 release is: [ ] Broken - do not release [ ] Alpha - go ahead and release as 7.0.12 Alpha [ ] Beta - go ahead and release as 7.0.12 Beta [X] Stable - go ahead and release as 7.0.12 Stable Cheers, Mark - MD5 OK - signatures OK - key in KEYS file - gz and zip for src and bin consistent - src consistent with svn tag - builds fine - build result looks consistent with binaries - no checkstyle complaints - only one Javadoc error, already fixe in trunk - Unit tests run OK for BIO, NIO and APR (0ne failure for APR) using Java 1.6.0_24 (yes, all of them) Concerning the APR failure: INFO: Failures in output/build/logs/TEST-org.apache.tomcat.util.net.TestXxxEndpoint.APR.txt WARN: Test failure in 'output/build/logs/TEST-org.apache.tomcat.util.net.TestXxxEndpoint.APR.txt': Testsuite: org.apache.tomcat.util.net.TestXxxEndpoint Tests run: 2, Failures: 1, Errors: 0, Time elapsed: 9.327 sec Failure only happens with APR (but only tried once). Detailed Result is: Testcase: testStartStopBindOnInit took 6.235 sec FAILED null junit.framework.AssertionFailedError at org.apache.tomcat.util.net.TestXxxEndpoint.testStartStopBindOnInit(TestXxxEndpoint.java:57) Testcase: testStartStopBindOnStart took 3.08 sec Additional log output: Apr 3, 2011 5:00:48 PM org.apache.catalina.core.AprLifecycleListener init INFO: Loaded APR based Apache Tomcat Native library 1.1.20. Apr 3, 2011 5:00:48 PM org.apache.catalina.core.AprLifecycleListener init INFO: APR capabilities: IPv6 [true], sendfile [true], accept filters [false], random [true]. Apr 3, 2011 5:00:51 PM org.apache.coyote.AbstractProtocolHandler init INFO: Initializing ProtocolHandler [http-apr-8001] Apr 3, 2011 5:00:51 PM org.apache.catalina.core.StandardService startInternal INFO: Starting service Tomcat Apr 3, 2011 5:00:51 PM org.apache.catalina.core.StandardEngine startInternal INFO: Starting Servlet Engine: Apache Tomcat/7.0.12 Apr 3, 2011 5:00:51 PM org.apache.catalina.startup.ContextConfig webConfig INFO: No global web.xml found Apr 3, 2011 5:00:53 PM org.apache.catalina.core.ApplicationContext log INFO: ContextListener: contextInitialized() Apr 3, 2011 5:00:53 PM org.apache.catalina.core.ApplicationContext log INFO: SessionListener: contextInitialized() Apr 3, 2011 5:00:53 PM org.apache.catalina.util.SessionIdGenerator createSecureRandom INFO: Creation of SecureRandom instance for session ID generation using [SHA1PRNG] took [146] milliseconds. Apr 3, 2011 5:00:53 PM org.apache.coyote.AbstractProtocolHandler start INFO: Starting ProtocolHandler [http-apr-8001] Apr 3, 2011 5:00:53 PM org.apache.coyote.AbstractProtocolHandler stop INFO: Stopping ProtocolHandler [http-apr-8001] Apr 3, 2011 5:00:54 PM org.apache.coyote.AbstractProtocolHandler pause INFO: Pausing ProtocolHandler [http-apr-8001] Apr 3, 2011 5:00:54 PM org.apache.catalina.core.StandardService stopInternal INFO: Stopping service Tomcat Apr 3, 2011 5:00:54 PM org.apache.catalina.core.ApplicationContext log INFO: SessionListener: contextDestroyed() Apr 3, 2011 5:00:54 PM org.apache.catalina.core.ApplicationContext log INFO: ContextListener: contextDestroyed() Apr 3, 2011 5:00:54 PM org.apache.coyote.AbstractProtocolHandler destroy INFO: Destroying ProtocolHandler [http-apr-8001] Apr 3, 2011 5:00:54 PM org.apache.catalina.core.AprLifecycleListener init INFO: Loaded APR based Apache Tomcat Native library 1.1.20. Apr 3, 2011 5:00:54 PM org.apache.catalina.core.AprLifecycleListener init INFO: APR capabilities: IPv6 [true], sendfile [true], accept filters [false], random [true]. Apr 3, 2011 5:00:54 PM org.apache.coyote.AbstractProtocolHandler init INFO: Initializing ProtocolHandler [http-apr-8002] Apr 3, 2011 5:00:54 PM org.apache.catalina.core.StandardService startInternal INFO: Starting service Tomcat Apr 3, 2011 5:00:54 PM org.apache.catalina.core.StandardEngine startInternal INFO: Starting Servlet Engine: Apache Tomcat/7.0.12 Apr 3, 2011 5:00:54 PM org.apache.catalina.startup.ContextConfig webConfig INFO: No global web.xml found Apr 3, 2011 5:00:55 PM org.apache.catalina.core.ApplicationContext log INFO: ContextListener: contextInitialized() Apr 3, 2011 5:00:55 PM org.apache.catalina.core.ApplicationContext log INFO: SessionListener: contextInitialized() Apr 3, 2011 5:00:55 PM org.apache.coyote.AbstractProtocolHandler start INFO: Starting ProtocolHandler [http-apr-8002] Apr 3, 2011 5:00:55 PM org.apache.coyote.AbstractProtocolHandler stop INFO: Stopping ProtocolHandler [http-apr-8002] Apr 3, 2011 5:00:56 PM org.apache.coyote.AbstractProtocolHandler start INFO: Starting ProtocolHandler [http-apr-8002] Apr 3, 2011 5:00:56 PM org.apache.coyote.AbstractProtocolHandler pause INFO:
Re: [GUMP@vmgump]: Project tomcat-trunk-test (in module tomcat-trunk) failed
On 04.04.2011 11:34, Stefan Bodewig wrote: On 2011-04-03, Rainer Jung wrote: On 02.04.2011 01:20, Konstantin Kolinko wrote: 2011/4/1 Konstantin Kolinkoknst.koli...@gmail.com: In the recent run: [junit] Apr 1, 2011 9:53:27 PM org.apache.catalina.util.SessionIdGenerator createSecureRandom [junit] INFO: Creation of SecureRandom instance fo [junit] r session ID generation using [SHA1PRNG] took [69,367] milliseconds. and so on in the next runs. That explains the slowness. It is good that we have this logging now. I know there was some related discussion on the users list, but just in case it didn't become clear from that. There is a bug in the Oracle JVM. Initialization of random number generation on Linux can block for a long time, because even if configured for using /dev/urandom it will use /dev/random. 1.6.0_24 even seems to be preconfigured for using /dev/urandom on Linux, but it dows not work due to an implementation bug. vmgump is on 6b20 and I don't think there is anything more recent available for Ubuntu 10.4 (unless we fiddle with package sources, I guess). Sorry, I didn't want to indicate it is a 1.6.0_24 problem only. It's just that I checked the default only for 1.6.0_24. The issue is open at Oracle for a longer. But you seem to be correct this is a Linux issue. On FreeBSD[1] I see 140 ms. It is also not strictly reproducable in the sense that fst startup means you don't have the problem. You can check via open files or similar, if /dev/random or /dev/urandom is being used. Even when /dev/random is used due t the bug, sometimes there is enough entropy, sometimes not. I usually run into the problem when trying to start two instances in parallel. One starts up fast, the other blocks. Workaround: You can still use the system property java.security.egd to switch to /dev/urandom, but you have to use a value that is semantically equivalent to /dev/urandom but not stringwise identical. You can set system properties viasysproperty inside the Gump descriptor and if you use sysproperty name=ant.build.clonevm value=true/ Ant will make sure any system property will be passed to a new Java VM that is forked as well[2] (as long as forking uses Ant's mechanisms, that is). Good thing. Konstantin already added a jvmarg to our local build.xml, I guess it will work in Gump but also when testing standalone. It might be a nice default setting for the ASF gump, because more projects might run into the same unpleasant issue. Stefan [1] http://gump.zones.apache.org/gump/public/tomcat-trunk/tomcat-trunk-test/gump_work/build_tomcat-trunk_tomcat-trunk-test.txt [2] http://ant.apache.org/manual/clonevm.html Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: anyone using git-svn for tomcat ?
On 07.04.2011 22:35, Sylvain Laurent wrote: Hello, I'm trying out git at the moment and found this page http://wiki.apache.org/general/GitAtApache Is anyone here using git in front of svn ? any problem, advice ? I used it some time for the httpd sources. I like that it is easy to transfer commits from the local repos to the ASF svn including commit log entry. The patch format is also nice. git-svn uses the svn perl bindings which produce crashes every now and then, at least on my system. I didn't have any situation where the crash left over inconsistent files or incomplete transactions. The crashes happen during process cleanup. Overall I liked it. Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: New connector sandbox
On 11.04.2011 11:34, Mladen Turk wrote: On 04/11/2011 09:00 AM, Konstantin Kolinko wrote: 2011/4/11 Mladen Turkmt...@apache.org: Hi, I plan to create a sandbox/connectors/native/iis7 for a native IIS7 C++ connector (since Microsoft deprecated ISAPI) Any objections? I do not mind. Though 1) Do you need those immediate levels? Will there be anything in them? Yes. Java part of the connector. IIS7 offers much more then just passing http requests. I guess the code will go into https://svn.apache.org/viewvc/tomcat/jk/trunk/native/iis7/ when it becomes mature? Not sure. Httpd has mod_proxy_http/mod_proxy_ajp. Having a full (without normalizing functionality) IIS connector would cover MS world. Other servers are irrelevant IMHO (we only had former SunOne supported which is now named Oracle something ...) IMHO mod_jk has reached state where any further functionality improvement is limited by the protocol, and since there is no desire/need to invent a new protocol, and since initial mod_jk premise (runs in any web server) makes no sense in today's real world, mixing that with jk connectors makes no sense as well. Idea is to make a simple and robust connector that will work well inside IIS7 and allow .NET interoperability, working both standalone and probably inside Windows Azure. +1, but maybe as Konstantin noted just a simple top-level sandbox name like iis7 or connector-iis7 is enough. You can create any needed structure underneath. I think there's no real need to group sandboxes. Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: New connector sandbox
On 27.04.2011 08:53, Henri Gomez wrote: Now that HTTP connector is as fast as AJP connector, is it still required ? Performance isn't a reasion for AJP in the last say 5 or more years. The major benefits of AJP are - smooth integration of a reverse proxy The connector patches the communication data of the web server into the webapp environment, i.e. client IP, protocol, server IP etc. - connection pooling including checking via cping/cpong Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
MIME type additions
We recently had some mime type additions, and the new BZ 51137 asks for more. I did some checking between the mime type file of httpd 2.3 latest and TC. There are about 600 more mime types in the httpd file, some of them with more than one suffix. Some entries are inconsistent between the two files, but not many. Below I will list the changes. I don't know whether it is a good idea to grow web.xml that much, but if people think it is useful, I can make our trunk web.xml mime types consistent with the one from httpd. We should expliciteley discuss the inconsistencies given at the start of the below list though. For reference: the official mime type list for registered types is at http://www.iana.org/assignments/media-types/index.html. 1) Mime types defined for suffixes which do not exist in httpd land: IANA registered (so we should keep them): application/mac-binhex40 hqx Not IANA registered, or suffix not contained in RFC but I suggest we keep them for compatibility reasons: application/annodex anx application/x-aim aim application/x-compress z application/x-compress Z application/x-gzip gz audio/annodex axa audio/basic ulw audio/flac flac audio/mp4 m4a audio/mp4 m4b audio/mp4 m4r audio/x-mpeg abs audio/x-mpeg mpega image/bmp dib image/pict pict image/x-jg art image/x-macpaint mac image/x-macpaint pnt image/x-quicktime qti image/x-quicktime qtif text/html body text/plain jsf text/plain jspf text/x-component htc text/x-server-parsed-html shtml video/annodex axv video/mpeg2 mpv2 video/x-dv dv video/x-rad-screenplay avx OK to keep all of them? 2) Wrong suffix TC:application/vnd.oasis.opendocument.text-master odm HTTPD: application/vnd.oasis.opendocument.text-master otm Here TC seems to be right, I'll check and fix httpd. TC:application/vnd.wap.wmlscriptc wmlscriptc HTTPD: application/vnd.wap.wmlscriptc wmlsc httpd seems right, we should fix TC. OK? 3) Inconsistent mime type between TC and httpd I suggest to take the definition from httpd because it is officially registered and seems unambiguous: TC:application/x-visio vsd HTTPD: application/vnd.visio vsd vst vss vsw TC:application/x-x509-ca-cert cer HTTPD: application/pkix-cert cer TC:audio/x-midi smf HTTPD: application/vnd.stardivision.math smf TC:audio/x-mpeg mp2 TC:audio/x-mpeg mp3 TC:audio/x-mpeg mpa HTTPD: audio/mpeg mpga mp2 mp2a mp3 m2a m3a TC:image/x-photoshop psd HTTPD: image/vnd.adobe.photoshop psd TC:x-world/x-vrml wrl HTTPD: model/vrml wrl vrml I suggest to take the definition from httpd because it seems better although it is more probably arguable: TC:application/x-troff roff TC:application/x-troff t TC:application/x-troff tr TC:application/x-troff-man man TC:application/x-troff-me me TC:application/x-wais-source ms HTTPD: text/troff t tr roff man me ms TC:audio/x-midi kar TC:audio/x-midi mid TC:audio/x-midi midi HTTPD: audio/midi mid midi kar rmi TC:text/javascript js HTTPD: application/javascript js TC:text/plain java HTTPD: text/x-java-source java I suggest we keep our definition, because there seems to be no clear favorite: TC:application/java class HTTPD: application/java-vm class TC:application/octet-stream exe HTTPD: application/x-msdownload exe dll com bat msi (add dll,...,msi like httpd) TC:application/x-cdf cdf TC:application/x-netcdf nc HTTPD: application/x-netcdf nc cdf TC:application/x-mif mif HTTPD: application/vnd.mif mif TC:audio/x-scpls pls HTTPD: application/pls+xml pls TC:image/pict pct TC:image/pict pic HTTPD: image/x-pict pic pct TC:video/mp4 m4v HTTPD: video/x-m4v m4v Other cases: TC:audio/x-mpeg mp1 HTTPD: missing I think this should be audio/mpeg, because IANA links to RFC http://www.rfc-editor.org/rfc/rfc3003.txt for audio/mpeg and the suffix mp1 is an example there. OK? 4) Mime types already defined, but httpd contains more suffixes I suggest we add the missing suffices for TC. # Same def but additional suffs TC:application/msword doc HTTPD: application/msword doc dot TC:application/octet-stream bin HTTPD: application/octet-stream bin dms lha lrf lzh so iso dmg dist distz pkg bpk dump elc deploy TC:application/vnd.ms-excel xls HTTPD: application/vnd.ms-excel xls xlm xla xlc xlt xlw TC:application/vnd.ms-powerpoint ppt pps HTTPD: application/vnd.ms-powerpoint ppt pps pot TC:text/plain txt HTTPD: text/plain txt text conf def list log in TC:video/mp4 mp4 HTTPD: video/mp4 mp4 mp4v mpg4 TC:video/mpeg mpeg mpg mpe HTTPD: video/mpeg mpeg mpg mpe m1v m2v 5) Long list of additional entries in httpd Should we add them (about 600 entries) as is? E.g. all of BZ 51137 are included here. Do we care about the order of the entries (alphabetic or some performance relevant ordering)? application/andrew-inset ez application/applixware aw application/atom+xml atom application/atomcat+xml atomcat
Re: BIO performance issues
I hope the following is not too long and confusing ... On 03.05.2011 22:02, Mark Thomas wrote: Scenario This ended up being very long, so I moved it to the end. The exact pattern of delays will vary depending on timeouts, request frequency etc. but the scenario shows an example of how delays can occur. The short version is that requests with data to process (particularly new connections) tend to get delayed in the queue waiting for a thread to process them when the threads are all tied up processing keep-alive connections. Root cause -- The underlying cause of all of the performance issues observed is when the threads are tied up doing HTTP keep-alive when there is no data process but there are other connections in the queue that do have data that could be processed. Solution A -- NIO is designed to handle this using a poller. That isn't available to BIO so I attempted to simulate it. That generated excessive CPU load so I do not think simulated polling is the tight solution. I expect generating the SocketTimeoutException is expensive, because the JVM has to generate the stack information. The rate of the Exception when handling mostly keep-alive (extreme case) is your poll timeout times the number of threads, e.g. 100ms timeout times 200 threads is 2000 exceptions per second. Even if there is another reason for the high CPU load, I expect it to be roughly proportional to the poll rate. In a saturated system with lots of keep-alive you will have: pollRate = 1 / pollTimeout * maxThreads (e.g. 1 / 0.1s * 200 = 2000/s) averageWaitBeforePoll = maxConnection / pollRate / 2 (e.g. 1 / 2000 / 2 / s = 1.5s) So we see, that in your case though we already have a high poll event rate, we end up with every connection only being polled every 2.5 seconds, which is too much of request latency. If we want to reduce this latency, we would need to increse the rate. But then CPU gets even worse. Or we need to reduce maxConnections. Let us try a different sizing: maxThreads 200 , maxConnections 1000 (less overcommitment, but still very different from 200), pollTimeout 200ms. rate = 1000, half of the previous rate due to the doubled timeout. averageWaitBeforePoll = 0.5 seconds. Although this is an improvement, we still have a high poll rate and even 0.5 seconds average wait time for new connections isn't nice. The tradeoff is: To be CPU effective, we have to reduce the poll rate. Assuming a fixed thread and connection count, this automatically leads to longer averageWaitBeforePoll, i.e. request latency. There seems to be no sweet spot for sizing the system. If we do not find an efficient way (in terms of CPU and blocking time of threads) to handle the keep-alive connections, then I don't expect a solution to the problem - except for disabling keep-alive or not accepting much more connections than we have threads. At the end that's the 75% threads busy then disable keep-alive solution. One could throw in some reduce keep-alive timeout under load feature, but I doubt it will help much more than the simply solution. Do we see a cpu time and thread blocking time efficient way of handling many keep-alive connections? I don't see any API, that would help here. Of course one could try to build a hyprid blocking for normal processing but non-blocking for keep-alive thing, but since we already have NIO I would also support recommending NIO for keep-alive. Switching the default from BIO to NIO is a big change, but only after we switch will we find the last buglets and problems arising under rare conditions. So if we want to switch, we should do it very soon. Doing it late in the TC 7 cycle would be bad. Lastly: APR uses server to server connections, as does HTTP when using a reverse proxy in front of Tomcat. In those cases we have much fewer connections with a higher rate of requests per connection. There maxThreads == maxConnections is fine (and even the 75% rule could be switched off). So for this scenario it would be nice to not drop BIO, at least until the major TC version after the default switched to NIO. Solution B -- Return to the Tomcat 6 implementation where maxConnections == maxThreads. Additional clean-up --- maxConnections is unnecessary in APR since pollerSize performs the same function. Summary --- The proposed changes are: a) restore disabling keep-alive when threads used= 75% of maxThreads b) remove maxConnections and associated code from the APR connector c) remove the configuration options for maxConnections from the BIO connector d) use maxThreads instead of maxConnections for the BIO connector e) update the docs I agree (especially after your additional clarifications in reply to Konstantin). Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 7.0.13
On 06.05.2011 17:37, Mark Thomas wrote: The proposed Apache Tomcat 7.0.13 release is now available for voting. It can be obtained from: http://people.apache.org/~markt/dev/tomcat-7/v7.0.13/ The svn tag is: http://svn.apache.org/repos/asf/tomcat/tc7.0.x/tags/TOMCAT_7_0_13/ The proposed 7.0.13 release is: [ ] Broken - do not release [ ] Alpha - go ahead and release as 7.0.13 Alpha [ ] Beta - go ahead and release as 7.0.13 Beta [X] Stable - go ahead and release as 7.0.13 Stable - MD5 OK - signatures OK - key in KEYS file - gz and zip for src and bin consistent - src consistent with svn tag Minor point: suffix .pl was missing from text.files, so the new mime types perl script checked in by me a few days ago has wrong line ends in the src tarballs. Not a show stopper, fixed in r1100522. - builds fine - build result looks consistent with binaries - no checkstyle complaints - no Javadoc errors - Unit tests run OK for BIO, NIO and APR 0ne failure for APR, not a regression. - *not* tested with TCK (I need to automate TCK testing) Build and tests were done using Java 1.6.0_24, OS was Solaris 10 Sparc. Concerning the APR failure: it is the same as for 7.0.12. Details from my 7.0.12 mail: It seems when using APR the connector binds to IPV6 and the Java based ServerSocket used to test whether the port is still taken binds to IPV4 - at least on my Solaris 10 Sparc System. So indeed both can bind at the same time, even when I do not stop the connector at all. To make the test valid I guess it had to bind to the socket using the same API as the connector (e.g. using the APR libs in the APR test case). If I try that, e.g. copying Socket setup from APREndpoint to the test class instead of using plain Java ServerSocket and bind to ::, then the test passes. Again, binding using the APR code to 0.0.0.0 the test fails, i.e. binding suceeds. The test works for the other two connectors and I could also verify that there was still a listen in netstat after stopping the connector in the case where an additional bind should have thrown an exception. So behaviour of the new config attribute bindOnInit seems OK. Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1099032 - in /tomcat/trunk/res/scripts: ./ check-mime.pl
Hi Felix,
TMTOWTDI. For standalone scripts I don't care very much about style.
Let's see below ...
On 08.05.2011 13:17, Felix Schumacher wrote:
Hi Rainer,
Am Dienstag, den 03.05.2011, 12:12 + schrieb rj...@apache.org:
Author: rjung
Date: Tue May 3 12:12:35 2011
New Revision: 1099032
URL: http://svn.apache.org/viewvc?rev=1099032view=rev
Log:
Add a script to check web.xml and httpd mime.types
for differences.
Added:
tomcat/trunk/res/scripts/
tomcat/trunk/res/scripts/check-mime.pl (with props)
Added: tomcat/trunk/res/scripts/check-mime.pl
URL:
http://svn.apache.org/viewvc/tomcat/trunk/res/scripts/check-mime.pl?rev=1099032view=auto
==
--- tomcat/trunk/res/scripts/check-mime.pl (added)
+++ tomcat/trunk/res/scripts/check-mime.pl Tue May 3 12:12:35 2011
@@ -0,0 +1,410 @@
+#!/usr/bin/perl
+
...
+# Script version, printed via getopts with --version
+$main::VERSION = '1.0';
Any reason for not using 'our' like
our $VERSION = '1.0'; ?
Done.
+
...
+
+# Parse arguments:
+# -m: mime.types file (httpd) to use
+# -i: input web.xml file to check
+# -o: output web.xml file (gets generated and overwritten)
+
+$Getopt::Std::STANDARD_HELP_VERSION = 1;
+our($opt_m, $opt_i, $opt_o);
Why should those options be visible by everyone outside this package?
'my' should be enough:
my ($opt_m, $opt_i, $opt_o);
Doesn't work. Seems getopts needs our.
+getopts('m:i:o:');
+
+
+# Check whether mandatory arguments are given
+if ($opt_m eq '' || $opt_i eq '' || $opt_o eq '') {
+HELP_MESSAGE(*STDOUT);
+exit 1;
+}
+
+
+# Switch locale for alphabetical ordering
+setlocale(LC_COLLATE, $LOCALE);
+
+# Read and parse httpd mime.types, build up hash extension-mime-type
+open(MIMETYPES, $opt_m) or die Could not open file '$opt_m' for read -
Aborting!;
You could use three param open and use lexical filehandles like
open my $mimetpyes_fh, '', $opt_m or die ...;
DONE
+while (MIMETYPES) {
+chomp($_);
+$line = $_;
while (my $line =$mimetypes_fh) {
chomp($line);
Keep as is, because I used the original line in the below WARN message.
+$line =~ s/#.*//;
+$line =~ s/^\s+//;
+if ($line ne '') {
+@cols = split(/\s+/, $line);
+if ($#cols 0) {
+for ($i=1; $i= $#cols; $i++) {
+$httpd{$cols[$i]} = $cols[0];
+}
+} else {
+print STDERR WARN mime.types line ignored: $_\n;
+}
+}
+}
+close(MIMETYPES);
($mimetype, @endings) = split(/\s+/, $line);
if (@endings 0) {
for my $ending (@endings) {
$httpd{$ending} = $mimetype;
}
} else {
print STDERR WARN mime.types line ignored: $_\n;
}
close $mimetypes_fh;
would be possible also.
DONE
+
+# Read and parse web.xml, build up hash extension-mime-type
+# and store the file parts form before and after mime mappings.
+open(WEBXML, $opt_i) or die Could not open file '$opt_i' for read -
Aborting!;
three-params open could be used again.
+
+# Skip and record all lines before the first mime type definition.
+# Because of comment handling we need to read one line ahead.
+$line = '';
+while (WEBXML) {
+if ($_ !~ /mime-mapping/) {
+$tomcat_pre .= $line;
+} else {
+last;
+}
+$line = $_;
+}
+
+$commented = 0;
+# If the previous line was start of a comment
+# set marker, else add it to pre.
+if ($line =~ /^\s*!--[^]*$/) {
+$commented = 1;
+} else {
+$tomcat_pre .= $line;
+}
+
+# Now we parse blocks of the form:
+#mime-mapping
+#extensionabs/extension
+#mime-typeaudio/x-mpeg/mime-type
+#/mime-mapping
+# Optional single comment lines directly after mime-mapping
+# are allowed. The whole block is also allowed to be commented out.
+
+while ($_ =~ /^\s*mime-mapping\s*$/) {
+$_ =WEBXML;
+chomp($_);
+$comment = '';
+if ($_ =~ /^\s*!--([^]*)--\s*$/) {
+$comment = $1;
+$_ =WEBXML;
+chomp($_);
+}
+if ($_ =~ /^\s*extension([^]*)\/extension\s*$/ ) {
+$extension = $1;
+$extension =~ s/^\s+//;
+$extension =~ s/\s+$//;
+} else {
+print STDERR ERROR Parse error in Tomcat mime-mapping line $.\n;
+print STDERR ERROR Expectedextension.../extension', got '$_' -
Aborting!\n;
+close(WEBXML);
+exit 2;
+}
+$_ =WEBXML;
+chomp($_);
+if ($_ =~ /^\s*mime-type([^]*)\/mime-type\s*$/ ) {
+$type = $1;
+$type =~ s/^\s+//;
+$type =~ s/\s+$//;
+if (exists($tomcat{$extension}) $tomcat{$extension} ne $type) {
+print STDERR WARN MIME mapping redefinition detected!\n;
+print STDERR WARN Kept '$extension' - '$tomcat{$extension}'\n;
+print STDERR WARN Ignored '$extension' - '$type'\n;
+} else {
+$tomcat{$extension} = $type;
+if ($comment ne '') {
+$tomcat_comments{$extension} = $comment;
+}
+if
Re: [VOTE] Release Apache Tomcat 7.0.14
On 10.05.2011 01:31, Mark Thomas wrote: The proposed Apache Tomcat 7.0.14 release is now available for voting. It can be obtained from: http://people.apache.org/~markt/dev/tomcat-7/v7.0.14/ The svn tag is: http://svn.apache.org/repos/asf/tomcat/tc7.0.x/tags/TOMCAT_7_0_14/ The proposed 7.0.14 release is: [ ] Broken - do not release [ ] Alpha - go ahead and release as 7.0.14 Alpha [ ] Beta - go ahead and release as 7.0.14 Beta [ ] Stable - go ahead and release as 7.0.14 Stable Can you please add the file bin/apache-tomcat-7.0.14-windows-x64.zip.asc It is missing. Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 7.0.14
On 10.05.2011 20:11, Mark Thomas wrote: On 10/05/2011 18:46, Rainer Jung wrote: On 10.05.2011 01:31, Mark Thomas wrote: The proposed Apache Tomcat 7.0.14 release is now available for voting. It can be obtained from: http://people.apache.org/~markt/dev/tomcat-7/v7.0.14/ The svn tag is: http://svn.apache.org/repos/asf/tomcat/tc7.0.x/tags/TOMCAT_7_0_14/ The proposed 7.0.14 release is: [ ] Broken - do not release [ ] Alpha - go ahead and release as 7.0.14 Alpha [ ] Beta - go ahead and release as 7.0.14 Beta [ ] Stable - go ahead and release as 7.0.14 Stable Can you please add the file bin/apache-tomcat-7.0.14-windows-x64.zip.asc It is missing. Done. Sorry for the oversight. No Problem. I just ran the tests. I get one failure: INFO: Failures in output/build/logs/TEST-org.apache.catalina.core.TestAsyncContextImpl.NIO.txt WARN: Test failure in 'output/build/logs/TEST-org.apache.catalina.core.TestAsyncContextImpl.NIO.txt': Testsuite: org.apache.catalina.core.TestAsyncContextImpl Tests run: 30, Failures: 1, Errors: 0, Time elapsed: 68.862 sec ... Testcase: testAsyncStartNoComplete took 4.289 sec »···FAILED Uri: /, Status: 200, Time: 998 junit.framework.AssertionFailedError: Uri: /, Status: 200, Time: 998 »···at org.apache.catalina.core.TestAsyncContextImpl.validateAccessLog(TestAsyncContextImpl.java:1049) »···at org.apache.catalina.core.TestAsyncContextImpl.testAsyncStartNoComplete(TestAsyncContextImpl.java:162) Any idea? I'm a bit short of time, because i'm investigating an httpd trunk problem in parallel. Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 7.0.14
On 10.05.2011 21:32, Rainer Jung wrote: On 10.05.2011 20:11, Mark Thomas wrote: On 10/05/2011 18:46, Rainer Jung wrote: On 10.05.2011 01:31, Mark Thomas wrote: The proposed Apache Tomcat 7.0.14 release is now available for voting. It can be obtained from: http://people.apache.org/~markt/dev/tomcat-7/v7.0.14/ The svn tag is: http://svn.apache.org/repos/asf/tomcat/tc7.0.x/tags/TOMCAT_7_0_14/ The proposed 7.0.14 release is: [ ] Broken - do not release [ ] Alpha - go ahead and release as 7.0.14 Alpha [ ] Beta - go ahead and release as 7.0.14 Beta [+1] Stable - go ahead and release as 7.0.14 Stable +1 Vote added. Comment about one missing test case below. Can you please add the file bin/apache-tomcat-7.0.14-windows-x64.zip.asc It is missing. Done. Sorry for the oversight. No Problem. I just ran the tests. I get one failure: INFO: Failures in output/build/logs/TEST-org.apache.catalina.core.TestAsyncContextImpl.NIO.txt WARN: Test failure in 'output/build/logs/TEST-org.apache.catalina.core.TestAsyncContextImpl.NIO.txt': Testsuite: org.apache.catalina.core.TestAsyncContextImpl Tests run: 30, Failures: 1, Errors: 0, Time elapsed: 68.862 sec ... Testcase: testAsyncStartNoComplete took 4.289 sec »···FAILED Uri: /, Status: 200, Time: 998 junit.framework.AssertionFailedError: Uri: /, Status: 200, Time: 998 »···at org.apache.catalina.core.TestAsyncContextImpl.validateAccessLog(TestAsyncContextImpl.java:1049) »···at org.apache.catalina.core.TestAsyncContextImpl.testAsyncStartNoComplete(TestAsyncContextImpl.java:162) Any idea? I'm a bit short of time, because i'm investigating an httpd trunk problem in parallel. Actually instead of me its the test case, that was short of time. It was expected to have a duration of at least 1000 ms in the access log, but the entry was 998 ms. Not clear, how it could be faster than the timeout, but as long as the margin is only 2ms I don't care very much. So +1 for release as stable :) Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1104422 - in /tomcat/trunk/webapps/docs: changelog.xml config/ajp.xml
On 17.05.2011 19:24, ma...@apache.org wrote: Author: markt Date: Tue May 17 17:24:36 2011 New Revision: 1104422 URL: http://svn.apache.org/viewvc?rev=1104422view=rev Log: Add remaining attributes to documentation AJP-NIO now passes Servlet TCK - remove experimental label w00t! 0xEE8E0DD5.asc Description: application/pgp-keys - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [PROPOSAL] Move to svnpubsub for /dist/tomcat
+1 to Marks proposal. Shot additional answer to Konstantin inline. On 18.05.2011 16:43, Konstantin Kolinko wrote: Will the commit messages be forwarded to the mailing list? At least the web server project does it like that. For an example see http://marc.info/?l=apache-cvsm=130509208030121w=2 regards, Rainer 0xEE8E0DD5.asc Description: application/pgp-keys - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
mod_jk 1.2.32 [was: Re: svn commit: r1127315 - /tomcat/jk/trunk/xdocs/reference/apache.xml]
On 25.05.2011 00:15, Christopher Schultz wrote: All, I'm not sure what the policy is on documentation changes and back-porting to already-released versions of mod_jk, but this clarifies how mod_jk works and would be beneficial to have on the web site without having to wait for a new release of mod_jk. Is there a good way to do that, or should we just wait for a new release? Thanks, -chris In some cases we updated that part of the site manually before a release. Especially since this doen't document anything not available in the latest release. Unfortunately the same page was changed by my http://svn.apache.org/viewvc?view=revisionrevision=1078805 documenting a new feature for 1.2.32. There are enough changes for a 1.2.32 anyhows, so I would propose we start a new release cycle in about 2 weeks. OK? Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [PROPOSAL] Move to svnpubsub for /dist/tomcat
On 24.05.2011 22:19, Mark Thomas wrote: On 24/05/2011 20:24, Konstantin Kolinko wrote: 2011/5/24 Mark Thomas ma...@apache.org: 1. In what repository will the artifacts go? IIRC, there is some additional repository. I think it wouldn't be good to have them in /repos/asf/ There is a separate /dist repo https://dist.apache.org/repos/dist/... dev and release, with tomcat as a new tree under each. Ah. I had forgotten our dev dist dir. This is currently: http://tomcat.apache.org/dev/dist/ Given the age of the items there, I propose that the contents of that dir are not retained when we move to svnpusub for dist. Those are not released files. +1 to remove them at any moment. I see there some Maven files there, including 6.0.32. http://tomcat.apache.org/dev/dist/m2-repository/ I think (as 6.0.32 should already be elsewhere) the subdirectories inside of m2-repository can be removed and recreated when preparing 6.0.33 release (if they are needed e.g. as a staging area). Anyway, the current scope is dist at www.apache.org, which does not interfere with the area on tomcat.apache.org. Sort of. The normal usage pattern for svnpubsub for /dist is that tomcat.apache.org/dev/dist and www.apache.org/dist/tomcat both move at the same time. Hence my proposal that when we move we drop whatever is currently in tomcat.apache.org/dev/dist Does that mean we can still stage something at t.a.o/dev/dist before releasing? Or would we move any staging to p.a.o/~myname? Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: mod_jk 1.2.32 [was: Re: svn commit: r1127315 - /tomcat/jk/trunk/xdocs/reference/apache.xml]
On 26.05.2011 15:36, Christopher Schultz wrote: Rainer, On 5/26/2011 5:06 AM, Rainer Jung wrote: There are enough changes for a 1.2.32 anyhow, so I would propose we start a new release cycle in about 2 weeks. Sounds great. Someone looking at the IPV6 patch (BZ 43968)? Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1132362 - in /tomcat/trunk/java/org/apache/coyote/http11: AbstractHttp11Processor.java Http11AprProcessor.java Http11NioProcessor.java Http11Processor.java
Hi Mark,
On 05.06.2011 12:06, ma...@apache.org wrote:
Modified:
tomcat/trunk/java/org/apache/coyote/http11/AbstractHttp11Processor.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/coyote/http11/AbstractHttp11Processor.java?rev=1132362r1=1132361r2=1132362view=diff
==
--- tomcat/trunk/java/org/apache/coyote/http11/AbstractHttp11Processor.java
(original)
+++ tomcat/trunk/java/org/apache/coyote/http11/AbstractHttp11Processor.java
Sun Jun 5 10:06:49 2011
@@ -41,6 +41,7 @@ import org.apache.juli.logging.Log;
import org.apache.tomcat.util.ExceptionUtils;
import org.apache.tomcat.util.buf.Ascii;
import org.apache.tomcat.util.buf.ByteChunk;
+import org.apache.tomcat.util.buf.HexUtils;
import org.apache.tomcat.util.buf.MessageBytes;
import org.apache.tomcat.util.http.FastHttpDateFormat;
import org.apache.tomcat.util.http.MimeHeaders;
@@ -967,6 +968,78 @@ public abstract class AbstractHttp11Proc
abstract boolean prepareSendfile(OutputFilter[] outputFilters);
+/**
+ * Parse host.
+ */
+protected void parseHost(MessageBytes valueMB) {
+
+if (valueMB == null || valueMB.isNull()) {
+// HTTP/1.0
+// If no host header, use the port info from the endpoint
+// The host will be obtained lazily from the socket if required
+// using ActionCode#REQ_LOCAL_NAME_ATTRIBUTE
+request.setServerPort(endpoint.getPort());
+return;
+}
+
+ByteChunk valueBC = valueMB.getByteChunk();
+byte[] valueB = valueBC.getBytes();
+int valueL = valueBC.getLength();
+int valueS = valueBC.getStart();
+int colonPos = -1;
+if (hostNameC.length valueL) {
+hostNameC = new char[valueL];
+}
+
+boolean ipv6 = (valueB[valueS] == '[');
+boolean bracketClosed = false;
+for (int i = 0; i valueL; i++) {
+char b = (char) valueB[i + valueS];
+hostNameC[i] = b;
+if (b == ']') {
+bracketClosed = true;
+} else if (b == ':') {
+if (!ipv6 || bracketClosed) {
+colonPos = i;
+break;
+}
+}
+}
+
+if (colonPos 0) {
+if (!endpoint.isSSLEnabled()) {
+// 80 - Default HTTP port
+request.setServerPort(80);
+} else {
+// 443 - Default HTTPS port
+request.setServerPort(443);
+}
+request.serverName().setChars(hostNameC, 0, valueL);
+} else {
+
+request.serverName().setChars(hostNameC, 0, colonPos);
+
+int port = 0;
+int mult = 1;
+for (int i = valueL - 1; i colonPos; i--) {
+int charValue = HexUtils.getDec(valueB[i + valueS]);
Any idea, why hex digits (including a-f, A-F) are allowed in port numbers?
I know you only moved that code, but it reminded me of an observation I
made long ago and forgot.
+if (charValue == -1) {
+// Invalid character
+error = true;
+// 400 - Bad request
+response.setStatus(400);
+adapter.log(request, response, 0);
+break;
+}
+port = port + (charValue * mult);
+mult = 10 * mult;
+}
+request.setServerPort(port);
+
+}
+
+}
Regards,
Rainer
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 7.0.15
Not a vote yet: I get a test failure: Testcase: testWelcomeFileStrict took 0.005 sec Caused an ERROR Forked Java VM exited abnormally. Please note the time in the report does not reflect the time until the VM exit. junit.framework.AssertionFailedError: Forked Java VM exited abnormally. Please note the time in the report does not reflect the time until the VM exit. And indeed there is a core file and a hotspot error file. The crash happens in tcnative, more precisely in apr_allocator_destroy(). Could it have to do with the recent addition of server.destroy() (BZ 51310)? Note that I only recently added the APR tests to my standard checks. Furthermore I could not reproduce it during a second test. So the root cause could be older. C [libapr-1.so.0+0x13f00] apr_allocator_destroy+0x10 C [libapr-1.so.0+0x14c20] apr_pool_terminate+0x4c j org.apache.tomcat.jni.Library.terminate()V+-2499892 j org.apache.tomcat.jni.Library.terminate()V+0 v ~StubRoutines::call_stub V [libjvm.so+0x16b1a4] V [libjvm.so+0x7c5a04] V [libjvm.so+0x22579c] V [libjvm.so+0x223eb4] C [libjava.so+0x10be4] Java_sun_reflect_NativeMethodAccessorImpl_invoke0+0x18 j sun.reflect.NativeMethodAccessorImpl.invoke0(Ljava/lang/reflect/Method;Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+-1751180 j sun.reflect.NativeMethodAccessorImpl.invoke0(Ljava/lang/reflect/Method;Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+0 j sun.reflect.NativeMethodAccessorImpl.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+87 j sun.reflect.DelegatingMethodAccessorImpl.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+6 j java.lang.reflect.Method.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+161 j org.apache.catalina.core.AprLifecycleListener.terminateAPR()V+23 j org.apache.catalina.core.AprLifecycleListener.lifecycleEvent(Lorg/apache/catalina/LifecycleEvent;)V+96 j org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(Ljava/lang/String;Ljava/lang/Object;)V+37 j org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(Ljava/lang/String;Ljava/lang/Object;)V+6 j org.apache.catalina.util.LifecycleBase.setStateInternal(Lorg/apache/catalina/LifecycleState;Ljava/lang/Object;Z)V+140 j org.apache.catalina.util.LifecycleBase.destroy()V+194 j org.apache.catalina.startup.Tomcat.destroy()V+9 j org.apache.catalina.startup.TomcatBaseTest.tearDown()V+57 j junit.framework.TestCase.runBare()V+34 j junit.framework.TestResult$1.protect()V+4 j junit.framework.TestResult.runProtected(Ljunit/framework/Test;Ljunit/framework/Protectable;)V+1 j junit.framework.TestResult.run(Ljunit/framework/TestCase;)V+18 j junit.framework.TestCase.run(Ljunit/framework/TestResult;)V+2 j junit.framework.TestSuite.runTest(Ljunit/framework/Test;Ljunit/framework/TestResult;)V+2 j junit.framework.TestSuite.run(Ljunit/framework/TestResult;)V+37 j org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run()V+693 j org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(Lorg/apache/tools/ant/taskdefs/optional/junit/JUnitTest;[Ljava/lang/String;ZZ)I+41 j org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main([Ljava/lang/String;)V+918 v ~StubRoutines::call_stub V [libjvm.so+0x16b1a4] V [libjvm.so+0x20f4fc] C [java+0x3ab8] - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 7.0.15
Not a vote yet: I get a test failure: Testcase: testWelcomeFileStrict took 0.005 sec Caused an ERROR Forked Java VM exited abnormally. Please note the time in the report does not reflect the time until the VM exit. junit.framework.AssertionFailedError: Forked Java VM exited abnormally. Please note the time in the report does not reflect the time until the VM exit. And indeed there is a core file and a hotspot error file. The crash happens in tcnative, more precisely in apr_allocator_destroy(). Could it have to do with the recent addition of server.destroy() (BZ 51310)? Note that I only recently added the APR tests to my standard checks. Furthermore I could not reproduce it during a second test. So the root cause could be older. C [libapr-1.so.0+0x13f00] apr_allocator_destroy+0x10 C [libapr-1.so.0+0x14c20] apr_pool_terminate+0x4c j org.apache.tomcat.jni.Library.terminate()V+-2499892 j org.apache.tomcat.jni.Library.terminate()V+0 v ~StubRoutines::call_stub V [libjvm.so+0x16b1a4] V [libjvm.so+0x7c5a04] V [libjvm.so+0x22579c] V [libjvm.so+0x223eb4] C [libjava.so+0x10be4] Java_sun_reflect_NativeMethodAccessorImpl_invoke0+0x18 j sun.reflect.NativeMethodAccessorImpl.invoke0(Ljava/lang/reflect/Method;Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+-1751180 j sun.reflect.NativeMethodAccessorImpl.invoke0(Ljava/lang/reflect/Method;Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+0 j sun.reflect.NativeMethodAccessorImpl.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+87 j sun.reflect.DelegatingMethodAccessorImpl.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+6 j java.lang.reflect.Method.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+161 j org.apache.catalina.core.AprLifecycleListener.terminateAPR()V+23 j org.apache.catalina.core.AprLifecycleListener.lifecycleEvent(Lorg/apache/catalina/LifecycleEvent;)V+96 j org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(Ljava/lang/String;Ljava/lang/Object;)V+37 j org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(Ljava/lang/String;Ljava/lang/Object;)V+6 j org.apache.catalina.util.LifecycleBase.setStateInternal(Lorg/apache/catalina/LifecycleState;Ljava/lang/Object;Z)V+140 j org.apache.catalina.util.LifecycleBase.destroy()V+194 j org.apache.catalina.startup.Tomcat.destroy()V+9 j org.apache.catalina.startup.TomcatBaseTest.tearDown()V+57 j junit.framework.TestCase.runBare()V+34 j junit.framework.TestResult$1.protect()V+4 j junit.framework.TestResult.runProtected(Ljunit/framework/Test;Ljunit/framework/Protectable;)V+1 j junit.framework.TestResult.run(Ljunit/framework/TestCase;)V+18 j junit.framework.TestCase.run(Ljunit/framework/TestResult;)V+2 j junit.framework.TestSuite.runTest(Ljunit/framework/Test;Ljunit/framework/TestResult;)V+2 j junit.framework.TestSuite.run(Ljunit/framework/TestResult;)V+37 j org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run()V+693 j org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(Lorg/apache/tools/ant/taskdefs/optional/junit/JUnitTest;[Ljava/lang/String;ZZ)I+41 j org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main([Ljava/lang/String;)V+918 v ~StubRoutines::call_stub V [libjvm.so+0x16b1a4] V [libjvm.so+0x20f4fc] C [java+0x3ab8] - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1132362 - in /tomcat/trunk/java/org/apache/coyote/http11: AbstractHttp11Processor.java Http11AprProcessor.java Http11NioProcessor.java Http11Processor.java
+for (int i = valueL - 1; i colonPos; i--) {
+int charValue = HexUtils.getDec(valueB[i + valueS]);
Any idea, why hex digits (including a-f, A-F) are allowed in port numbers?
I know you only moved that code, but it reminded me of an observation I
made long ago and forgot.
I can't think of any good reason. Happy to limit that to the digits 0-9.
Would you prefer renaming HexUtils to NumberUtils (or similar) and havin
getDecFromHex() and getDecFromDec() there, or a new class similar to
HexUtils called DecUtils?
Regards,
Rainer
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [PROPOSAL] Enable session replication by default.
On 07.06.2011 21:39, Mark Thomas wrote: On 07/06/2011 20:24, Jess Holle wrote: web apps whose web.xml does not specify distributable should certainly not be treated as such -- that would be a spec violation and break lots of web apps. How many times do I have to write this? This is NOT what is being proposed. All the proposed change does is fix a regression that prevents *any* web application for declaring itself as distributable. +1 to that change and to 7.0.15 is broken. Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 7.0.15
Update: I ran org/apache/tomcat/util/http/mapper/TestMapperWelcomeFiles.java in a loop. The crash happens in about 5-10% of all runs. I'm not saying the crsh is specific to this test, I just tried to reproduce it with the test for which I noticed it first. The good thing: - I checked without r1130539 (BZ 51310, added a destroy cal) and the problem still occurs - I checked with 7.0.14 and the problem still occurs. So it is not a regression. - Even better: very rarely instead of a crash I get and unterminated loop in apr_allocator_destroy because of circular pointer chains. And that - crashes and rare untrminated loops in apr_allocator_destroy - makes it exactly the same kind of fault I occasionally notice when testing apr using its own test suite. We (APR) still do not know the root cause for this, last time there was speculation about the test being borked. I might use our often failing little TC test to investigate the APR problem :) Regards, Rainer On 05.06.2011 18:33, Rainer Jung wrote: Not a vote yet: I get a test failure: Testcase: testWelcomeFileStrict took 0.005 sec Caused an ERROR Forked Java VM exited abnormally. Please note the time in the report does not reflect the time until the VM exit. junit.framework.AssertionFailedError: Forked Java VM exited abnormally. Please note the time in the report does not reflect the time until the VM exit. And indeed there is a core file and a hotspot error file. The crash happens in tcnative, more precisely in apr_allocator_destroy(). Could it have to do with the recent addition of server.destroy() (BZ 51310)? Note that I only recently added the APR tests to my standard checks. Furthermore I could not reproduce it during a second test. So the root cause could be older. C [libapr-1.so.0+0x13f00] apr_allocator_destroy+0x10 C [libapr-1.so.0+0x14c20] apr_pool_terminate+0x4c j org.apache.tomcat.jni.Library.terminate()V+-2499892 j org.apache.tomcat.jni.Library.terminate()V+0 v ~StubRoutines::call_stub V [libjvm.so+0x16b1a4] V [libjvm.so+0x7c5a04] V [libjvm.so+0x22579c] V [libjvm.so+0x223eb4] C [libjava.so+0x10be4] Java_sun_reflect_NativeMethodAccessorImpl_invoke0+0x18 j sun.reflect.NativeMethodAccessorImpl.invoke0(Ljava/lang/reflect/Method;Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+-1751180 j sun.reflect.NativeMethodAccessorImpl.invoke0(Ljava/lang/reflect/Method;Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+0 j sun.reflect.NativeMethodAccessorImpl.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+87 j sun.reflect.DelegatingMethodAccessorImpl.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+6 j java.lang.reflect.Method.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+161 j org.apache.catalina.core.AprLifecycleListener.terminateAPR()V+23 j org.apache.catalina.core.AprLifecycleListener.lifecycleEvent(Lorg/apache/catalina/LifecycleEvent;)V+96 j org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(Ljava/lang/String;Ljava/lang/Object;)V+37 j org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(Ljava/lang/String;Ljava/lang/Object;)V+6 j org.apache.catalina.util.LifecycleBase.setStateInternal(Lorg/apache/catalina/LifecycleState;Ljava/lang/Object;Z)V+140 j org.apache.catalina.util.LifecycleBase.destroy()V+194 j org.apache.catalina.startup.Tomcat.destroy()V+9 j org.apache.catalina.startup.TomcatBaseTest.tearDown()V+57 j junit.framework.TestCase.runBare()V+34 j junit.framework.TestResult$1.protect()V+4 j junit.framework.TestResult.runProtected(Ljunit/framework/Test;Ljunit/framework/Protectable;)V+1 j junit.framework.TestResult.run(Ljunit/framework/TestCase;)V+18 j junit.framework.TestCase.run(Ljunit/framework/TestResult;)V+2 j junit.framework.TestSuite.runTest(Ljunit/framework/Test;Ljunit/framework/TestResult;)V+2 j junit.framework.TestSuite.run(Ljunit/framework/TestResult;)V+37 j org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run()V+693 j org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(Lorg/apache/tools/ant/taskdefs/optional/junit/JUnitTest;[Ljava/lang/String;ZZ)I+41 j org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main([Ljava/lang/String;)V+918 v ~StubRoutines::call_stub V [libjvm.so+0x16b1a4] V [libjvm.so+0x20f4fc] C [java+0x3ab8] - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1134063 - /tomcat/trunk/java/org/apache/coyote/AsyncStateMachine.java
I like it :)
On 09.06.2011 22:10, ma...@apache.org wrote:
Author: markt
Date: Thu Jun 9 20:10:23 2011
New Revision: 1134063
URL: http://svn.apache.org/viewvc?rev=1134063view=rev
Log:
Document the state transition diagram
Modified:
tomcat/trunk/java/org/apache/coyote/AsyncStateMachine.java
Modified: tomcat/trunk/java/org/apache/coyote/AsyncStateMachine.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/coyote/AsyncStateMachine.java?rev=1134063r1=1134062r2=1134063view=diff
==
--- tomcat/trunk/java/org/apache/coyote/AsyncStateMachine.java (original)
+++ tomcat/trunk/java/org/apache/coyote/AsyncStateMachine.java Thu Jun 9
20:10:23 2011
@@ -24,8 +24,8 @@ import org.apache.tomcat.util.res.String
/**
* Manages the state transitions for async requests.
- * TODO: State transition diagram
*
+ * pre
* The internal states that are used are:
* DISPATCHED- Standard request. Not in Async mode.
* STARTING - ServletRequest.startAsync() has been called but the
@@ -48,6 +48,41 @@ import org.apache.tomcat.util.res.String
* request finishes, the dispatch() will be processed.
* DISPATCHING - The dispatch is being processed.
* ERROR - Something went wrong.
+ *
+ * ||
+ * |\|/
+ * | |--ERROR
+ * | |complete()/|\ |
+ * | |error()| |postProcess()
+ * | | | |
+ * | | postProcess() | \|/ auto
+ * | |
|---DISPATCHED--COMPLETING|
+ * | | | /|\ | | /|\
|
+ * | | ||--| | |--|
|
+ * | | ^| |startAsync()timeout()
|
+ * | | || |
|
+ * | \|/|| complete() \|/postProcess()
|
+ * | MUST_COMPLETE-- | --STARTING--|
^
+ * | /|\ | | |
|
+ * | | | | |
|
+ * | | ^ |dispatch() |
|
+ * | | | | |
|
+ * | | | \|/ \|/
complete() |
+ * | | | MUST_DISPATCH
STARTED---|
+ * | | | | | |
+ * | | | |postProcess()| |
+ * ^ ^ | | dispatch() | |auto
+ * | | | ||| |
+ * | | | auto \|/ \|/ \|/
+ * | | |---DISPATCHING-TIMING_OUT
+ * | | dispatch() | |
+ * | | | |
+ * | || |
+ * | complete() |
+ * | |
+ * |---|
+ * error()
+ * /pre
*/
public class AsyncStateMachine {
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Outdated Maven Info in TC 7 docs
Our docs page about Tomcat Maven artefacts http://tomcat.apache.org/tomcat-7.0-doc/maven-jars.html seems outdated. The staging repository linked there doesn't contain anything after 7.0.2. The text below the link indicates something about switching to the ASF main repos, but I think we could be more precise now (but unfortunately not me). Furthermore the Nexus search on https://repository.apache.org doesn't provide any hits for our TC 7 artefacts, but http://search.maven.org finds them? Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1134965 - in /tomcat/trunk/webapps/docs: changelog.xml maven-jars.xml
Thanks Mark. I had put my new changelog entry into the Coyote section. Maybe that's not optimal for your Maven entry, which seems to be more like General. Regards, Rainer On 12.06.2011 21:28, ma...@apache.org wrote: Author: markt Date: Sun Jun 12 19:28:17 2011 New Revision: 1134965 URL: http://svn.apache.org/viewvc?rev=1134965view=rev Log: Update the Maven repo info Modified: tomcat/trunk/webapps/docs/changelog.xml tomcat/trunk/webapps/docs/maven-jars.xml Modified: tomcat/trunk/webapps/docs/changelog.xml URL: http://svn.apache.org/viewvc/tomcat/trunk/webapps/docs/changelog.xml?rev=1134965r1=1134964r2=1134965view=diff == --- tomcat/trunk/webapps/docs/changelog.xml (original) +++ tomcat/trunk/webapps/docs/changelog.xml Sun Jun 12 19:28:17 2011 @@ -50,8 +50,16 @@ subsection name=Coyote changelog fix -Fix unit test for bindOnInit which was failing for APR on some platforms. -(rjung) +Fix unit test for bindOnInit which was failing for APR on some +platforms. (rjung) + /fix +/changelog + /subsection + subsection +changelog name=Web applications + fix +Update Maven repository information in the documentation to reflect +current usage. (markt) /fix /changelog /subsection - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Crash in APR when pausing endpoint
I had some spare time for analyzing the crashes in TestMapperWelcomeFiles. It seems there are several varieties, but at least I do now understand enough to report here: In Http11AprProcessor.process() when parsing the request line fails, e.g. it is not yet there, we add the socket back to the poller. Then we check the endpoint for being paused. If so, we set error to true. At the end of process(), if error is true, we return SocketState.CLOSED, which in turn lets the SocketProcessor closes the socket (and destroys the native memory allocated with it). Now what I experience sporadically, is that the original thread A is thrown off the CPU after adding the socket back to the poller, but before proceeding. Another thread B now gets the socket from the poller, uses it for request processing and at the end destroys it. Now A wakes up and proceeds as described above, and since now the endpoint is paused, it also tries to destroy the socket, leading to a crash. This seems to be a flaw. I suggest we add only to the poller if we know no error occured and the endpoint is not paused. The patch for AjpApr is simpler but similar. See for both classes: http://people.apache.org/~rjung/patches/tc7-apr-add_to_poller.patch I checked this patch against one full run of the test suite with HTTP APR and also against 150 runs of TestMapperWelcomeFiles. No crashes or errors any more. WDYT? Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Crash in APR when pausing endpoint
On 13.06.2011 17:49, Mark Thomas wrote: On 13/06/2011 16:07, Rainer Jung wrote: I had some spare time for analyzing the crashes in TestMapperWelcomeFiles. It seems there are several varieties, but at least I do now understand enough to report here: ... This seems to be a flaw. I suggest we add only to the poller if we know no error occured and the endpoint is not paused. The patch for AjpApr is simpler but similar. See for both classes: http://people.apache.org/~rjung/patches/tc7-apr-add_to_poller.patch I checked this patch against one full run of the test suite with HTTP APR and also against 150 runs of TestMapperWelcomeFiles. No crashes or errors any more. WDYT? Analysis and patch make sense to me. Thanks for reviewing. After about 900 test iterations I committed in r1135208. Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 7.0.16
On 11.06.2011 13:33, Mark Thomas wrote: The proposed 7.0.16 release is: [ ] Broken - do not release [ ] Alpha - go ahead and release as 7.0.16 Alpha [ ] Beta - go ahead and release as 7.0.16 Beta [X] Stable - go ahead and release as 7.0.16 Stable +1 for stable. - MD5 OK - signatures OK - key in KEYS file - gz and zip for src and bin consistent - src consistent with svn tag X except for the additional modules directory in svn Not a show stopper. - builds fine - build result looks consistent with binaries - no checkstyle complaints - no Javadoc errors - Unit tests run OK for BIO, NIO and APR X Sporadic crashes for TestMapperWelcomeFiles when using APR, not a regression, now fixed by r1135208 X TestXxxEndpoint fails with APR on Solaris due to a test buglet, not a regression, now fixed by r1134938 - JMX MBean-Comparison OK X a few additional entries in tomcat.util.scan.DefaultJarScanner.jarsToSkip as expected Build and tests were done using Java 1.6.0_24, OS was Solaris 10 Sparc, tcnative was 1.1.20 based on APR 1.4.5 and OpenSSL 0.9.8r. Looks pretty good! Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [GUMP@vmgump]: Project tomcat-trunk-test (in module tomcat-trunk) failed
On 15.06.2011 14:49, Mark Thomas wrote: On 15/06/2011 13:29, Konstantin Kolinko wrote: The failure happened in [junit] Test org.apache.catalina.core.TestAsyncContextImpl FAILED when running with NIO. Running the same test with BIO was OK. The log file from the test is [1]. [1]: http://vmgump.apache.org/gump/public/tomcat-trunk/tomcat-trunk-test/gump_file/TEST-org.apache.catalina.core.TestAsyncContextImpl.NIO.txt.html The failure there: Testcase: testListeners took 6.23 sec FAILED Uri: /stage1, Status: 200, Time: 4999 junit.framework.AssertionFailedError: Uri: /stage1, Status: 200, Time: 4999 at org.apache.catalina.core.TestAsyncContextImpl.validateAccessLog(TestAsyncContextImpl.java:1052) at org.apache.catalina.core.TestAsyncContextImpl.testListeners(TestAsyncContextImpl.java:628) Looks like a timing issue with the AccessLog tests. These work for me when running locally. I'm tempted to leave the timings as is for now and see if we get regular failures. If we do, we can increase the margins. So at least it is not only me with my exotic systems seeing a few test failures every now and then. I noticed a similar failure when testing 7.0.14: Testcase: testAsyncStartNoComplete took 4.289 sec »···FAILED Uri: /, Status: 200, Time: 998 junit.framework.AssertionFailedError: Uri: /, Status: 200, Time: 998 »···at org.apache.catalina.core.TestAsyncContextImpl.validateAccessLog(TestAsyncContextImpl.java:1049) »···at org.apache.catalina.core.TestAsyncContextImpl.testAsyncStartNoComplete(TestAsyncContextImpl.java:162) It turned out, the expectation was a request duration of 1000ms, and the access log contained a duration of 998ms. It only happens spordically for me, I neither oberved it during 7.0.15 tests, nor for 7.0.16. Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [GUMP@vmgump]: Project tomcat-trunk-test (in module tomcat-trunk) failed
On 15.06.2011 14:49, Mark Thomas wrote: On 15/06/2011 13:29, Konstantin Kolinko wrote: The failure happened in [junit] Test org.apache.catalina.core.TestAsyncContextImpl FAILED when running with NIO. Running the same test with BIO was OK. The log file from the test is [1]. [1]: http://vmgump.apache.org/gump/public/tomcat-trunk/tomcat-trunk-test/gump_file/TEST-org.apache.catalina.core.TestAsyncContextImpl.NIO.txt.html The failure there: Testcase: testListeners took 6.23 sec FAILED Uri: /stage1, Status: 200, Time: 4999 junit.framework.AssertionFailedError: Uri: /stage1, Status: 200, Time: 4999 at org.apache.catalina.core.TestAsyncContextImpl.validateAccessLog(TestAsyncContextImpl.java:1052) at org.apache.catalina.core.TestAsyncContextImpl.testListeners(TestAsyncContextImpl.java:628) Looks like a timing issue with the AccessLog tests. These work for me when running locally. I'm tempted to leave the timings as is for now and see if we get regular failures. If we do, we can increase the margins. So at least it is not only me with my exotic systems seeing a few test failures every now and then. I noticed a similar failure when testing 7.0.14: Testcase: testAsyncStartNoComplete took 4.289 sec »···FAILED Uri: /, Status: 200, Time: 998 junit.framework.AssertionFailedError: Uri: /, Status: 200, Time: 998 »···at org.apache.catalina.core.TestAsyncContextImpl.validateAccessLog(TestAsyncContextImpl.java:1049) »···at org.apache.catalina.core.TestAsyncContextImpl.testAsyncStartNoComplete(TestAsyncContextImpl.java:162) It turned out, the expectation was a request duration of 1000ms, and the access log contained a duration of 998ms. It only happens spordically for me, I neither oberved it during 7.0.15 tests, nor for 7.0.16. Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Questions about the ajp1.3 connector
On 15.06.2011 08:18, 姚伟斌 wrote: Hi, folks, I have some questions about the ajp1.3 connector. Is there any other official document for ajp1.3 connector? This url ( http://tomcat.apache.org/connectors-doc/ajp/ajpv13a.html) seems lack of something. No, that is the official protocol documentation. In Send Body Chunk Packet, Is always there an extra zero byte with each packet chunk? Include the zero length chunk? Hmm, not sure what you mean, you would need to show a packet dump. Since you mention a zero length chunk: this could be the use of the cping/cpong feature (connection testing), which uses packets with empty bodies. You can always use mod_jk with JkLogLevel trace to get a complete packet dump of communications and compare with your implementation. If you have additions for the docs, let us know, so that we can include it. I have developed a module for the AJP connection between Nginx and Tomcat( https://github.com/yaoweibin/nginx_ajp_module/tree/test_for_ferenc). Cool. But it seems there are some problems with the response body chunk If you present readable packet dumps and ask more precisely about which bytes you are unsure, we might be able to explain :) Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Current test failures for APR
Notice: currently I get test failures when testing APR. Just in caes someone else is also wondering - you are not alone :) org.apache.catalina.connector.TestCoyoteAdapter crash in testPathParmsFooSessionValue (jni Socker recvbb) org.apache.catalina.connector.TestKeepAliveCount non-terminating loop during shutdown in testHttp11 org.apache.catalina.core.TestStandardContextResources non-terminating loop during shutdown in testResources org.apache.el.TestELInJsp Testcase: testBug45451 took 3.145 sec Caused an ERROR null java.lang.NullPointerException at org.apache.el.TestELInJsp.assertEcho(TestELInJsp.java:411) at org.apache.el.TestELInJsp.testBug45451(TestELInJsp.java:159) org.apache.naming.resources.TestWarDirContext Testcase: testReservedJNDIFileNamesNoCache took 3.184 sec FAILED expected:p'singlequote2.jsp in file system/p but was:null junit.framework.ComparisonFailure: expected:p'singlequote2.jsp in file system/p but was:null at org.apache.naming.resources.TestWarDirContext.testReservedJNDIFileNamesNoCache(TestWarDirContext.java:115) org.apache.tomcat.util.http.TestCookiesDefaultSysProps Testcase: testCookiesInstance took 4.816 sec FAILED expected:Cookie name fail but was:null junit.framework.ComparisonFailure: expected:Cookie name fail but was:null at org.apache.tomcat.util.http.TestCookiesDefaultSysProps.testCookiesInstance(TestCookiesDefaultSysProps.java:49) org.apache.tomcat.util.http.TestCookiesNoStrictNamingSysProps Testcase: testCookiesInstance took 5.515 sec FAILED expected:Cookie name ok but was:null junit.framework.ComparisonFailure: expected:Cookie name ok but was:null at org.apache.tomcat.util.http.TestCookiesNoStrictNamingSysProps.testCookiesInstance(TestCookiesNoStrictNamingSysProps.java:52) org.apache.tomcat.util.http.TestCookiesStrictSysProps Testcase: testCookiesInstance took 5.418 sec FAILED expected:Cookie name fail but was:null junit.framework.ComparisonFailure: expected:Cookie name fail but was:null at org.apache.tomcat.util.http.TestCookiesStrictSysProps.testCookiesInstance(TestCookiesStrictSysProps.java:50) org.apache.tomcat.util.http.mapper.TestMapperWelcomeFiles Testcase: testWelcomeFileNotStrict took 7.412 sec FAILED expected:200 but was:-1 junit.framework.AssertionFailedError: expected:200 but was:-1 at org.apache.tomcat.util.http.mapper.TestMapperWelcomeFiles.testWelcomeFileNotStrict(TestMapperWelcomeFiles.java:59) I'll see whether it is reproducible and whether I get an idea about the root cause. I guess something about the refactoring, but form looking at the changes nothing was obvious. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Current test failures for APR
Current assumption: Fixed by r1137372. It'll take some time until I have seen enough passing tests. Will report back. Regards, Rainer On 19.06.2011 14:52, Rainer Jung wrote: Notice: currently I get test failures when testing APR. Just in caes someone else is also wondering - you are not alone :) org.apache.catalina.connector.TestCoyoteAdapter crash in testPathParmsFooSessionValue (jni Socker recvbb) org.apache.catalina.connector.TestKeepAliveCount non-terminating loop during shutdown in testHttp11 org.apache.catalina.core.TestStandardContextResources non-terminating loop during shutdown in testResources org.apache.el.TestELInJsp Testcase: testBug45451 took 3.145 sec Caused an ERROR null java.lang.NullPointerException at org.apache.el.TestELInJsp.assertEcho(TestELInJsp.java:411) at org.apache.el.TestELInJsp.testBug45451(TestELInJsp.java:159) org.apache.naming.resources.TestWarDirContext Testcase: testReservedJNDIFileNamesNoCache took 3.184 sec FAILED expected:p'singlequote2.jsp in file system/p but was:null junit.framework.ComparisonFailure: expected:p'singlequote2.jsp in file system/p but was:null at org.apache.naming.resources.TestWarDirContext.testReservedJNDIFileNamesNoCache(TestWarDirContext.java:115) org.apache.tomcat.util.http.TestCookiesDefaultSysProps Testcase: testCookiesInstance took 4.816 sec FAILED expected:Cookie name fail but was:null junit.framework.ComparisonFailure: expected:Cookie name fail but was:null at org.apache.tomcat.util.http.TestCookiesDefaultSysProps.testCookiesInstance(TestCookiesDefaultSysProps.java:49) org.apache.tomcat.util.http.TestCookiesNoStrictNamingSysProps Testcase: testCookiesInstance took 5.515 sec FAILED expected:Cookie name ok but was:null junit.framework.ComparisonFailure: expected:Cookie name ok but was:null at org.apache.tomcat.util.http.TestCookiesNoStrictNamingSysProps.testCookiesInstance(TestCookiesNoStrictNamingSysProps.java:52) org.apache.tomcat.util.http.TestCookiesStrictSysProps Testcase: testCookiesInstance took 5.418 sec FAILED expected:Cookie name fail but was:null junit.framework.ComparisonFailure: expected:Cookie name fail but was:null at org.apache.tomcat.util.http.TestCookiesStrictSysProps.testCookiesInstance(TestCookiesStrictSysProps.java:50) org.apache.tomcat.util.http.mapper.TestMapperWelcomeFiles Testcase: testWelcomeFileNotStrict took 7.412 sec FAILED expected:200 but was:-1 junit.framework.AssertionFailedError: expected:200 but was:-1 at org.apache.tomcat.util.http.mapper.TestMapperWelcomeFiles.testWelcomeFileNotStrict(TestMapperWelcomeFiles.java:59) I'll see whether it is reproducible and whether I get an idea about the root cause. I guess something about the refactoring, but form looking at the changes nothing was obvious. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Current test failures for APR
On 19.06.2011 16:36, Rainer Jung wrote: Current assumption: Fixed by r1137372. It'll take some time until I have seen enough passing tests. Will report back. 5 runs through the test suite later it looks good now (pre r1137375). Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Using eval vs. exec in shell scripts
Since Mladens change r918873 in March 2010 we use eval instead of exec in the shell scripts. The svn log says: Use eval instead direct call or exec command so that arguments with spaces are properly handled Eval leaves a copy of the shell process hanging around until Tomcat shutdown. I want to experiment with different solutions, but have no idea, what kind of whitespace use the switch from exec to eval was supposed to change. Mladen or whoever else understood this: can you give an example which didn't work with the exec based scripts? Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Overhauling setclasspath.(bat|sh)?
1) Renaming Since quite some time now the setclasspath script doesn't have anything to do with setting a class path. It only searches for JRE / JDK and sets up the path to the Java or JDB binary plus JAVA_ENDORSED_DIRS. So it would be more correct to call it checkjava.sh or setupjava.sh or whatever. Do you think it's too late for TC 7 to rename the script? Good ideas for a new name? 2) Removing BASEDIR In addition it contains a validity check for BASEDIR. This is bogus: whereever setclasspath is sources, we directly before set BASEDIR to the path from which we source setclasspath. In addition, apart from the validity check, BASEDIR is never ever used. I'd say we can safely remove BASEDIR (not setting it in catalina.* and not checking it in setclasspath.*). Makes the scripts a bit simpler. Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Using eval vs. exec in shell scripts
On 20.06.2011 14:52, Mladen Turk wrote: On 06/20/2011 01:39 PM, Rainer Jung wrote: Since Mladens change r918873 in March 2010 we use eval instead of exec in the shell scripts. The svn log says: Use eval instead direct call or exec command so that arguments with spaces are properly handled Mladen or whoever else understood this: can you give an example which didn't work with the exec based scripts? eg. export JAVA_OPTS=$JAVA_OPTS \-XX:OnError=gdb - %p\ Thanks for the example. ... and We eval for start/stop so we can get the pid. And this is broken now. We used $! with exec and we still use it with eval. But with eval $! returns the pid of a child shell and the java process id a child of that pid. since eval and exec behave differently when handling quoted args this was giving different results on catalina.sh run/start Yes, I got it. I experimented with eval exec (sic!) and it looks promising. The following tiny script is useful for experimenting: #!/bin/sh dir='/var/tmp/with spaces' arg1='-Dprop1=val1 with space' arg2=-DpropX=y -DpropY=Z args=\$arg1\ $arg2 mkdir -p $dir cp -p /usr/bin/sleep $dir echo Starting using eval ... eval \$dir\/sleep 60 $args pid=$! echo PID is: $pid ps -p $pid kill -9 $pid echo Starting using eval exec ... eval exec \$dir\/sleep 60 $args pid=$! echo PID is: $pid ps -p $pid kill -9 $pid rm -rf $dir I think eval exec is the right solution. Seems to behave nice for whitespace and doesn't add an intermediate process between the startup script and the Java process. Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Overhauling setclasspath.(bat|sh)?
On 20.06.2011 14:54, Leon Rosenberg wrote: On Mon, Jun 20, 2011 at 2:50 PM, Rainer Jung rainer.j...@kippdata.de wrote: 1) Renaming Since quite some time now the setclasspath script doesn't have anything to do with setting a class path. It only searches for JRE / JDK and sets up the path to the Java or JDB binary plus JAVA_ENDORSED_DIRS. So it would be more correct to call it checkjava.sh or setupjava.sh or whatever. Do you think it's too late for TC 7 to rename the script? Good ideas for a new name? 2cents Hello Rainer, the last and only time I used setclasspath.sh I was using it to set custom classpath (adding a folder with config to the classpath). For me setclasspath as name made perfectly sense till now ;-) regards Leon /2cents The right place for this and any other customization of the startup variables is setenv.sh. Another reason for renaming ;) Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1137607 - /tomcat/trunk/bin/catalina.sh
On 20.06.2011 14:56, Mladen Turk wrote: On 06/20/2011 02:37 PM, rj...@apache.org wrote: Author: rjung Date: Mon Jun 20 12:37:01 2011 New Revision: 1137607 URL: http://svn.apache.org/viewvc?rev=1137607view=rev Log: Slight improvement of configtest handling in Unix shell script: - add to usage - don't use CATALINA_OPTS (think memory size etc.) Why have you choose to kill all of the existing scripts out there? I haven't ;) -jpda won't work any more. Please revert that part. I'll check. Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1137607 - /tomcat/trunk/bin/catalina.sh
On 20.06.2011 14:56, Mladen Turk wrote: On 06/20/2011 02:37 PM, rj...@apache.org wrote: Author: rjung Date: Mon Jun 20 12:37:01 2011 New Revision: 1137607 URL: http://svn.apache.org/viewvc?rev=1137607view=rev Log: Slight improvement of configtest handling in Unix shell script: - add to usage - don't use CATALINA_OPTS (think memory size etc.) Why have you choose to kill all of the existing scripts out there? -jpda won't work any more. Please revert that part. Hmmm, after checking, I don't understand. Did you see the configtest in the above log message? This is not about start, only about configtest.sh. So do you have an actual problem with jpda or did you only think there is a problem? Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1137607 - /tomcat/trunk/bin/catalina.sh
On 20.06.2011 15:41, Mladen Turk wrote: On 06/20/2011 03:28 PM, Mark Thomas wrote: On 20/06/2011 14:21, Mladen Turk wrote: Just don't see what was the problem with that option that would require it to go away. This wasn't discussed on the dev list so if I weren't tracking the svn commits it would be a big surprise on the next tomcat release. Look at the patch again. It only removes the option for configtest It depends what you have in CATALINA_OPTS. If you have -d32/-d64 this won't get picked. However still don't get it why it was removed? Funny, but I was actually trying to add $CATALINA_OPTS to the version command, so we get consistent JVM behavior. We do have two options, JAVA_OPTS and CATALINA_OPTS. The only difference between them is, for which of the catalina.sh subcommand they are used. - JAVA_OPTS for all - CATALINA_OPTS only for starting (and run and debug) Why are there 2 option lists? Because at least for the memory sizing you need to have a split. If you run production tomcat with say 2GB heap, and add the same flag when running version or stop, then you will temporrarily try to start another 2GB Java process. Another example are the jmx listeners. If you add a port via the sun management system property and add it to the stop or version command as well, the JVM will not be able to start, so the version or stop command will fail. In general all commands except those that start a Tomcat (and thus deploy webapps etc.) should not use that type of params. They should go into CATALINA_OPTS. Everything that you can use multiple times in parallel, even for the helper programs can go in JAVA_OPTS. Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1137607 - /tomcat/trunk/bin/catalina.sh
On 20.06.2011 16:06, Mladen Turk wrote: On 06/20/2011 03:53 PM, Rainer Jung wrote: On 20.06.2011 15:41, Mladen Turk wrote: In general all commands except those that start a Tomcat (and thus deploy webapps etc.) should not use that type of params. They should go into CATALINA_OPTS. Everything that you can use multiple times in parallel, even for the helper programs can go in JAVA_OPTS. Hmm, make sense. Seems there is general missunderstanding of those two. People usually put in JAVA_OPTS what actually belongs to CATALINA_OPTS. Dunno what to think actually at the moment. Yes, I always thought the names are confusing. But probably much to late now. The split was introduced long ago in TC 6 times. If we change it, we break peoples config who set them in setenv. One can make some sense out of the name: CATALINA_OPTS are the ones that CATALINA=Tomcat needs to run. Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
OneLineFormatter by default?
Should we use the new OneLineFormatter as the default juli formatter? I never found anyone who liked the default java.util.logging log format, which spreads all messages out via two lines. One line contains the timestamp, the other line the message. So if your grep for a message, you want find out when it was issued, and if you look for a certain time range, yout wont see the actual messages. Non-sense. Now that we have our nice little OneLineFormatter, why not use it as default? If we use it as default: should be have it as default without config, i.e. as a default in code, or do we want to add the .formatter lines to our loggging.properties? Or add the formatter system property to catalina.properties? I think I would favor having it as a code default, i.e. without any configuration. Any comments? Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: OneLineFormatter by default?
Thanks Konstantin. I'll take a look at cleaning up 1) to 3), likely using the DateFormatCache from the AccessLogValve as a utility class. Regards, Rainer On 20.06.2011 18:52, Konstantin Kolinko wrote: 2011/6/20 Rainer Jung rainer.j...@kippdata.de: Should we use the new OneLineFormatter as the default juli formatter? I never found anyone who liked the default java.util.logging log format, which spreads all messages out via two lines. One line contains the timestamp, the other line the message. So if your grep for a message, you want find out when it was issued, and if you look for a certain time range, yout wont see the actual messages. Non-sense. Now that we have our nice little OneLineFormatter, why not use it as default? I like the default SimpleFormatter. With the SimpleFormatter those messages fit better when they are printed into console window. It is easier to read through the log files as well. With OneLineFormatter the messages are shifted to the right. The offset is arbitrary, because class names before the message have arbitrary length. Enabling line wrapping in file viewer is possible, but does not make those lines more readable. It is hard to read. I think SimpleFormatter should stay as the default. Some nitpicks looking at the source code of OneLineFormatter. 1) OneLineFormatter#currentDate and currentDateString are used in double locking. If I understand it correctly, the should be made volatile. Though see the next point. 2) I do not understand why OneLineFormatter#addTimestamp( ) method is public. It could be protected. It is not used anywhere else. Furthermore, the only place where it is called, the #format() method, always creates a new instance of Date object. Thus if (currentDate != date) comparison of object instances does not make sense. 3) msec value looses its leading zero. E.g. in two subsequent lines: 20-Jun-2011 20:25:25.46 20-Jun-2011 20:25:25.531 4) SimpleFormatter#format() delegates message formatting to Formatter#formatMessage(..) which performs lookup through a resource bundle and does formatting of parameters. OneLineFormatter does not do it. It just uses the message as String. It is not of much difference for Tomcat, because Tomcat does not use java.util.logging directly, but some other webapps may use it. (Not a very strong argument though). If we use it as default: should be have it as default without config, i.e. as a default in code, or do we want to add the .formatter lines to our loggging.properties? Or add the formatter system property to catalina.properties? I think I would favor having it as a code default, i.e. without any configuration. In the code you can change default for the JULI's FileHandler only. (Unless you tweak properties loading itself). There are other Handler implementations there. If it were changed I'd prefer it to be in the configuration. Regarding grep: Some grep implementations (e.g. the GNU one) have --context, --before-context, --after-context options to print several lines of context for each match (section 2.1.5 in [1]). [1]: http://www.gnu.org/software/grep/manual/ Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: OneLineFormatter by default?
On 20.06.2011 20:10, Mark Thomas wrote: On 20/06/2011 19:07, Rainer Jung wrote: Thanks Konstantin. I'll take a look at cleaning up 1) to 3), likely using the DateFormatCache from the AccessLogValve as a utility class. Already on it. Note DateFormatCache can't be used because a) JULI can't depend on Catalina and b) the AccessLog timestamps are accurate to the nearest second whereas the logging timestamps use ms. Sorry for not having answered quicker: - you can use DateFormatCache like in the AccessLogValve: cachig is most efficient if done on a per second basis. Adding the milliseconds after the cached format is trivial and can be done after retrieving the format. - Yup, I have a variant ready, that copied a small DateFormatCache class into juli. I can post the patch in a few minutes, just want to test first. Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1137731 - in /tomcat/trunk: java/org/apache/juli/OneLineFormatter.java webapps/docs/changelog.xml
A version using the DateFormatCache is available at: http://people.apache.org/~rjung/patches/OneLineFormatter-DateFormatCache.patch Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1137803 - /tomcat/trunk/webapps/docs/changelog.xml
On 21.06.2011 00:28, ma...@apache.org wrote: Author: markt Date: Mon Jun 20 22:28:57 2011 New Revision: 1137803 URL: http://svn.apache.org/viewvc?rev=1137803view=rev Log: Ordering Modified: tomcat/trunk/webapps/docs/changelog.xml I always forget whether there's a standard (I would like to have one): - Ordering of sections: OK, defined by comment in changelog - Ordering inside section: - chronological (oldest first or last)? - first by add, update, fix (in which order?) and then chronological (oldest first or last)? If the rule is clear, I can add it as another comment into the file. Who knows the rules? Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: DO NOT REPLY [Bug 51206] CATALINA_BASE is not visible to setenv.sh
On 21.06.2011 09:54, bugzi...@apache.org wrote: Rainer implemented this in 7.0.x and it will be included in 7.0.17 onwards. Sorry, this BZ slipped my attention. Thanks. Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Multiple catalina.properties
Noticing that e maintain two copies of jarsToSkip lists, one in
catalina.properties and one in TomcatBaseTest, I was thinking about a
test case to compare the two. I then stumbled over our
catalina.properties copy in the startup package, which doesn't have a
jarsToSkip at all.
File java/org/apache/catalina/startup/catalina.properties is identical
to conf/catalina.properties except for:
-common.loader=${catalina.home}/lib,${catalina.home}/lib/*.jar
+common.loader=${catalina.base}/lib,${catalina.base}/lib/*.jar,${catalina.home}/lib,${catalina.home}/lib/*.jar
and the missing jarsToSkip block.
I think there is no reason for these differences and that the file in
the startup package should be the same as the default conf one we ship.
Right?
If so, shouldn't we simply remove the file in startup from svn, and add
a copy to tomcat.classes from the conf version to the copy to classes
part of the compile target? The file is also packaged into the src
jars. For this we can add a copy from conf to startup at the beginning
of the compile and add the file to the svn:ignore. Does that work for you?
Concerning the skipToJars in TomcatBaseTest: What about making
loadProperties in CatalinaProperties protected and use that one to
populate the System Properties that are defined in catalina.properties.
That would also ensre, that we test against any other sysprops we add to
the default catalina.properties, like
tomcat.util.buf.StringCache.byte.enabled=true
Regards,
Rainer
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Multiple catalina.properties
On 23.06.2011 09:42, Rainer Jung wrote:
Noticing that e maintain two copies of jarsToSkip lists, one in
catalina.properties and one in TomcatBaseTest, I was thinking about a
test case to compare the two. I then stumbled over our
catalina.properties copy in the startup package, which doesn't have a
jarsToSkip at all.
File java/org/apache/catalina/startup/catalina.properties is identical
to conf/catalina.properties except for:
-common.loader=${catalina.home}/lib,${catalina.home}/lib/*.jar
+common.loader=${catalina.base}/lib,${catalina.base}/lib/*.jar,${catalina.home}/lib,${catalina.home}/lib/*.jar
and the missing jarsToSkip block.
I think there is no reason for these differences and that the file in
the startup package should be the same as the default conf one we ship.
Right?
If so, shouldn't we simply remove the file in startup from svn, and add
a copy to tomcat.classes from the conf version to the copy to classes
part of the compile target? The file is also packaged into the src
jars. For this we can add a copy from conf to startup at the beginning
of the compile and add the file to the svn:ignore. Does that work for you?
Concerning the skipToJars in TomcatBaseTest: What about making
loadProperties in CatalinaProperties protected and use that one to
populate the System Properties that are defined in catalina.properties.
That would also ensre, that we test against any other sysprops we add to
the default catalina.properties, like
tomcat.util.buf.StringCache.byte.enabled=true
In fact since loadProperties() is automatically called in
CatalinaProperties when loading the class, we don't need to make it
protected. Adding
+// Trigger loading of catalina.properties
+CatalinaProperties.getProperty(foo);
to TomcatBaseTest and of course having jarsToSkip in the startup copy of
catalina.properties is enough.
Regards,
Rainer
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Multiple catalina.properties
On 23.06.2011 11:40, Mark Thomas wrote:
On 23/06/2011 08:42, Rainer Jung wrote:
Noticing that e maintain two copies of jarsToSkip lists, one in
catalina.properties and one in TomcatBaseTest, I was thinking about a
test case to compare the two. I then stumbled over our
catalina.properties copy in the startup package, which doesn't have a
jarsToSkip at all.
File java/org/apache/catalina/startup/catalina.properties is identical
to conf/catalina.properties except for:
-common.loader=${catalina.home}/lib,${catalina.home}/lib/*.jar
+common.loader=${catalina.base}/lib,${catalina.base}/lib/*.jar,${catalina.home}/lib,${catalina.home}/lib/*.jar
and the missing jarsToSkip block.
I think there is no reason for these differences and that the file in
the startup package should be the same as the default conf one we ship.
Right?
Agreed.
If so, shouldn't we simply remove the file in startup from svn, and add
a copy to tomcat.classes from the conf version to the copy to classes
part of the compile target? The file is also packaged into the src
jars. For this we can add a copy from conf to startup at the beginning
of the compile and add the file to the svn:ignore. Does that work for you?
Yep.
Done, copy before compile (copy to classes is automatic then), remove
during clean and svn:ignore set.
Concerning the skipToJars in TomcatBaseTest: What about making
loadProperties in CatalinaProperties protected and use that one to
populate the System Properties that are defined in catalina.properties.
That would also ensre, that we test against any other sysprops we add to
the default catalina.properties, like
tomcat.util.buf.StringCache.byte.enabled=true
Works for me. The more duplication we can remove, the better.
Tested and implemented using the easier trigger loading
CatalinaProperties is enough.
Now we are back to one list to maintain :)
Thanks for your feedback!
Regards,
Rainer
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Overhauling setclasspath.(bat|sh)?
On 21.06.2011 11:40, Konstantin Kolinko wrote: 2011/6/20 Rainer Jung rainer.j...@kippdata.de: 1) Renaming Since quite some time now the setclasspath script doesn't have anything to do with setting a class path. It only searches for JRE / JDK and sets up the path to the Java or JDB binary plus JAVA_ENDORSED_DIRS. So it would be more correct to call it checkjava.sh or setupjava.sh or whatever. Do you think it's too late for TC 7 to rename the script? Good ideas for a new name? The name may be mentioned in mailing list archives or elsewhere. I do not think it is worth renaming, but won't oppose it. Since at least Leon reported back he took the name as a suggestion to include classpath customization in there and I can imagine there are others as well for whom we would break their installation when upgrading, I suggest we postpone renaming to TC 8. That might be the time for a bigger script refactoring using shell and bat functions to keep the catalina and tool-wrapper scripts in sync more easily. 2) Removing BASEDIR In addition it contains a validity check for BASEDIR. This is bogus: whereever setclasspath is sources, we directly before set BASEDIR to the path from which we source setclasspath. In addition, apart from the validity check, BASEDIR is never ever used. It is used: set JAVA_ENDORSED_DIRS=%BASEDIR%\endorsed but given that it always is equal to CATALINA_HOME I think it is OK to replace it with CATALINA_HOME. Removed / repaced in r1138835. Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Using juli DateFormatCache in AccessLogValve?
Since OneLineFormatter now uses the DateFormatCache util class, and to prevent any dependency of juli form other packages that util class sits in juli, what do we think about using it also in AccessLogValve? At the moment the valve has a local copy as an inner class. Of course a dependency on juli is OK, because we have it most of the time for logging, but it is a bit strange, that this time it is for a utility class. What do you think about directly using the juli DateFormatCache in the AccessLogValve? Overall I think the benefits of having the code only once outweigh the strangeness of that kind of dependency. And yes, I removed a small generalization form the class when including it in juli, which I would thean add back to make the same class work for both uses. Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Supporting more general globs in loader definition?
At the moment the file globs we support in the loader definitions in catalina.properties are hard coded to DIRECTORY/*.jar. Sometimes it would be helpful to allow a bit more flexible globs, like e.g. log4j-1.2.*.jar or similar. Would there be any interest if I would investigate whether we can use e.g. the DirectoryScanner from ant to support more general globs? Since we want to define the loader path, we only want to end up with directories and jar files. So one idea would be to filter the result of the DirectoryScanner to only include dirs and jars that match. If we find that more secure, we could also restrict to jars only, because I think that's the most probable use case for globs and picking up any dirs e.g. when using a recursive pattern might not be what the user expected. The result should be compatible to what the users got when using the strict *.jar pattern. Since we scan the directories only on startup and the ant code is mature, I don't expect any problematic performance impact. I don't have a patch yet, but wanted to check for general feedback before investigating more deeply. Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Overhauling setclasspath.(bat|sh)?
Hi Chris, On 23.06.2011 16:29, Christopher Schultz wrote: Rainer, On 6/23/2011 7:33 AM, Rainer Jung wrote: On 21.06.2011 11:40, Konstantin Kolinko wrote: 2011/6/20 Rainer Jung rainer.j...@kippdata.de: 1) Renaming Since quite some time now the setclasspath script doesn't have anything to do with setting a class path. It only searches for JRE / JDK and sets up the path to the Java or JDB binary plus JAVA_ENDORSED_DIRS. So it would be more correct to call it checkjava.sh or setupjava.sh or whatever. Do you think it's too late for TC 7 to rename the script? Good ideas for a new name? The name may be mentioned in mailing list archives or elsewhere. I do not think it is worth renaming, but won't oppose it. Since at least Leon reported back he took the name as a suggestion to include classpath customization in there and I can imagine there are others as well for whom we would break their installation when upgrading, I suggest we postpone renaming to TC 8. That might be the time for a bigger script refactoring using shell and bat functions to keep the catalina and tool-wrapper scripts in sync more easily. It seems reasonable to allow for both setupjava.sh (or whatever the preferred name is) AND setclasspath.sh and prefer the former: if it exists, run that instead of setclasspath.sh. Also, we could issue a WARN message to the console if setclasspath.sh exists yet still run it. We could, but the scripts are already pretty long and complex for simple start scripts. I hesitate making them even harder to understand. I think it's not worth the benefit for TC 7. Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Supporting more general globs in loader definition?
On 23.06.2011 16:34, Rainer Jung wrote: At the moment the file globs we support in the loader definitions in catalina.properties are hard coded to DIRECTORY/*.jar. Sometimes it would be helpful to allow a bit more flexible globs, like e.g. log4j-1.2.*.jar or similar. Would there be any interest if I would investigate whether we can use e.g. the DirectoryScanner from ant to support more general globs? Since we want to define the loader path, we only want to end up with directories and jar files. So one idea would be to filter the result of the DirectoryScanner to only include dirs and jars that match. If we find that more secure, we could also restrict to jars only, because I think that's the most probable use case for globs and picking up any dirs e.g. when using a recursive pattern might not be what the user expected. The result should be compatible to what the users got when using the strict *.jar pattern. Since we scan the directories only on startup and the ant code is mature, I don't expect any problematic performance impact. I don't have a patch yet, but wanted to check for general feedback before investigating more deeply. Sent a bit to quickly: A much simplr solution would be using the Matcher util class we already imported from ant to support globs in the jar scanner skip list. If we only allow the globs to be part of the file name, then the impl would be pretty straightforward using the Matcher. Globs in the file name and not the directory part is the most important use case and easy to understand in its consequences. So I lean towards this type of improvement right now. Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Supporting more general globs in loader definition?
On 23.06.2011 16:51, Christopher Schultz wrote: Rainer, On 6/23/2011 10:39 AM, Rainer Jung wrote: Globs in the file name and not the directory part is the most important use case and easy to understand in its consequences. So I lean towards this type of improvement right now. So: /path/to/*.jar (allowed today) /path/to/foo*.jar(proposed) /path/*/foo.jar (not proposed) /path/**/foo.jar (ant-style ** for any depth, not proposed) ? Any reason not to allow globs in the non-filename path portion? I can't really see a use case for actually wanting a path-glob but am interested in your reasoning. I think there are no very strong arguments for or against supporting globs in directory names and supporting **. I just finished the implementation for only supporting globs in the file name part and that's actually very simple using the util class we already have today. I'd say when defining the class path for Tomcat you want some kind of strictness to avoid unexpected stuff to get loaded. We allow to shortcut the jar list at the moment by loading all Jars from a directory (the *.jar pattern), but I feel a bit uncomfortable with searching recursive via ** and also about whether people understand what it means to include matched directories. The use case I have in mind, is some directoyr with extensions, where you install all of them, but want to choose which ones to load. At the moment you do it by listing all Jars explicitely. Now when upgrading the dependencies and the Jars have versions in their name, you have to update all your CATALINA_BASE/catalina.properties, because you had to include the explicit file names. Using globs like log4j-1.2.*.jar you can keep the config stable for a longer time. Will post a patch to inspect once my testing is done. Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Supporting more general globs in loader definition?
And this would be the patch: http://people.apache.org/~rjung/patches/tc7-loader-glob.patch Regards, Rainer On 23.06.2011 16:39, Rainer Jung wrote: On 23.06.2011 16:34, Rainer Jung wrote: At the moment the file globs we support in the loader definitions in catalina.properties are hard coded to DIRECTORY/*.jar. Sometimes it would be helpful to allow a bit more flexible globs, like e.g. log4j-1.2.*.jar or similar. Would there be any interest if I would investigate whether we can use e.g. the DirectoryScanner from ant to support more general globs? Since we want to define the loader path, we only want to end up with directories and jar files. So one idea would be to filter the result of the DirectoryScanner to only include dirs and jars that match. If we find that more secure, we could also restrict to jars only, because I think that's the most probable use case for globs and picking up any dirs e.g. when using a recursive pattern might not be what the user expected. The result should be compatible to what the users got when using the strict *.jar pattern. Since we scan the directories only on startup and the ant code is mature, I don't expect any problematic performance impact. I don't have a patch yet, but wanted to check for general feedback before investigating more deeply. Sent a bit to quickly: A much simplr solution would be using the Matcher util class we already imported from ant to support globs in the jar scanner skip list. If we only allow the globs to be part of the file name, then the impl would be pretty straightforward using the Matcher. Globs in the file name and not the directory part is the most important use case and easy to understand in its consequences. So I lean towards this type of improvement right now. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Supporting more general globs in loader definition?
On 23.06.2011 19:46, Konstantin Kolinko wrote:
2011/6/23 Rainer Jung rainer.j...@kippdata.de:
At the moment the file globs we support in the loader definitions in
catalina.properties are hard coded to DIRECTORY/*.jar.
Sometimes it would be helpful to allow a bit more flexible globs, like
e.g. log4j-1.2.*.jar or similar.
Would there be any interest if I would investigate whether we can use
e.g. the DirectoryScanner from ant to support more general globs?
Since we want to define the loader path, we only want to end up with
directories and jar files. So one idea would be to filter the result of
the DirectoryScanner to only include dirs and jars that match. If we
find that more secure, we could also restrict to jars only, because I
think that's the most probable use case for globs and picking up any
dirs e.g. when using a recursive pattern might not be what the user
expected.
The result should be compatible to what the users got when using the
strict *.jar pattern.
Since we scan the directories only on startup and the ant code is
mature, I don't expect any problematic performance impact.
I don't have a patch yet, but wanted to check for general feedback
before investigating more deeply.
Regards,
Rainer
So, you are talking about common.loader, shared.loader, and
server.loader values in catalina.properties file.
Yes.
(I somehow thought it was about jarsToSkip).
I added globs there for TC 7.0.3.
It is hard to find a use case for this feature you are asking for.
I will explain below.
The only use case that comes to my mind is to prioritize some jars
over the others.
E.g. to put ${catalina.base}/lib/patch-*.jar ahead of the other
*.jars in the same directory. Though it does not differ much from
using ${catalina.base}/lib/patches/*.jar
Yeah, I didn't think about that one.
So, technically I do not mind allowing any name prefix before *.jar. I
do not think there should be more wide glob support, like allowing '?'
or '*' in any position in the name. Do you have a use case for globs?
Politically, I do not like to have much emphasis on the
common.loader property.
I expect the list of jars to be put in common.loader to be rather
short. You put there the jars used by Tomcat, the jars used by
components declared in server.xml and context files, database drivers.
People should really put everything else into WEB-INF/lib, or use a
VirtualWebappLoader.
Agreed.
As an example of a mess: using the pattern log4j-1.2.*.jar from
your example it is easy to select several versions of Log4J, which
might result in a disaster. If there is only one version of log4j,
why not to copy or symlink it into designated directory? Thus all the
libraries will be in one place and will be easier managed.
See below, it is about updating.
One more note:
I recently added support for arbitrary system properties expansion in
the value of common.loader and other *.loader properties. As a side
effect it is now possible to use whatever Unix command (e.g. find) in
setenv.sh to build a list of jars and define it as a system property.
I saw that, a great improvement.
Summarizing: I do not mind to add support for name*.jar, but will
think twice about anything else.
The only concrete example I have in mind is about adding log4j to Tomcat
to let it log via Log4J.
Here the situation I'm thinking about is a split CATALINA_HOME vs.
CATALINA_BASE installation. Log4J is provided in some extra directory of
CATALINA_HOME using the normal jar file name, e.g. log4j-1.2.16.jar.
The jar will be referenced from catalina.properties in CATALINA_BASE not
using a *.jar pattern, because in the extra dir there is a couple of
jars, some you want to include, some not.
Now when CATALINA_HOME is updated, there might be a new version of log4j
(not: multiple versions) and the entry in catalina.properties does no
longer match, leading to Tomcat using java.util.logging instead.
Of course there are several solutions:
- installing log4j in a directory not used for other jars, so one can
use *.jar
- installing the log4j jar under a name, that does not include the version
- Fixing the entry in catalina.properties as part of the update
- Ignoring the problem, because there might never be another version of
log4j after 1.2.16
But supporting a glob in the file name would also work.
Regards,
Rainer
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Multiple instances of the same Tomcat version (was: svn commit: r1139381)
On 24.06.2011 22:22, Konstantin Kolinko wrote:
2011/6/24 ma...@apache.org:
Author: markt
Date: Fri Jun 24 16:43:40 2011
New Revision: 1139381
URL: http://svn.apache.org/viewvc?rev=1139381view=rev
Log:
Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=50949
Provide the ability to specify the AJP port and service name when installing
Tomcat using the Windows installer. This permits multiple instances of the
same Tomcat version to be installed side-by-side.
It does not permit multiple instances, unless you are able to specify
shutdown port as well.
Though I suspect that for running as a service that value can be -1, thought
1) I have not tested whether that is true lately.
2) if Tomcat is installed to be integrated with an IDE, e.g. to be
used with Eclipse IDE, an explicit shutdown port will be needed. That
is because when you create a Server in Eclipse, it copies
configuration files from existing installation of Tomcat and later
uses the port specified there to stopping launched Tomcat.
I don't know whether that is a good fit for this discussion, but I think
technically the nicest way is to choose a port range and a port
convention, for example:
- AJP: NN09
- HTTP: NN80
- Shutdown: NN05
- HTTPS: NN43
and let the user choose NN or NNN. In server.xml it could be
port=${portBase}80 etc. and in the startup options -DportBase=NN.
Regards,
Rainer
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Using eval vs. exec in shell scripts
On 26.06.2011 01:45, bradleymccrorey wrote: I'll be watching this quite closely. We run thousands of TC6 instances onsite here, and are a daemontools shop. This change breaks daemontools, as the svc command will attempt to stop the tomcat service by sending a TERM to the catalina.sh process, which leaves the child java process still running. For one customer who insists on TC7, I've had to take the measure of changing the catalina.sh script to use the old method for now. This is not maintainable, however. Should there be a bug filed somewhere for this? Cheers, Bradley McCrorey Did you follow the later messages in this discusison thread? I made an error in not including all quotes use din catalina.sh in my simpl test script. So when using the correct scripts, the eval did *not* leave a copy of the shel process hanging around. If you think there is a problem, you can discuss the technical details here, and if the list doesn't find a solution for you, you can open a bug. Regards, Rainer Rainer Jung-3 wrote: Since Mladens change r918873 in March 2010 we use eval instead of exec in the shell scripts. The svn log says: Use eval instead direct call or exec command so that arguments with spaces are properly handled Eval leaves a copy of the shell process hanging around until Tomcat shutdown. I want to experiment with different solutions, but have no idea, what kind of whitespace use the switch from exec to eval was supposed to change. Mladen or whoever else understood this: can you give an example which didn't work with the exec based scripts? Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Using eval vs. exec in shell scripts
On 26.06.2011 17:35, bradleymccrorey wrote: Rainer Jung-3 wrote: Did you follow the later messages in this discusison thread? I made an error in not including all quotes use din catalina.sh in my simpl test script. So when using the correct scripts, the eval did *not* leave a copy of the shel process hanging around. I certainly did, but obviously didn't understand that things were working as expected. Please let me know if I'm misunderstanding. However, if you're saying that the default scripts are working, then I'll definitely have to dispute this. I am :) Observe: [root@c37f9170a86c583d8a16fc7e60e759cf test]# curl -L http://www.fightrice.com/mirrors/apache/tomcat/tomcat-7/v7.0.16/bin/apache-tomcat-7.0.16.tar.gz |tar xzf - % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed 100 7067k 100 7067k0 0 10.0M 0 --:--:-- --:--:-- --:--:-- 10.2M [root@c37f9170a86c583d8a16fc7e60e759cf test]# cd apache-tomcat-7.0.16/ [root@c37f9170a86c583d8a16fc7e60e759cf apache-tomcat-7.0.16]# bin/catalina.sh run Using CATALINA_BASE: /root/test/apache-tomcat-7.0.16 Using CATALINA_HOME: /root/test/apache-tomcat-7.0.16 Using CATALINA_TMPDIR: /root/test/apache-tomcat-7.0.16/temp Using JRE_HOME:/usr Using CLASSPATH: /root/test/apache-tomcat-7.0.16/bin/bootstrap.jar:/root/test/apache-tomcat-7.0.16/bin/tomcat-juli.jar Jun 26, 2011 10:50:22 AM org.apache.catalina.core.AprLifecycleListener init ... INFO: Starting ProtocolHandler [http-bio-8080] Jun 26, 2011 10:50:22 AM org.apache.coyote.AbstractProtocol start INFO: Starting ProtocolHandler [ajp-bio-8009] Jun 26, 2011 10:50:22 AM org.apache.catalina.startup.Catalina start INFO: Server startup in 648 ms [1]+ Stopped bin/catalina.sh run [root@c37f9170a86c583d8a16fc7e60e759cf apache-tomcat-7.0.16]# bg [1]+ bin/catalina.sh run [root@c37f9170a86c583d8a16fc7e60e759cf apache-tomcat-7.0.16]# ps auxww |grep catalina root 1611 0.0 0.4 4576 1116 pts/0S10:50 0:00 /bin/sh bin/catalina.sh run root 1622 14.5 11.0 650752 28236 pts/0Sl 10:50 0:01 /usr/bin/java -Djava.util.logging.config.file=/root/test/apache-tomcat-7.0.16/conf/logging.properties -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Djava.endorsed.dirs=/root/test/apache-tomcat-7.0.16/endorsed -classpath /root/test/apache-tomcat-7.0.16/bin/bootstrap.jar:/root/test/apache-tomcat-7.0.16/bin/tomcat-juli.jar -Dcatalina.base=/root/test/apache-tomcat-7.0.16 -Dcatalina.home=/root/test/apache-tomcat-7.0.16 -Djava.io.tmpdir=/root/test/apache-tomcat-7.0.16/temp org.apache.catalina.startup.Bootstrap start root 1643 0.0 0.2 4000 660 pts/0S+ 10:50 0:00 grep catalina You can clearly see here that there are two processes: one for the shell script, and one for the actual java process. Is this not what I should be seeing? You should, bot only when using run, which is precisely meant to not decouple the console from the process. If you use start, which is the normal sart method, your observations should be different. Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Using eval vs. exec in shell scripts
On 26.06.2011 17:59, bradleymccrorey wrote: Rainer Jung-3 wrote: You can clearly see here that there are two processes: one for the shell script, and one for the actual java process. Is this not what I should be seeing? You should, bot only when using run, which is precisely meant to not decouple the console from the process. Hm. Perhaps we're trying to achieve different things here. With the old scripts, the behavior of the run switch was that the process would not fork, and would remain in the foreground, and only have one process (the java process). The new version seems to imitate this by leaving the running java process in the foreground of the current shell. However, there are still *2* processes: one for the catalina.sh, and one for java. This is a fundamental change in the way the script behaves. Does this clarify what I'm trying to achieve? Sorry if I'm being thick-headed, and thanks very much for your consideration. Fixed for run in r1139904. Please try the following change (eval - eval exec): Index: catalina.sh === --- catalina.sh (revision 1139151) +++ catalina.sh (working copy) @@ -312,7 +312,7 @@ echo Using Security Manager fi shift -eval \$_RUNJAVA\ \$LOGGING_CONFIG\ $JAVA_OPTS $CATALINA_OPTS \ +eval exec \$_RUNJAVA\ \$LOGGING_CONFIG\ $JAVA_OPTS $CATALINA_OPTS \ -Djava.endorsed.dirs=\$JAVA_ENDORSED_DIRS\ -classpath \$CLASSPATH\ \ -Djava.security.manager \ -Djava.security.policy==\$CATALINA_BASE/conf/catalina.policy\ \ @@ -321,7 +321,7 @@ -Djava.io.tmpdir=\$CATALINA_TMPDIR\ \ org.apache.catalina.startup.Bootstrap $@ start else -eval \$_RUNJAVA\ \$LOGGING_CONFIG\ $JAVA_OPTS $CATALINA_OPTS \ +eval exec \$_RUNJAVA\ \$LOGGING_CONFIG\ $JAVA_OPTS $CATALINA_OPTS \ -Djava.endorsed.dirs=\$JAVA_ENDORSED_DIRS\ -classpath \$CLASSPATH\ \ -Dcatalina.base=\$CATALINA_BASE\ \ -Dcatalina.home=\$CATALINA_HOME\ \ Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: JK 1.2.32 release kick
+1, great! On 27.06.2011 20:03, Mladen Turk wrote: Hi, I have a time slot available so I volunteer as a 1.2.32 RM. Think we are good for a new release. Comments, objections? - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
response.encodeURL(http://localhost:8080) produces an invalid URL?
Motivated by https://issues.apache.org/jira/browse/WICKET-3841 I tested response.encodeURL(http://localhost:8080;) and I get http://localhost:8080;jsessionid=... (cookies off). Note that there is no slash between the port and the sessionid path info. According to my reading of RFC3986 (URIs), the input URI is a correct URI, the resulting URI is not: because it has an authority, the rest must be zero or more path-abempty, which always start with a slash. Did anyone stumble over this yet? If there's no objections, I'll write a patch and check, what the TCK has to say. The spec does not see to contain any specification of encodeURL apart from the JavaDoc. Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
