svn commit: r1711404 - /tomcat/tc7.0.x/trunk/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/interceptor/SlowQueryReportJmx.java
Author: kfujino
Date: Fri Oct 30 06:25:14 2015
New Revision: 1711404
URL: http://svn.apache.org/viewvc?rev=1711404&view=rev
Log:
No-functional changes.
Remove TODO.
Modified:
tomcat/tc7.0.x/trunk/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/interceptor/SlowQueryReportJmx.java
Modified:
tomcat/tc7.0.x/trunk/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/interceptor/SlowQueryReportJmx.java
URL:
http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/interceptor/SlowQueryReportJmx.java?rev=1711404&r1=1711403&r2=1711404&view=diff
==
---
tomcat/tc7.0.x/trunk/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/interceptor/SlowQueryReportJmx.java
(original)
+++
tomcat/tc7.0.x/trunk/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/interceptor/SlowQueryReportJmx.java
Fri Oct 30 06:25:14 2015
@@ -124,7 +124,6 @@ public class SlowQueryReportJmx extends
@Override
public void reset(ConnectionPool parent, PooledConnection con) {
-// TODO Auto-generated method stub
super.reset(parent, con);
if (parent!=null) {
poolName = parent.getName();
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1711403 - /tomcat/tc8.0.x/trunk/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/interceptor/SlowQueryReportJmx.java
Author: kfujino
Date: Fri Oct 30 06:24:26 2015
New Revision: 1711403
URL: http://svn.apache.org/viewvc?rev=1711403&view=rev
Log:
No-functional changes.
Remove TODO.
Modified:
tomcat/tc8.0.x/trunk/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/interceptor/SlowQueryReportJmx.java
Modified:
tomcat/tc8.0.x/trunk/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/interceptor/SlowQueryReportJmx.java
URL:
http://svn.apache.org/viewvc/tomcat/tc8.0.x/trunk/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/interceptor/SlowQueryReportJmx.java?rev=1711403&r1=1711402&r2=1711403&view=diff
==
---
tomcat/tc8.0.x/trunk/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/interceptor/SlowQueryReportJmx.java
(original)
+++
tomcat/tc8.0.x/trunk/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/interceptor/SlowQueryReportJmx.java
Fri Oct 30 06:24:26 2015
@@ -123,7 +123,6 @@ public class SlowQueryReportJmx extends
@Override
public void reset(ConnectionPool parent, PooledConnection con) {
-// TODO Auto-generated method stub
super.reset(parent, con);
if (parent!=null) {
poolName = parent.getName();
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1711402 - /tomcat/trunk/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/interceptor/SlowQueryReportJmx.java
Author: kfujino
Date: Fri Oct 30 06:23:50 2015
New Revision: 1711402
URL: http://svn.apache.org/viewvc?rev=1711402&view=rev
Log:
No-functional changes.
Remove TODO.
Modified:
tomcat/trunk/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/interceptor/SlowQueryReportJmx.java
Modified:
tomcat/trunk/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/interceptor/SlowQueryReportJmx.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/interceptor/SlowQueryReportJmx.java?rev=1711402&r1=1711401&r2=1711402&view=diff
==
---
tomcat/trunk/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/interceptor/SlowQueryReportJmx.java
(original)
+++
tomcat/trunk/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/interceptor/SlowQueryReportJmx.java
Fri Oct 30 06:23:50 2015
@@ -123,7 +123,6 @@ public class SlowQueryReportJmx extends
@Override
public void reset(ConnectionPool parent, PooledConnection con) {
-// TODO Auto-generated method stub
super.reset(parent, con);
if (parent!=null) {
poolName = parent.getName();
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Switch 6.0.x from RTC to CTR
> > [ ] Continue to use RTC for 6.0.x > [X] Switch 6.0.x to CTR > > -- > Keiichi.Fujino >
[GUMP@vmgump]: Project tomcat-tc8.0.x-test-nio2 (in module tomcat-8.0.x) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at gene...@gump.apache.org. Project tomcat-tc8.0.x-test-nio2 has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 18 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - tomcat-tc8.0.x-test-nio2 : Tomcat 8.x, a web server implementing the Java Servlet 3.1, ... Full details are available at: http://vmgump.apache.org/gump/public/tomcat-8.0.x/tomcat-tc8.0.x-test-nio2/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Dependency on commons-daemon exists, no need to add for property commons-daemon.native.src.tgz. -DEBUG- Dependency on commons-daemon exists, no need to add for property tomcat-native.tar.gz. -INFO- Failed with reason build failed -INFO- Project Reports in: /srv/gump/public/workspace/tomcat-8.0.x/output/logs-NIO2 -INFO- Project Reports in: /srv/gump/public/workspace/tomcat-8.0.x/output/test-tmp-NIO2/logs -WARNING- No directory [/srv/gump/public/workspace/tomcat-8.0.x/output/test-tmp-NIO2/logs] The following work was performed: http://vmgump.apache.org/gump/public/tomcat-8.0.x/tomcat-tc8.0.x-test-nio2/gump_work/build_tomcat-8.0.x_tomcat-tc8.0.x-test-nio2.html Work Name: build_tomcat-8.0.x_tomcat-tc8.0.x-test-nio2 (Type: Build) Work ended in a state of : Failed Elapsed: 37 mins 12 secs Command Line: /usr/lib/jvm/java-8-oracle/bin/java -Djava.awt.headless=true -Dbuild.sysclasspath=only org.apache.tools.ant.Main -Dgump.merge=/srv/gump/public/gump/work/merge.xml -Djunit.jar=/srv/gump/public/workspace/junit/target/junit-4.13-SNAPSHOT.jar -Dobjenesis.jar=/srv/gump/public/workspace/objenesis/main/target/objenesis-2.3-SNAPSHOT.jar -Dtest.reports=output/logs-NIO2 -Dtomcat-native.tar.gz=/srv/gump/public/workspace/apache-commons/daemon/dist/bin/commons-daemon-20151030-native-src.tar.gz -Dexamples.sources.skip=true -Djdt.jar=/srv/gump/packages/eclipse/plugins/R-4.5-201506032000/ecj-4.5.jar -Dcommons-daemon.jar=/srv/gump/public/workspace/apache-commons/daemon/dist/commons-daemon-20151030.jar -Dcommons-daemon.native.src.tgz=/srv/gump/public/workspace/apache-commons/daemon/dist/bin/commons-daemon-20151030-native-src.tar.gz -Dtest.temp=output/test-tmp-NIO2 -Dtest.accesslog=true -Dexecute.test.nio=false -Dtest.openssl.path=/srv/gump/public/workspace/openssl-1.0.2/dest-20151030/bin /openssl -Dexecute.test.bio=false -Dexecute.test.apr=false -Dtest.excludePerformance=true -Dexecute.test.nio2=true -Deasymock.jar=/srv/gump/public/workspace/easymock/core/target/easymock-3.5-SNAPSHOT.jar -Dhamcrest.jar=/srv/gump/packages/hamcrest/hamcrest-core-1.3.jar -Dcglib.jar=/srv/gump/packages/cglib/cglib-nodep-2.2.jar test [Working Directory: /srv/gump/public/workspace/tomcat-8.0.x] CLASSPATH: /usr/lib/jvm/java-8-oracle/lib/tools.jar:/srv/gump/public/workspace/tomcat-8.0.x/output/build/webapps/examples/WEB-INF/classes:/srv/gump/public/workspace/tomcat-8.0.x/output/testclasses:/srv/gump/public/workspace/ant/dist/lib/ant.jar:/srv/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/srv/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/srv/gump/public/workspace/ant/dist/lib/ant-junit.jar:/srv/gump/public/workspace/ant/dist/lib/ant-junit4.jar:/srv/gump/public/workspace/ant/dist/lib/ant-swing.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-xalan2.jar:/srv/gump/public/workspace/xml-commons/java/build/resolver.jar:/srv/gump/public/workspace/tomcat-8.0.x/output/build/bin/bootstrap.jar:/srv/gump/public/workspace/tomcat-8.0.x/output/build/bin/tomcat-juli.jar:/srv/gump/public/workspace/tomcat-8.0.x/output/build/lib/annotations-api.jar:/srv/gump/public/workspace/tomcat-8.0.x/output/build/lib/servlet-api.ja r:/srv/gump/public/workspace/tomcat-8.0.x/output/build/lib/jsp-api.jar:/srv/gump/public/workspace/tomcat-8.0.x/output/build/lib/el-api.jar:/srv/gump/public/workspace/tomcat-8.0.x/output/build/lib/websocket-api.jar:/srv/gump/public/workspace/tomcat-8.0.x/output/build/lib/catalina.jar:/srv/gump/public/workspace/tomcat-8.0.x/output/build/lib/catalina-ant.jar:/srv/gump/public/workspace/tomcat-8.0.x/output/build/lib/catalina-storeconfig.jar:/srv/gump/public/workspace/tomcat-8.0.x/output/build/lib/tomcat-coyote.jar:/srv/gump/public/workspace/tomcat-8.0.x/output/build/lib/jasper.jar:/srv/gump/public/workspace/tomcat-8.0.x/output/build/lib/jasper-el.jar:/srv/gump/public/workspace/tomcat-8.0.x/output/build/lib/catalina-tribes.jar:/srv/gump/public/workspace/tomcat-8.0.x/output/build/lib/catalina-ha.jar:/srv/gump/public/workspace/tomcat-8.0.x/output/build/lib/tomcat-api.jar:/srv/gump/publi
[Bug 57799] MessageCreationException: Couldn't create SOAP message with Nio2 connector protocol
https://bz.apache.org/bugzilla/show_bug.cgi?id=57799 --- Comment #25 from Remy Maucherat --- When I say in the channel read, I mean here for the debug code: org.apache.tomcat.util.net.Nio2Channel.read(Nio2Channel.java:133) -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 57799] MessageCreationException: Couldn't create SOAP message with Nio2 connector protocol
https://bz.apache.org/bugzilla/show_bug.cgi?id=57799 --- Comment #24 from Remy Maucherat --- Hum, it's not trunk, it's branch 8 head. Anyway, the SSL thing was just coincidental, never mind. It would be nice in the channel read to capture the previous stack trace (throw and catch an exception, put it in a field, then catch the ReadPendingException and print the saved one). -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 57799] MessageCreationException: Couldn't create SOAP message with Nio2 connector protocol
https://bz.apache.org/bugzilla/show_bug.cgi?id=57799 --- Comment #23 from Justin --- (In reply to Remy Maucherat from comment #21) > This could use another trunk retest. Built, ran /trunk@1711357. Client now throws exception connected to non-SSL port too... 2015-10-29 16:44:58,287 exception [Thread-23] - ... - javax.xml.ws.soap.SOAPFaultException: Couldn't create SOAP message due to exception: java.nio.channels.ReadPendingException at com.sun.xml.ws.fault.SOAP11Fault.getProtocolException(SOAP11Fault.java:193) at com.sun.xml.ws.fault.SOAPFaultBuilder.createException(SOAPFaultBuilder.java:126) at com.sun.xml.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:123) at com.sun.xml.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:93) at com.sun.xml.ws.client.sei.SEIStub.invoke(SEIStub.java:144) Tomcat server exception in catalina.out... 29-Oct-2015 16:44:58.122 SEVERE [http-nio2-8080-exec-7] com.sun.xml.ws.transport.http.HttpAdapter$HttpToolkit.handle Couldn't create SOAP message due to exception: java.nio.channels.ReadPendingException com.sun.xml.ws.protocol.soap.MessageCreationException: Couldn't create SOAP message due to exception: java.nio.channels.ReadPendingException at com.sun.xml.ws.encoding.SOAPBindingCodec.decode(SOAPBindingCodec.java:363) at com.sun.xml.ws.transport.http.HttpAdapter.decodePacket(HttpAdapter.java:336) at com.sun.xml.ws.transport.http.HttpAdapter.access$400(HttpAdapter.java:96) at com.sun.xml.ws.transport.http.HttpAdapter$HttpToolkit.handle(HttpAdapter.java:591) at com.sun.xml.ws.transport.http.HttpAdapter.handle(HttpAdapter.java:259) at com.sun.xml.ws.transport.http.servlet.ServletAdapter.invokeAsync(ServletAdapter.java:213) at com.sun.xml.ws.transport.http.servlet.WSServletDelegate.doGet(WSServletDelegate.java:159) at com.sun.xml.ws.transport.http.servlet.WSServletDelegate.doPost(WSServletDelegate.java:194) at com.sun.xml.ws.transport.http.servlet.WSServlet.doPost(WSServlet.java:80) at javax.servlet.http.HttpServlet.service(HttpServlet.java:648) at javax.servlet.http.HttpServlet.service(HttpServlet.java:729) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:291) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:239) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:218) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:106) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:142) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:79) at org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:616) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:88) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:518) at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1091) at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:673) at org.apache.tomcat.util.net.Nio2Endpoint$SocketProcessor.doRun(Nio2Endpoint.java:1074) at org.apache.tomcat.util.net.Nio2Endpoint$SocketProcessor.run(Nio2Endpoint.java:1033) at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) at java.lang.Thread.run(Unknown Source) Caused by: java.nio.channels.ReadPendingException at sun.nio.ch.AsynchronousSocketChannelImpl.read(Unknown Source) at sun.nio.ch.AsynchronousSocketChannelImpl.read(Unknown Source) at org.apache.tomcat.util.net.Nio2Channel.read(Nio2Channel.java:133) at org.apache.coyote.http11.InternalNio2InputBuffer.fill(InternalNio2InputBuffer.java:225) at org.apache.coyote.http11.InternalNio2InputBuffer$SocketInputBuffer.doRead(InternalNio2InputBuffer.java:336) at org.apache.coyote.http11.filters.ChunkedInputFilter.readBytes(ChunkedInputFilter.java:320) at org.apache.coyote.http11.filters.ChunkedInputFilter.parseChunkHeader(ChunkedInputFilter.java:350) at org.apache.coyote.http11.filters.ChunkedInputFilter.doRead(ChunkedInputFilter.java:190) at org.apache.coyote.http11.AbstractInputBuffer.doRead(AbstractInputBuffer.java:416) at org.apache.coyote.Request.doRead(Request.java:469) at org.apache.catalina.connector.InputBuffer.realReadBytes(InputBuffer.java:342) at org.apache.tomcat.util.buf.ByteChunk.substract(ByteChunk.j
Re: [VOTE] Switch 6.0.x from RTC to CTR
2015-10-29 0:42 GMT+02:00 Mark Thomas : > > All, > > Many years ago, we switched all release branches to RTC primarily to > address a community problem where we could not agree on the best way > forward for some parts of the code. > > RTC served us well. The disagreements ceased pretty much instantly. > However, RTC also slowed us down. > > The development of 7.0.x started as CTR with a possibility of switching > to RTC if necessary. It never was. We chose not to switch 7.0.x to RTC > because the community issues that made RTC necessary had been solved and > RTC added unnecessary overhead and delay. 8.0.x and now 9.0.x progressed > the same way. Today, only 6.0.x is RTC. > > I believe the use of RTC for 6.0.x is causing more harm than good. There > are fixes I don't propose for backport to 6.0.x because of the extra > hassle RTC introduces. I suspect others take a similar approach judging > on the number of fixes that don't make it back to 6.0.x. > > I would therefore like to propose that we switch the 6.0.x release > branch from RTC to CTR and am therefore calling a VOTE to make this change. > > [ ] Continue to use RTC for 6.0.x > [X] Switch 6.0.x to CTR Regards, Violeta > Thanks, > > Mark > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org >
[Bug 58565] Connection will be closed on slow file download with non blocking http protocol
https://bz.apache.org/bugzilla/show_bug.cgi?id=58565 --- Comment #9 from Konstantin Kolinko --- (In reply to comment #8) > It would seem with the default buffer on Linux + localhost ... 1. If I understand correctly, real networks have some quality-of-service mechanisms. A well known one is MTU size. For a localhost connection the MTU size is enormous. 2. I do not know how wget implements its --limit-rate feature. Maybe all those MBs of data have already arrived and are in it's own (client's) buffer. 3. Maybe in some configurations it makes sense to specify timeouts measured by throughput, instead of a time unit. (E.g. it may be easier to configure requirement of minimum throughput of X kb/s instead of a read timeout of Y sec.) It means that the actual timeout (that will be used as an argument to APIs) needs to be calculated dynamically based on amount of data that have been transfered earlier over this connection. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 58565] Connection will be closed on slow file download with non blocking http protocol
https://bz.apache.org/bugzilla/show_bug.cgi?id=58565 --- Comment #8 from Remy Maucherat --- It works for me with the right configuration, but not the default one, so I chose WORKSFORME but I don't mind if someone wants to change it. It would seem with the default buffer on Linux + localhost and the default 20s timeout, the client read speed would have to be over 64KB/s to avoid a timeout. Increasing the timeout from 20s to 60s would allow slower speeds. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1711315 - in /tomcat/tc8.0.x/trunk: java/org/apache/coyote/http11/ java/org/apache/coyote/http11/upgrade/ java/org/apache/tomcat/util/net/ webapps/docs/
Author: remm
Date: Thu Oct 29 18:19:58 2015
New Revision: 1711315
URL: http://svn.apache.org/viewvc?rev=1711315&view=rev
Log:
Cancel pending blocking IO operation following a timeout in the NIO2 connector.
Modified:
tomcat/tc8.0.x/trunk/java/org/apache/coyote/http11/InternalNio2InputBuffer.java
tomcat/tc8.0.x/trunk/java/org/apache/coyote/http11/InternalNio2OutputBuffer.java
tomcat/tc8.0.x/trunk/java/org/apache/coyote/http11/upgrade/Nio2ServletInputStream.java
tomcat/tc8.0.x/trunk/java/org/apache/coyote/http11/upgrade/Nio2ServletOutputStream.java
tomcat/tc8.0.x/trunk/java/org/apache/tomcat/util/net/SecureNio2Channel.java
tomcat/tc8.0.x/trunk/webapps/docs/changelog.xml
Modified:
tomcat/tc8.0.x/trunk/java/org/apache/coyote/http11/InternalNio2InputBuffer.java
URL:
http://svn.apache.org/viewvc/tomcat/tc8.0.x/trunk/java/org/apache/coyote/http11/InternalNio2InputBuffer.java?rev=1711315&r1=1711314&r2=1711315&view=diff
==
---
tomcat/tc8.0.x/trunk/java/org/apache/coyote/http11/InternalNio2InputBuffer.java
(original)
+++
tomcat/tc8.0.x/trunk/java/org/apache/coyote/http11/InternalNio2InputBuffer.java
Thu Oct 29 18:19:58 2015
@@ -22,6 +22,7 @@ import java.net.SocketTimeoutException;
import java.nio.ByteBuffer;
import java.nio.channels.CompletionHandler;
import java.util.concurrent.ExecutionException;
+import java.util.concurrent.Future;
import java.util.concurrent.TimeUnit;
import java.util.concurrent.TimeoutException;
@@ -219,9 +220,10 @@ public class InternalNio2InputBuffer ext
} else {
byteBuffer.clear();
flipped = false;
+Future future = null;
try {
-nRead = socket.getSocket().read(byteBuffer)
-.get(socket.getTimeout(),
TimeUnit.MILLISECONDS).intValue();
+future = socket.getSocket().read(byteBuffer);
+nRead = future.get(socket.getTimeout(),
TimeUnit.MILLISECONDS).intValue();
} catch (ExecutionException e) {
if (e.getCause() instanceof IOException) {
throw (IOException) e.getCause();
@@ -231,6 +233,9 @@ public class InternalNio2InputBuffer ext
} catch (InterruptedException e) {
throw new IOException(e);
} catch (TimeoutException e) {
+if (future != null) {
+future.cancel(true);
+}
throw new SocketTimeoutException();
}
if (nRead > 0) {
Modified:
tomcat/tc8.0.x/trunk/java/org/apache/coyote/http11/InternalNio2OutputBuffer.java
URL:
http://svn.apache.org/viewvc/tomcat/tc8.0.x/trunk/java/org/apache/coyote/http11/InternalNio2OutputBuffer.java?rev=1711315&r1=1711314&r2=1711315&view=diff
==
---
tomcat/tc8.0.x/trunk/java/org/apache/coyote/http11/InternalNio2OutputBuffer.java
(original)
+++
tomcat/tc8.0.x/trunk/java/org/apache/coyote/http11/InternalNio2OutputBuffer.java
Thu Oct 29 18:19:58 2015
@@ -24,6 +24,7 @@ import java.nio.ByteBuffer;
import java.nio.channels.CompletionHandler;
import java.util.ArrayList;
import java.util.concurrent.ExecutionException;
+import java.util.concurrent.Future;
import java.util.concurrent.Semaphore;
import java.util.concurrent.TimeUnit;
import java.util.concurrent.TimeoutException;
@@ -393,12 +394,14 @@ public class InternalNio2OutputBuffer ex
// Ignore timeout
}
}
+Future future = null;
try {
if (bufferedWrites.size() > 0) {
for (ByteBuffer buffer : bufferedWrites) {
buffer.flip();
while (buffer.hasRemaining()) {
-if
(socket.getSocket().write(buffer).get(socket.getTimeout(),
TimeUnit.MILLISECONDS).intValue() < 0) {
+future = socket.getSocket().write(buffer);
+if (future.get(socket.getTimeout(),
TimeUnit.MILLISECONDS).intValue() < 0) {
throw new
EOFException(sm.getString("iob.failedwrite"));
}
}
@@ -410,7 +413,8 @@ public class InternalNio2OutputBuffer ex
flipped = true;
}
while (byteBuffer.hasRemaining()) {
-if
(socket.getSocket().write(byteBuffer).get(socket.getTimeout(),
TimeUnit.MILLISECONDS).intValue() < 0) {
+future = socket.getSocket().write(byteBuffer);
+if (future.get(socket.getTimeout(),
TimeUnit.MILLISECONDS).intValue() < 0) {
throw new
EOFException(sm.getString("iob.failedwrite"));
}
[Bug 58565] Connection will be closed on slow file download with non blocking http protocol
https://bz.apache.org/bugzilla/show_bug.cgi?id=58565 --- Comment #7 from Christopher Schultz --- It seems like less buffer for NIO makes sense in general, though I agree that changing the default is probably not necessary, here. It might be worth mentioning in the documentation that NIO + slow speed = increased change of end-to-end timeouts. It seems like there is also the possibility of maybe having some kind of QoS setting that causes flushes to occur with more regularity, even if the buffer is large enough to handle more data. Something like once every few seconds maybe? That way, the (slow) writes won't pile-up and cause a large flush that takes too much time. I don't know enough about the underlying NIO and threading strategy to know whether this would be easy or difficult, or yet another unnecessary complication in an already complicated machine. But theoretically, there are always some values for which connections will be dropped due to this problem. Unless buffers are eliminated, which degrades NIO -> BIO which is of course not what we want. How does a user balance throughput and performance against fault-tolerance? (also, should this resolution be INVALID/NOTABUG or WORKSFORME?) -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 58565] Connection will be closed on slow file download with non blocking http protocol
https://bz.apache.org/bugzilla/show_bug.cgi?id=58565 Remy Maucherat changed: What|Removed |Added Resolution|--- |WORKSFORME Status|NEW |RESOLVED --- Comment #6 from Remy Maucherat --- Well, it's a network stack thing so it is transparent. I suppose it is dynamic depending on the memory condition. The network stack has an incentive to make buffers huge since it will vastly improve performance as everything is non blocking. Luckily, it is exposed in NIOx (NIO2 has fewer socket options compared to NIO1, but it has that one) and I could find socket.txBufSize allows configuration in Tomcat, and probably there's something at the OS level as well. So a low value for socket.txBufSize allows this to run, I just verified it. By default I found out it is 1313280 for me [AKA memory is cheap :) ]. Anyway, thanks for the hint to get me to look at the socket options, it is now determined it is only a configuration issue. Given the low speeds needed for this to happen and the possible performance impact, I would be -1 for trying to override the network stack default without explicit user configuration. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 58565] Connection will be closed on slow file download with non blocking http protocol
https://bz.apache.org/bugzilla/show_bug.cgi?id=58565 --- Comment #5 from Christopher Schultz --- Bufferbloat strikes again. :( Does NIOx have enough control over the underlying socket/connection to reduce buffer sizes so that this problem is minimized? -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 57799] MessageCreationException: Couldn't create SOAP message with Nio2 connector protocol
https://bz.apache.org/bugzilla/show_bug.cgi?id=57799 --- Comment #22 from Remy Maucherat --- Investigating another issue, it seems possible this one is caused by a timeout exception that gets swallowed, followed by a new read attempt. It is not really a Tomcat bug if the theory is correct. In trunk, I added a cancel of the blocking read/write in case a timeout occurs, but it could cause a loop and the connection to stay active forever: a Servlet is not supposed to catch exceptions. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1711305 - /tomcat/trunk/java/org/apache/tomcat/util/net/SecureNio2Channel.java
Author: remm
Date: Thu Oct 29 17:07:56 2015
New Revision: 1711305
URL: http://svn.apache.org/viewvc?rev=1711305&view=rev
Log:
Propagate SSL read timeouts and cancel properly, to be able to cancel the
operation if a timeout occurs.
Modified:
tomcat/trunk/java/org/apache/tomcat/util/net/SecureNio2Channel.java
Modified: tomcat/trunk/java/org/apache/tomcat/util/net/SecureNio2Channel.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/util/net/SecureNio2Channel.java?rev=1711305&r1=1711304&r2=1711305&view=diff
==
--- tomcat/trunk/java/org/apache/tomcat/util/net/SecureNio2Channel.java
(original)
+++ tomcat/trunk/java/org/apache/tomcat/util/net/SecureNio2Channel.java Thu Oct
29 17:07:56 2015
@@ -574,7 +574,7 @@ public class SecureNio2Channel extends N
private class FutureRead implements Future {
private final ByteBuffer dst;
-private final Future integer;
+private Future integer;
private FutureRead(ByteBuffer dst) {
this.dst = dst;
if (unwrapBeforeRead || netInBuffer.position() > 0) {
@@ -597,7 +597,12 @@ public class SecureNio2Channel extends N
}
@Override
public Integer get() throws InterruptedException, ExecutionException {
-return (integer == null) ? unwrap(netInBuffer.position(), -1,
TimeUnit.MILLISECONDS) : unwrap(integer.get().intValue(), -1,
TimeUnit.MILLISECONDS);
+try {
+return (integer == null) ? unwrap(netInBuffer.position(), -1,
TimeUnit.MILLISECONDS) : unwrap(integer.get().intValue(), -1,
TimeUnit.MILLISECONDS);
+} catch (TimeoutException e) {
+// Cannot happen: no timeout
+throw new ExecutionException(e);
+}
}
@Override
public Integer get(long timeout, TimeUnit unit)
@@ -605,7 +610,7 @@ public class SecureNio2Channel extends N
TimeoutException {
return (integer == null) ? unwrap(netInBuffer.position(), timeout,
unit) : unwrap(integer.get(timeout, unit).intValue(), timeout, unit);
}
-private Integer unwrap(int nRead, long timeout, TimeUnit unit) throws
ExecutionException {
+private Integer unwrap(int nRead, long timeout, TimeUnit unit) throws
ExecutionException, TimeoutException, InterruptedException {
//are we in the middle of closing or closed?
if (closing || closed)
return Integer.valueOf(-1);
@@ -637,14 +642,11 @@ public class SecureNio2Channel extends N
//if we need more network data, then bail out for now.
if (unwrap.getStatus() == Status.BUFFER_UNDERFLOW) {
if (read == 0) {
-try {
-if (timeout > 0) {
-return
unwrap(sc.read(netInBuffer).get(timeout, unit).intValue(), timeout, unit);
-} else {
-return
unwrap(sc.read(netInBuffer).get().intValue(), -1, TimeUnit.MILLISECONDS);
-}
-} catch (InterruptedException | TimeoutException
e) {
-throw new ExecutionException(e);
+integer = sc.read(netInBuffer);
+if (timeout > 0) {
+return unwrap(integer.get(timeout,
unit).intValue(), timeout, unit);
+} else {
+return unwrap(integer.get().intValue(), -1,
TimeUnit.MILLISECONDS);
}
} else {
break;
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1711303 - /tomcat/trunk/java/org/apache/tomcat/util/net/Nio2Endpoint.java
Author: remm
Date: Thu Oct 29 17:01:31 2015
New Revision: 1711303
URL: http://svn.apache.org/viewvc?rev=1711303&view=rev
Log:
After a timeout using a future, the operation that caused the timeout should be
cancelled, otherwise it will still be pending. Found it investigating 58565,
and could be "causing" 57799 (which would be a timeout on a read being
swallowed and then disguised as a pending exception after trying to read again).
Modified:
tomcat/trunk/java/org/apache/tomcat/util/net/Nio2Endpoint.java
Modified: tomcat/trunk/java/org/apache/tomcat/util/net/Nio2Endpoint.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/util/net/Nio2Endpoint.java?rev=1711303&r1=1711302&r2=1711303&view=diff
==
--- tomcat/trunk/java/org/apache/tomcat/util/net/Nio2Endpoint.java (original)
+++ tomcat/trunk/java/org/apache/tomcat/util/net/Nio2Endpoint.java Thu Oct 29
17:01:31 2015
@@ -37,6 +37,7 @@ import java.util.ArrayList;
import java.util.concurrent.ExecutionException;
import java.util.concurrent.Executor;
import java.util.concurrent.ExecutorService;
+import java.util.concurrent.Future;
import java.util.concurrent.RejectedExecutionException;
import java.util.concurrent.Semaphore;
import java.util.concurrent.TimeUnit;
@@ -1151,10 +1152,11 @@ public class Nio2Endpoint extends Abstra
private int fillReadBuffer(boolean block) throws IOException {
socketBufferHandler.configureReadBufferForWrite();
int nRead = 0;
+Future integer = null;
if (block) {
try {
-nRead =
getSocket().read(socketBufferHandler.getReadBuffer()).get(
-getNio2ReadTimeout(),
TimeUnit.MILLISECONDS).intValue();
+integer =
getSocket().read(socketBufferHandler.getReadBuffer());
+nRead = integer.get(getNio2ReadTimeout(),
TimeUnit.MILLISECONDS).intValue();
// Blocking read so need to release here since there will
// not be a callback to a completion handler.
readPending.release();
@@ -1167,8 +1169,10 @@ public class Nio2Endpoint extends Abstra
} catch (InterruptedException e) {
throw new IOException(e);
} catch (TimeoutException e) {
-SocketTimeoutException ex = new SocketTimeoutException();
-throw ex;
+if (integer != null) {
+integer.cancel(true);
+}
+throw new SocketTimeoutException();
}
} else {
Nio2Endpoint.startInline();
@@ -1226,11 +1230,12 @@ public class Nio2Endpoint extends Abstra
*/
@Override
protected void doWriteInternal(boolean block) throws IOException {
+Future integer = null;
try {
socketBufferHandler.configureWriteBufferForRead();
do {
-if
(getSocket().write(socketBufferHandler.getWriteBuffer()).get(
-getNio2WriteTimeout(),
TimeUnit.MILLISECONDS).intValue() < 0) {
+integer =
getSocket().write(socketBufferHandler.getWriteBuffer());
+if (integer.get(getNio2WriteTimeout(),
TimeUnit.MILLISECONDS).intValue() < 0) {
throw new
EOFException(sm.getString("iob.failedwrite"));
}
} while (socketBufferHandler.getWriteBuffer().hasRemaining());
@@ -1243,6 +1248,9 @@ public class Nio2Endpoint extends Abstra
} catch (InterruptedException e) {
throw new IOException(e);
} catch (TimeoutException e) {
+if (integer != null) {
+integer.cancel(true);
+}
throw new SocketTimeoutException();
}
}
@@ -1254,7 +1262,6 @@ public class Nio2Endpoint extends Abstra
throw getError();
}
-
// Before doing a blocking flush, make sure that any pending non
// blocking write has completed.
try {
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[GUMP@vmgump]: Project tomcat-tc8.0.x-test-apr (in module tomcat-8.0.x) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at gene...@gump.apache.org. Project tomcat-tc8.0.x-test-apr has an issue affecting its community integration. This issue affects 1 projects. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - tomcat-tc8.0.x-test-apr : Tomcat 8.x, a web server implementing the Java Servlet 3.1, ... Full details are available at: http://vmgump.apache.org/gump/public/tomcat-8.0.x/tomcat-tc8.0.x-test-apr/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Dependency on commons-daemon exists, no need to add for property commons-daemon.native.src.tgz. -DEBUG- Dependency on commons-daemon exists, no need to add for property tomcat-native.tar.gz. -INFO- Failed with reason build failed -INFO- Project Reports in: /srv/gump/public/workspace/tomcat-8.0.x/output/logs-APR -INFO- Project Reports in: /srv/gump/public/workspace/tomcat-8.0.x/output/test-tmp-APR/logs -WARNING- No directory [/srv/gump/public/workspace/tomcat-8.0.x/output/test-tmp-APR/logs] The following work was performed: http://vmgump.apache.org/gump/public/tomcat-8.0.x/tomcat-tc8.0.x-test-apr/gump_work/build_tomcat-8.0.x_tomcat-tc8.0.x-test-apr.html Work Name: build_tomcat-8.0.x_tomcat-tc8.0.x-test-apr (Type: Build) Work ended in a state of : Failed Elapsed: 38 mins 42 secs Command Line: /usr/lib/jvm/java-8-oracle/bin/java -Djava.awt.headless=true -Dbuild.sysclasspath=only org.apache.tools.ant.Main -Dgump.merge=/srv/gump/public/gump/work/merge.xml -Djunit.jar=/srv/gump/public/workspace/junit/target/junit-4.13-SNAPSHOT.jar -Dobjenesis.jar=/srv/gump/public/workspace/objenesis/main/target/objenesis-2.3-SNAPSHOT.jar -Dtest.reports=output/logs-APR -Dtomcat-native.tar.gz=/srv/gump/public/workspace/apache-commons/daemon/dist/bin/commons-daemon-20151029-native-src.tar.gz -Dexamples.sources.skip=true -Djdt.jar=/srv/gump/packages/eclipse/plugins/R-4.5-201506032000/ecj-4.5.jar -Dtest.apr.loc=/srv/gump/public/workspace/tomcat-native/dest-20151029/lib -Dcommons-daemon.jar=/srv/gump/public/workspace/apache-commons/daemon/dist/commons-daemon-20151029.jar -Dcommons-daemon.native.src.tgz=/srv/gump/public/workspace/apache-commons/daemon/dist/bin/commons-daemon-20151029-native-src.tar.gz -Dtest.temp=output/test-tmp-APR -Dtest.accesslog=true -Dexecute.test.nio=false -Dtest .openssl.path=/srv/gump/public/workspace/openssl-1.0.2/dest-20151029/bin/openssl -Dexecute.test.bio=false -Dexecute.test.apr=true -Dtest.excludePerformance=true -Dexecute.test.nio2=false -Deasymock.jar=/srv/gump/public/workspace/easymock/core/target/easymock-3.5-SNAPSHOT.jar -Dhamcrest.jar=/srv/gump/packages/hamcrest/hamcrest-core-1.3.jar -Dcglib.jar=/srv/gump/packages/cglib/cglib-nodep-2.2.jar test [Working Directory: /srv/gump/public/workspace/tomcat-8.0.x] CLASSPATH: /usr/lib/jvm/java-8-oracle/lib/tools.jar:/srv/gump/public/workspace/tomcat-8.0.x/output/build/webapps/examples/WEB-INF/classes:/srv/gump/public/workspace/tomcat-8.0.x/output/testclasses:/srv/gump/public/workspace/ant/dist/lib/ant.jar:/srv/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/srv/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/srv/gump/public/workspace/ant/dist/lib/ant-junit.jar:/srv/gump/public/workspace/ant/dist/lib/ant-junit4.jar:/srv/gump/public/workspace/ant/dist/lib/ant-swing.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-xalan2.jar:/srv/gump/public/workspace/xml-commons/java/build/resolver.jar:/srv/gump/public/workspace/tomcat-8.0.x/output/build/bin/bootstrap.jar:/srv/gump/public/workspace/tomcat-8.0.x/output/build/bin/tomcat-juli.jar:/srv/gump/public/workspace/tomcat-8.0.x/output/build/lib/annotations-api.jar:/srv/gump/public/workspace/tomcat-8.0.x/output/build/lib/servlet-api.ja r:/srv/gump/public/workspace/tomcat-8.0.x/output/build/lib/jsp-api.jar:/srv/gump/public/workspace/tomcat-8.0.x/output/build/lib/el-api.jar:/srv/gump/public/workspace/tomcat-8.0.x/output/build/lib/websocket-api.jar:/srv/gump/public/workspace/tomcat-8.0.x/output/build/lib/catalina.jar:/srv/gump/public/workspace/tomcat-8.0.x/output/build/lib/catalina-ant.jar:/srv/gump/public/workspace/tomcat-8.0.x/output/build/lib/catalina-storeconfig.jar:/srv/gump/public/workspace/tomcat-8.0.x/output/build/lib/tomcat-coyote.jar:/srv/gump/public/workspace/tomcat-8.0.x/output/build/lib/jasper.jar:/srv/gump/public/workspace/tomcat-8.0.x/output/build/lib/jasper-el.jar:/srv/gump/public/workspace/tomcat-8.0.x/output/build/lib/catalina-tribes.jar:/srv/gump/public/workspace/tomcat-8.0.x/output/build/lib/catalina-ha.jar:/srv/gump/public/workspace/tomcat-8.
Re: [VOTE] Switch 6.0.x from RTC to CTR
Am 28. Oktober 2015 23:42:08 MEZ, schrieb Mark Thomas : >All, > >Many years ago, we switched all release branches to RTC primarily to >address a community problem where we could not agree on the best way >forward for some parts of the code. > >RTC served us well. The disagreements ceased pretty much instantly. >However, RTC also slowed us down. > >The development of 7.0.x started as CTR with a possibility of switching >to RTC if necessary. It never was. We chose not to switch 7.0.x to RTC >because the community issues that made RTC necessary had been solved >and >RTC added unnecessary overhead and delay. 8.0.x and now 9.0.x >progressed >the same way. Today, only 6.0.x is RTC. > >I believe the use of RTC for 6.0.x is causing more harm than good. >There >are fixes I don't propose for backport to 6.0.x because of the extra >hassle RTC introduces. I suspect others take a similar approach judging >on the number of fixes that don't make it back to 6.0.x. > >I would therefore like to propose that we switch the 6.0.x release >branch from RTC to CTR and am therefore calling a VOTE to make this >change. > >[ ] Continue to use RTC for 6.0.x >[x] Switch 6.0.x to CTR Felix > >Thanks, > >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
[Bug 58565] Connection will be closed on slow file download with non blocking http protocol
https://bz.apache.org/bugzilla/show_bug.cgi?id=58565 --- Comment #4 from Dave --- so what do you recommend? our application is accessed by many of our customers via gsm modem. In some cases the speed is lower than 8kb/sec (gprs). Which timeout do i have to change? -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 58565] Connection will be closed on slow file download with non blocking http protocol
https://bz.apache.org/bugzilla/show_bug.cgi?id=58565 --- Comment #3 from Remy Maucherat --- After debugging, it looks like it's a combination of factors. What happens is that the network stack buffers things a lot without blocking. At some point it will block until everything gets flushed. Unfortunately, the flushing takes forever due to the client speed limit, and a legitimate write connection timeout occurs in Tomcat. Then the network stack will continue trickling bytes to the client until the connection is closed due to the error (which occurred a long time before). I would recommend to *not* increase the timeout for the connection [that would be a workaround], and I doubt this can be fixed effectively. So this could end up as a WONTFIX. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 58565] Connection will be closed on slow file download with non blocking http protocol
https://bz.apache.org/bugzilla/show_bug.cgi?id=58565 --- Comment #2 from Dave --- just as a note. i tried it with windows and linux and got the same results/problems. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 58565] Connection will be closed on slow file download with non blocking http protocol
https://bz.apache.org/bugzilla/show_bug.cgi?id=58565 Remy Maucherat changed: What|Removed |Added Severity|major |normal --- Comment #1 from Remy Maucherat --- Ok. Internally things are very different with NIOx: lots of buffering in the network stack and non blocking calls. It is possible this needs OS level configuration if available, and Tomcat itself doesn't do anything wrong. This will be investigated. Downgrading severity since in a way it's an anti DoS feature ... -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Session management
Roel, On 10/29/15 6:32 AM, Roel Storms wrote: > On Oct 28, 2015 21:01, "Christopher Schultz" > wrote: >> On 10/28/15 12:34 PM, Mark Thomas wrote: >>> On 28/10/2015 13:01, Roel Storms wrote: Hello, I was looking into session management on Tomcat 8.0.29 and found this comment: In apache.catalina.connector.Request method doGetSession(bool) line >> 2886: * // Attempt to reuse session id if one was submitted in a >> cookie* *// Do not reuse the session id if it is from a URL, to prevent possible* *// phishing attacks* // Use the SSL session ID if one is present. Why do you put more trust in a session id from a *cookie* then from a >> *URL*? Is there an (invalid) assumption that cookies are hard to manipulate? >>> >>> It is based on the fact that cookies require more effort from an >>> attacker to control. >> >> Just to clarify, the "attacker" in this case isn't the user of the web >> application. Yes, any client can send any header (cookie) they want. But >> an attacker trying to trick someone else into sending a cookie is going >> to have a harder time than trying to get them to click on a link that >> has an embedded session identifier. >> >>> Creating the session with the client provided ID is required for some >>> features to operate correctly. >>> Additionally I was hoping to find some* design documentation on the >> session mechanism*. Has anyone constructed any diagram or created some other >> form of documentation useful for figuring out how sessions are created and maintained? >>> >>> Not that I am aware of. The relevant source code isn't that long. >>> Reading it is probably the quickest way. >> >> Roel, what are you looking for specifically? The servlet spec lays-out >> when sessions are created/destroyed, etc. Do you think Tomcat needs >> documentation in addition to that? >> >> -chris >> >> > I understand the difference. But still, isn't it possible to not allow it > for cookies. You mention some web applications depend on it. In what way? There are some web applications that will break if you disable cookies on the browser. There are other applications that will break if cookies are not used on the server as the means of communicating the session id from the client to the server. This usually happens when programmers don't realize that every URL emitted back to the client needs to go through HttpServletResponse.encodeURL or HttpServletResponse.encodeRedirectURL. If you don't do these things, cookie-based session-tracking will be required. > I am still looking into it but a.t.m. I am drawing my own UML diagrams to > figure out how an incoming Http packet results in a Catalina.Request being > generated and where I can intercept in order for me to use a different > session management mechanism. Do you just want to change from cookie-based session-tracking to URL-based session-tracking? Because you can do that using web.xml and don't have to write any code. If you want to completely change the way Tomcat deals with sessions, you can write your own Manager implementation and wire it in using context.xml: http://tomcat.apache.org/tomcat-8.0-doc/config/manager.html Note that session-id management and session-storage are separated in Tomcat. I don't think you'll be able to meddle in the session-id management of Tomcat without significant work. On the other hand, if you want to put session data into memcached instead of in the JVM's heap, you can write your own Manager to do that and allow Tomcat to continue to manage the session-id management with the client. > Someone pointed out that I might be able to achieve what I want using > interceptors. Let's see what we can find. It's still not clear to me what you actually want to do, so I can't offer any advice. -chris - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Switch 6.0.x from RTC to CTR
Mark, On 10/28/15 6:42 PM, Mark Thomas wrote: > Many years ago, we switched all release branches to RTC primarily to > address a community problem where we could not agree on the best way > forward for some parts of the code. > > RTC served us well. The disagreements ceased pretty much instantly. > However, RTC also slowed us down. > > The development of 7.0.x started as CTR with a possibility of switching > to RTC if necessary. It never was. We chose not to switch 7.0.x to RTC > because the community issues that made RTC necessary had been solved and > RTC added unnecessary overhead and delay. 8.0.x and now 9.0.x progressed > the same way. Today, only 6.0.x is RTC. > > I believe the use of RTC for 6.0.x is causing more harm than good. There > are fixes I don't propose for backport to 6.0.x because of the extra > hassle RTC introduces. I suspect others take a similar approach judging > on the number of fixes that don't make it back to 6.0.x. > > I would therefore like to propose that we switch the 6.0.x release > branch from RTC to CTR and am therefore calling a VOTE to make this change. > > [ ] Continue to use RTC for 6.0.x > [X] Switch 6.0.x to CTR I must admit I kind of like RTC for "mature" products, but on the other hand Tomcat 7 is quite mature and it's pretty rare that something is broken. The release process is so painless with Tomcat 7 and later and rolling another release in case of a regression is easy. With Tomcat 6, I would be more careful than with later release because of these two facts: 1. Building Tomcat 6 is somewhat more tricky 2. Test-case coverage is dismal So, while I do vote in favor of CTR for Tomcat 6, I'd say that we should probably treat Tomcat 6 as if it were already in maintenance mode, and only back-port security or other functionality-breaking patches. -chris - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Switch 6.0.x from RTC to CTR
Am 29.10.2015 um 00:57 schrieb Konstantin Kolinko: 2015-10-29 1:42 GMT+03:00 Mark Thomas : All, Many years ago, we switched all release branches to RTC primarily to address a community problem where we could not agree on the best way forward for some parts of the code. RTC served us well. The disagreements ceased pretty much instantly. However, RTC also slowed us down. The development of 7.0.x started as CTR with a possibility of switching to RTC if necessary. It never was. We chose not to switch 7.0.x to RTC because the community issues that made RTC necessary had been solved and RTC added unnecessary overhead and delay. 8.0.x and now 9.0.x progressed the same way. Today, only 6.0.x is RTC. I believe the use of RTC for 6.0.x is causing more harm than good. There are fixes I don't propose for backport to 6.0.x because of the extra hassle RTC introduces. I suspect others take a similar approach judging on the number of fixes that don't make it back to 6.0.x. I would therefore like to propose that we switch the 6.0.x release branch from RTC to CTR and am therefore calling a VOTE to make this change. [ ] Continue to use RTC for 6.0.x [x] Switch 6.0.x to CTR 2. RTC seriously gets in a way, as review rate is slow. After waiting for several months it is easy to loose track of the original problem. Historically, I think Mark's work on introduction of automated tests in Tomcat 7 became a key of success of CTR model for Tomcat 7 and later. We do not have automated test in Tomcat 6 yet, but I no longer consider it a showstopper against CTR. I agreed also with these comments of Konstantin. I guess we should not push backports to TC 6 to hard and instead value stability over new features there. Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 58564] Simplify Boolean.parseBoolean(System.getProperty("xxx"), "false") to Boolean.getBoolean("xxx")
https://bz.apache.org/bugzilla/show_bug.cgi?id=58564
Konstantin Kolinko changed:
What|Removed |Added
Resolution|--- |WONTFIX
Status|NEW |RESOLVED
--- Comment #1 from Konstantin Kolinko ---
Boolean.parseBoolean(System.getProperty("xxx"), "false") explicitly shows that
the default is "false". Using Boolean.getBoolean() hides this fact. Unlike
similar methods elsewhere, there is no 2-arguments variant of this method to
provide an explicit default.
The default value can be different in different versions of Tomcat. It is
better to cleanly see what is the actual default value.
--
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Switch 6.0.x from RTC to CTR
On 10/28/2015 11:42 PM, Mark Thomas wrote: > [X] Switch 6.0.x to CTR Basically there are so few fixes in 6.0.x that the RTC blocks any move in 6.0.x Cheers Jean-Frederic - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 58565] New: Connection will be closed on slow file download with non blocking http protocol
https://bz.apache.org/bugzilla/show_bug.cgi?id=58565 Bug ID: 58565 Summary: Connection will be closed on slow file download with non blocking http protocol Product: Tomcat 8 Version: 8.0.28 Hardware: PC OS: All Status: NEW Severity: major Priority: P2 Component: Connectors Assignee: dev@tomcat.apache.org Reporter: david.pentz...@commscope.com Problem: Setup Tomcat (8.0.28) with default settings. Copy a file in a webapp e.g. webapps/root and download the file with limited speed to simulate a slow modem download. wget http://xxx.xxx.xxx.xxx:8080/xxx/7.zip --limit-rate=1k Connection is closed always after 6minutes and 24seconds e.g: Saving to: ‘7.zip’ 7.zip 0%[ ] 767.99K 1.00KB/s in 6m 24s 2015-10-28 17:27:39 (1024 B/s) - Connection closed at byte 786426. Retrying. if i change the protocol to an old blocking protocol: protocol="org.apache.coyote.http11.Http11Protocol" everything is fine and the download will complete with slow speed. If the change the speed (with protocol HTTP/1.1) the time after the connection is closed is different (e.g. for 7kb/sec it will always close after 3minutes and 21sec). If the speed is 8kb/sec or higher the download is stable with both protocols. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 58564] New: Simplify Boolean.parseBoolean(System.getProperty("xxx"), "false") to Boolean.getBoolean("xxx")
https://bz.apache.org/bugzilla/show_bug.cgi?id=58564
Bug ID: 58564
Summary: Simplify
Boolean.parseBoolean(System.getProperty("xxx"),
"false") to Boolean.getBoolean("xxx")
Product: Tomcat 8
Version: trunk
Hardware: All
OS: All
Status: NEW
Severity: enhancement
Priority: P2
Component: Catalina
Assignee: dev@tomcat.apache.org
Reporter: huxing.zh...@gmail.com
Hi folks,
in svn commit: r1710933
or github commit:
https://github.com/apache/tomcat/commit/55c52b0f0697d2e12d9ce842d0f7f0df20da1ff7
I think the following code snippet:
Boolean.parseBoolean(System.getProperty("org.apache.catalina.STRICT_SERVLET_COMPLIANCE",
"false"));
is equivalent to:
Boolean.getBoolean("org.apache.catalina.STRICT_SERVLET_COMPLIANCE");
which is simpler.
According to the documentation:
https://docs.oracle.com/javase/6/docs/api/java/lang/Boolean.html
static boolean getBoolean(String name):
Returns true if and only if the system property named by the argument exists
and is equal to the string "true".
How do you guys think?
--
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 58244] two way SSL loses client certificate after a few requests
https://bz.apache.org/bugzilla/show_bug.cgi?id=58244 --- Comment #4 from Petr Brouzda --- We have similar (maybe the same) problem. We run - Tomcat 8.0.24 with APR. - HTTPS APR connector with SSLVerifyClient="require". - on Debian 6 Client is a legacy application with no HTTPS support. So it uses "stunnel" (https://www.stunnel.org) for http-to-https proxy. 1) At the first request from this client ... server application sees client's certificate in javax.servlet.request.X509Certificate correctly. 2) Second and any subsequent requests within the same stunnel connection ... server application didn't see client's certificate, javax.servlet.request.X509Certificate is null. 3) After stunnel daemon is restarted, the first request is proceed correctly (with certificate info in javax.servlet.request.X509Certificate) and subsequent requests has javax.servlet.request.X509Certificate = null. The difference is that (based on stunnel's logfile) the first request creates a new SSL session, and subsequent requests reuses that session. Maybe there is a problem within APR that client certificate is not available when SSL session is reused. (Other clients than stunnel works without problem.) -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Switch 6.0.x from RTC to CTR
On 28/10/2015 23:27, Rémy Maucherat wrote: > 2015-10-28 23:42 GMT+01:00 Mark Thomas : > >> I would therefore like to propose that we switch the 6.0.x release >> branch from RTC to CTR and am therefore calling a VOTE to make this change. >> >> [ ] Continue to use RTC for 6.0.x >> [X] Switch 6.0.x to CTR >> > Comments: > - How close is 6.0 from getting only critical fixes and security issues ? In theory it is there now. In practise, people back-port additional fixes for bugs that are unlikely to rate as critical. > - On the upside for RTC for such a mature branch, it probably improves > stability. It makes regressions less likely mainly because the review process takes so long that any regressions will have emerged in 8.0.x/7.0.x. The review process itself doesn't seem (to me at least) to be that good at spotting them. > I suppose RTC could get it into the commit stream I see: trunk > -> 8 -> 7 -> and now 6. Yes, assuming the commit merges cleanly. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Session management
Chris and Mark, On Oct 28, 2015 21:01, "Christopher Schultz" wrote: > Mark, > > On 10/28/15 12:34 PM, Mark Thomas wrote: > > On 28/10/2015 13:01, Roel Storms wrote: > >> Hello, > >> > >> > >> I was looking into session management on Tomcat 8.0.29 and found this > >> comment: > >> > >> In apache.catalina.connector.Request method doGetSession(bool) line > 2886: > >> > >>* // Attempt to reuse session id if one was submitted in a > cookie* > >> *// Do not reuse the session id if it is from a URL, to prevent > >> possible* > >> *// phishing attacks* > >> // Use the SSL session ID if one is present. > >> > >> Why do you put more trust in a session id from a *cookie* then from a > *URL*? > >> Is there an (invalid) assumption that cookies are hard to manipulate? > > > > It is based on the fact that cookies require more effort from an > > attacker to control. > > Just to clarify, the "attacker" in this case isn't the user of the web > application. Yes, any client can send any header (cookie) they want. But > an attacker trying to trick someone else into sending a cookie is going > to have a harder time than trying to get them to click on a link that > has an embedded session identifier. > > > Creating the session with the client provided ID is required for some > > features to operate correctly. > > > >> Additionally I was hoping to find some* design documentation on the > session > >> mechanism*. Has anyone constructed any diagram or created some other > form > >> of documentation useful for figuring out how sessions are created and > >> maintained? > > > > Not that I am aware of. The relevant source code isn't that long. > > Reading it is probably the quickest way. > > Roel, what are you looking for specifically? The servlet spec lays-out > when sessions are created/destroyed, etc. Do you think Tomcat needs > documentation in addition to that? > > -chris > > > I understand the difference. But still, isn't it possible to not allow it > for cookies. You mention some web applications depend on it. In what way? > > I am still looking into it but a.t.m. I am drawing my own UML diagrams to > figure out how an incoming Http packet results in a Catalina.Request being > generated and where I can intercept in order for me to use a different > session management mechanism. > > Someone pointed out that I might be able to achieve what I want using > interceptors. Let's see what we can find. > > > Rgds, > > Roel >
svn commit: r1711192 - in /tomcat/tc7.0.x/trunk: modules/jdbc-pool/doc/jdbc-pool.xml modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/interceptor/SlowQueryReport.java webapps/docs/changelog
Author: kfujino
Date: Thu Oct 29 08:36:22 2015
New Revision: 1711192
URL: http://svn.apache.org/viewvc?rev=1711192&view=rev
Log:
When creating a QueryStats object, ensure that maxQueries is checked.
If maxQueries is a value less than or equal to 0, QueryStats are never created.
Modified:
tomcat/tc7.0.x/trunk/modules/jdbc-pool/doc/jdbc-pool.xml
tomcat/tc7.0.x/trunk/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/interceptor/SlowQueryReport.java
tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml
Modified: tomcat/tc7.0.x/trunk/modules/jdbc-pool/doc/jdbc-pool.xml
URL:
http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/modules/jdbc-pool/doc/jdbc-pool.xml?rev=1711192&r1=1711191&r2=1711192&view=diff
==
--- tomcat/tc7.0.x/trunk/modules/jdbc-pool/doc/jdbc-pool.xml (original)
+++ tomcat/tc7.0.x/trunk/modules/jdbc-pool/doc/jdbc-pool.xml Thu Oct 29
08:36:22 2015
@@ -668,6 +668,7 @@
(int as String) The maximum number of queries to keep track of in
order to preserve memory space.
+ A value less than or equal to 0 will disable this feature.
The default value is 1000.
Modified:
tomcat/tc7.0.x/trunk/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/interceptor/SlowQueryReport.java
URL:
http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/interceptor/SlowQueryReport.java?rev=1711192&r1=1711191&r2=1711192&view=diff
==
---
tomcat/tc7.0.x/trunk/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/interceptor/SlowQueryReport.java
(original)
+++
tomcat/tc7.0.x/trunk/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/interceptor/SlowQueryReport.java
Thu Oct 29 08:36:22 2015
@@ -139,14 +139,18 @@ public class SlowQueryReport extends Abs
@Override
public void prepareStatement(String sql, long time) {
-QueryStats qs = getQueryStats(sql);
-if (qs != null) qs.prepare(time);
+if (this.maxQueries > 0 ) {
+QueryStats qs = getQueryStats(sql);
+if (qs != null) qs.prepare(time);
+}
}
@Override
public void prepareCall(String sql, long time) {
-QueryStats qs = getQueryStats(sql);
-if (qs != null) qs.prepare(time);
+if (this.maxQueries > 0 ) {
+QueryStats qs = getQueryStats(sql);
+if (qs != null) qs.prepare(time);
+}
}
/**
Modified: tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml
URL:
http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml?rev=1711192&r1=1711191&r2=1711192&view=diff
==
--- tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml (original)
+++ tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml Thu Oct 29 08:36:22 2015
@@ -145,6 +145,12 @@
58489: Correct QueryStatsComparator to hold up the
general contract for Comparator. (fschumacher)
+
+When creating a QueryStats object, ensure that
+maxQueries is checked. If maxQueries is a
+value less than or equal to 0, QueryStats are never
+created. (kfujino)
+
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Adding request/session valve to Tomcat
Hello Chris,
Thanks for pointing me to my mistake. I did not check
InheritableThreadLocal functionality enough. In my usecase not an issue I
think.
With 'default' I do not mean 'enabled by default'. I mean that it is
available in the classpath like the valves mentioned in
https://tomcat.apache.org/tomcat-7.0-doc/config/valve.html.
I only access the data in this valve from the loginModule and so I think
that FORWARD and INCLUDE are no issue there...
To prevent those errors it might be better to add a callback like in
WebLogic or WebSphere to be able to access the request from within the jass
loginModule. I checked JASPIC don't read much enthusiasm about it. Good
thing would be that it is standardised but how many people change container
and so need portability?
MAG,
Milo
2015-10-28 21:08 GMT+01:00 Christopher Schultz :
> Milo,
>
> On 10/28/15 4:03 PM, Milo van der Zee wrote:
> > That is what I did but I expect a lot of people to have this problem.
> > Seeing a lot of default valves included I would like to also have this
> > valve as default.
>
> -1
>
> Most applications don't need this. It's another layer of code that
> doesn't need to execute for every request. It's another potential way
> for request objects to be leaked. It's a potential security
> vulnerability / encapsulation violation.
>
> You have easily implemented this Valve and can feel free to distribute
> it, but Tomcat is not likely to include this Valve and, if so, I would
> strenuously object to it being enabled by default.
>
> > public class RequestValve extends ValveBase {
> > /**
> > * Session for current thread.
> > */
> > static InheritableThreadLocal requestHolder = new
> > InheritableThreadLocal<>();
> >
> > @Override
> > public void invoke(Request request, Response response) throws
> > IOException, ServletException {
> > requestHolder.set(request);
> > try {
> > getNext().invoke(request, response);
> > } finally {
> > requestHolder.remove();
> > }
> > }
> >
> > public static Request getRequest() {
> > return requestHolder.get();
> > }
> > }
>
> Have you checked to make sure this Valve works as expected when the
> request is FORWARDed or INCLUDed?
>
> -chris
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>
svn commit: r1711191 - in /tomcat/tc8.0.x/trunk: modules/jdbc-pool/doc/jdbc-pool.xml modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/interceptor/SlowQueryReport.java webapps/docs/changelog
Author: kfujino
Date: Thu Oct 29 08:33:15 2015
New Revision: 1711191
URL: http://svn.apache.org/viewvc?rev=1711191&view=rev
Log:
When creating a QueryStats object, ensure that maxQueries is checked.
If maxQueries is a value less than or equal to 0, QueryStats are never created.
Modified:
tomcat/tc8.0.x/trunk/modules/jdbc-pool/doc/jdbc-pool.xml
tomcat/tc8.0.x/trunk/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/interceptor/SlowQueryReport.java
tomcat/tc8.0.x/trunk/webapps/docs/changelog.xml
Modified: tomcat/tc8.0.x/trunk/modules/jdbc-pool/doc/jdbc-pool.xml
URL:
http://svn.apache.org/viewvc/tomcat/tc8.0.x/trunk/modules/jdbc-pool/doc/jdbc-pool.xml?rev=1711191&r1=1711190&r2=1711191&view=diff
==
--- tomcat/tc8.0.x/trunk/modules/jdbc-pool/doc/jdbc-pool.xml (original)
+++ tomcat/tc8.0.x/trunk/modules/jdbc-pool/doc/jdbc-pool.xml Thu Oct 29
08:33:15 2015
@@ -694,6 +694,7 @@
(int as String) The maximum number of queries to keep track of in
order to preserve memory space.
+ A value less than or equal to 0 will disable this feature.
The default value is 1000.
Modified:
tomcat/tc8.0.x/trunk/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/interceptor/SlowQueryReport.java
URL:
http://svn.apache.org/viewvc/tomcat/tc8.0.x/trunk/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/interceptor/SlowQueryReport.java?rev=1711191&r1=1711190&r2=1711191&view=diff
==
---
tomcat/tc8.0.x/trunk/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/interceptor/SlowQueryReport.java
(original)
+++
tomcat/tc8.0.x/trunk/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/interceptor/SlowQueryReport.java
Thu Oct 29 08:33:15 2015
@@ -148,14 +148,18 @@ public class SlowQueryReport extends Abs
@Override
public void prepareStatement(String sql, long time) {
-QueryStats qs = getQueryStats(sql);
-if (qs != null) qs.prepare(time);
+if (this.maxQueries > 0 ) {
+QueryStats qs = getQueryStats(sql);
+if (qs != null) qs.prepare(time);
+}
}
@Override
public void prepareCall(String sql, long time) {
-QueryStats qs = getQueryStats(sql);
-if (qs != null) qs.prepare(time);
+if (this.maxQueries > 0 ) {
+QueryStats qs = getQueryStats(sql);
+if (qs != null) qs.prepare(time);
+}
}
/**
Modified: tomcat/tc8.0.x/trunk/webapps/docs/changelog.xml
URL:
http://svn.apache.org/viewvc/tomcat/tc8.0.x/trunk/webapps/docs/changelog.xml?rev=1711191&r1=1711190&r2=1711191&view=diff
==
--- tomcat/tc8.0.x/trunk/webapps/docs/changelog.xml (original)
+++ tomcat/tc8.0.x/trunk/webapps/docs/changelog.xml Thu Oct 29 08:33:15 2015
@@ -152,6 +152,12 @@
58489: Correct QueryStatsComparator to hold up the
general contract for Comparator. (fschumacher)
+
+When creating a QueryStats object, ensure that
+maxQueries is checked. If maxQueries is a
+value less than or equal to 0, QueryStats are never
+created. (kfujino)
+
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1711190 - in /tomcat/trunk/modules/jdbc-pool: doc/jdbc-pool.xml src/main/java/org/apache/tomcat/jdbc/pool/interceptor/SlowQueryReport.java
Author: kfujino
Date: Thu Oct 29 08:28:57 2015
New Revision: 1711190
URL: http://svn.apache.org/viewvc?rev=1711190&view=rev
Log:
When creating a QueryStats object, ensure that maxQueries is checked.
If maxQueries is a value less than or equal to 0, QueryStats are never created.
Modified:
tomcat/trunk/modules/jdbc-pool/doc/jdbc-pool.xml
tomcat/trunk/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/interceptor/SlowQueryReport.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=1711190&r1=1711189&r2=1711190&view=diff
==
--- tomcat/trunk/modules/jdbc-pool/doc/jdbc-pool.xml (original)
+++ tomcat/trunk/modules/jdbc-pool/doc/jdbc-pool.xml Thu Oct 29 08:28:57 2015
@@ -694,6 +694,7 @@
(int as String) The maximum number of queries to keep track of in
order to preserve memory space.
+ A value less than or equal to 0 will disable this feature.
The default value is 1000.
Modified:
tomcat/trunk/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/interceptor/SlowQueryReport.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/interceptor/SlowQueryReport.java?rev=1711190&r1=1711189&r2=1711190&view=diff
==
---
tomcat/trunk/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/interceptor/SlowQueryReport.java
(original)
+++
tomcat/trunk/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/interceptor/SlowQueryReport.java
Thu Oct 29 08:28:57 2015
@@ -148,14 +148,18 @@ public class SlowQueryReport extends Abs
@Override
public void prepareStatement(String sql, long time) {
-QueryStats qs = getQueryStats(sql);
-if (qs != null) qs.prepare(time);
+if (this.maxQueries > 0 ) {
+QueryStats qs = getQueryStats(sql);
+if (qs != null) qs.prepare(time);
+}
}
@Override
public void prepareCall(String sql, long time) {
-QueryStats qs = getQueryStats(sql);
-if (qs != null) qs.prepare(time);
+if (this.maxQueries > 0 ) {
+QueryStats qs = getQueryStats(sql);
+if (qs != null) qs.prepare(time);
+}
}
/**
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[GUMP@vmgump]: Project tomcat-trunk-test-apr (in module tomcat-trunk) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at gene...@gump.apache.org. Project tomcat-trunk-test-apr has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 4 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - tomcat-trunk-test-apr : Tomcat 9.x, a web server implementing the Java Servlet 4.0, ... Full details are available at: http://vmgump.apache.org/gump/public/tomcat-trunk/tomcat-trunk-test-apr/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Dependency on commons-daemon exists, no need to add for property commons-daemon.native.src.tgz. -DEBUG- Dependency on commons-daemon exists, no need to add for property tomcat-native.tar.gz. -INFO- Failed with reason build failed -INFO- Project Reports in: /srv/gump/public/workspace/tomcat-trunk/output/logs-APR -INFO- Project Reports in: /srv/gump/public/workspace/tomcat-trunk/output/test-tmp-APR/logs -WARNING- No directory [/srv/gump/public/workspace/tomcat-trunk/output/test-tmp-APR/logs] The following work was performed: http://vmgump.apache.org/gump/public/tomcat-trunk/tomcat-trunk-test-apr/gump_work/build_tomcat-trunk_tomcat-trunk-test-apr.html Work Name: build_tomcat-trunk_tomcat-trunk-test-apr (Type: Build) Work ended in a state of : Failed Elapsed: 46 mins 20 secs Command Line: /usr/lib/jvm/java-8-oracle/bin/java -Djava.awt.headless=true -Dbuild.sysclasspath=only org.apache.tools.ant.Main -Dgump.merge=/srv/gump/public/gump/work/merge.xml -Djunit.jar=/srv/gump/public/workspace/junit/target/junit-4.13-SNAPSHOT.jar -Dobjenesis.jar=/srv/gump/public/workspace/objenesis/main/target/objenesis-2.3-SNAPSHOT.jar -Dtest.reports=output/logs-APR -Dtomcat-native.tar.gz=/srv/gump/public/workspace/apache-commons/daemon/dist/bin/commons-daemon-20151029-native-src.tar.gz -Dexamples.sources.skip=true -Djdt.jar=/srv/gump/packages/eclipse/plugins/R-4.5-201506032000/ecj-4.5.jar -Dtest.apr.loc=/srv/gump/public/workspace/tomcat-native-trunk/dest-20151029/lib -Dtest.relaxTiming=true -Dcommons-daemon.jar=/srv/gump/public/workspace/apache-commons/daemon/dist/commons-daemon-20151029.jar -Dcommons-daemon.native.src.tgz=/srv/gump/public/workspace/apache-commons/daemon/dist/bin/commons-daemon-20151029-native-src.tar.gz -Dtest.temp=output/test-tmp-APR -Dtest.accesslog=true - Dexecute.test.nio=false -Dtest.openssl.path=/srv/gump/public/workspace/openssl-master/dest-20151029/bin/openssl -Dexecute.test.apr=true -Dtest.excludePerformance=true -Dexecute.test.nio2=false -Deasymock.jar=/srv/gump/public/workspace/easymock/core/target/easymock-3.5-SNAPSHOT.jar -Dhamcrest.jar=/srv/gump/packages/hamcrest/hamcrest-core-1.3.jar -Dcglib.jar=/srv/gump/packages/cglib/cglib-nodep-2.2.jar test [Working Directory: /srv/gump/public/workspace/tomcat-trunk] CLASSPATH: /usr/lib/jvm/java-8-oracle/lib/tools.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/webapps/examples/WEB-INF/classes:/srv/gump/public/workspace/tomcat-trunk/output/testclasses:/srv/gump/public/workspace/ant/dist/lib/ant.jar:/srv/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/srv/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/srv/gump/public/workspace/ant/dist/lib/ant-junit.jar:/srv/gump/public/workspace/ant/dist/lib/ant-junit4.jar:/srv/gump/public/workspace/ant/dist/lib/ant-swing.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-xalan2.jar:/srv/gump/public/workspace/xml-commons/java/build/resolver.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/bin/bootstrap.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/bin/tomcat-juli.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/annotations-api.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/servlet-api.ja r:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/jsp-api.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/el-api.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/websocket-api.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/jaspic-api.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/catalina.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/catalina-ant.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/catalina-storeconfig.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/tomcat-coyote.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/jasper.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/jasper-el.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/catalina-tribes.jar:/srv/g
