RE: org.apache.tomcat.util.net.AbstractEndpoint#shutdownExecutor lasts 5s?
Romain, what you could do for a work around right now, is to set an executor yourself. This way, Tomcat won't attempt to stop it, and there wont be a delay. http://tomcat.apache.org/tomcat-7.0-doc/config/executor.html the only time tomcat attempts to stop the executor, is if it created it, but if you pass in an executor, tomcat wont stop it. Filip -Original Message- From: Romain Manni-Bucau [mailto:rmannibu...@gmail.com] Sent: Wednesday, November 06, 2013 7:12 AM To: Tomcat Developers List Subject: org.apache.tomcat.util.net.AbstractEndpoint#shutdownExecutor lasts 5s? Hi does org.apache.tomcat.util.net.AbstractEndpoint#shutdownExecutor have to last 5s since something was done (request) on the instance? My issue is with arquillian (tomcat and tomee) we need to wait some seconds (engouh to be human visible). When running a single test (I'm not Linus Torvald so I need to debug sometimes ;) it is not that nice. Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
I'm back
Ladies and Gentlemen, I'm back, it will take a little while to get up to speed on all changes but I intend to get involved again, so go easy on me while I learn the new tools of the trade ;) Filip - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
RE: org.apache.tomcat.util.net.AbstractEndpoint#shutdownExecutor lasts 5s?
http-bio-1234-exec-19 daemon prio=10 tid=0x7fc30c014000 nid=0x5bb2 runnable [0x7fc31250f000] java.lang.Thread.State: RUNNABLE at java.net.SocketInputStream.socketRead0(Native Method) at java.net.SocketInputStream.read(SocketInputStream.java:152) at java.net.SocketInputStream.read(SocketInputStream.java:122) this is a connection kept alive from a client, and Tomcat is waiting for it to send the next request until it times out. Filip -Original Message- From: Romain Manni-Bucau [mailto:rmannibu...@gmail.com] Sent: Wednesday, November 06, 2013 10:04 AM To: Tomcat Developers List Subject: Re: org.apache.tomcat.util.net.AbstractEndpoint#shutdownExecutor lasts 5s? Well if the server does something I'll do. Here is my thread dump: https://gist.github.com/rmannibucau/156c39bed29270cd5e06 Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2013/11/6 Mark Thomas ma...@apache.org: On 06/11/2013 16:58, Mark Thomas wrote: On 06/11/2013 16:49, Romain Manni-Bucau wrote: it is too long. If I try to summarize the execution of tests here what the user feel: 1) tomcat starts (ok a bit long) - understandable so OK 2) tests are executed (~ fast if you don't abuse of shrinkwrap things) - OK 3) tomcat shutdown (after tests) - KO: the server doesn't anything more (no more requests to process) but is waiting for its executor to shutdown Thanks, I think I understand now. There should only be a delay at point 3 if the server is still doing something otherwise the executor shut down should be pretty much immediate. If the executor is taking a noticeable time to shut down then it would be worth looking at what the threads are doing. If memory serves me correctly, this was added to enable a more graceful shutdown of WebSocket connections when the server and/or connector were stopped. This is not blocking at all, I just wanted to report this is not as nice as before when it was synchronous and that a little config would help a lot (or maybe another algo). It could be made configurable but in the case you describe above it looks like there might be some other issue at play here. Oh, and open an enhancement request so this doesn't get lost. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
RE: [VOTE] Apache Tomcat Maven plugin 2.2
+1 -Original Message- From: Olivier Lamy [mailto:ol...@apache.org] Sent: Wednesday, November 06, 2013 6:05 PM To: Tomcat Developers List Subject: [VOTE] Apache Tomcat Maven plugin 2.2 Hi, I'd like to release Apache Tomcat Maven plugin 2.2. We fixed 22 issues. See https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=1231212 0version=12323925 Maven Staging repository: https://repository.apache.org/content/repositories/orgapachetomcat-085/ Source release artifact: https://dist.apache.org/repos/dist/dev/tomcat/maven-plugin/v2.2/ Site: http://tomcat.apache.org/maven-plugin-2.2 Vote open for 72H [+1] [0] [-1] Thanks -- Olivier Lamy Ecetera: http://ecetera.com.au http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
RE: svn commit: r1377689 - /tomcat/trunk/java/org/apache/catalina/core/JreMemoryLeakPreventionListener.java
-Original Message- From: Konstantin Kolinko [mailto:knst.koli...@gmail.com] Sent: Monday, August 27, 2012 2:09 PM To: Tomcat Developers List Subject: Re: svn commit: r1377689 - /tomcat/trunk/java/org/apache/catalina/core/JreMemoryLeakPreventionListe ner.java 2012/8/27 Mark Thomas ma...@apache.org: On 27/08/2012 15:20, fha...@apache.org wrote: Author: fhanik Date: Mon Aug 27 14:20:55 2012 New Revision: 1377689 URL: http://svn.apache.org/viewvc?rev=1377689view=rev Log: Per http://markmail.org/message/nqnogctvfuyzhtol 1. Already encountered two users that would like to set this value. There is never any need to hard code any value, regardless of its use What is the use case for wanting to set this value? I can understand users not liking the previous value that triggered a full GC every hour and wanting to change that but I fail to see why anyone would want to change this now it is set to trigger a full GC every 290 million years or so. 2. This turns it into a property on the listener Thanks. If the feature is retained, that is a much better implementation. Re: 1: Maybe somebody wants their full GC once an hour, or once a day? There are documentation glitches yet to be fixed: a. systemprops.xml change in trunk was not reverted by this commit. It was reverted in 7.0.x only. [Filip Hanik] I don't see the property in trunk, do you? b. The new property is yet to be documented in listeners.xml. [Filip Hanik] Done Filip Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
RE: svn commit: r1377689 - /tomcat/trunk/java/org/apache/catalina/core/JreMemoryLeakPreventionListener.java
-Original Message- From: Konstantin Kolinko [mailto:knst.koli...@gmail.com] Sent: Monday, August 27, 2012 3:41 PM To: Tomcat Developers List Subject: Re: svn commit: r1377689 - /tomcat/trunk/java/org/apache/catalina/core/JreMemoryLeakPreventionListe ner.java 2012/8/28 Filip Hanik (mailing lists) devli...@hanik.com: There are documentation glitches yet to be fixed: a. systemprops.xml change in trunk was not reverted by this commit. It was reverted in 7.0.x only. [Filip Hanik] I don't see the property in trunk, do you? I took care of that an hour ago. http://svn.apache.org/viewvc?rev=1377831view=rev [Filip Hanik] Got it, what's the point of the following code change? -method.invoke(null, getGcDaemonPeriod()); +method.invoke(null, Long.valueOf(getGcDaemonPeriod())); b. The new property is yet to be documented in listeners.xml. [Filip Hanik] Done Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
RE: svn commit: r1377689 - /tomcat/trunk/java/org/apache/catalina/core/JreMemoryLeakPreventionListener.java
-Original Message- From: Mark Thomas [mailto:ma...@apache.org] Sent: Monday, August 27, 2012 3:44 PM To: Tomcat Developers List Subject: Re: svn commit: r1377689 - /tomcat/trunk/java/org/apache/catalina/core/JreMemoryLeakPreventionListe ner.java On 27/08/2012 22:37, Filip Hanik (mailing lists) wrote: -Original Message- From: Konstantin Kolinko [mailto:knst.koli...@gmail.com] Sent: Monday, August 27, 2012 2:09 PM To: Tomcat Developers List Subject: Re: svn commit: r1377689 - /tomcat/trunk/java/org/apache/catalina/core/JreMemoryLeakPreventionListe ner.java 2012/8/27 Mark Thomas ma...@apache.org: On 27/08/2012 15:20, fha...@apache.org wrote: Author: fhanik Date: Mon Aug 27 14:20:55 2012 New Revision: 1377689 URL: http://svn.apache.org/viewvc?rev=1377689view=rev Log: Per http://markmail.org/message/nqnogctvfuyzhtol 1. Already encountered two users that would like to set this value. There is never any need to hard code any value, regardless of its use What is the use case for wanting to set this value? I can understand users not liking the previous value that triggered a full GC every hour and wanting to change that but I fail to see why anyone would want to change this now it is set to trigger a full GC every 290 million years or so. Maybe somebody wants their full GC once an hour, or once a day? That is not what this listener is for. The listener's purpose is to prevent memory leaks, not provide options that allow users to tinker with internal JVM GC settings. I have yet to see a valid use case for this new attribute. [Filip Hanik] The use case is very much valid, as if they had previously called that method, your code will override it. So in effect, you're hard coding the GC interval, but not letting a user control it. It's not tomcat's role to configure GC intervals. It may be that tomcat somehow initiated the GC interval, and if that is the case, it must expose the actual interval to the user. Tomcat should not change JVM settings without letting the user configure them, Filip - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
RE: svn commit: r1377689 - /tomcat/trunk/java/org/apache/catalina/core/JreMemoryLeakPreventionListener.java
-Original Message-
From: Mark Thomas [mailto:ma...@apache.org]
Sent: Monday, August 27, 2012 3:55 PM
To: Tomcat Developers List
Subject: Re: svn commit: r1377689 -
/tomcat/trunk/java/org/apache/catalina/core/JreMemoryLeakPreventionListe
ner.java
On 27/08/2012 22:48, Filip Hanik (mailing lists) wrote:
-Original Message-
From: Mark Thomas [mailto:ma...@apache.org]
Sent: Monday, August 27, 2012 3:44 PM
To: Tomcat Developers List
Subject: Re: svn commit: r1377689 -
/tomcat/trunk/java/org/apache/catalina/core/JreMemoryLeakPreventionListe
ner.java
On 27/08/2012 22:37, Filip Hanik (mailing lists) wrote:
-Original Message-
From: Konstantin Kolinko [mailto:knst.koli...@gmail.com]
Sent: Monday, August 27, 2012 2:09 PM
To: Tomcat Developers List
Subject: Re: svn commit: r1377689 -
/tomcat/trunk/java/org/apache/catalina/core/JreMemoryLeakPreventionListe
ner.java
2012/8/27 Mark Thomas ma...@apache.org:
On 27/08/2012 15:20, fha...@apache.org wrote:
Author: fhanik
Date: Mon Aug 27 14:20:55 2012
New Revision: 1377689
URL: http://svn.apache.org/viewvc?rev=1377689view=rev
Log:
Per http://markmail.org/message/nqnogctvfuyzhtol
1. Already encountered two users that would like to set this
value.
There is
never any need to hard code any value, regardless of its use
What is the use case for wanting to set this value? I can
understand
users not liking the previous value that triggered a full GC every
hour
and wanting to change that but I fail to see why anyone would want
to
change this now it is set to trigger a full GC every 290 million
years
or so.
Maybe somebody wants their full GC once an hour, or once a day?
That is not what this listener is for. The listener's purpose is to
prevent memory leaks, not provide options that allow users to tinker
with internal JVM GC settings.
I have yet to see a valid use case for this new attribute.
[Filip Hanik]
The use case is very much valid, as if they had previously called that
method, your code will override it.
So in effect, you're hard coding the GC interval, but not letting a
user
control it.
Nope. You should have looked at the implementation of
sun.misc.GC#requestLatency(long) rather than assuming how it worked.
It's not tomcat's role to configure GC intervals. It may be that
tomcat
somehow initiated the GC interval, and if that is the case, it must
expose
the actual interval to the user. Tomcat should not change JVM settings
without letting the user configure them,
Tomcat setting this value has zero impact on any user code or JRE code
that sets a lower value either before Tomcat sets it or after.
I still see no valid use case for this attribute and without a valid use
case my veto remains.
[Filip Hanik]
Now you're just being stubborn. It would be like me going back and vetoing
the hard coded value, and we'd run around in circles like little chickens.
The reason I think the veto is unreasonable is that there is no
functionality removed with this. There is nothing to be lost.
IIRC any call changes the value, since there is only one daemon thread
created. And since gcDaemonProtection is true by default means that 99.9% of
tomcat instances will have this daemon thread running. Since we have this
thread running, then we might as well hand out the ability to the users.
Since you are turning this thread on, give them the ability to change the
interval at which it is running.
141 } else {
142 /* Notify the existing daemon thread
143 * that the lateency target has changed
144 */
145 lock.notify();
146 }
Mark
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
RE: pooledconnection tccl?
I've thought about this, you see if it is using TCCL it will cause a memory leak on app reload as the app wont be unloaded due to the pool holding it. But I think we should make it an option Best Filip -Original Message- From: Romain Manni-Bucau [mailto:rmannibu...@gmail.com] Sent: Wednesday, August 22, 2012 3:14 AM To: Tomcat Developers List Subject: Re: pooledconnection tccl? if the resource is an app resource it should be closed with the stop() and recreated with the start *Romain Manni-Bucau* *Twitter: @rmannibucau* *Blog: http://rmannibucau.wordpress.com* 2012/8/22 Pid * p...@pidster.com On 19 Aug 2012, at 19:11, Romain Manni-Bucau rmannibu...@gmail.com wrote: Hi, org.apache.tomcat.jdbc.pool.PooledConnection#connectUsingDriver uses tomcat classloader to create the driver, couldn't it be the TCCL? this way it could allow to provide the driver in the webapp. What would happen if the app is reloaded? p *Romain Manni-Bucau* *Twitter: @rmannibucau* *Blog: http://rmannibucau.wordpress.com* - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
RE: tomat-jdbc hashCode
Fixed in r1370074 and r1370075 http://svn.apache.org/viewvc?rev=1370075view=rev http://svn.apache.org/viewvc?rev=1370074view=rev -Original Message- From: Filip Hanik Mailing Lists [mailto:devli...@hanik.com] Sent: Monday, July 30, 2012 5:58 AM To: Tomcat Developers List Subject: Re: tomat-jdbc hashCode nope, I will fix that Filip - Original Message - From: Romain Manni-Bucau rmannibu...@gmail.com To: Tomcat Developers List dev@tomcat.apache.org Sent: Tuesday, July 24, 2012 5:18:32 PM Subject: tomat-jdbc hashCode Hi, just noticed tomcat jdbc doesn't manage hashCode if the connection is already close (it is in org.apache.tomcat.jdbc.pool.JdbcInterceptor). Any reason to do so? - Romain - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: tomat-jdbc hashCode
nope, I will fix that Filip - Original Message - From: Romain Manni-Bucau rmannibu...@gmail.com To: Tomcat Developers List dev@tomcat.apache.org Sent: Tuesday, July 24, 2012 5:18:32 PM Subject: tomat-jdbc hashCode Hi, just noticed tomcat jdbc doesn't manage hashCode if the connection is already close (it is in org.apache.tomcat.jdbc.pool.JdbcInterceptor). Any reason to do so? - Romain - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
RE: Unit tests and trunk
Oracle reopened http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7115226 based on the bug we filed http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7183450 Filip -Original Message- From: Mark Thomas [mailto:ma...@apache.org] Sent: Thursday, July 12, 2012 1:30 AM To: Tomcat Developers List Subject: Re: Unit tests and trunk On 12/07/2012 02:05, Filip Hanik wrote: I can reproduce the bug in both our unit tests and the original bug report. further more I can turn non blocking into blocking by opening an closing a selector that is never used. definitely a bug, since a jvm/network flag resolves it. while your vm may support ipv6, there is still an additional software layer. Indeed and all are present. The reason I said it claims to support IPv6 is that I hadn't tested it to confirm what the OS was claiming was indeed true. I'm sure there will be more bug reports as more people turn to java 7 on windows/hardware Yep. Mark Sent from my iPhone On Jul 11, 2012, at 16:42, Mark Thomas ma...@apache.org wrote: On 11/07/2012 23:30, Filip Hanik (mailing lists) wrote: I wasn't able to reproduce on a Win 7 VM because the VM environment itself doesn't support IPv6 Given who we work for, the opportunities for humorous comments is extensive :) I'll settle for saying that I've double checked the VM I have and it does (claim to) support IPv6. I'll try out the test case provided in the original bug report. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1360729 - in /tomcat/trunk: ./ modules/jdbc-pool/src/test/java/org/apache/tomcat/jdbc/test/driver/ res/dbcp/
not sure if they want to make Java 7 minimum requirement - Original Message - From: sebb seb...@gmail.com To: Tomcat Developers List dev@tomcat.apache.org Sent: Saturday, July 14, 2012 8:04:42 PM Subject: Re: svn commit: r1360729 - in /tomcat/trunk: ./ modules/jdbc-pool/src/test/java/org/apache/tomcat/jdbc/test/driver/ res/dbcp/ Do these patches need to be fed back to Commons DBCP? Or do they only apply to the version embedded by Tomcat? On 14 July 2012 21:47, Rainer Jung rainer.j...@kippdata.de wrote: On 14.07.2012 22:25, Filip Hanik Mailing Lists wrote: I know, it's the same patch for DBCP as for DBCP2. Roger that. we can fix it, not urgent though No hurry, maybe we'll be on DBCP2 until the first TC 8 release. Rainer - Original Message - From: Rainer Jung rainer.j...@kippdata.de To: dev@tomcat.apache.org Sent: Friday, July 13, 2012 3:47:27 AM Subject: Re: svn commit: r1360729 - in /tomcat/trunk: ./ modules/jdbc-pool/src/test/java/org/apache/tomcat/jdbc/test/driver/ res/dbcp/ On 12.07.2012 17:38, fha...@apache.org wrote: Author: fhanik Date: Thu Jul 12 15:38:28 2012 New Revision: 1360729 URL: http://svn.apache.org/viewvc?rev=1360729view=rev Log: Configure Tomcat trunk to build with Java 7. This includes adding a patch to the Commons-DBCP code from res/dbcp Added: tomcat/trunk/res/dbcp/ tomcat/trunk/res/dbcp/dbcp-java-7.patch (with props) Just an info: when compiling TC trunk with Java 7 and ant 1.8.2 a few minutes ago, many of the offsets when applying the patch were quite big: [copy] Copying 68 files to /shared/build/dev/tomcat/deps/tomcat8-deps/tomcat8-deps/dbcp [patch] patching file src/java/org/apache/commons/dbcp/DelegatingCallableStatement.java [patch] Hunk #1 succeeded at 660 (offset -114 lines). [patch] patching file src/java/org/apache/commons/dbcp/cpdsadapter/DriverAdapterCPDS.java [patch] patching file src/java/org/apache/commons/dbcp/DelegatingResultSet.java [patch] Hunk #1 succeeded at 1078 (offset -196 lines). [patch] patching file src/java/org/apache/commons/dbcp/PoolingDataSource.java [patch] Hunk #1 succeeded at 437 (offset -52 lines). [patch] patching file src/java/org/apache/commons/dbcp/DelegatingConnection.java [patch] Hunk #1 succeeded at 678 (offset -126 lines). [patch] patching file src/java/org/apache/commons/dbcp/PoolingDriver.java [patch] Hunk #1 succeeded at 496 (offset -5 lines). [patch] patching file src/java/org/apache/commons/dbcp/DelegatingStatement.java [patch] Hunk #1 succeeded at 385 (offset -144 lines). [patch] patching file src/java/org/apache/commons/dbcp/DelegatingDatabaseMetaData.java [patch] Hunk #1 succeeded at 1206 (offset -171 lines). [patch] patching file src/java/org/apache/commons/dbcp/BasicDataSource.java [patch] Hunk #1 succeeded at 28 with fuzz 1. [patch] Hunk #2 succeeded at 1580 (offset -221 lines). [patch] patching file src/java/org/apache/commons/dbcp/datasources/InstanceKeyDataSource.java [patch] Hunk #1 succeeded at 887 (offset -1 lines). Compilation for everything including DBCP works though. Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1360729 - in /tomcat/trunk: ./ modules/jdbc-pool/src/test/java/org/apache/tomcat/jdbc/test/driver/ res/dbcp/
I know, it's the same patch for DBCP as for DBCP2. we can fix it, not urgent though - Original Message - From: Rainer Jung rainer.j...@kippdata.de To: dev@tomcat.apache.org Sent: Friday, July 13, 2012 3:47:27 AM Subject: Re: svn commit: r1360729 - in /tomcat/trunk: ./ modules/jdbc-pool/src/test/java/org/apache/tomcat/jdbc/test/driver/ res/dbcp/ On 12.07.2012 17:38, fha...@apache.org wrote: Author: fhanik Date: Thu Jul 12 15:38:28 2012 New Revision: 1360729 URL: http://svn.apache.org/viewvc?rev=1360729view=rev Log: Configure Tomcat trunk to build with Java 7. This includes adding a patch to the Commons-DBCP code from res/dbcp Added: tomcat/trunk/res/dbcp/ tomcat/trunk/res/dbcp/dbcp-java-7.patch (with props) Just an info: when compiling TC trunk with Java 7 and ant 1.8.2 a few minutes ago, many of the offsets when applying the patch were quite big: [copy] Copying 68 files to /shared/build/dev/tomcat/deps/tomcat8-deps/tomcat8-deps/dbcp [patch] patching file src/java/org/apache/commons/dbcp/DelegatingCallableStatement.java [patch] Hunk #1 succeeded at 660 (offset -114 lines). [patch] patching file src/java/org/apache/commons/dbcp/cpdsadapter/DriverAdapterCPDS.java [patch] patching file src/java/org/apache/commons/dbcp/DelegatingResultSet.java [patch] Hunk #1 succeeded at 1078 (offset -196 lines). [patch] patching file src/java/org/apache/commons/dbcp/PoolingDataSource.java [patch] Hunk #1 succeeded at 437 (offset -52 lines). [patch] patching file src/java/org/apache/commons/dbcp/DelegatingConnection.java [patch] Hunk #1 succeeded at 678 (offset -126 lines). [patch] patching file src/java/org/apache/commons/dbcp/PoolingDriver.java [patch] Hunk #1 succeeded at 496 (offset -5 lines). [patch] patching file src/java/org/apache/commons/dbcp/DelegatingStatement.java [patch] Hunk #1 succeeded at 385 (offset -144 lines). [patch] patching file src/java/org/apache/commons/dbcp/DelegatingDatabaseMetaData.java [patch] Hunk #1 succeeded at 1206 (offset -171 lines). [patch] patching file src/java/org/apache/commons/dbcp/BasicDataSource.java [patch] Hunk #1 succeeded at 28 with fuzz 1. [patch] Hunk #2 succeeded at 1580 (offset -221 lines). [patch] patching file src/java/org/apache/commons/dbcp/datasources/InstanceKeyDataSource.java [patch] Hunk #1 succeeded at 887 (offset -1 lines). Compilation for everything including DBCP works though. Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
RE: access to build environment
-Original Message- From: Mark Thomas [mailto:ma...@apache.org] Sent: Thursday, July 12, 2012 1:33 AM To: Tomcat Developers List Subject: Re: access to build environment On 12/07/2012 02:06, Filip Hanik wrote: I'd guess those two, do we use anything else for tomcat ci? Not on ASF infrastructure. The first step is to get trunk building with 1.7. It doesn't at the moment because of some jdbc-pool tests that implement some of the SQL interfaces. Fix those and we can change the source version in the build and see what breaks. Gump we can fix directly. buildbot we may need to ask infra to fix (whch means I might have the karma to fix it anyway). [Filip Hanik] You got it. I'll be removing the jdbc-pool externals and do a svn copy for Tomcat 7. That way I can refactor in trunk even for jdbc-pool. Mark Sent from my iPhone On Jul 11, 2012, at 16:42, Mark Thomas ma...@apache.org wrote: On 11/07/2012 23:40, Filip Hanik (mailing lists) wrote: How do I get access to the build environment? Which build environment? Gump, buildbot, something else? Mark So we can change the build to default to Java 7 Filip - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
RE: svn commit: r1360905 - /tomcat/trunk/java/org/apache/tomcat/util/net/NioSelectorPool.java
You are correct, I was chasing down the following:
Testsuite: org.apache.catalina.websocket.TestWebSocket
Tests run: 6, Failures: 1, Errors: 0, Time elapsed: 2.048 sec
INFO: Starting ProtocolHandler [http-nio-127.0.0.1-auto-2-9027]
Jul 12, 2012 11:56:27 AM
org.apache.coyote.AbstractProtocol$AbstractConnectionHandler process
SEVERE: null
java.lang.IllegalArgumentException: Negative timeout
at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
at
org.apache.tomcat.util.net.NioSelectorPool.read(NioSelectorPool.java:267)
at
org.apache.tomcat.util.net.NioSelectorPool.read(NioSelectorPool.java:227)
at
org.apache.coyote.http11.upgrade.UpgradeNioProcessor.readSocket(UpgradeNioProcessor.java:139)
at
org.apache.coyote.http11.upgrade.UpgradeNioProcessor.read(UpgradeNioProcessor.java:112)
at org.apache.catalina.websocket.WsFrame.nextFrame(WsFrame.java:213)
at
org.apache.catalina.websocket.WsInputStream.nextFrame(WsInputStream.java:68)
at
org.apache.catalina.websocket.StreamInbound.onData(StreamInbound.java:117)
at
org.apache.coyote.http11.upgrade.UpgradeProcessor.upgradeDispatch(UpgradeProcessor.java:83)
at
org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:583)
at
org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.process(Http11NioProtocol.java:223)
at
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1676)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)
We should not use -1 in our unit tests. I'm tempted to get rid of the -1 notion
all together, no sane person should ever use no timeout :)
-Original Message-
From: Mark Thomas [mailto:ma...@apache.org]
Sent: Thursday, July 12, 2012 2:20 PM
To: Tomcat Developers List
Subject: Re: svn commit: r1360905 -
/tomcat/trunk/java/org/apache/tomcat/util/net/NioSelectorPool.java
On 12/07/2012 21:11, fha...@apache.org wrote:
Author: fhanik
Date: Thu Jul 12 20:11:31 2012
New Revision: 1360905
URL: http://svn.apache.org/viewvc?rev=1360905view=rev
Log:
Correct handling of timeout - negative or zero means no timeout but an
instant
Nope. The expected and documented behaviour for a negative timeout for
all connectors is an infinite timeout.
Mark
Modified:
tomcat/trunk/java/org/apache/tomcat/util/net/NioSelectorPool.java
Modified:
tomcat/trunk/java/org/apache/tomcat/util/net/NioSelectorPool.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/util/ne
t/NioSelectorPool.java?rev=1360905r1=1360904r2=1360905view=diff
==
--- tomcat/trunk/java/org/apache/tomcat/util/net/NioSelectorPool.java
(original)
+++ tomcat/trunk/java/org/apache/tomcat/util/net/NioSelectorPool.java
Thu Jul 12 20:11:31 2012
@@ -196,7 +196,11 @@ public class NioSelectorPool {
//register OP_WRITE to the selector
if (key==null) key =
socket.getIOChannel().register(selector, SelectionKey.OP_WRITE);
else key.interestOps(SelectionKey.OP_WRITE);
-keycount = selector.select(writeTimeout);
+if (writeTimeout=0) {
+keycount = selector.selectNow();
+} else {
+keycount = selector.select(writeTimeout);
+}
}
if (writeTimeout 0 (selector == null || keycount
== 0) ) timedout = (System.currentTimeMillis()-time)=writeTimeout;
}//while
@@ -264,7 +268,11 @@ public class NioSelectorPool {
//register OP_WRITE to the selector
if (key==null) key =
socket.getIOChannel().register(selector, SelectionKey.OP_READ);
else key.interestOps(SelectionKey.OP_READ);
-keycount = selector.select(readTimeout);
+if (readTimeout=0) {
+keycount = selector.selectNow();
+} else {
+keycount = selector.select(readTimeout);
+}
}
if (readTimeout 0 (selector == null || keycount
== 0) ) timedout = (System.currentTimeMillis()-time)=readTimeout;
}//while
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional
RE: Current unit test behaviour for trunk using Java 7 on Solaris
Fixed in http://svn.apache.org/viewvc?view=revisionrevision=1360917 DBCP should compile as well as JDBC-POOL with 1.7 now too -Original Message- From: Rainer Jung [mailto:rainer.j...@kippdata.de] Sent: Thursday, July 12, 2012 6:33 AM To: Tomcat Developers List Subject: Current unit test behaviour for trunk using Java 7 on Solaris Versions TC trunk r1360616 tested with Java 1.7.0_05 on Solaris 10 Sparc. Compiled everything with the same JVM version using compile.source=1.7 compile.target=1.7 except for DBCP which was compiled with Java 6. Unit test failures == One test failure, namely org.apache.catalina.websocket.TestWebSocket for NIO: Testcase: testKey took 4.628 sec Testcase: testBug53339 took 0.262 sec Testcase: testSimple took 0.585 sec FAILED junit.framework.AssertionFailedError: at org.apache.catalina.websocket.TestWebSocket$WebSocketClient.readMessage( TestWebSocket.java:419) at org.apache.catalina.websocket.TestWebSocket$WebSocketClient.access$300(T estWebSocket.java:343) at org.apache.catalina.websocket.TestWebSocket.testSimple(TestWebSocket.jav a:99) Testcase: testNoConnection took 0.555 sec Testcase: testNoUpgrade took 0.425 sec Testcase: testDetectWrongVersion took 0.377 sec possibly due to the following exception which is not happening for BIO and APR (negative Timeout): [junit] 12-Jul-2012 13:19:24.329 INFO [main] org.apache.coyote.AbstractProtocol.pause Pausing ProtocolHandler [http-nio-127.0.0.1-auto-2-48250] [junit] 12-Jul-2012 13:19:24.330 SEVERE [http-nio-127.0.0.1-auto-2-exec-1] org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process null [junit] java.lang.IllegalArgumentException: Negative timeout [junit] at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97) [junit] at org.apache.tomcat.util.net.NioSelectorPool.read(NioSelectorPool.java:267 ) [junit] at org.apache.tomcat.util.net.NioSelectorPool.read(NioSelectorPool.java:227 ) [junit] at org.apache.coyote.http11.upgrade.UpgradeNioProcessor.readSocket(UpgradeN ioProcessor.java:139) [junit] at org.apache.coyote.http11.upgrade.UpgradeNioProcessor.read(UpgradeNioProc essor.java:112) [junit] at org.apache.catalina.websocket.WsFrame.nextFrame(WsFrame.java:213) [junit] at org.apache.catalina.websocket.WsInputStream.nextFrame(WsInputStream.java :68) [junit] at org.apache.catalina.websocket.StreamInbound.onData(StreamInbound.java:11 7) [junit] at org.apache.coyote.http11.upgrade.UpgradeProcessor.upgradeDispatch(Upgrad eProcessor.java:83) [junit] at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(Abs tractProtocol.java:583) [junit] at org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.proce ss(Http11NioProtocol.java:223) [junit] at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.j ava:1676) [junit] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.jav a:1110) [junit] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.ja va:603) [junit] at java.lang.Thread.run(Thread.java:722) [junit] [junit] 12-Jul-2012 13:19:24.381 INFO [main] org.apache.catalina.core.StandardService.stopInternal Stopping service Tomcat ... [junit] 12-Jul-2012 13:19:24.769 INFO [main] org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler [http-nio-127.0.0.1-auto-3-48253] [junit] 12-Jul-2012 13:19:24.795 SEVERE [http-nio-127.0.0.1-auto-3-exec-1] org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process null [junit] java.lang.IllegalArgumentException: Negative timeout [junit] at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97) [junit] at org.apache.tomcat.util.net.NioSelectorPool.read(NioSelectorPool.java:267 ) [junit] at org.apache.tomcat.util.net.NioSelectorPool.read(NioSelectorPool.java:227 ) [junit] at org.apache.coyote.http11.upgrade.UpgradeNioProcessor.readSocket(UpgradeN ioProcessor.java:139) [junit] at org.apache.coyote.http11.upgrade.UpgradeNioProcessor.read(UpgradeNioProc essor.java:98) [junit] at org.apache.catalina.websocket.WsFrame.blockingRead(WsFrame.java:149) [junit] at org.apache.catalina.websocket.WsFrame.init(WsFrame.java:66) [junit] at org.apache.catalina.websocket.WsFrame.nextFrame(WsFrame.java:215) [junit] at org.apache.catalina.websocket.WsInputStream.nextFrame(WsInputStream.java :68) [junit] at org.apache.catalina.websocket.WsInputStream.makePayloadDataAvailable(WsI nputStream.java:136) [junit] at org.apache.catalina.websocket.WsInputStream.read(WsInputStream.java:103) [junit] at
Re: Current unit test behaviour for trunk using Java 7 on Solaris
and properly fixed in http://svn.apache.org/viewvc?view=revisionrevision=1360929 - Original Message - From: Filip Hanik (mailing lists) devli...@hanik.com To: Tomcat Developers List dev@tomcat.apache.org Sent: Thursday, July 12, 2012 2:43:55 PM Subject: RE: Current unit test behaviour for trunk using Java 7 on Solaris Fixed in http://svn.apache.org/viewvc?view=revisionrevision=1360917 DBCP should compile as well as JDBC-POOL with 1.7 now too -Original Message- From: Rainer Jung [mailto:rainer.j...@kippdata.de] Sent: Thursday, July 12, 2012 6:33 AM To: Tomcat Developers List Subject: Current unit test behaviour for trunk using Java 7 on Solaris Versions TC trunk r1360616 tested with Java 1.7.0_05 on Solaris 10 Sparc. Compiled everything with the same JVM version using compile.source=1.7 compile.target=1.7 except for DBCP which was compiled with Java 6. Unit test failures == One test failure, namely org.apache.catalina.websocket.TestWebSocket for NIO: Testcase: testKey took 4.628 sec Testcase: testBug53339 took 0.262 sec Testcase: testSimple took 0.585 sec FAILED junit.framework.AssertionFailedError: at org.apache.catalina.websocket.TestWebSocket$WebSocketClient.readMessage( TestWebSocket.java:419) at org.apache.catalina.websocket.TestWebSocket$WebSocketClient.access$300(T estWebSocket.java:343) at org.apache.catalina.websocket.TestWebSocket.testSimple(TestWebSocket.jav a:99) Testcase: testNoConnection took 0.555 sec Testcase: testNoUpgrade took 0.425 sec Testcase: testDetectWrongVersion took 0.377 sec possibly due to the following exception which is not happening for BIO and APR (negative Timeout): [junit] 12-Jul-2012 13:19:24.329 INFO [main] org.apache.coyote.AbstractProtocol.pause Pausing ProtocolHandler [http-nio-127.0.0.1-auto-2-48250] [junit] 12-Jul-2012 13:19:24.330 SEVERE [http-nio-127.0.0.1-auto-2-exec-1] org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process null [junit] java.lang.IllegalArgumentException: Negative timeout [junit] at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97) [junit] at org.apache.tomcat.util.net.NioSelectorPool.read(NioSelectorPool.java:267 ) [junit] at org.apache.tomcat.util.net.NioSelectorPool.read(NioSelectorPool.java:227 ) [junit] at org.apache.coyote.http11.upgrade.UpgradeNioProcessor.readSocket(UpgradeN ioProcessor.java:139) [junit] at org.apache.coyote.http11.upgrade.UpgradeNioProcessor.read(UpgradeNioProc essor.java:112) [junit] at org.apache.catalina.websocket.WsFrame.nextFrame(WsFrame.java:213) [junit] at org.apache.catalina.websocket.WsInputStream.nextFrame(WsInputStream.java :68) [junit] at org.apache.catalina.websocket.StreamInbound.onData(StreamInbound.java:11 7) [junit] at org.apache.coyote.http11.upgrade.UpgradeProcessor.upgradeDispatch(Upgrad eProcessor.java:83) [junit] at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(Abs tractProtocol.java:583) [junit] at org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.proce ss(Http11NioProtocol.java:223) [junit] at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.j ava:1676) [junit] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.jav a:1110) [junit] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.ja va:603) [junit] at java.lang.Thread.run(Thread.java:722) [junit] [junit] 12-Jul-2012 13:19:24.381 INFO [main] org.apache.catalina.core.StandardService.stopInternal Stopping service Tomcat ... [junit] 12-Jul-2012 13:19:24.769 INFO [main] org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler [http-nio-127.0.0.1-auto-3-48253] [junit] 12-Jul-2012 13:19:24.795 SEVERE [http-nio-127.0.0.1-auto-3-exec-1] org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process null [junit] java.lang.IllegalArgumentException: Negative timeout [junit] at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97) [junit] at org.apache.tomcat.util.net.NioSelectorPool.read(NioSelectorPool.java:267 ) [junit] at org.apache.tomcat.util.net.NioSelectorPool.read(NioSelectorPool.java:227 ) [junit] at org.apache.coyote.http11.upgrade.UpgradeNioProcessor.readSocket(UpgradeN ioProcessor.java:139) [junit] at org.apache.coyote.http11.upgrade.UpgradeNioProcessor.read(UpgradeNioProc essor.java:98) [junit] at org.apache.catalina.websocket.WsFrame.blockingRead(WsFrame.java:149) [junit
RE: Unit tests and trunk
-Original Message-
From: Mark Thomas [mailto:ma...@apache.org]
Sent: Wednesday, July 11, 2012 2:45 AM
To: Tomcat Developers List
Subject: Re: Unit tests and trunk
On 11/07/2012 02:27, Filip Hanik (mailing lists) wrote:
Here's what I've found out so far
The patch below does solve the problem. In a rather remarkable way.
The line
int cnt = socket.write(buf); //write the data
never returns 0, meaning the writes are always blocking. Even though
they
are not supposed to be.
Remove this patch, and socket.write(buf) returns 0, and then we never
get
issued the OP_WRITE from the selector itself.
I'm not sure I follow the above. Remove the patch and it returns 0?
[Filip Hanik]
Correct, as it should. The buffer should fill up very quick, and when the
buffer is full NIO returns 0, can't write.
So there are two problems:
a) The selector doesn't work the same in Java 7 as it does in Java 5 and 6
b) Starting a new selector turns non blocking writes into blocking, even
when I write 10MB in the TestOutputBuffer test, there is not a single
socket.write that returns 0. Removing the Selector.open call, and
immediately we have a hit return 0 as expected.
Regardless, it seems very strange that the patch below fixes it. I had a
quick look through the Java source and couldn't see anything immediately
obvious. Any ideas what is going on?
[Filip Hanik]
Can't think of anything but a bug in the JDK. I'll keep investigating.
Possibly we have to move the async NIO stuff to get it to work
Mark
Index: java/org/apache/tomcat/util/net/NioBlockingSelector.java
===
--- java/org/apache/tomcat/util/net/NioBlockingSelector.java
(revision
1359329)
+++ java/org/apache/tomcat/util/net/NioBlockingSelector.java
(working
copy)
@@ -89,6 +89,12 @@
int keycount = 1; //assume we can write
long time = System.currentTimeMillis(); //start the timeout
timer
try {
+
+synchronized (Selector.class) {
+Selector s = Selector.open();
+s.close();
+}
+
while ( (!timedout) buf.hasRemaining()) {
if (keycount 0) { //only write if we were
registered for
a write
int cnt = socket.write(buf); //write the data
-Original Message-
From: Filip Hanik (mailing lists) [mailto:devli...@hanik.com]
Sent: Tuesday, July 10, 2012 10:43 AM
To: 'Tomcat Developers List'
Subject: RE: Unit tests and trunk
Ok, definitely a bug in Java 7/Windows 7.
If I turn on ProcMon from sysinternals to try to figure out what is
going
on, the test succeeds everytime. Shutdown procmon, and it hangs
again.
The
Selector is not registering the OP_WRITE event
Filip
-Original Message-
From: Filip Hanik (mailing lists) [mailto:devli...@hanik.com]
Sent: Monday, July 09, 2012 2:31 PM
To: 'Tomcat Developers List'
Subject: RE: Unit tests and trunk
This failure happens when the write blocks, and we enter the
Selector
for a
write operation.
filip
-Original Message-
From: Filip Hanik (mailing lists) [mailto:devli...@hanik.com]
Sent: Monday, July 09, 2012 2:23 PM
To: 'Tomcat Developers List'
Subject: RE: Unit tests and trunk
I'm on Windows 7 and see TestOutputBuffer fail inconsistently with
Java
7
Most runs are failures.
I'll be looking into this this week
-Original Message-
From: Mark Thomas [mailto:ma...@apache.org]
Sent: Monday, July 09, 2012 4:33 AM
To: Tomcat Developers List
Subject: Unit tests and trunk
With the fixes over the weekend for setting traffic class, I now
see
the
unit tests passing consistently for:
Windows: BIO, NIO, APR
Linux: BIO, NIO
I do see a consistent failure for Linux and APR with the Comet
tests.
It
is the connector stop test failing (the one that was failing in
buildbot
previously with NIO). I'll take a look at this today.
Mark
--
--
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
---
-
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
-
To unsubscribe, e-mail: dev
RE: Unit tests and trunk
-Original Message-
From: Filip Hanik (mailing lists) [mailto:devli...@hanik.com]
Sent: Wednesday, July 11, 2012 10:13 AM
To: 'Tomcat Developers List'
Subject: RE: Unit tests and trunk
-Original Message-
From: Mark Thomas [mailto:ma...@apache.org]
Sent: Wednesday, July 11, 2012 2:45 AM
To: Tomcat Developers List
Subject: Re: Unit tests and trunk
On 11/07/2012 02:27, Filip Hanik (mailing lists) wrote:
Here's what I've found out so far
The patch below does solve the problem. In a rather remarkable way.
The line
int cnt = socket.write(buf); //write the data
never returns 0, meaning the writes are always blocking. Even though
they
are not supposed to be.
Remove this patch, and socket.write(buf) returns 0, and then we
never
get
issued the OP_WRITE from the selector itself.
I'm not sure I follow the above. Remove the patch and it returns 0?
[Filip Hanik]
Correct, as it should. The buffer should fill up very quick, and when
the
buffer is full NIO returns 0, can't write.
So there are two problems:
a) The selector doesn't work the same in Java 7 as it does in Java 5 and
6
b) Starting a new selector turns non blocking writes into blocking, even
when I write 10MB in the TestOutputBuffer test, there is not a single
socket.write that returns 0. Removing the Selector.open call, and
immediately we have a hit return 0 as expected.
Regardless, it seems very strange that the patch below fixes it. I had
a
quick look through the Java source and couldn't see anything
immediately
obvious. Any ideas what is going on?
[Filip Hanik]
Can't think of anything but a bug in the JDK. I'll keep investigating.
Possibly we have to move the async NIO stuff to get it to work
[Filip Hanik]
Btw, this affects the BIO connector too. The write blocks and hangs forever.
Maybe it's just my Windows 7 system. Works fine on linux.
Mark
Index: java/org/apache/tomcat/util/net/NioBlockingSelector.java
===
--- java/org/apache/tomcat/util/net/NioBlockingSelector.java
(revision
1359329)
+++ java/org/apache/tomcat/util/net/NioBlockingSelector.java
(working
copy)
@@ -89,6 +89,12 @@
int keycount = 1; //assume we can write
long time = System.currentTimeMillis(); //start the timeout
timer
try {
+
+synchronized (Selector.class) {
+Selector s = Selector.open();
+s.close();
+}
+
while ( (!timedout) buf.hasRemaining()) {
if (keycount 0) { //only write if we were
registered for
a write
int cnt = socket.write(buf); //write the data
-Original Message-
From: Filip Hanik (mailing lists) [mailto:devli...@hanik.com]
Sent: Tuesday, July 10, 2012 10:43 AM
To: 'Tomcat Developers List'
Subject: RE: Unit tests and trunk
Ok, definitely a bug in Java 7/Windows 7.
If I turn on ProcMon from sysinternals to try to figure out what is
going
on, the test succeeds everytime. Shutdown procmon, and it hangs
again.
The
Selector is not registering the OP_WRITE event
Filip
-Original Message-
From: Filip Hanik (mailing lists) [mailto:devli...@hanik.com]
Sent: Monday, July 09, 2012 2:31 PM
To: 'Tomcat Developers List'
Subject: RE: Unit tests and trunk
This failure happens when the write blocks, and we enter the
Selector
for a
write operation.
filip
-Original Message-
From: Filip Hanik (mailing lists) [mailto:devli...@hanik.com]
Sent: Monday, July 09, 2012 2:23 PM
To: 'Tomcat Developers List'
Subject: RE: Unit tests and trunk
I'm on Windows 7 and see TestOutputBuffer fail inconsistently
with
Java
7
Most runs are failures.
I'll be looking into this this week
-Original Message-
From: Mark Thomas [mailto:ma...@apache.org]
Sent: Monday, July 09, 2012 4:33 AM
To: Tomcat Developers List
Subject: Unit tests and trunk
With the fixes over the weekend for setting traffic class, I now
see
the
unit tests passing consistently for:
Windows: BIO, NIO, APR
Linux: BIO, NIO
I do see a consistent failure for Linux and APR with the Comet
tests.
It
is the connector stop test failing (the one that was failing in
buildbot
previously with NIO). I'll take a look at this today.
Mark
--
--
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
-
--
-
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
RE: Unit tests and trunk
The idea of creating a VM that is like mine was a good one. I did a clean install of Windows 7 64 bit, and it works like a charm. My network stack must have something installed at the network stack Filip -Original Message- From: Mark Thomas [mailto:ma...@apache.org] Sent: Wednesday, July 11, 2012 1:32 PM To: Tomcat Developers List Subject: Re: Unit tests and trunk On 11/07/2012 20:13, Filip Hanik (mailing lists) wrote: -Original Message- From: Filip Hanik (mailing lists) [mailto:devli...@hanik.com] Sent: Wednesday, July 11, 2012 10:13 AM To: 'Tomcat Developers List' Subject: RE: Unit tests and trunk -Original Message- From: Mark Thomas [mailto:ma...@apache.org] Sent: Wednesday, July 11, 2012 2:45 AM To: Tomcat Developers List Subject: Re: Unit tests and trunk On 11/07/2012 02:27, Filip Hanik (mailing lists) wrote: Here's what I've found out so far The patch below does solve the problem. In a rather remarkable way. The line int cnt = socket.write(buf); //write the data never returns 0, meaning the writes are always blocking. Even though they are not supposed to be. Remove this patch, and socket.write(buf) returns 0, and then we never get issued the OP_WRITE from the selector itself. I'm not sure I follow the above. Remove the patch and it returns 0? [Filip Hanik] Correct, as it should. The buffer should fill up very quick, and when the buffer is full NIO returns 0, can't write. So there are two problems: a) The selector doesn't work the same in Java 7 as it does in Java 5 and 6 b) Starting a new selector turns non blocking writes into blocking, even when I write 10MB in the TestOutputBuffer test, there is not a single socket.write that returns 0. Removing the Selector.open call, and immediately we have a hit return 0 as expected. Regardless, it seems very strange that the patch below fixes it. I had a quick look through the Java source and couldn't see anything immediately obvious. Any ideas what is going on? [Filip Hanik] Can't think of anything but a bug in the JDK. I'll keep investigating. Possibly we have to move the async NIO stuff to get it to work [Filip Hanik] Btw, this affects the BIO connector too. The write blocks and hangs forever. Maybe it's just my Windows 7 system. Works fine on linux. Let me see if I can find (or create if necessary) a clean-ish Windows 7 VM to test this on. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
RE: Unit tests and trunk
Ok, I have a resolution to this, it's a IPv6 problem. The reason it worked on my virtual machine, is cause the virtual machine doesn't have IPv6 When I add jvmarg value=-Djava.net.preferIPv4Stack=true/ To the unit tests, it works fine on Windows. Here is what led me to believe in this: http://blog.bielu.com/2011/11/hotspot-64bit-server-hangs-on-socket.html -Original Message- From: Filip Hanik (mailing lists) [mailto:devli...@hanik.com] Sent: Wednesday, July 11, 2012 2:54 PM To: 'Tomcat Developers List' Subject: RE: Unit tests and trunk The idea of creating a VM that is like mine was a good one. I did a clean install of Windows 7 64 bit, and it works like a charm. My network stack must have something installed at the network stack Filip -Original Message- From: Mark Thomas [mailto:ma...@apache.org] Sent: Wednesday, July 11, 2012 1:32 PM To: Tomcat Developers List Subject: Re: Unit tests and trunk On 11/07/2012 20:13, Filip Hanik (mailing lists) wrote: -Original Message- From: Filip Hanik (mailing lists) [mailto:devli...@hanik.com] Sent: Wednesday, July 11, 2012 10:13 AM To: 'Tomcat Developers List' Subject: RE: Unit tests and trunk -Original Message- From: Mark Thomas [mailto:ma...@apache.org] Sent: Wednesday, July 11, 2012 2:45 AM To: Tomcat Developers List Subject: Re: Unit tests and trunk On 11/07/2012 02:27, Filip Hanik (mailing lists) wrote: Here's what I've found out so far The patch below does solve the problem. In a rather remarkable way. The line int cnt = socket.write(buf); //write the data never returns 0, meaning the writes are always blocking. Even though they are not supposed to be. Remove this patch, and socket.write(buf) returns 0, and then we never get issued the OP_WRITE from the selector itself. I'm not sure I follow the above. Remove the patch and it returns 0? [Filip Hanik] Correct, as it should. The buffer should fill up very quick, and when the buffer is full NIO returns 0, can't write. So there are two problems: a) The selector doesn't work the same in Java 7 as it does in Java 5 and 6 b) Starting a new selector turns non blocking writes into blocking, even when I write 10MB in the TestOutputBuffer test, there is not a single socket.write that returns 0. Removing the Selector.open call, and immediately we have a hit return 0 as expected. Regardless, it seems very strange that the patch below fixes it. I had a quick look through the Java source and couldn't see anything immediately obvious. Any ideas what is going on? [Filip Hanik] Can't think of anything but a bug in the JDK. I'll keep investigating. Possibly we have to move the async NIO stuff to get it to work [Filip Hanik] Btw, this affects the BIO connector too. The write blocks and hangs forever. Maybe it's just my Windows 7 system. Works fine on linux. Let me see if I can find (or create if necessary) a clean-ish Windows 7 VM to test this on. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
RE: svn commit: r1360372 - /tomcat/trunk/webapps/docs/aio.xml
Will fix -Original Message- From: Mark Thomas [mailto:ma...@apache.org] Sent: Wednesday, July 11, 2012 4:03 PM To: Tomcat Developers List Subject: Re: svn commit: r1360372 - /tomcat/trunk/webapps/docs/aio.xml On 11/07/2012 20:51, fha...@apache.org wrote: Author: fhanik Date: Wed Jul 11 19:51:57 2012 New Revision: 1360372 URL: http://svn.apache.org/viewvc?rev=1360372view=rev Log: Clarify documentation around send file Modified: tomcat/trunk/webapps/docs/aio.xml Modified: tomcat/trunk/webapps/docs/aio.xml URL: http://svn.apache.org/viewvc/tomcat/trunk/webapps/docs/aio.xml?rev=13603 72r1=1360371r2=1360372view=diff == --- tomcat/trunk/webapps/docs/aio.xml (original) +++ tomcat/trunk/webapps/docs/aio.xml Wed Jul 11 19:51:57 2012 @@ -343,6 +343,11 @@ public class ChatServlet licodeorg.apache.tomcat.sendfile.start/code: Start offset as a Long/li licodeorg.apache.tomcat.sendfile.end/code: End offset as a Long/li /ul + p +In addition to setting these parameters it is necessary to set the content-length header. +or set a transfer-encoding like chunked. +Tomcat will not do that for you, since you may have already written data to the + /p Looks like a line / word or two is missing in this commit. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
RE: Unit tests and trunk
-Original Message- From: Mark Thomas [mailto:ma...@apache.org] Sent: Wednesday, July 11, 2012 4:28 PM To: Tomcat Developers List Subject: Re: Unit tests and trunk On 11/07/2012 22:39, Filip Hanik (mailing lists) wrote: Ok, I have a resolution to this, it's a IPv6 problem. The reason it worked on my virtual machine, is cause the virtual machine doesn't have IPv6 When I add jvmarg value=-Djava.net.preferIPv4Stack=true/ To the unit tests, it works fine on Windows. Here is what led me to believe in this: http://blog.bielu.com/2011/11/hotspot-64bit-server-hangs-on- socket.html Hmm. It looks like Oracle failed to reproduce the issue - possibly because the IPv6 part was not clear in the original bug report. Probably time to raise an issue with Oracle with clearer instructions to reproduce. (I have a clean Win 7 VM I am happy to trial any test case on if that helps). [Filip Hanik] I wasn't able to reproduce on a Win 7 VM because the VM environment itself doesn't support IPv6 Mark -Original Message- From: Filip Hanik (mailing lists) [mailto:devli...@hanik.com] Sent: Wednesday, July 11, 2012 2:54 PM To: 'Tomcat Developers List' Subject: RE: Unit tests and trunk The idea of creating a VM that is like mine was a good one. I did a clean install of Windows 7 64 bit, and it works like a charm. My network stack must have something installed at the network stack Filip -Original Message- From: Mark Thomas [mailto:ma...@apache.org] Sent: Wednesday, July 11, 2012 1:32 PM To: Tomcat Developers List Subject: Re: Unit tests and trunk On 11/07/2012 20:13, Filip Hanik (mailing lists) wrote: -Original Message- From: Filip Hanik (mailing lists) [mailto:devli...@hanik.com] Sent: Wednesday, July 11, 2012 10:13 AM To: 'Tomcat Developers List' Subject: RE: Unit tests and trunk -Original Message- From: Mark Thomas [mailto:ma...@apache.org] Sent: Wednesday, July 11, 2012 2:45 AM To: Tomcat Developers List Subject: Re: Unit tests and trunk On 11/07/2012 02:27, Filip Hanik (mailing lists) wrote: Here's what I've found out so far The patch below does solve the problem. In a rather remarkable way. The line int cnt = socket.write(buf); //write the data never returns 0, meaning the writes are always blocking. Even though they are not supposed to be. Remove this patch, and socket.write(buf) returns 0, and then we never get issued the OP_WRITE from the selector itself. I'm not sure I follow the above. Remove the patch and it returns 0? [Filip Hanik] Correct, as it should. The buffer should fill up very quick, and when the buffer is full NIO returns 0, can't write. So there are two problems: a) The selector doesn't work the same in Java 7 as it does in Java 5 and 6 b) Starting a new selector turns non blocking writes into blocking, even when I write 10MB in the TestOutputBuffer test, there is not a single socket.write that returns 0. Removing the Selector.open call, and immediately we have a hit return 0 as expected. Regardless, it seems very strange that the patch below fixes it. I had a quick look through the Java source and couldn't see anything immediately obvious. Any ideas what is going on? [Filip Hanik] Can't think of anything but a bug in the JDK. I'll keep investigating. Possibly we have to move the async NIO stuff to get it to work [Filip Hanik] Btw, this affects the BIO connector too. The write blocks and hangs forever. Maybe it's just my Windows 7 system. Works fine on linux. Let me see if I can find (or create if necessary) a clean-ish Windows 7 VM to test this on. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
RE: Unit tests and trunk
I opened a new issue pointing back to the old issue http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7183450. It may take a day or two before your bug shows up in this external database. -Original Message- From: Filip Hanik (mailing lists) [mailto:devli...@hanik.com] Sent: Wednesday, July 11, 2012 4:30 PM To: 'Tomcat Developers List' Subject: RE: Unit tests and trunk -Original Message- From: Mark Thomas [mailto:ma...@apache.org] Sent: Wednesday, July 11, 2012 4:28 PM To: Tomcat Developers List Subject: Re: Unit tests and trunk On 11/07/2012 22:39, Filip Hanik (mailing lists) wrote: Ok, I have a resolution to this, it's a IPv6 problem. The reason it worked on my virtual machine, is cause the virtual machine doesn't have IPv6 When I add jvmarg value=-Djava.net.preferIPv4Stack=true/ To the unit tests, it works fine on Windows. Here is what led me to believe in this: http://blog.bielu.com/2011/11/hotspot-64bit-server-hangs-on- socket.html Hmm. It looks like Oracle failed to reproduce the issue - possibly because the IPv6 part was not clear in the original bug report. Probably time to raise an issue with Oracle with clearer instructions to reproduce. (I have a clean Win 7 VM I am happy to trial any test case on if that helps). [Filip Hanik] I wasn't able to reproduce on a Win 7 VM because the VM environment itself doesn't support IPv6 Mark -Original Message- From: Filip Hanik (mailing lists) [mailto:devli...@hanik.com] Sent: Wednesday, July 11, 2012 2:54 PM To: 'Tomcat Developers List' Subject: RE: Unit tests and trunk The idea of creating a VM that is like mine was a good one. I did a clean install of Windows 7 64 bit, and it works like a charm. My network stack must have something installed at the network stack Filip -Original Message- From: Mark Thomas [mailto:ma...@apache.org] Sent: Wednesday, July 11, 2012 1:32 PM To: Tomcat Developers List Subject: Re: Unit tests and trunk On 11/07/2012 20:13, Filip Hanik (mailing lists) wrote: -Original Message- From: Filip Hanik (mailing lists) [mailto:devli...@hanik.com] Sent: Wednesday, July 11, 2012 10:13 AM To: 'Tomcat Developers List' Subject: RE: Unit tests and trunk -Original Message- From: Mark Thomas [mailto:ma...@apache.org] Sent: Wednesday, July 11, 2012 2:45 AM To: Tomcat Developers List Subject: Re: Unit tests and trunk On 11/07/2012 02:27, Filip Hanik (mailing lists) wrote: Here's what I've found out so far The patch below does solve the problem. In a rather remarkable way. The line int cnt = socket.write(buf); //write the data never returns 0, meaning the writes are always blocking. Even though they are not supposed to be. Remove this patch, and socket.write(buf) returns 0, and then we never get issued the OP_WRITE from the selector itself. I'm not sure I follow the above. Remove the patch and it returns 0? [Filip Hanik] Correct, as it should. The buffer should fill up very quick, and when the buffer is full NIO returns 0, can't write. So there are two problems: a) The selector doesn't work the same in Java 7 as it does in Java 5 and 6 b) Starting a new selector turns non blocking writes into blocking, even when I write 10MB in the TestOutputBuffer test, there is not a single socket.write that returns 0. Removing the Selector.open call, and immediately we have a hit return 0 as expected. Regardless, it seems very strange that the patch below fixes it. I had a quick look through the Java source and couldn't see anything immediately obvious. Any ideas what is going on? [Filip Hanik] Can't think of anything but a bug in the JDK. I'll keep investigating. Possibly we have to move the async NIO stuff to get it to work [Filip Hanik] Btw, this affects the BIO connector too. The write blocks and hangs forever. Maybe it's just my Windows 7 system. Works fine on linux. Let me see if I can find (or create if necessary) a clean-ish Windows 7 VM to test this on. Mark -- -- - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org --- -- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
access to build environment
How do I get access to the build environment? So we can change the build to default to Java 7 Filip - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
RE: Unit tests and trunk
Ok, definitely a bug in Java 7/Windows 7. If I turn on ProcMon from sysinternals to try to figure out what is going on, the test succeeds everytime. Shutdown procmon, and it hangs again. The Selector is not registering the OP_WRITE event Filip -Original Message- From: Filip Hanik (mailing lists) [mailto:devli...@hanik.com] Sent: Monday, July 09, 2012 2:31 PM To: 'Tomcat Developers List' Subject: RE: Unit tests and trunk This failure happens when the write blocks, and we enter the Selector for a write operation. filip -Original Message- From: Filip Hanik (mailing lists) [mailto:devli...@hanik.com] Sent: Monday, July 09, 2012 2:23 PM To: 'Tomcat Developers List' Subject: RE: Unit tests and trunk I'm on Windows 7 and see TestOutputBuffer fail inconsistently with Java 7 Most runs are failures. I'll be looking into this this week -Original Message- From: Mark Thomas [mailto:ma...@apache.org] Sent: Monday, July 09, 2012 4:33 AM To: Tomcat Developers List Subject: Unit tests and trunk With the fixes over the weekend for setting traffic class, I now see the unit tests passing consistently for: Windows: BIO, NIO, APR Linux: BIO, NIO I do see a consistent failure for Linux and APR with the Comet tests. It is the connector stop test failing (the one that was failing in buildbot previously with NIO). I'll take a look at this today. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
RE: Unit tests and trunk
Here's what I've found out so far
The patch below does solve the problem. In a rather remarkable way.
The line
int cnt = socket.write(buf); //write the data
never returns 0, meaning the writes are always blocking. Even though they
are not supposed to be.
Remove this patch, and socket.write(buf) returns 0, and then we never get
issued the OP_WRITE from the selector itself.
Index: java/org/apache/tomcat/util/net/NioBlockingSelector.java
===
--- java/org/apache/tomcat/util/net/NioBlockingSelector.java(revision
1359329)
+++ java/org/apache/tomcat/util/net/NioBlockingSelector.java(working
copy)
@@ -89,6 +89,12 @@
int keycount = 1; //assume we can write
long time = System.currentTimeMillis(); //start the timeout timer
try {
+
+synchronized (Selector.class) {
+Selector s = Selector.open();
+s.close();
+}
+
while ( (!timedout) buf.hasRemaining()) {
if (keycount 0) { //only write if we were registered for
a write
int cnt = socket.write(buf); //write the data
-Original Message-
From: Filip Hanik (mailing lists) [mailto:devli...@hanik.com]
Sent: Tuesday, July 10, 2012 10:43 AM
To: 'Tomcat Developers List'
Subject: RE: Unit tests and trunk
Ok, definitely a bug in Java 7/Windows 7.
If I turn on ProcMon from sysinternals to try to figure out what is
going
on, the test succeeds everytime. Shutdown procmon, and it hangs again.
The
Selector is not registering the OP_WRITE event
Filip
-Original Message-
From: Filip Hanik (mailing lists) [mailto:devli...@hanik.com]
Sent: Monday, July 09, 2012 2:31 PM
To: 'Tomcat Developers List'
Subject: RE: Unit tests and trunk
This failure happens when the write blocks, and we enter the Selector
for a
write operation.
filip
-Original Message-
From: Filip Hanik (mailing lists) [mailto:devli...@hanik.com]
Sent: Monday, July 09, 2012 2:23 PM
To: 'Tomcat Developers List'
Subject: RE: Unit tests and trunk
I'm on Windows 7 and see TestOutputBuffer fail inconsistently with
Java
7
Most runs are failures.
I'll be looking into this this week
-Original Message-
From: Mark Thomas [mailto:ma...@apache.org]
Sent: Monday, July 09, 2012 4:33 AM
To: Tomcat Developers List
Subject: Unit tests and trunk
With the fixes over the weekend for setting traffic class, I now
see
the
unit tests passing consistently for:
Windows: BIO, NIO, APR
Linux: BIO, NIO
I do see a consistent failure for Linux and APR with the Comet
tests.
It
is the connector stop test failing (the one that was failing in
buildbot
previously with NIO). I'll take a look at this today.
Mark
--
--
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
RE: Unit tests and trunk
I'm on Windows 7 and see TestOutputBuffer fail inconsistently with Java 7 Most runs are failures. I'll be looking into this this week -Original Message- From: Mark Thomas [mailto:ma...@apache.org] Sent: Monday, July 09, 2012 4:33 AM To: Tomcat Developers List Subject: Unit tests and trunk With the fixes over the weekend for setting traffic class, I now see the unit tests passing consistently for: Windows: BIO, NIO, APR Linux: BIO, NIO I do see a consistent failure for Linux and APR with the Comet tests. It is the connector stop test failing (the one that was failing in buildbot previously with NIO). I'll take a look at this today. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
RE: Unit tests and trunk
This failure happens when the write blocks, and we enter the Selector for a write operation. filip -Original Message- From: Filip Hanik (mailing lists) [mailto:devli...@hanik.com] Sent: Monday, July 09, 2012 2:23 PM To: 'Tomcat Developers List' Subject: RE: Unit tests and trunk I'm on Windows 7 and see TestOutputBuffer fail inconsistently with Java 7 Most runs are failures. I'll be looking into this this week -Original Message- From: Mark Thomas [mailto:ma...@apache.org] Sent: Monday, July 09, 2012 4:33 AM To: Tomcat Developers List Subject: Unit tests and trunk With the fixes over the weekend for setting traffic class, I now see the unit tests passing consistently for: Windows: BIO, NIO, APR Linux: BIO, NIO I do see a consistent failure for Linux and APR with the Comet tests. It is the connector stop test failing (the one that was failing in buildbot previously with NIO). I'll take a look at this today. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
RE: svn commit: r1356849 - /tomcat/trunk/java/org/apache/catalina/startup/Tomcat.java
-Original Message-
From: Mark Thomas [mailto:ma...@apache.org]
Sent: Tuesday, July 03, 2012 12:37 PM
To: Tomcat Developers List
Subject: Re: svn commit: r1356849 -
/tomcat/trunk/java/org/apache/catalina/startup/Tomcat.java
On 03/07/2012 18:54, fha...@apache.org wrote:
Author: fhanik
Date: Tue Jul 3 17:54:25 2012
New Revision: 1356849
URL: http://svn.apache.org/viewvc?rev=1356849view=rev
Log:
Allow servlets to specify async support as annotation when added
programatically
Modified:
tomcat/trunk/java/org/apache/catalina/startup/Tomcat.java
Modified: tomcat/trunk/java/org/apache/catalina/startup/Tomcat.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/start
up/Tomcat.java?rev=1356849r1=1356848r2=1356849view=diff
==
--- tomcat/trunk/java/org/apache/catalina/startup/Tomcat.java
(original)
+++ tomcat/trunk/java/org/apache/catalina/startup/Tomcat.java Tue Jul
3 17:54:25 2012
@@ -29,6 +29,7 @@ import java.util.logging.Logger;
import javax.servlet.Servlet;
import javax.servlet.ServletException;
+import javax.servlet.annotation.WebServlet;
import org.apache.catalina.Container;
import org.apache.catalina.Context;
@@ -801,11 +802,25 @@ public class Tomcat {
@SuppressWarnings(deprecation)
public ExistingStandardWrapper( Servlet existing ) {
this.existing = existing;
+this.asyncSupported = isAsyncSupported();
I don't get what the purpose of the above line is given that
asyncSupported is set again without apparently being used a few lines
later. What am I missing?
[Filip Hanik]
That line will have to go. The other line ends up setting it to true if there
is an annotation (default is false)
Filip
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
RE: buildbot failure in ASF Buildbot on tomcat-trunk
Will fix! -Original Message- From: Konstantin Kolinko [mailto:knst.koli...@gmail.com] Sent: Tuesday, July 03, 2012 12:51 PM To: Tomcat Developers List Subject: Re: buildbot failure in ASF Buildbot on tomcat-trunk 2012/7/3 build...@apache.org: The Buildbot has detected a new failure on builder tomcat-trunk while building ASF Buildbot. Full details are available at: http://ci.apache.org/builders/tomcat-trunk/builds/3153 NPE in TestStandardWrapper, both NIO and BIO: [[[ Testcase: testSecurityAnnotationsMethods2 took 0.106 sec Caused an ERROR null java.lang.NullPointerException at org.apache.catalina.startup.TomcatBaseTest$1.available(TomcatBaseTest.ja va:308) at org.apache.catalina.startup.TomcatBaseTest.postUrl(TomcatBaseTest.java:3 51) at org.apache.catalina.startup.TomcatBaseTest.postUrl(TomcatBaseTest.java:3 11) at org.apache.catalina.core.TestStandardWrapper.doTest(TestStandardWrapper. java:263) at org.apache.catalina.core.TestStandardWrapper.testSecurityAnnotationsMeth ods2(TestStandardWrapper.java:85) ]]] See logs here: http://ci.apache.org/projects/tomcat/tomcat8/logs/ -1356852/ Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
RE: svn commit: r1355615 - in /tomcat/trunk: java/org/apache/catalina/realm/JNDIRealm.java webapps/docs/config/realm.xml
Thanks for the review and fix
-Original Message-
From: Konstantin Kolinko [mailto:knst.koli...@gmail.com]
Sent: Sunday, July 01, 2012 6:06 AM
To: Tomcat Developers List
Subject: Re: svn commit: r1355615 - in /tomcat/trunk:
java/org/apache/catalina/realm/JNDIRealm.java
webapps/docs/config/realm.xml
2012/6/30 fha...@apache.org:
Author: fhanik
Date: Sat Jun 30 01:04:59 2012
New Revision: 1355615
URL: http://svn.apache.org/viewvc?rev=1355615view=rev
Log:
With more and more use of RFC 2307 http://tools.ietf.org/html/rfc2307
There is a new way to search for roles using the memberUid that can
contain the value of another attribute within the users directory entry.
This may not be very specific to 2307, but that is where I see this
combination of role searches occur the most.
Example: http://www.openldap.org/lists/openldap-
technical/200904/msg00024.html
Modified:
tomcat/trunk/java/org/apache/catalina/realm/JNDIRealm.java
tomcat/trunk/webapps/docs/config/realm.xml
Modified: tomcat/trunk/java/org/apache/catalina/realm/JNDIRealm.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/realm
/JNDIRealm.java?rev=1355615r1=1355614r2=1355615view=diff
==
--- tomcat/trunk/java/org/apache/catalina/realm/JNDIRealm.java
(original)
+++ tomcat/trunk/java/org/apache/catalina/realm/JNDIRealm.java Sat Jun
30 01:04:59 2012
@@ -126,8 +126,9 @@ import org.ietf.jgss.GSSCredential;
* property./li
* liThe coderoleSearch/code pattern optionally includes
pattern
* replacements {0} for the distinguished name, and/or
{1} for
- * the username, of the authenticated user for which roles
will be
- * retrieved./li
+ * the username, and/or {2} the value of the
userRoleAttribute
+ * attribute from the users entry, of the authenticated user
+ * for which roles will be retrieved./li
* liThe coderoleBase/code property can be set to the
element that
* is the base of the search for matching roles. If not
specified,
* the entire context will be searched./li
@@ -292,6 +293,14 @@ public class JNDIRealm extends RealmBase
*/
protected String userPassword = null;
+/**
+ * The name of the attribute inside the users
+ * directory entry where the value will be
+ * taken to search for roles
+ * This attribute is not used during a nested search
+ */
+protected String userRoleAttribute = null;
+
/**
* A string of LDAP user patterns or paths, :-separated
@@ -829,6 +838,14 @@ public class JNDIRealm extends RealmBase
}
+public String getUserRoleAttribute() {
+return userRoleAttribute;
+}
+
+public void setUserRoleAttribute(String userRoleAttribute) {
+this.userRoleAttribute = userRoleAttribute;
+}
+
/**
* Return the message format pattern for selecting users in this
Realm.
*/
@@ -839,6 +856,8 @@ public class JNDIRealm extends RealmBase
}
+
+
/**
* Set the message format pattern for selecting users in this
Realm.
* This may be one simple pattern, or multiple patterns to be
tried,
@@ -1230,6 +1249,9 @@ public class JNDIRealm extends RealmBase
list.add(userPassword);
if (userRoleName != null)
list.add(userRoleName);
+if (userRoleAttribute != null) {
+list.add(userRoleAttribute);
+}
String[] attrIds = new String[list.size()];
list.toArray(attrIds);
@@ -1265,7 +1287,7 @@ public class JNDIRealm extends RealmBase
// If no attributes are requested, no need to look for them
if (attrIds == null || attrIds.length == 0) {
-return new User(username, dn, null, null);
+return new User(username, dn, null, null,null);
}
// Get required attributes from user entry
@@ -1283,12 +1305,17 @@ public class JNDIRealm extends RealmBase
if (userPassword != null)
password = getAttributeValue(userPassword, attrs);
+String userRoleAttrValue = null;
+if (userRoleAttribute != null) {
+userRoleAttrValue = getAttributeValue(userRoleAttribute,
attrs);
+}
+
// Retrieve values of userRoleName attribute
ArrayListString roles = null;
if (userRoleName != null)
roles = addAttributeValues(userRoleName, attrs, roles);
-return new User(username, dn, password, roles);
+return new User(username, dn, password, roles,
userRoleAttrValue);
}
@@ -1427,12 +1454,17 @@ public class JNDIRealm extends RealmBase
if (userPassword != null)
password =
jdbc-pool build in 7.0.28
Haven't had time to confirm this yet myself. I helped a user troubleshoot an issue, something that looked like a bug that was already fixed https://issues.apache.org/bugzilla/show_bug.cgi?id=53367 The conversation is at http://tomcat.markmail.org/thread/betq2iim6todqlde and when I gave the user a JAR from trunk, the symptoms went away. So either 1. I forgot to update SVN external property 2. The user wasn't running 7.0.28 3. Our build didn't pick up the changes made I'll take a look at 3. on Monday Best Filip - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
non blocking API
I posted some feedback to the expert group: http://java.net/projects/servlet-spec/lists/users/archive/2012-06/message/15 - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Starting on 3.1 implementation
As some of you noticed, I added in the stubs for Servlet 3.1 yesterday. I'm planning on starting on 3.1 features, mainly the non blocking read/writes. In Tomcat, we already have an implementation of this in the sandbox http://svn.apache.org/viewvc/tomcat/sandbox/gdev6x/ That works fully, and I'll probably model it after that. There are a couple of things I suggest with that for trunk 1. Make the NIO connector the default, so that no configuration changes are required to use 3.1 features 2. Retain BIO connectors, it will simply throw IllegalStateExceptions or OperationNotSupported exceptions where appropriate 3.1 seems to be a fairly minor update so far, so we should be able to start pushing Tomcat 8 right around the time as the spec is finalized. Filip - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
RE: Starting on 3.1 implementation
3.1 seems to be a fairly minor update so far, so we should be able to start pushing Tomcat 8 right around the time as the spec is finalized. Just a word of caution. The EG is far from agreed on the best way to do the non-blocking API at the moment. As with happened with the 3.0 async API, a complete re-write could still happen. [Filip Hanik] That's ok. Non blocking can be done in many ways. As with the sandbox example, it was done without modifying streams, and still worked. So as long as the underlying implementation supports it, I don't suspect that an API change would change a lot in the belly of the beast. The EL EG has added a whole bunch of features. On the plus side the updated jjt file is included in the spec that should speed things up a fair bit. I haven't heard anything in terms of JSP updates. I can't imagine there will be much there. My current focus on Tomcat 8 is re-factoring the resources to remove all the JNDI stuff. After that, I'll probably look at the HTTP upgrade bit. [Filip Hanik] Interesting, what's up with JNDI, prolly something I missed from an earlier discussion? Filip - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
RE: Starting on 3.1 implementation
3.1 seems to be a fairly minor update so far, so we should be able to start pushing Tomcat 8 right around the time as the spec is finalized. Just a word of caution. The EG is far from agreed on the best way to do the non-blocking API at the moment. As with happened with the 3.0 async API, a complete re-write could still happen. [Filip Hanik] I'd expect this API to change public abstract boolean canWrite(); if this returns true, and then I write 1MB of buffered data, what does the system expect this to be non blocking? The better signature would have been public abstract int canWrite(); and at least return the number of free bytes we have in the response buffer (configurable) Filip - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
RE: svn commit: r1354112 - in /tomcat/trunk/java/javax/servlet: ./ http/
-Original Message-
From: Konstantin Kolinko [mailto:knst.koli...@gmail.com]
Sent: Tuesday, June 26, 2012 11:38 AM
To: Tomcat Developers List
Subject: Re: svn commit: r1354112 - in /tomcat/trunk/java/javax/servlet:
./ http/
2012/6/26 fha...@apache.org:
Author: fhanik
Date: Tue Jun 26 17:07:22 2012
New Revision: 1354112
URL: http://svn.apache.org/viewvc?rev=1354112view=rev
Log:
In preparation for next servlet revision
Align with the servlet specification signatures as they are defined by
the spec itself. These do not represent any functional changes
Most of these are just ordering of methods, others are runtime
exception that are defined differently in the method signatures
As an fyi, the easiest way to compare signatures between two libraries
is to use javap and diff on the output, that's how I found these
changes, verified them against the javadoc and implemented into tomcat
Modified:
tomcat/trunk/java/javax/servlet/AsyncContext.java
tomcat/trunk/java/javax/servlet/RequestDispatcher.java
tomcat/trunk/java/javax/servlet/ServletContext.java
tomcat/trunk/java/javax/servlet/ServletRequest.java
tomcat/trunk/java/javax/servlet/ServletRequestWrapper.java
tomcat/trunk/java/javax/servlet/ServletSecurityElement.java
tomcat/trunk/java/javax/servlet/http/Cookie.java
tomcat/trunk/java/javax/servlet/http/HttpServletRequest.java
tomcat/trunk/java/javax/servlet/http/HttpServletRequestWrapper.java
--- tomcat/trunk/java/javax/servlet/RequestDispatcher.java (original)
+++ tomcat/trunk/java/javax/servlet/RequestDispatcher.java Tue Jun 26
17:07:22 2012
@@ -39,22 +39,22 @@ import java.io.IOException;
*/
public interface RequestDispatcher {
+ static final String FORWARD_REQUEST_URI =
javax.servlet.forward.request_uri;
+ static final String FORWARD_CONTEXT_PATH =
javax.servlet.forward.context_path;
+ static final String FORWARD_PATH_INFO =
javax.servlet.forward.path_info;
+ static final String FORWARD_SERVLET_PATH =
javax.servlet.forward.servlet_path;
+ static final String FORWARD_QUERY_STRING =
javax.servlet.forward.query_string;
+ static final String INCLUDE_REQUEST_URI =
javax.servlet.include.request_uri;
+ static final String INCLUDE_CONTEXT_PATH =
javax.servlet.include.context_path;
+ static final String INCLUDE_PATH_INFO =
javax.servlet.include.path_info;
+ static final String INCLUDE_SERVLET_PATH =
javax.servlet.include.servlet_path;
+ static final String INCLUDE_QUERY_STRING =
javax.servlet.include.query_string;
Maybe public static final?
It is not necessary in an interface, but for consistency with below
ones.
[Filip Hanik]
I'm just following the Servlet 3.0 signatures.
Since it doesn't matter, leaving it as is easier when tracking diffs. If you
were to run a javap against it, you'd find that the code that yields the
JavaDoc have the same definitions.
Filip
public static final String ERROR_EXCEPTION =
javax.servlet.error.exception;
public static final String ERROR_EXCEPTION_TYPE =
javax.servlet.error.exception_type;
public static final String ERROR_MESSAGE =
javax.servlet.error.message;
public static final String ERROR_REQUEST_URI =
javax.servlet.error.request_uri;
public static final String ERROR_SERVLET_NAME =
javax.servlet.error.servlet_name;
public static final String ERROR_STATUS_CODE =
javax.servlet.error.status_code;
Best regards,
Konstantin Kolinko
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
RE: Timing for 7.0.29
+1 -Original Message- From: Mark Thomas [mailto:ma...@apache.org] Sent: Tuesday, June 26, 2012 2:12 PM To: Tomcat Developers List Subject: Timing for 7.0.29 I'm sure circumstances will conspire against me but I am currently planning to start the 7.0.29 release process early next week. That aligns with my general aim of getting a release out at the start of each month and there are some regressions in 7.0.28 that I'd rather fix sooner than later. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
RE: WARNING: Incorrect connection count when running testsuite for APR/native 1.1.24
This is one example of counting down twice. There are a lot of places
calling destroySocket, the best would have been to pass a SocketWrapper
instead of long and keep a AtomicBoolean to track if destroy has been called
on it.
if (running !paused) {
// Hand this socket off to an appropriate processor
if (!processSocketWithOptions(socket)) {
countDownConnection();
// Close socket and pool right away
destroySocket(socket);
}
} else {
countDownConnection();
// Close socket and pool right away
destroySocket(socket);
}
Then the actual implementation of destroySocket(long) does the same thing,
it counts it down again.
private void destroySocket(long socket) {
// If not running the socket will be destroyed by
// parent pool or acceptor socket.
// In any case disable double free which would cause JVM core.
destroySocket(socket, running);
}
private void destroySocket(long socket, boolean doIt) {
// Be VERY careful if you call this method directly. If it is called
// twice for the same socket the JVM will core. Currently this is
only
// called from Poller.closePollset() to ensure kept alive
connections
// are closed when calling stop() followed by start().
if (doIt socket != 0) {
Socket.destroy(socket);
countDownConnection();
}
}
-Original Message-
From: Konstantin Kolinko [mailto:knst.koli...@gmail.com]
Sent: Tuesday, June 12, 2012 9:21 PM
To: Tomcat Developers List
Subject: WARNING: Incorrect connection count when running testsuite
for APR/native 1.1.24
Hi!
I run the testsuite for Tomcat trunk with APR connector with release
candidate for Tomcat Native 1.1.24, on WinXP 32-bit.
The testsuite passes successfully, but looking closer into log files I
see many occurrences of the following warning:
12.06.2012 21:13:43 org.apache.tomcat.util.net.AbstractEndpoint
countDownConnection
WARNING: Incorrect connection count, multiple socket.close called on
the same socket.
There are ~50 tests when it fails, the first one being
org.apache.catalina.authenticator.TestFormAuthenticator
It sounds like there are cases when BZ 53173 (connection counting and
maxConnections) is not fixed yet for APR connector.
Best regards,
Konstantin Kolinko
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
RE: svn commit: r1349984 - /tomcat/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java
} else {
-countDownConnection();
// Close socket and pool right away
destroySocket(socket);
}
[Filip Hanik]
'running' variable could be false here, at which point, socket nor countdown
happens
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
RE: svn commit: r1349984 - /tomcat/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java
My suggestion for a 7.0.28 is to have -1 for the default value of
maxConnections for APR. This disables maxConnections until we have a better
grip on it.
Changing it to track closures is quite a surgery, something I would do for
trunk, but leave out of 7.0.x. This leaves existing code flow intact, but
changes parameter types everywhere.
Actually rewriting the code to ensure it never gets called more than once
without tracking it, seems a bit risky.
I ran unit tests with the same fix,
-Original Message-
From: ma...@apache.org [mailto:ma...@apache.org]
Sent: Wednesday, June 13, 2012 12:29 PM
To: dev@tomcat.apache.org
Subject: svn commit: r1349984 -
/tomcat/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java
Author: markt
Date: Wed Jun 13 18:29:07 2012
New Revision: 1349984
URL: http://svn.apache.org/viewvc?rev=1349984view=rev
Log:
Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=53173
Remove some duplicate calls to countDownConnection()
While the connector is running, destroySocket() will call
countDownConnection()
Once the connector is stopped, the latch is removed so it does not
matter that destroySocket() does not call countDownConnection() in that
case
Modified:
tomcat/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java
Modified: tomcat/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/util/ne
t/AprEndpoint.java?rev=1349984r1=1349983r2=1349984view=diff
==
--- tomcat/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java
(original)
+++ tomcat/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java Wed
Jun 13 18:29:07 2012
@@ -981,12 +981,10 @@ public class AprEndpoint extends Abstrac
if (running !paused) {
// Hand this socket off to an appropriate
processor
if (!processSocketWithOptions(socket)) {
-countDownConnection();
// Close socket and pool right away
destroySocket(socket);
}
} else {
-countDownConnection();
// Close socket and pool right away
destroySocket(socket);
}
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Time for 7.0.28?
Over 2 months since last release Got some critical fixes that I would like to see released - max connections broken - send file in nio broken - jdbc pool can hang during DB failure Filip - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
RE: [VOTE] Release Apache Tomcat Native 1.1.24
[X] Stable, go ahead and release - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
RE: Tomcat 7 code policy (was: Re: svn commit: r1345848)
-Original Message- From: Konstantin Kolinko [mailto:knst.koli...@gmail.com] Sent: Monday, June 04, 2012 3:50 PM To: Tomcat Developers List Subject: Re: Tomcat 7 code policy (was: Re: svn commit: r1345848) 2012/6/5 Konstantin Kolinko knst.koli...@gmail.com: For that reason, I'd like us to be more conscious about our commits on v7 and start looking at v7 as bug fixes and stabilization as the primary drivers for commits. Stabilization usually means that we stop fixing bugs in stable version besides easy ones and allow them in trunk only. It is not what I want for 7.0 now. There is no expected date for Tomcat 8, and if the date is too far (e.g. further than 9 months) it would be too late for most problems that users are reporting. What do people think about introducing a STATUS file in 7.0, but not yet switching to full RTC policy? I mean let the author decide and propose his change for review if he deems it is too risky to commit immediately, or is worth reviewing. E.g. if a) the change is too complex, b) touches many components, c) touches core pieces of Tomcat. I do not think 7.0 will benefit from slow RTC of Tomcat 6, but there are some patches that are worth a review, and having a formal STATUS file approach is better that random discussions on dev@. One notable benefit of the STATUS file is that the change is proposed when it is ready for review. [Filip Hanik] I think the STATUS file is slowly becoming obsolete. If we instead adopted git, and used features like those available on github where you can create a merge request, you'd have everything in one place, and nothing was lost. My only point with the original post was to slow down the zero value commits in Tomcat 7, as people start to rely on it for production grade, we should treat it the same. I think it's too early for RTC, but it's too late for refactoring in that branch too. Balance is the key. Filip Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
RE: svn commit: r1345848 - in /tomcat/tc7.0.x/trunk: ./ java/org/apache/catalina/deploy/NamingResources.java java/org/apache/tomcat/util/net/AbstractEndpoint.java
Ok, this is back to code discipline. At some point, we'd have to expect that
more users will adopt v7 in production (I'm still seeing 80%+ being on v6), at
that point, commits like this do nothing except pollute the diffs.
Servlet 3.1 has released a draft, where I'd expect that trunk is headed. There
is no reason for v7 to continue to be an exact mirror of trunk, especially from
a formatting point of view.
While this makes the code prettier, it makes it a lot harder to trace
regressions.
I'd suggest we start treating this as a stable branch, stable in my perception
is that it's a branch that I use to support production environments, and that I
can use to trace regressions and fixes.
Let me give an example, in my job, I primarily work in support. In the last two
weeks we've had some serious production regressions on v7, and tracing it down
was a lot harder than it usually is as the v7 branch still is fairly volatile
in development, even though we're already at 7.0.27.
A commit that doesn't change functionality but changes formatting, adds more
lines to each diff I review when I trace back changes.
I would assume that the tomcat dev community in some shape or form must feel
the same sense of supporting our users when we look through the user
community's bug reports, and trace down the bugs.
For that reason, I'd like us to be more conscious about our commits on v7 and
start looking at v7 as bug fixes and stabilization as the primary drivers for
commits. Beautification of code in v7 doesn't make fixing it later easier, it
makes it harder. And beautification's primary goal is simpler to read, use and
maintain. But it only works if the original code was that way.
If we want to make code formatting a 'requirement', let's discuss that, and
adjust the build scripts accordingly. Now it's a manual process. I'd suggest
that formatting requirements would be started on a new thread, and started with
trunk.
Best
Filip
-Original Message-
From: kkoli...@apache.org [mailto:kkoli...@apache.org]
Sent: Monday, June 04, 2012 1:28 AM
To: dev@tomcat.apache.org
Subject: svn commit: r1345848 - in /tomcat/tc7.0.x/trunk: ./
java/org/apache/catalina/deploy/NamingResources.java
java/org/apache/tomcat/util/net/AbstractEndpoint.java
Author: kkolinko
Date: Mon Jun 4 07:27:46 2012
New Revision: 1345848
URL: http://svn.apache.org/viewvc?rev=1345848view=rev
Log:
Merged revision 1345846 from tomcat/trunk:
Code formatting (indents). No functional change.
Modified:
tomcat/tc7.0.x/trunk/ (props changed)
tomcat/tc7.0.x/trunk/java/org/apache/catalina/deploy/NamingResources.jav
a
tomcat/tc7.0.x/trunk/java/org/apache/tomcat/util/net/AbstractEndpoint.ja
va
Propchange: tomcat/tc7.0.x/trunk/
--
Merged /tomcat/trunk:r1345846
Modified:
tomcat/tc7.0.x/trunk/java/org/apache/catalina/deploy/NamingResources.jav
a
URL:
http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/java/org/apache/catali
na/deploy/NamingResources.java?rev=1345848r1=1345847r2=1345848view=di
ff
==
---
tomcat/tc7.0.x/trunk/java/org/apache/catalina/deploy/NamingResources.jav
a (original)
+++
tomcat/tc7.0.x/trunk/java/org/apache/catalina/deploy/NamingResources.jav
a Mon Jun 4 07:27:46 2012
@@ -400,7 +400,8 @@ public class NamingResources extends Lif
throw new IllegalArgumentException(sm.getString(
namingResources.resourceTypeFail,
resource.getName(),
resource.getType()));
-}entries.add(resource.getName());
+}
+entries.add(resource.getName());
}
synchronized (resourceEnvRefs) {
Modified:
tomcat/tc7.0.x/trunk/java/org/apache/tomcat/util/net/AbstractEndpoint.ja
va
URL:
http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/java/org/apache/tomcat
/util/net/AbstractEndpoint.java?rev=1345848r1=1345847r2=1345848view=d
iff
==
---
tomcat/tc7.0.x/trunk/java/org/apache/tomcat/util/net/AbstractEndpoint.ja
va (original)
+++
tomcat/tc7.0.x/trunk/java/org/apache/tomcat/util/net/AbstractEndpoint.ja
va Mon Jun 4 07:27:46 2012
@@ -163,10 +163,11 @@ public abstract class AbstractEndpoint {
LimitLatch latch = this.connectionLimitLatch;
if (latch != null) {
// Update the latch that enforces this
-if (maxCon == -1)
+if (maxCon == -1) {
releaseConnectionLatch();
-else
-latch.setLimit(maxCon);
+} else {
+latch.setLimit(maxCon);
+}
} else if (maxCon 0) {
initializeConnectionLatch();
}
RE: svn commit: r1345848 - in /tomcat/tc7.0.x/trunk: ./ java/org/apache/catalina/deploy/NamingResources.java java/org/apache/tomcat/util/net/AbstractEndpoint.java
-Original Message- From: Mark Thomas [mailto:ma...@apache.org] Sent: Monday, June 04, 2012 12:41 PM To: Tomcat Developers List Subject: Re: svn commit: r1345848 - in /tomcat/tc7.0.x/trunk: ./ java/org/apache/catalina/deploy/NamingResources.java java/org/apache/tomcat/util/net/AbstractEndpoint.java On 04/06/2012 17:05, Filip Hanik (mailing lists) wrote: Ok, this is back to code discipline. At some point, we'd have to expect that more users will adopt v7 in production (I'm still seeing 80%+ being on v6), at that point, commits like this do nothing except pollute the diffs. It depends which diffs you are looking at. If you are checking trunk against 7.0.x to check that the back-port of a fix hasn't been missed then having trunk and 7.0.x as closely aligned as possible is helpful. If you are checking the changes in 7.0.x then formatting changes don't help. It all depends on your point of view. I would also add that consistently formatted code is easier to read and less likely to be misread. [Filip Hanik] That's my point exactly. I believe we did a great job with stabilizing Apache Tomcat 6, and keeping it stable. I don't think we are doing as good of a job with Apache Tomcat 7. I think we can do better. So it's really what is the goal, if the goal to back port patches from trunk, then sure. Format both branches. That goal however has a flaw, it doesn't treat 7.0.x as a production grade branch, but a development branch. Servlet 3.1 has released a draft, where I'd expect that trunk is headed. There is no reason for v7 to continue to be an exact mirror of trunk, especially from a formatting point of view. That work hasn't started in Tomcat yet so at the moment there is no driver for them to diverge. That will probably change over the next few months. [Filip Hanik] Should change fairly shortly since the draft is out. While this makes the code prettier, it makes it a lot harder to trace regressions. Not just prettier (see above) but I agree regarding regressions. I'd suggest we start treating this as a stable branch, stable in my perception is that it's a branch that I use to support production environments, and that I can use to trace regressions and fixes. The obvious change would be to move 7.0.x to RTC rather than CTR. That inevitably slows down the pace of development. We as a community need to decide if that is what we want to do. If you want to propose that, I suggest you start a new thread on that specific topic. [Filip Hanik] Doesn't have to be one extreme to another. All it takes a bit more discipline and an aligned goal with the 7.0.x branch. Filip - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
RE: [VOTE] Release Apache Tomcat Connectors 1.2.37
[X] Stable, go ahead and release -Original Message- From: Mladen Turk [mailto:mt...@apache.org] Sent: Tuesday, May 29, 2012 3:24 AM To: Tomcat Developers List Subject: [VOTE] Release Apache Tomcat Connectors 1.2.37 Hi, Apache Tomcat Connectors 1.2.37 release candidate is ready for vote at [1]. This version solves regression(s) found in released version 1.2.36 which can crash web server if configured in certain way. The VOTE will remain open for at least 48 hours. The Apache Tomcat Connectors 1.2.37 is [ ] Stable, go ahead and release [ ] Broken because of ... [1] http://people.apache.org/~mturk/tomcat-connectors/jk-1.2.37/ Regards -- ^TM - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
RE: svn commit: r1342473 - in /tomcat/tc7.0.x/trunk: ./ java/org/apache/coyote/http11/Http11NioProcessor.java java/org/apache/tomcat/util/net/NioEndpoint.java
Changing a public API method is something I would do for trunk. I'm not sure
about a .28 release that is considered stable.
Filip
-Original Message-
From: kkoli...@apache.org [mailto:kkoli...@apache.org]
Sent: Thursday, May 24, 2012 5:02 PM
To: dev@tomcat.apache.org
Subject: svn commit: r1342473 - in /tomcat/tc7.0.x/trunk: ./
java/org/apache/coyote/http11/Http11NioProcessor.java
java/org/apache/tomcat/util/net/NioEndpoint.java
Author: kkolinko
Date: Thu May 24 23:02:12 2012
New Revision: 1342473
URL: http://svn.apache.org/viewvc?rev=1342473view=rev
Log:
Merged revision 1342320 from tomcat/trunk:
Simplify.
The req argument in processSendfile() is always true, and it is no
more used since r1340215
Modified:
tomcat/tc7.0.x/trunk/ (props changed)
tomcat/tc7.0.x/trunk/java/org/apache/coyote/http11/Http11NioProcessor.ja
va
tomcat/tc7.0.x/trunk/java/org/apache/tomcat/util/net/NioEndpoint.java
Propchange: tomcat/tc7.0.x/trunk/
--
Merged /tomcat/trunk:r1342320
Modified:
tomcat/tc7.0.x/trunk/java/org/apache/coyote/http11/Http11NioProcessor.ja
va
URL:
http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/java/org/apache/coyote
/http11/Http11NioProcessor.java?rev=1342473r1=1342472r2=1342473view=d
iff
==
---
tomcat/tc7.0.x/trunk/java/org/apache/coyote/http11/Http11NioProcessor.ja
va (original)
+++
tomcat/tc7.0.x/trunk/java/org/apache/coyote/http11/Http11NioProcessor.ja
va Thu May 24 23:02:12 2012
@@ -284,7 +284,7 @@ public class Http11NioProcessor extends
socketWrapper.getSocket().getPoller().getSelector());
//do the first write on this thread, might as well
openSocket =
socketWrapper.getSocket().getPoller().processSendfile(key,
-(KeyAttachment) socketWrapper, true, true);
+(KeyAttachment) socketWrapper, true);
return true;
}
return false;
Modified:
tomcat/tc7.0.x/trunk/java/org/apache/tomcat/util/net/NioEndpoint.java
URL:
http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/java/org/apache/tomcat
/util/net/NioEndpoint.java?rev=1342473r1=1342472r2=1342473view=diff
==
---
tomcat/tc7.0.x/trunk/java/org/apache/tomcat/util/net/NioEndpoint.java
(original)
+++
tomcat/tc7.0.x/trunk/java/org/apache/tomcat/util/net/NioEndpoint.java
Thu May 24 23:02:12 2012
@@ -1230,7 +1230,7 @@ public class NioEndpoint extends Abstrac
NioChannel channel = attachment.getChannel();
if (sk.isReadable() || sk.isWritable() ) {
if ( attachment.getSendfileData() != null ) {
-processSendfile(sk,attachment,true, false);
+processSendfile(sk,attachment, false);
} else if ( attachment.getComet() ) {
//check if thread is available
if ( isWorkerAvailable() ) {
@@ -1276,7 +1276,7 @@ public class NioEndpoint extends Abstrac
return result;
}
-public boolean processSendfile(SelectionKey sk, KeyAttachment
attachment, boolean reg, boolean event) {
+public boolean processSendfile(SelectionKey sk, KeyAttachment
attachment, boolean event) {
NioChannel sc = null;
try {
unreg(sk, attachment, sk.readyOps());
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
RE: svn commit: r1342473 - in /tomcat/tc7.0.x/trunk: ./ java/org/apache/coyote/http11/Http11NioProcessor.java java/org/apache/tomcat/util/net/NioEndpoint.java
Yes, I only bring it up cause I feel we already change way to much in point
releases. Even at 7.0.27 do we have stability issues, and that is not
something that happened with v5 and v6 where I felt we had a bit more
stability that late into the releases. I feel that in trunk, that is where
we continue development.
Tomcat is known for stabilizing it's product with very little changes that
late in the a release. Tomcat 7 has been far more volatile that I am used
to. We have a trunk for that exact purpose, to clean up, to improve and to
change API's.
Filip
-Original Message-
From: Konstantin Kolinko [mailto:knst.koli...@gmail.com]
Sent: Wednesday, May 30, 2012 3:36 PM
To: Tomcat Developers List
Subject: Re: svn commit: r1342473 - in /tomcat/tc7.0.x/trunk: ./
java/org/apache/coyote/http11/Http11NioProcessor.java
java/org/apache/tomcat/util/net/NioEndpoint.java
2012/5/30 Filip Hanik (mailing lists) devli...@hanik.com:
Changing a public API method is something I would do for trunk. I'm
not sure about a .28 release that is considered stable.
API Stability section of RELEASE-NOTES.txt says those are our
internals and may change without notice between point releases.
Is there a scenario when 3-rd party code would call that method, that
we may be concerned of?
This processSendfile() method is undocumented and it feels tightly
coupled with processing done elsewhere, and that overall feels like
internals.
I will add @deprecated version of processSendfile() method in
NioEndpoint that will ignore one of its parameters and call the
correct one. It feels waste, but it is not much to code.
Thank you for review.
Best regards,
Konstantin Kolinko
-Original Message-
From: kkoli...@apache.org [mailto:kkoli...@apache.org]
Sent: Thursday, May 24, 2012 5:02 PM
To: dev@tomcat.apache.org
Subject: svn commit: r1342473 - in /tomcat/tc7.0.x/trunk: ./
java/org/apache/coyote/http11/Http11NioProcessor.java
java/org/apache/tomcat/util/net/NioEndpoint.java
Author: kkolinko
Date: Thu May 24 23:02:12 2012
New Revision: 1342473
URL: http://svn.apache.org/viewvc?rev=1342473view=rev
Log:
Merged revision 1342320 from tomcat/trunk:
Simplify.
The req argument in processSendfile() is always true, and it is no
more used since r1340215
Modified:
tomcat/tc7.0.x/trunk/ (props changed)
tomcat/tc7.0.x/trunk/java/org/apache/coyote/http11/Http11NioProcessor.ja
va
tomcat/tc7.0.x/trunk/java/org/apache/tomcat/util/net/NioEndpoint.java
Propchange: tomcat/tc7.0.x/trunk/
-
---
--
Merged /tomcat/trunk:r1342320
Modified:
tomcat/tc7.0.x/trunk/java/org/apache/coyote/http11/Http11NioProcessor.ja
va
URL:
http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/java/org/apache/coyote
/http11/Http11NioProcessor.java?rev=1342473r1=1342472r2=1342473view=d
iff
==
---
tomcat/tc7.0.x/trunk/java/org/apache/coyote/http11/Http11NioProcessor.ja
va (original)
+++
tomcat/tc7.0.x/trunk/java/org/apache/coyote/http11/Http11NioProcessor.ja
va Thu May 24 23:02:12 2012
@@ -284,7 +284,7 @@ public class Http11NioProcessor extends
socketWrapper.getSocket().getPoller().getSelector());
//do the first write on this thread, might as well
openSocket =
socketWrapper.getSocket().getPoller().processSendfile(key,
- (KeyAttachment) socketWrapper, true, true);
+ (KeyAttachment) socketWrapper, true);
return true;
}
return false;
Modified:
tomcat/tc7.0.x/trunk/java/org/apache/tomcat/util/net/NioEndpoint.java
URL:
http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/java/org/apache/tomcat
/util/net/NioEndpoint.java?rev=1342473r1=1342472r2=1342473view=diff
==
---
tomcat/tc7.0.x/trunk/java/org/apache/tomcat/util/net/NioEndpoint.java
(original)
+++
tomcat/tc7.0.x/trunk/java/org/apache/tomcat/util/net/NioEndpoint.java
Thu May 24 23:02:12 2012
@@ -1230,7 +1230,7 @@ public class NioEndpoint extends Abstrac
NioChannel channel = attachment.getChannel();
if (sk.isReadable() || sk.isWritable() ) {
if ( attachment.getSendfileData() != null )
{
- processSendfile(sk,attachment,true,
false);
+ processSendfile(sk,attachment, false);
} else if ( attachment.getComet() ) {
//check if thread is available
if ( isWorkerAvailable() ) {
@@ -1276,7 +1276,7 @@ public class NioEndpoint extends Abstrac
return result;
}
- public boolean
Re: svn commit: r1340215 - /tomcat/trunk/java/org/apache/tomcat/util/net/NioEndpoint.java
- Mensaje original -
De: Rainer Jung rainer.j...@kippdata.de
}
Was that intentional? I'd say the timestamp should be provided by the
log framework and not by java.sql.Date. But maybe the whole message
is
just a leftover from debugging the issue.
The same for the TC 7 backport.
hi Rainer, no, not intentional, it is left over from debugging. I will remove
the Date object
Filip
try {
unreg(sk, attachment, sk.readyOps());
SendfileData sd = attachment.getSendfileData();
+//setup the file channel
if ( sd.fchannel == null ) {
File f = new File(sd.fileName);
if ( !f.exists() ) {
...
Regards,
Rainer
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
RE: svn commit: r1335546 - /tomcat/trunk/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/interceptor/ConnectionState.java
Yes we should. I can do it today, unless you beat me to it
-Original Message-
From: Konstantin Kolinko [mailto:knst.koli...@gmail.com]
Sent: Monday, May 14, 2012 5:55 AM
To: Tomcat Developers List
Subject: Re: svn commit: r1335546 - /tomcat/trunk/modules/jdbc-
pool/src/main/java/org/apache/tomcat/jdbc/pool/interceptor/ConnectionSta
te.java
2012/5/8 fha...@apache.org:
Author: fhanik
Date: Tue May 8 14:17:43 2012
New Revision: 1335546
URL: http://svn.apache.org/viewvc?rev=1335546view=rev
Log:
When a connection is disconnected, make sure we reset the cached
values. This can happen during a failed validation when reconnect() is
called.
Should we include this change into 7.0.x? It looks OK, but I have not
tested.
The svn:externals value in 7.0.x has not been updated yet.
Best regards,
Konstantin Kolinko
Modified:
tomcat/trunk/modules/jdbc-
pool/src/main/java/org/apache/tomcat/jdbc/pool/interceptor/ConnectionSta
te.java
Modified: tomcat/trunk/modules/jdbc-
pool/src/main/java/org/apache/tomcat/jdbc/pool/interceptor/ConnectionSta
te.java
URL: http://svn.apache.org/viewvc/tomcat/trunk/modules/jdbc-
pool/src/main/java/org/apache/tomcat/jdbc/pool/interceptor/ConnectionSta
te.java?rev=1335546r1=1335545r2=1335546view=diff
==
--- tomcat/trunk/modules/jdbc-
pool/src/main/java/org/apache/tomcat/jdbc/pool/interceptor/ConnectionSta
te.java (original)
+++ tomcat/trunk/modules/jdbc-
pool/src/main/java/org/apache/tomcat/jdbc/pool/interceptor/ConnectionSta
te.java Tue May 8 14:17:43 2012
@@ -110,6 +110,19 @@ public class ConnectionState extends Jdb
}
+
+ @Override
+ public void disconnected(ConnectionPool parent, PooledConnection
con, boolean finalizing) {
+ //we are resetting, reset our defaults
+ autoCommit = null;
+ transactionIsolation = null;
+ readOnly = null;
+ catalog = null;
+ super.disconnected(parent, con, finalizing);
+ }
+
+
+
@Override
public Object invoke(Object proxy, Method method, Object[] args)
throws Throwable {
String name = method.getName();
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
RE: [VOTE] Release Apache Tomcat Connectors 1.2.36
The Apache Tomcat Connectors 1.2.36 is [X] Stable, go ahead and release [ ] Broken because of ... Filip -Original Message- From: Mladen Turk [mailto:mt...@apache.org] Sent: Friday, May 11, 2012 3:27 AM To: dev@tomcat.apache.org Subject: Re: [VOTE] Release Apache Tomcat Connectors 1.2.36 On 05/09/2012 04:25 PM, Mladen Turk wrote: The VOTE will remain open for at least 48 hours. The Apache Tomcat Connectors 1.2.36 is [X] Stable, go ahead and release [ ] Broken because of ... Just FTR. [1] http://people.apache.org/~mturk/tomcat-connectors/jk-1.2.36/ Regards -- ^TM - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
RE: svn commit: r1333218 - in /tomcat/trunk: java/org/apache/tomcat/util/net/NioEndpoint.java webapps/docs/changelog.xml webapps/docs/config/http.xml
Math.min is the intention here. On a 64 core box, it should still only have 2
pollers, not 64
The comment should read ('from' instead of 'of')
Very hard for applications to see a performance benefit *from* more than 2
pollers
-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net]
Sent: Wednesday, May 02, 2012 7:14 PM
To: Tomcat Developers List
Subject: Re: svn commit: r1333218 - in /tomcat/trunk:
java/org/apache/tomcat/util/net/NioEndpoint.java
webapps/docs/changelog.xml webapps/docs/config/http.xml
Filip,
On 5/2/12 5:33 PM, fha...@apache.org wrote:
Very hard for applications to see a performance benefit of more than 2
pollers
[...]
-protected int pollerThreadCount =
Runtime.getRuntime().availableProcessors();
+protected int pollerThreadCount =
Math.min(2,Runtime.getRuntime().availableProcessors());
I think you mean Math.max(). What you have is a minimum of 2 and a
maximum of the number of cores, which is exactly the opposite of what
your commit comment says is appropriate.
-chris
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: have Re: MaxQueueSize for Executor and Tomcat 6
- Original Message - From: Rüdiger Plüm, Vodafone Group ruediger.pl...@vodafone.com Ok. As far as I can see the new method execute(Runnable command, long timeout, TimeUnit unit); of the Executor interface is implemented but not used. Would it still be an acceptable backport if 1. The changes to the Executor interface are removed from the patch 2. The implementation of execute(Runnable command, long timeout, TimeUnit unit); is removed from the patch. If yes I can update the patch. Yes Regards Rüdiger - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
RE: svn commit: r1307093 - /tomcat/trunk/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/DisposableConnectionFacade.java
-Original Message- From: Konstantin Kolinko [mailto:knst.koli...@gmail.com] Sent: Wednesday, April 04, 2012 2:34 PM To: Tomcat Developers List Subject: Re: svn commit: r1307093 - /tomcat/trunk/modules/jdbc- pool/src/main/java/org/apache/tomcat/jdbc/pool/DisposableConnectionFacad e.java 2012/4/4 Filip Hanik Mailing Lists devli...@hanik.com: I know of two places where long lines cause problems: 1. Commit e-mails. Long lines are wrapped and it impacts readability. 2. Side-by-side comparison in viewvc when you do colored comparison here I see a challenge, since so many of our commits, are not code commits, but like a line wrap commit like this, this pollutes our diffs and why I'm not a big fan of changing it for changing it. I do not remember many line-wrap commits. [Filip Hanik] You're looking at the reply of one. There are ending whitespace commits, because sometimes people forget to run checkstyle and we would be nagged if someone does not fix the code. Therefore I would like to stick to the current convention of 80 chars. It is not a hard convention (we do not enforce it through checkstyle), but something to follow. The convention is something fairly new. For most of the time of Tomcat's life time, it was the committers preference, but fairly recently is when we started modifying style for style's sake. So the archives you refer to, can't go that far back. The only convention we've had through the history of Tomcat, is spaces, not tabs, not line length etc. a. I might be not very careful in selecting English words. Please excuse me. b. I do not see much difference between convention and preference. [Filip Hanik] Convention = mutually agreed upon standard Preference = Individual standard, like I like 120, markt likes 80 If it is a preference of many then it has to be respected as a convention. Isn't it? [Filip Hanik] Not really, only if it is mutually agreed upon Previous discussion (December 2010): http://markmail.org/thread/alo77qd4yiduvqvz [Filip Hanik] Opinions in this thread as I read it is - 80 is a bit outdated - 80 is not enforced We also have this description of our coding style: http://tomcat.apache.org/getinvolved.html#Coding_Conventions [Filip Hanik] Again, I'm only bringing this up for the following reasons - I think we can modernize our preferences/conventions/standards - If we are gonna enforce something like that, let's automate it a bit more Now, since only three people have chimed in, you, me and Mark, and both you and Mark believe that 80 is good for now, then we should aim for it, but as the thread points out, not enforced. I'll bring it up in another year or so, when monitors are even better :) Filip Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - 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.27
[X] Stable - go ahead and release as 7.0.27 Stable - Original Message - From: Mark Thomas ma...@apache.org To: Tomcat Developers List dev@tomcat.apache.org Sent: Saturday, March 31, 2012 11:07:30 AM Subject: [VOTE] Release Apache Tomcat 7.0.27 The proposed Apache Tomcat 7.0.27 release is now available for voting. It can be obtained from: https://dist.apache.org/repos/dist/dev/tomcat/tomcat-7/v7.0.27/ The Maven staging repo is: https://repository.apache.org/content/repositories/orgapachetomcat-132/ The svn tag is: http://svn.apache.org/repos/asf/tomcat/tc7.0.x/tags/TOMCAT_7_0_27/ The proposed 7.0.27 release is: [ ] Broken - do not release [ ] Stable - go ahead and release as 7.0.27 Stable Cheers, Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1307093 - /tomcat/trunk/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/DisposableConnectionFacade.java
- Original Message -
From: ma...@apache.org
To: dev@tomcat.apache.org
Sent: Thursday, March 29, 2012 2:19:18 PM
Subject: svn commit: r1307093 -
/tomcat/trunk/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/DisposableConnectionFacade.java
Author: markt
Date: Thu Mar 29 20:19:18 2012
New Revision: 1307093
@Override
-public Object invoke(Object proxy, Method method, Object[] args)
throws Throwable {
+public Object invoke(Object proxy, Method method, Object[] args)
+throws Throwable {
Can we change the line length to something more modern than our 1980s monitors
that were limited to 80 characters.
In today's environment, 80 characters is like your chat window, surely we can
go 120 or 150 and get way more readable code
Filip
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1307093 - /tomcat/trunk/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/DisposableConnectionFacade.java
- Original Message -
From: Mark Thomas ma...@apache.org
To: Tomcat Developers List dev@tomcat.apache.org
Sent: Wednesday, April 4, 2012 11:18:42 AM
Subject: Re: svn commit: r1307093 -
/tomcat/trunk/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/DisposableConnectionFacade.java
On 04/04/2012 17:12, Filip Hanik Mailing Lists wrote:
- Original Message -
From: ma...@apache.org To: dev@tomcat.apache.org Sent: Thursday,
March 29, 2012 2:19:18 PM Subject: svn commit: r1307093 -
/tomcat/trunk/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/DisposableConnectionFacade.java
Author: markt
Date: Thu Mar 29 20:19:18 2012 New Revision: 1307093
@Override -public Object invoke(Object proxy, Method method,
Object[] args) throws Throwable { +public Object invoke(Object
proxy, Method method, Object[] args) +throws Throwable
{
Can we change the line length to something more modern than our
1980s
monitors that were limited to 80 characters. In today's
environment,
80 characters is like your chat window, surely we can go 120 or 150
and get way more readable code
If I was going to dedicate my whole screen to the code pane then yes,
whole screen can probably fit 300+ characters, so were not talking whole screen.
80 is so tiny that it takes up a quarter of my screen or less.
I would therefor suggest to increase this, as it will dramatically shrink the
number of lines of code, and readability
but there are other useful panes I want to see as well. 80 chars is
about right for the code window (and the line length we generally
stick
to throughout the Tomcat code base).
Mark
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1307093 - /tomcat/trunk/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/DisposableConnectionFacade.java
- Original Message -
From: Konstantin Kolinko knst.koli...@gmail.com
To: Tomcat Developers List dev@tomcat.apache.org
Sent: Wednesday, April 4, 2012 11:52:01 AM
Subject: Re: svn commit: r1307093 -
/tomcat/trunk/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/DisposableConnectionFacade.java
2012/4/4 Filip Hanik Mailing Lists devli...@hanik.com:
- Original Message -
From: Mark Thomas ma...@apache.org
To: Tomcat Developers List dev@tomcat.apache.org
Sent: Wednesday, April 4, 2012 11:18:42 AM
Subject: Re: svn commit: r1307093 -
/tomcat/trunk/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/DisposableConnectionFacade.java
On 04/04/2012 17:12, Filip Hanik Mailing Lists wrote:
- Original Message -
From: ma...@apache.org To: dev@tomcat.apache.org Sent:
Thursday,
March 29, 2012 2:19:18 PM Subject: svn commit: r1307093 -
/tomcat/trunk/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/DisposableConnectionFacade.java
Author: markt
Date: Thu Mar 29 20:19:18 2012 New Revision: 1307093
@Override - public Object invoke(Object proxy, Method
method,
Object[] args) throws Throwable { + public Object
invoke(Object
proxy, Method method, Object[] args) + throws
Throwable
{
Can we change the line length to something more modern than our
1980s
monitors that were limited to 80 characters. In today's
environment,
80 characters is like your chat window, surely we can go 120 or
150
and get way more readable code
If I was going to dedicate my whole screen to the code pane then
yes,
whole screen can probably fit 300+ characters, so were not talking
whole screen.
80 is so tiny that it takes up a quarter of my screen or less.
I would therefor suggest to increase this, as it will dramatically
shrink the number of lines of code, and readability
I know of two places where long lines cause problems:
1. Commit e-mails.
Long lines are wrapped and it impacts readability.
2. Side-by-side comparison in viewvc when you do colored comparison
here I see a challenge, since so many of our commits, are not code commits, but
like a line wrap commit like this,
this pollutes our diffs and why I'm not a big fan of changing it for changing
it.
Therefore I would like to stick to the current convention of 80
chars.
It is not a hard convention (we do not enforce it through
checkstyle),
but something to follow.
The convention is something fairly new. For most of the time of Tomcat's life
time, it was the committers preference, but fairly recently is when we started
modifying style for style's sake. So the archives you refer to, can't go that
far back. The only convention we've had through the history of Tomcat, is
spaces, not tabs, not line length etc.
There should be several previous discussions on this topic in the
archives...
Best regards,
Konstantin Kolinko
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
RE: svn commit: r1306130 - in /tomcat/trunk/java/org/apache/catalina/startup: LocalStrings.properties UserConfig.java
-Original Message-
From: kfuj...@apache.org [mailto:kfuj...@apache.org]
Sent: Tuesday, March 27, 2012 8:51 PM
To: dev@tomcat.apache.org
Subject: svn commit: r1306130 - in
/tomcat/trunk/java/org/apache/catalina/startup: LocalStrings.properties
UserConfig.java
+ for (Future? result : results) {
+ try {
+ result.get();
+ } catch (Exception e) {
+
host.getLogger().error(sm.getString(userConfig.deploy.threaded.error),
e);
+ }
+ }
}
[Filip Hanik]
If results[0].get() fails, are you not going to wait for the others to
complete?
If results[0].get() fails, I am going to wait for the others to complete.
Thus I implemented try-catch inside a loop.
Is there wrong code in this rev?
Or don't I understand your comment correctly?
[Filip Hanik]
You got it right, I just misread the location of the try-catch
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
--
Keiichi.Fujino
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
RE: svn commit: r1305931 - in /tomcat/trunk/modules/jdbc-pool: doc/ src/main/java/org/apache/tomcat/jdbc/pool/ src/main/java/org/apache/tomcat/jdbc/pool/jmx/
If InterruptedException was thrown by JRE it alone means that
interrupted flag has been cleared. So Thread.interrupted() call is a
NOOP.
(Effectively the interruption state means to interrupt the next
wait() etc. call immediately when they are called. When the actual
interruption happens the exception is created and the flag is
cleared.)
To propagate the interruption state the code would be
if (propagate) {
Thread.currentThread().interrupt();
}
[Filip Hanik]
You are correct. I will adjust this.
Best regards,
Konstantin Kolinko
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
RE: [VOTE] Release Apache Taglibs Parent POM 3
[+1] Released -Original Message- From: Jeremy Boynes [mailto:jer...@boynes.com] On Behalf Of Jeremy Boynes Sent: Sunday, March 25, 2012 11:02 PM To: Tomcat Developers List Subject: [VOTE] Release Apache Taglibs Parent POM 3 The proposed 3 release of Apache Taglibs Parent POM is now available for voting. This release addresses issues found during the 1 release process including duplicate LICENSE files and poor site configuration, and updates the copyright date in the NOTICE file from release 2 (withdrawn). The Maven staging repo is: https://repository.apache.org/content/repositories/orgapachetomcat-111/ and SVN tag is: http://svn.apache.org/repos/asf/tomcat/taglibs/taglibs-parent/tags/taglibs- parent-3/ Please vote on whether Apache Taglibs Parent 3 should be: [+1] Released, or [-1] Not released because ... Thanks Jeremy - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
RE: [VOTE] Release Apache Taglibs Parent POM 3
-Original Message- From: Jeremy Boynes [mailto:jer...@boynes.com] On Behalf Of Jeremy Boynes Sent: Wednesday, March 28, 2012 8:38 AM To: Tomcat Developers List Subject: Re: [VOTE] Release Apache Taglibs Parent POM 3 Request for more votes please, we only have one binding vote so far. [Filip Hanik] Add your own :) - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
RE: svn commit: r1306130 - in /tomcat/trunk/java/org/apache/catalina/startup: LocalStrings.properties UserConfig.java
-Original Message-
From: kfuj...@apache.org [mailto:kfuj...@apache.org]
Sent: Tuesday, March 27, 2012 8:51 PM
To: dev@tomcat.apache.org
Subject: svn commit: r1306130 - in
/tomcat/trunk/java/org/apache/catalina/startup: LocalStrings.properties
UserConfig.java
+for (Future? result : results) {
+try {
+result.get();
+} catch (Exception e) {
+
host.getLogger().error(sm.getString(userConfig.deploy.threaded.error),
e);
+}
+}
}
[Filip Hanik]
If results[0].get() fails, are you not going to wait for the others to complete?
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
RE: buildbot failure in ASF Buildbot on tomcat-trunk
Is it my email client, or are some of these emails empty? -Original Message- From: build...@apache.org [mailto:build...@apache.org] Sent: Wednesday, March 28, 2012 10:00 AM To: dev@tomcat.apache.org Subject: buildbot failure in ASF Buildbot on tomcat-trunk - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: SPDY support
Tomcat 7 is a Servlet 3.0 implementation with requirements to support Java 6,
wouldn't this break that contract if we do it for NIO/BIO?
Could this be done as a extras package for the Java connectors?
Why not add this into trunk first, and work with it there, as opposed to an
external repository?
Filip
- Original Message -
From: Costin Manolache cos...@gmail.com
To: Tomcat Developers List dev@tomcat.apache.org
Sent: Saturday, March 24, 2012 10:44:19 PM
Subject: Re: SPDY support
Hi,
I did a first round of backporting to tomcat7 - only the hooks.
Please take
a look and let me know:
https://github.com/costinm/tomcat/blob/trunk/tomcat7.diff
I've also submitted to git the changes to support SPDY/NPN for NIO
and JIO
connectors - almost same diff, but the important change is:
https://github.com/costinm/tomcat/commit/698f4105a818e872877f3e8d9c50e003e2e706f0
The problem is that it add a compile dep on
http://wiki.eclipse.org/Jetty/Feature/NPN
the classes are modified from openjdk7 - it'll also need to be added
at
runtime ( if spdy support with nio/jio is needed ), but I assume
users can
download the jar until it gets merged into jdk7.
Alternative is to move all the coyote/spdy/{nio,jio} classes to a
separate
repository, outside tomcat tree. I guess we could also move all spdy
impl
to a separate repo and only leave the hooks.
Costin
On Mon, Mar 19, 2012 at 11:31 AM, Costin Manolache cos...@gmail.com
wrote:
On Mon, Mar 19, 2012 at 10:43 AM, Gus Heck ph...@copyright.com
wrote:
I just bumped into the whole concept of SPDY this morning, and it
sounds
fabulous, and I'm quite happy to see that it's already underway in
trunk.
I'm quite likely to be using a lot of development using Vaadin
framework in
the near future, which I expect probably stands to benefit
significantly
from SPDY. However, it seems that SPDY support in java is a wee
tad
nascent. As I understand it, there's an issue with oracle JDK
support for
NPN that is forcing tomcat to use APR. I also notice that Jetty
has just
released a version that supports SPDY using the NPN that is
apparently in
OpenJDK 7 already (will it appear in an oracle java update?).
Clearly this
is a key innovation, and it looks like between Apache Hhttpd and
Chrome/Firefox/Safari, more than 50% of the web will support it on
both
client and server merely by staying up to date with their current
software.
I have Jetty NPN working with tomcat - so NIO/BIO will also support
SPDY.
You will have to download/install the jetty implementation of npn
jar
yourself until it's merged into JDK7, don't know what are their
plans.
The APR seems faster - but not by a huge margin, I haven't tested
the
limits yet ( I want to find out what's the max number of kept-alive
spdy
connections - need more machines because of the 64k limit on local
ports).
My question is this: will SPDY support be released in some form
before
Tomcat 8 (in who's branch it seems to currently live)? JSR 340
(servlet
3.1) seems to be targeting Q3 2012 and I would presume that that
means
tomcat 8 is no sooner than Q3 or Q4 - 2012. Seems a shame to make
this wait
until that time (assuming it's anywhere near ready).
I have a patch for tomcat7 to add only the NPN hooks - it's pretty
small
and clean, I'll get a discussion started, but it should be
possible.
Then it's up to tomcat-dev on whether to backport the spdy
packages, or
have tomcat7 download the spdy jars separately ( i.e. release them
as a
'plugin' / add-on ).
It'll take a bit of time until it's done - not easy to find free
time to
work on this.
Costin
-Gus
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
RE: [VOTE] Release Apache Tomcat Connectors 1.2.35
[X] Stable, go ahead and release -Original Message- From: Mladen Turk [mailto:mt...@apache.org] Sent: Thursday, March 22, 2012 10:50 AM To: Tomcat Developers List Subject: Re: [VOTE] Release Apache Tomcat Connectors 1.2.35 On 03/22/2012 02:46 PM, Mladen Turk wrote: The VOTE will remain open for at least 48 hours. The Apache Tomcat Connectors 1.2.35 is [X] Stable, go ahead and release [ ] Broken because of ... My vote. Since we already gathered enough votes for 1.2.34 and this version only fixes user config typo (no other functional change) think we can even close the vote before 48-hours time frame (given we collect two more +1s of course :) Regards -- ^TM - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
RE: svn commit: r1303082 - /tomcat/trunk/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/PoolExhaustedException.java
On windows, it wasn't picking up ~/.subversion/config but ~/AppData/Roaming/Subversion/config Filip -Original Message- From: Filip Hanik (mailing lists) [mailto:devli...@hanik.com] Sent: Wednesday, March 21, 2012 6:17 PM To: 'Tomcat Developers List' Subject: RE: svn commit: r1303082 - /tomcat/trunk/modules/jdbc- pool/src/main/java/org/apache/tomcat/jdbc/pool/PoolExhaustedException. java I got all that setup, it's not picking up my home directory, I will check to see what it is looking for -Original Message- From: Konstantin Kolinko [mailto:knst.koli...@gmail.com] Sent: Wednesday, March 21, 2012 4:26 PM To: Tomcat Developers List Subject: Re: svn commit: r1303082 - /tomcat/trunk/modules/jdbc- pool/src/main/java/org/apache/tomcat/jdbc/pool/PoolExhaustedException. java 2012/3/20 Filip Hanik (mailing lists) devli...@hanik.com: I need to investigate this, and why my config file is not being picked up by subversion Maybe you do not have this setting: [miscellany] enable-auto-props = yes in the file named config in Subversion configuration area. [1] The default value of it is no. [1] http://svnbook.red-bean.com/en/1.7/svn.advanced.confarea.html Best Filip -Original Message- From: kkoli...@apache.org [mailto:kkoli...@apache.org] Sent: Tuesday, March 20, 2012 12:39 PM To: dev@tomcat.apache.org Subject: svn commit: r1303082 - /tomcat/trunk/modules/jdbc- pool/src/main/java/org/apache/tomcat/jdbc/pool/PoolExhaustedException. java Author: kkolinko Date: Tue Mar 20 18:39:28 2012 New Revision: 1303082 URL: http://svn.apache.org/viewvc?rev=1303082view=rev Log: svn:eol-style = native (...) Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat Connectors 1.2.34
[X] Stable, go ahead and release - Original Message - From: Henri Gomez henri.go...@gmail.com To: Tomcat Developers List dev@tomcat.apache.org Sent: Wednesday, March 21, 2012 2:33:58 AM Subject: Re: [VOTE] Release Apache Tomcat Connectors 1.2.34 The Apache Tomcat Connectors 1.2.34 is [X] Stable, go ahead and release [ ] Broken because of ... - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
RE: svn commit: r1303082 - /tomcat/trunk/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/PoolExhaustedException.java
I got all that setup, it's not picking up my home directory, I will check to see what it is looking for -Original Message- From: Konstantin Kolinko [mailto:knst.koli...@gmail.com] Sent: Wednesday, March 21, 2012 4:26 PM To: Tomcat Developers List Subject: Re: svn commit: r1303082 - /tomcat/trunk/modules/jdbc- pool/src/main/java/org/apache/tomcat/jdbc/pool/PoolExhaustedException. java 2012/3/20 Filip Hanik (mailing lists) devli...@hanik.com: I need to investigate this, and why my config file is not being picked up by subversion Maybe you do not have this setting: [miscellany] enable-auto-props = yes in the file named config in Subversion configuration area. [1] The default value of it is no. [1] http://svnbook.red-bean.com/en/1.7/svn.advanced.confarea.html Best Filip -Original Message- From: kkoli...@apache.org [mailto:kkoli...@apache.org] Sent: Tuesday, March 20, 2012 12:39 PM To: dev@tomcat.apache.org Subject: svn commit: r1303082 - /tomcat/trunk/modules/jdbc- pool/src/main/java/org/apache/tomcat/jdbc/pool/PoolExhaustedException. java Author: kkolinko Date: Tue Mar 20 18:39:28 2012 New Revision: 1303082 URL: http://svn.apache.org/viewvc?rev=1303082view=rev Log: svn:eol-style = native (...) Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
RE: svn commit: r1302948 - in /tomcat/trunk/modules/jdbc-pool/src: main/java/org/apache/tomcat/jdbc/pool/ main/java/org/apache/tomcat/jdbc/pool/jmx/ test/java/org/apache/tomcat/jdbc/test/
-Original Message- There is no need in the above clone() method. It has the same access level (protected) as super one. I see that PoolProperties is written as implements Cloneable. In such case the clone method is usually redeclared as public one. [Filip Hanik] No, implements Cloneable , just means that the JVM wont throw an exception if you try to call the method and it is not implemented. It lets the JVM do the cloning for you The IDE added in the method, and I don't see how it hurts - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
RE: svn commit: r1303082 - /tomcat/trunk/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/PoolExhaustedException.java
I need to investigate this, and why my config file is not being picked up by
subversion
Best
Filip
-Original Message-
From: kkoli...@apache.org [mailto:kkoli...@apache.org]
Sent: Tuesday, March 20, 2012 12:39 PM
To: dev@tomcat.apache.org
Subject: svn commit: r1303082 - /tomcat/trunk/modules/jdbc-
pool/src/main/java/org/apache/tomcat/jdbc/pool/PoolExhaustedException.
java
Author: kkolinko
Date: Tue Mar 20 18:39:28 2012
New Revision: 1303082
URL: http://svn.apache.org/viewvc?rev=1303082view=rev
Log:
svn:eol-style = native
Modified:
tomcat/trunk/modules/jdbc-
pool/src/main/java/org/apache/tomcat/jdbc/pool/PoolExhaustedException.
java (contents, props changed)
Modified: tomcat/trunk/modules/jdbc-
pool/src/main/java/org/apache/tomcat/jdbc/pool/PoolExhaustedException.
java
URL: http://svn.apache.org/viewvc/tomcat/trunk/modules/jdbc-
pool/src/main/java/org/apache/tomcat/jdbc/pool/PoolExhaustedException.
java?rev=1303082r1=1303081r2=1303082view=diff
==
--- tomcat/trunk/modules/jdbc-
pool/src/main/java/org/apache/tomcat/jdbc/pool/PoolExhaustedException.
java (original)
+++ tomcat/trunk/modules/jdbc-
pool/src/main/java/org/apache/tomcat/jdbc/pool/PoolExhaustedException.
java Tue Mar 20 18:39:28 2012
@@ -1,54 +1,54 @@
-/*
- * Licensed to the Apache Software Foundation (ASF) under one or more
- * contributor license agreements. See the NOTICE file distributed with
- * this work for additional information regarding copyright ownership.
- * The ASF licenses this file to You under the Apache License, Version 2.0
- * (the License); you may not use this file except in compliance with
- * the License. You may obtain a copy of the License at
- *
- * http://www.apache.org/licenses/LICENSE-2.0
- *
- * Unless required by applicable law or agreed to in writing, software
- * distributed under the License is distributed on an AS IS BASIS,
- * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
implied.
- * See the License for the specific language governing permissions and
- * limitations under the License.
- */
-package org.apache.tomcat.jdbc.pool;
-
-import java.sql.SQLException;
-
-public class PoolExhaustedException extends SQLException {
-
-public PoolExhaustedException() {
-}
-
-public PoolExhaustedException(String reason) {
-super(reason);
-}
-
-public PoolExhaustedException(Throwable cause) {
-super(cause);
-}
-
-public PoolExhaustedException(String reason, String SQLState) {
-super(reason, SQLState);
-}
-
-public PoolExhaustedException(String reason, Throwable cause) {
-super(reason, cause);
-}
-
-public PoolExhaustedException(String reason, String SQLState, int
vendorCode) {
-super(reason, SQLState, vendorCode);
-}
-
-public PoolExhaustedException(String reason, String sqlState, Throwable
cause) {
-super(reason, sqlState, cause);
-}
-
-public PoolExhaustedException(String reason, String sqlState, int
vendorCode, Throwable cause) {
-super(reason, sqlState, vendorCode, cause);
-}
-
-}
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the License); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an AS IS BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.tomcat.jdbc.pool;
+
+import java.sql.SQLException;
+
+public class PoolExhaustedException extends SQLException {
+
+public PoolExhaustedException() {
+}
+
+public PoolExhaustedException(String reason) {
+super(reason);
+}
+
+public PoolExhaustedException(Throwable cause) {
+super(cause);
+}
+
+public PoolExhaustedException(String reason, String SQLState) {
+super(reason, SQLState);
+}
+
+public PoolExhaustedException(String reason, Throwable cause) {
+super(reason, cause);
+}
+
+public PoolExhaustedException(String reason, String SQLState, int
vendorCode) {
+super(reason, SQLState, vendorCode);
+}
+
+public PoolExhaustedException(String reason, String sqlState, Throwable
cause) {
+super(reason, sqlState, cause);
+}
+
+public
RE: svn commit: r1303096 - in /tomcat/trunk/modules/jdbc-pool: doc/jdbc-pool.xml src/test/java/org/apache/tomcat/jdbc/test/MultipleCloseTest.java
Have we published a check style configuration file?
-Original Message-
From: kkoli...@apache.org [mailto:kkoli...@apache.org]
Sent: Tuesday, March 20, 2012 12:56 PM
To: dev@tomcat.apache.org
Subject: svn commit: r1303096 - in /tomcat/trunk/modules/jdbc-pool:
doc/jdbc-pool.xml
src/test/java/org/apache/tomcat/jdbc/test/MultipleCloseTest.java
Author: kkolinko
Date: Tue Mar 20 18:55:40 2012
New Revision: 1303096
URL: http://svn.apache.org/viewvc?rev=1303096view=rev
Log:
Fix checkstyle issues with trailing spaces and imports formatting.
Modified:
tomcat/trunk/modules/jdbc-pool/doc/jdbc-pool.xml
tomcat/trunk/modules/jdbc-
pool/src/test/java/org/apache/tomcat/jdbc/test/MultipleCloseTest.java
Modified: tomcat/trunk/modules/jdbc-pool/doc/jdbc-pool.xml
URL: http://svn.apache.org/viewvc/tomcat/trunk/modules/jdbc-
pool/doc/jdbc-pool.xml?rev=1303096r1=1303095r2=1303096view=diff
==
--- tomcat/trunk/modules/jdbc-pool/doc/jdbc-pool.xml (original)
+++ tomcat/trunk/modules/jdbc-pool/doc/jdbc-pool.xml Tue Mar 20
18:55:40 2012
@@ -70,7 +70,7 @@
liAbility to configure custom interceptors.
This allows you to write custom interceptors to enhance the
functionality. You can use interceptors to gather query stats,
cache session states, reconnect the connection upon failures, retry
queries, cache query results, and so on.
- Your options are endless and the interceptors are dynamic, not
tied to
a JDK version of a
+ Your options are endless and the interceptors are dynamic, not
tied to
a JDK version of a
codejava.sql/code/codejavax.sql/code interface./li
liHigh performance - we will show some differences in performance
later on/li
liExtremely simple, due to the very simplified implementation, the
line
count and source file count are very low, compare with c3p0
@@ -455,7 +455,7 @@
/p
/attribute
attribute name=useDisposableConnectionFacade required=false
- p(boolean) Set this to true if you wish to put a facade on your
connection so that it cannot be reused after it has been closed. This prevents
a thread holding on to a
+ p(boolean) Set this to true if you wish to put a facade on your
connection so that it cannot be reused after it has been closed. This prevents
a thread holding on to a
reference of a connection it has already called closed
on, to
execute queries on it. Default value is codefalse/code for backwards
compatibility.
/p
/attribute
Modified: tomcat/trunk/modules/jdbc-
pool/src/test/java/org/apache/tomcat/jdbc/test/MultipleCloseTest.java
URL: http://svn.apache.org/viewvc/tomcat/trunk/modules/jdbc-
pool/src/test/java/org/apache/tomcat/jdbc/test/MultipleCloseTest.java?rev
=1303096r1=1303095r2=1303096view=diff
==
--- tomcat/trunk/modules/jdbc-
pool/src/test/java/org/apache/tomcat/jdbc/test/MultipleCloseTest.java
(original)
+++ tomcat/trunk/modules/jdbc-
pool/src/test/java/org/apache/tomcat/jdbc/test/MultipleCloseTest.java Tue
Mar 20 18:55:40 2012
@@ -18,6 +18,7 @@
package org.apache.tomcat.jdbc.test;
import java.sql.Connection;
+
import org.apache.tomcat.jdbc.test.driver.Driver;
public class MultipleCloseTest extends DefaultTestCase {
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: WebSockets in Tomcat 6
- Original Message - From: Costin Manolache cos...@gmail.com I haven't looked at the tomcat6/tomcat7 interfaces, but I think the current hook mechanism used by spdy could be ported with minimal risk and could be used by websockets. Tomcat 7 may be a candidate. Tomcat 6, If I was an administrator, I would not expect any code changes like that in a dot release. All we need in both cases is for the request to stop being processed by the original protocol, and to have direct access to the socket. Than spdy can do its multiplexing and websocket can keep the socket alive and let the original request headers go away. Yes, I'd like to see some real numbers on the request header overhead. I doubt it will be an issue for Tomcat 6. For Tomcat 7 large refactorings and optimzations are happening all the time, so in there it makes sense. The hard part for spdy backporting is getting the SpdyProcessor - i.e. the virtual/multiplexed request/response, not associated with a real socket. ( which still requires lots of work on trunk, to get the rest of the features - comet, websocket-over-spdy, etc ). Not sure how hard it'll be to backport, but still it shouldn't be very risky. As I just got back into the code mode of Tomcat, I'll look forward to take a look and see how it progresses. Filip - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
WebSockets in Tomcat 6
http://people.apache.org/~fhanik/reports/servers/
Attached is a patch that leverages the Tomcat WebSocket API with minimalistic
changes and uses that to implement WebSockets in Tomcat 6.0.x
http://people.apache.org/~fhanik/websockets-for-tomcat-6.patch
This implementation doesn't touch the endpoints or any real connector logic,
making it risk free. The only change that could do anything, would be the
XXXProcessor
+if (statusCode == HttpServletResponse.SC_SWITCHING_PROTOCOLS) {
+outputBuffer.addActiveFilter
+(outputFilters[Constants.IDENTITY_FILTER]);
+} else
Where it sets an identity filter when the user is switching protocols.
Otherwise Tomcat defaults to chunked encoding. You can still see Tomcat 8 sends
a
Transfer-Encoding:chunked
as part of a web socket response.
This implementation also works with BIO connector, as Tomcat's CometProcessor
interface supports both, and let's the implementer implement both Comet and non
Comet in the same class.
Hopefully this patch shows
1. It's fairly risk free to implement this in stables branches as Tomcat 6, and
possibly Tomcat 7 (as we may want to treat this as fairly stable and minimize
refactoring this late in the game)
2. Performance of Comet is similar to the non Comet implementation
3. It took me 4 hours to do this migration, so it's definitely very easy to
work with Comet once you have the bulk work done (the WebSocket protocol impl
by Mark Thomas)
The test suite report is at
http://people.apache.org/~fhanik/reports/servers/
I would suggest we consider this for Tomcat 6(my experience is still most users
are using this version). For Tomcat 7, I would recommend it, as it avoids
refactoring, but I'm pretty neutral about it.
Filip
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1207856 - /tomcat/tc7.0.x/trunk/modules/
svn propset svn:externals '^/tomcat/trunk/modules/jdbc-pool@1207712 jdbc-pool' modules does that seem right? - Original Message - From: fha...@apache.org To: dev@tomcat.apache.org Sent: Tuesday, November 29, 2011 6:00:19 AM Subject: svn commit: r1207856 - /tomcat/tc7.0.x/trunk/modules/ Author: fhanik Date: Tue Nov 29 13:00:18 2011 New Revision: 1207856 URL: http://svn.apache.org/viewvc?rev=1207856view=rev Log: maybe this time Modified: tomcat/tc7.0.x/trunk/modules/ (props changed) Propchange: tomcat/tc7.0.x/trunk/modules/ -- --- svn:externals (original) +++ svn:externals Tue Nov 29 13:00:18 2011 @@ -1 +1 @@ -^/tomcat/trunk/modules/jdbc-pool@1207712 modules/jdbc-pool +^/tomcat/trunk/modules/jdbc-pool@1207712 jdbc-pool - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - 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.35
[X] Stable Filip - Original Message - From: jean-frederic clere jfcl...@gmail.com To: dev@tomcat.apache.org Sent: Monday, November 28, 2011 4:30:37 AM Subject: [VOTE] Release build 6.0.35 The candidates binaries are available here: http://people.apache.org/~jfclere/tomcat-6/v6.0.35/ According to the release process, the 6.0.35 build corresponding to the tag TOMCAT_6_0_35 is: [ ] Broken [ ] Alpha [ ] Beta [ ] Stable Cheers Jean-Frederic - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Proxied client IP logging
if you have two proxy servers, very common, the X-Forwarded-For becomes a comma separated list of IP addresses Shankar Unni wrote: Tim Funk wrote: 2) X-Forwarded-For (IIRC) can be multi-valued (comma seperated via multiple proxies) Plus, other load balancers seem to stick in other headers, too (e.g. X-Real-IP). (These two seem to be the most popular). It'll be an interesting job to figure out the real IP address if your request goes through *two* proxy servers, and they each set a different header.. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
