Re: Question about taglibs. Issue 37466
On Feb 17, 2015, at 8:23 AM, Jeremy Boynes jboy...@apache.org wrote: On Feb 17, 2015, at 4:34 AM, Konstantin Kolinko knst.koli...@gmail.com wrote: 2015-02-14 20:04 GMT+03:00 Stephan van Loendersloot (LIST) step...@republika.nl: Hi everyone, I have a question about this issue: https://bz.apache.org/bugzilla/show_bug.cgi?id=37466 I tried to switch to the latest Tomcat TagLibs implementation, but due to this fixed bug, it seems that posted form parameters aren't visible anymore in relative pages imported by c:import tags. The JSTl specicication 1.2, Section 7.2 (page 57) states that relative URLs should be processed in the exact same way as the include action of the JSP specification (jsp:include) when used in the same application context. The older, Jakarta TagLibs don't have this problem, but the Tomcat TagLibs do... Can anyone tell me if the fix breaks the specification guidelines, or did I misread the whole thing? BZ 37466 fix (r495005) was committed 8 years ago. You need to provide an example that reproduces your issue. Wrapping a request with overwritten getMethod() should not break parsing of POST parameters. The parameters parsing is done by tomcat internals and operates on the original request, not on the wrapper. I think there may be an issue here but would like an example to confirm. This change was introduced between 1.1 and 1.2 and after GlassFish forked away. The original thread that led to BZ 37466 related to HEAD requests where the original HttpServletRequest was being passed to a RequestDispatcher. What I took from the thread is that this would result an empty response from the imported resource which the application was not expecting - it tried to parse empty content and failed. The r495005 patch attempts to fix this by forcing the method to GET, mirroring the semantic of an external absolute URL where the JSTL spec mandates a GET request is made when using HTTP. I’m not convinced this change was correct. For relative URLs it specifies the “whole environment is available … as well as request parameters” and by forcing the method to GET we are indicating that there is no request body to parse and so parameters in the original POST body should be skipped. As Konstantin said, Tomcat does not take account of wrappers so will still extract parameters from the request body but that may not be true for other containers or if the application code is parsing the request content. Perhaps the issue here is actually with Tomcat’s implementation of HttpServlet and/or DefaultServlet where it appears doHead() never returns content even for dispatched includes. If these only suppressed content for the original response but did return content for included responses then BZ 37466 would not be an issue. This would also seem to be necessary to return the same headers for HEAD as GET e.g. ensuring that the Content-Length returned included bytes from the included resource. Stephan, please can you submit an example showing what’s failing for you and include info on which container you are using and what version of taglibs you are upgrading from. In the original issue, a JSP page was using c:import to read a XML resource for parsing: c:import url=/org/apache/taglibs/standard/tag/el/core/Test37466.xml varReader=xmlSource” This is dispatched and handled by DefaultServlet: service() (from HttpServlet) uses getMethod() to determine that doHead() should be called doHead() calls serveResource() with content = false if content is false, serveResource() does not write any data to the response the value captured by the HttpResponseWrapper will be empty If instead, a JSP is used to serve the included resource its _jspService method does not check the HTTP method and always emits content. This can be verified with a simple JSP that does a jsp:include of a .txt or .jsp resource where the Content-Length header is different depending on whether a GET or HEAD request is made. Similarly, HttpServlet’s doHead() method is implemented by wrapping the response in a NoBodyResponse and then calling doGet(). The patch for 37466 attempts to fix this by overriding getMethod() to always return GET. This avoids the issue with DefaultServlet but breaks other servlets that actually use the method to dispatch e.g. anything that expects to handle a POST request in doPost(). I think instead the fix should be in Tomcat’s HttpServlet and DefaultServlet which should not suppress the output if they being called as an include. I’ll open an issue against Tomcat and propose a patch for this. — Jeremy signature.asc Description: Message signed with OpenPGP using GPGMail
[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. 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 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: 28 mins 46 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.2-SNAPSHOT.jar -Dtest.reports=output/logs-NIO2 -Dtomcat-native.tar.gz=/srv/gump/public/workspace/apache-commons/daemon/dist/bin/commons-daemon-20150218-native-src.tar.gz -Dexamples.sources.skip=true -Djdt.jar=/srv/gump/packages/eclipse/plugins/R-4.4-201406061215/ecj-4.4.jar -Dcommons-daemon.jar=/srv/gump/public/workspace/apache-commons/daemon/dist/commons-daemon-20150218.jar -Dcommons-daemon.native.src.tgz=/srv/gump/public/workspace/apache-commons/daemon/dist/bin/commons-daemon-20150218-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-20150218/bin /openssl -Dexecute.test.apr=false -Dexecute.test.bio=false -Dexecute.test.nio2=true -Deasymock.jar=/srv/gump/public/workspace/easymock/easymock/target/easymock-3.4-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/public/workspace/tomcat-8.0.x/output/build/lib/tomcat-jni.jar:/srv/gump/public/workspace/tomcat-8.0.x/output/bu ild/lib/tomcat-spdy.jar:/srv/gump/public
Re: svn commit: r1660498 - /tomcat/trunk/java/org/apache/tomcat/util/net/Nio2Endpoint.java
2015-02-17 22:52 GMT+01:00 Mark Thomas ma...@apache.org: On 17/02/2015 21:02, ma...@apache.org wrote: Author: markt Date: Tue Feb 17 21:02:09 2015 New Revision: 1660498 URL: http://svn.apache.org/r1660498 Log: Possible fix for occasional NIO2 CI failures. Without the sync it is possible for a write registration to get lost. I still see the error but less frequently. So I think this patch is a step in the right direction. The logs still indicate that a write registration is being lost somewhere so my plan is to continue the code review. I'm a bit puzzled as to why blocking is related to that. Anyway, last time this failure occurred with the same symptom, this was caused by SecureNio2Channel: r1586789. Since this wasn't changed during the refactoring, I don't think it needs to be suspected this time though. Following the NPE fix I made, there are signs of double closing of the socket. I doubt this can be avoided simply with adding a null check. 17-Feb-2015 22:00:20.936 WARNING [https-nio2-127.0.0.1-auto-2-Acceptor-0] org.apache.tomcat.util.net.AbstractEndpoint.countDownConnection Incorrect connection count, multiple socket.close called on the same socket. Rémy
Re: svn commit: r1660498 - /tomcat/trunk/java/org/apache/tomcat/util/net/Nio2Endpoint.java
On 18/02/2015 09:19, Rémy Maucherat wrote: 2015-02-17 22:52 GMT+01:00 Mark Thomas ma...@apache.org: On 17/02/2015 21:02, ma...@apache.org wrote: Author: markt Date: Tue Feb 17 21:02:09 2015 New Revision: 1660498 URL: http://svn.apache.org/r1660498 Log: Possible fix for occasional NIO2 CI failures. Without the sync it is possible for a write registration to get lost. I still see the error but less frequently. So I think this patch is a step in the right direction. The logs still indicate that a write registration is being lost somewhere so my plan is to continue the code review. I'm a bit puzzled as to why blocking is related to that. I was too. I'm beginning to think what looked like less frequent occurrence of the error was just random effects. I'm leaning towards reverting this patch. Anyway, last time this failure occurred with the same symptom, this was caused by SecureNio2Channel: r1586789. Since this wasn't changed during the refactoring, I don't think it needs to be suspected this time though. Following the NPE fix I made, there are signs of double closing of the socket. I doubt this can be avoided simply with adding a null check. 17-Feb-2015 22:00:20.936 WARNING [https-nio2-127.0.0.1-auto-2-Acceptor-0] org.apache.tomcat.util.net.AbstractEndpoint.countDownConnection Incorrect connection count, multiple socket.close called on the same socket. That might be a different issue. I'm not sure. I'm fairly confident that the problem we are seeing with TestWebSocketFrameClientSSL is related to a write registration not happening / getting lost. The symptom is that the server just stops writing, the client times out after 60s and the test fails. I found a few places where this might be going wrong but - much like the commit above - I'm not convinced that the affected code path is used at all - let alone used in this test. I have a few other ideas about where it might be going wrong that I want to look at today. If those don't pan out it will be back to adding debug log statements. If folks want to follow along then I'll be using this branch in my fork of the Tomcat trunk git mirror: https://github.com/markt-asf/tomcat/tree/linux-debug At the moment that branch is an exact copy of trunk. I am just running the unit tests in a loop waiting for the first failure. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1660582 - in /tomcat/trunk/java/org/apache: coyote/http11/upgrade/UpgradeServletInputStream.java coyote/http11/upgrade/UpgradeServletOutputStream.java tomcat/util/net/Nio2Endpoint.jav
2015-02-18 10:45 GMT+01:00 Mark Thomas ma...@apache.org:
On 18/02/2015 09:25, r...@apache.org wrote:
Author: remm
Date: Wed Feb 18 09:25:30 2015
New Revision: 1660582
URL: http://svn.apache.org/r1660582
Log:
- Add debugging of my own (sorry), on socket close.
- Try dropping the direct socket close from the upgraded streams (the
sockets seem to still be closed and the ws tests pass with NIO1+2).
That should be fine. The socket will get closed in
UpgradeProcessor.upgradeDispatch()
I noticed in the test runs that the close debug was still there, so it
looked relatively fine.
Actually following the discussions on the EG, I don't think the close
required logic is fully right, it would seem it should wait for both input
AND output to be closed, but this needs to be validated.
I agree the close logic is wrong. I wanted to fix the existing issues
before I started on this. Looking at the code, it shouldn't be too hard
to fix.
The stream close could cause calling shutdownInput and shutdownOutput.
Switching to:
if (upgradeServletInputStream.isCloseRequired()
upgradeServletOutputStream.isCloseRequired()) {
return SocketState.CLOSED;
}
in UpgradeProcessor doesn't work (the socket close occurs during shutdown
during the tests).
Rémy
Re: svn commit: r1660498 - /tomcat/trunk/java/org/apache/tomcat/util/net/Nio2Endpoint.java
2015-02-18 10:39 GMT+01:00 Mark Thomas ma...@apache.org: I'm fairly confident that the problem we are seeing with TestWebSocketFrameClientSSL is related to a write registration not happening / getting lost. The symptom is that the server just stops writing, the client times out after 60s and the test fails. There's one failure on the last run, but it's on the non SSL variant of the test, and it doesn't timeout. Testcase: testConnectToServerEndpoint took 23.317 sec FAILED expected:10 but was:81754 junit.framework.AssertionFailedError: expected:10 but was:81754 at org.apache.tomcat.websocket.TestWebSocketFrameClient.testConnectToServerEndpoint(TestWebSocketFrameClient.java:76) Rémy
Re: Question about taglibs. Issue 37466
Hi Konstantin, Jeremy, Yes I can provide a simple example shortly... Apologies for breaking the first rule of questioning: provide all details about operating system, container, libraries, etc. Would it be best if I continue this discussion here or at Jira? On 17-02-15 17:23, Jeremy Boynes wrote: On Feb 17, 2015, at 4:34 AM, Konstantin Kolinko knst.koli...@gmail.com wrote: 2015-02-14 20:04 GMT+03:00 Stephan van Loendersloot (LIST) step...@republika.nl: Hi everyone, I have a question about this issue: https://bz.apache.org/bugzilla/show_bug.cgi?id=37466 I tried to switch to the latest Tomcat TagLibs implementation, but due to this fixed bug, it seems that posted form parameters aren't visible anymore in relative pages imported by c:import tags. The JSTl specicication 1.2, Section 7.2 (page 57) states that relative URLs should be processed in the exact same way as the include action of the JSP specification (jsp:include) when used in the same application context. The older, Jakarta TagLibs don't have this problem, but the Tomcat TagLibs do... Can anyone tell me if the fix breaks the specification guidelines, or did I misread the whole thing? BZ 37466 fix (r495005) was committed 8 years ago. You need to provide an example that reproduces your issue. Wrapping a request with overwritten getMethod() should not break parsing of POST parameters. The parameters parsing is done by tomcat internals and operates on the original request, not on the wrapper. I think there may be an issue here but would like an example to confirm. This change was introduced between 1.1 and 1.2 and after GlassFish forked away. The original thread that led to BZ 37466 related to HEAD requests where the original HttpServletRequest was being passed to a RequestDispatcher. What I took from the thread is that this would result an empty response from the imported resource which the application was not expecting - it tried to parse empty content and failed. The r495005 patch attempts to fix this by forcing the method to GET, mirroring the semantic of an external absolute URL where the JSTL spec mandates a GET request is made when using HTTP. I’m not convinced this change was correct. For relative URLs it specifies the “whole environment is available … as well as request parameters” and by forcing the method to GET we are indicating that there is no request body to parse and so parameters in the original POST body should be skipped. As Konstantin said, Tomcat does not take account of wrappers so will still extract parameters from the request body but that may not be true for other containers or if the application code is parsing the request content. Perhaps the issue here is actually with Tomcat’s implementation of HttpServlet and/or DefaultServlet where it appears doHead() never returns content even for dispatched includes. If these only suppressed content for the original response but did return content for included responses then BZ 37466 would not be an issue. This would also seem to be necessary to return the same headers for HEAD as GET e.g. ensuring that the Content-Length returned included bytes from the included resource. Stephan, please can you submit an example showing what’s failing for you and include info on which container you are using and what version of taglibs you are upgrading from. Thanks Jeremy - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1660498 - /tomcat/trunk/java/org/apache/tomcat/util/net/Nio2Endpoint.java
On 18/02/2015 09:47, Rémy Maucherat wrote: 2015-02-18 10:39 GMT+01:00 Mark Thomas ma...@apache.org: I'm fairly confident that the problem we are seeing with TestWebSocketFrameClientSSL is related to a write registration not happening / getting lost. The symptom is that the server just stops writing, the client times out after 60s and the test fails. There's one failure on the last run, but it's on the non SSL variant of the test, and it doesn't timeout. Testcase: testConnectToServerEndpoint took 23.317 sec FAILED expected:10 but was:81754 junit.framework.AssertionFailedError: expected:10 but was:81754 at org.apache.tomcat.websocket.TestWebSocketFrameClient.testConnectToServerEndpoint(TestWebSocketFrameClient.java:76) Looks like we have multiple issues to track down then. Right now I'm having difficulty getting reproducing the problem that results in a timeout. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1660582 - in /tomcat/trunk/java/org/apache: coyote/http11/upgrade/UpgradeServletInputStream.java coyote/http11/upgrade/UpgradeServletOutputStream.java tomcat/util/net/Nio2Endpoint.java
Author: remm
Date: Wed Feb 18 09:25:30 2015
New Revision: 1660582
URL: http://svn.apache.org/r1660582
Log:
- Add debugging of my own (sorry), on socket close.
- Try dropping the direct socket close from the upgraded streams (the sockets
seem to still be closed and the ws tests pass with NIO1+2). Actually following
the discussions on the EG, I don't think the close required logic is fully
right, it would seem it should wait for both input AND output to be closed, but
this needs to be validated.
Modified:
tomcat/trunk/java/org/apache/coyote/http11/upgrade/UpgradeServletInputStream.java
tomcat/trunk/java/org/apache/coyote/http11/upgrade/UpgradeServletOutputStream.java
tomcat/trunk/java/org/apache/tomcat/util/net/Nio2Endpoint.java
Modified:
tomcat/trunk/java/org/apache/coyote/http11/upgrade/UpgradeServletInputStream.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/coyote/http11/upgrade/UpgradeServletInputStream.java?rev=1660582r1=1660581r2=1660582view=diff
==
---
tomcat/trunk/java/org/apache/coyote/http11/upgrade/UpgradeServletInputStream.java
(original)
+++
tomcat/trunk/java/org/apache/coyote/http11/upgrade/UpgradeServletInputStream.java
Wed Feb 18 09:25:30 2015
@@ -142,7 +142,6 @@ public class UpgradeServletInputStream e
@Override
public void close() throws IOException {
closeRequired = true;
-socketWrapper.close();
}
Modified:
tomcat/trunk/java/org/apache/coyote/http11/upgrade/UpgradeServletOutputStream.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/coyote/http11/upgrade/UpgradeServletOutputStream.java?rev=1660582r1=1660581r2=1660582view=diff
==
---
tomcat/trunk/java/org/apache/coyote/http11/upgrade/UpgradeServletOutputStream.java
(original)
+++
tomcat/trunk/java/org/apache/coyote/http11/upgrade/UpgradeServletOutputStream.java
Wed Feb 18 09:25:30 2015
@@ -172,7 +172,6 @@ public class UpgradeServletOutputStream
@Override
public void close() throws IOException {
closeRequired = true;
-socketWrapper.close();
}
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=1660582r1=1660581r2=1660582view=diff
==
--- tomcat/trunk/java/org/apache/tomcat/util/net/Nio2Endpoint.java (original)
+++ tomcat/trunk/java/org/apache/tomcat/util/net/Nio2Endpoint.java Wed Feb 18
09:25:30 2015
@@ -589,6 +589,10 @@ public class Nio2Endpoint extends Abstra
}
public void closeSocket(SocketWrapperBaseNio2Channel socket) {
+if (log.isDebugEnabled()) {
+log.debug(Calling [ + this + ].closeSocket([ + socket + ],[
+ socket.getSocket() + ]),
+new Exception());
+}
if (socket == null) {
return;
}
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1660582 - in /tomcat/trunk/java/org/apache: coyote/http11/upgrade/UpgradeServletInputStream.java coyote/http11/upgrade/UpgradeServletOutputStream.java tomcat/util/net/Nio2Endpoint.jav
On 18/02/2015 09:25, r...@apache.org wrote: Author: remm Date: Wed Feb 18 09:25:30 2015 New Revision: 1660582 URL: http://svn.apache.org/r1660582 Log: - Add debugging of my own (sorry), on socket close. - Try dropping the direct socket close from the upgraded streams (the sockets seem to still be closed and the ws tests pass with NIO1+2). That should be fine. The socket will get closed in UpgradeProcessor.upgradeDispatch() Actually following the discussions on the EG, I don't think the close required logic is fully right, it would seem it should wait for both input AND output to be closed, but this needs to be validated. I agree the close logic is wrong. I wanted to fix the existing issues before I started on this. Looking at the code, it shouldn't be too hard to fix. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1660677 - in /tomcat/site/trunk: docs/download-70.cgi docs/download-80.cgi docs/download-native.cgi docs/download-taglibs.cgi xdocs/download-native.cgi xdocs/download-taglibs.cgi
Author: markt Date: Wed Feb 18 16:59:09 2015 New Revision: 1660677 URL: http://svn.apache.org/r1660677 Log: Ensure correct props are set on cgi files Modified: tomcat/site/trunk/docs/download-70.cgi (props changed) tomcat/site/trunk/docs/download-80.cgi (props changed) tomcat/site/trunk/docs/download-native.cgi (props changed) tomcat/site/trunk/docs/download-taglibs.cgi (props changed) tomcat/site/trunk/xdocs/download-native.cgi (props changed) tomcat/site/trunk/xdocs/download-taglibs.cgi (props changed) Propchange: tomcat/site/trunk/docs/download-70.cgi -- svn:executable = * Propchange: tomcat/site/trunk/docs/download-80.cgi -- svn:executable = * Propchange: tomcat/site/trunk/docs/download-native.cgi -- svn:eol-style = native Propchange: tomcat/site/trunk/docs/download-taglibs.cgi -- svn:executable = * Propchange: tomcat/site/trunk/xdocs/download-native.cgi -- svn:eol-style = native Propchange: tomcat/site/trunk/xdocs/download-taglibs.cgi -- svn:eol-style = native - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 57540] report TLS protocol version
https://bz.apache.org/bugzilla/show_bug.cgi?id=57540 --- Comment #19 from Christopher Schultz ch...@christopherschultz.net --- I have a question about your implementation in mod_jk: why are you passing the SSL_PROTOCOL as a SC_A_REQ_ATTRIBUTE instead of a first-class piece of information, like SC_A_SSL_CIPHER is done? Would that represent a change to the protocol, since SC_A_SSL_CIPHER is a constant defined by the protocol and SSL_PROTOCOL has nothing yet defined? I'm going to commit this patch to trunk and then work on a proposal for a back-port, since a lot has changed between Tomcat 8 and the trunk at this point. -- 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: svn commit: r1660609 - in /tomcat/trunk/java/org/apache/coyote/http11/upgrade: UpgradeProcessor.java UpgradeServletOutputStream.java
On 18/02/2015 15:04, Mark Thomas wrote: On 18/02/2015 14:01, Rémy Maucherat wrote: 2015-02-18 14:19 GMT+01:00 Mark Thomas ma...@apache.org: Hmm. I've been running a test with this plus a bunch of possibly unnecessary sync expansions looping over the suspect test for over an hour now without any failures. This patch does fix a logic problem but I thought it was one that would result in multiple write registrations rather than a missed registration. I'm going to look at this more closely until either I convince myself that this change could fix the 'missed write registration' problem or one of the tests fails. No problem with watching the CI results for some time and see if it works. I tried fiddling with the write notification code some time ago, since it's different from 8.x, but I ran into problems, so I won't make any changes to it until it gets stable. Progress. I can reproduce a variant (where no messages are sent) of this this easily with a debugger now. Next up, finding the root cause followed by a fix. After some further research, the bug is triggered by the long poll handling for NIO2. However, I don't think this is the actual root cause. My current thinking on that is that the upgrade process isn't explicitly triggering the first onWritePossible() and onDataAvailable() calls. Currently we 'work-around' this in various ways in various places - particularly WebSocket. I believe some of the problems we seeing are caused by edge cases in these work-arounds. I'm currently exploring explicitly triggering the onWritePossible() and onDataAvailable() calls but I have some more work to do on this as the work-arounds needs to be removed to avoid double registration etc. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1660738 - in /tomcat/tc6.0.x/trunk: STATUS.txt dist.xml extras.xml webapps/docs/changelog.xml
Author: kkolinko
Date: Wed Feb 18 21:58:05 2015
New Revision: 1660738
URL: http://svn.apache.org/r1660738
Log:
Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=57344
Provide sha1 checksum files for Tomcat downloads.
Modified:
tomcat/tc6.0.x/trunk/STATUS.txt
tomcat/tc6.0.x/trunk/dist.xml
tomcat/tc6.0.x/trunk/extras.xml
tomcat/tc6.0.x/trunk/webapps/docs/changelog.xml
Modified: tomcat/tc6.0.x/trunk/STATUS.txt
URL:
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/STATUS.txt?rev=1660738r1=1660737r2=1660738view=diff
==
--- tomcat/tc6.0.x/trunk/STATUS.txt (original)
+++ tomcat/tc6.0.x/trunk/STATUS.txt Wed Feb 18 21:58:05 2015
@@ -28,12 +28,6 @@ None
PATCHES PROPOSED TO BACKPORT:
[ New proposals should be added at the end of the list ]
-* Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=57344
- Provide sha1 checksum files for Tomcat downloads.
- https://issues.apache.org/bugzilla/attachment.cgi?id=32287
- +1: kkolinko, remm, markt, schultz
- -1:
-
* Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=57558
Add missing JARs in Ant task definition. Expand the pattern in
catalina-tasks.xml to include all jars in ${catalina.home}/lib.
Modified: tomcat/tc6.0.x/trunk/dist.xml
URL:
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/dist.xml?rev=1660738r1=1660737r2=1660738view=diff
==
--- tomcat/tc6.0.x/trunk/dist.xml (original)
+++ tomcat/tc6.0.x/trunk/dist.xml Wed Feb 18 21:58:05 2015
@@ -738,14 +738,19 @@
/antcall
/target
- !-- Helper target, used to create a md5 checksum file --
+ !-- Helper target, used to create checksum files --
!-- Requires 'file' as a parameter. --
target name=md5sum
fail unless=file /
-fail if=filename /
-fail if=value /
+local name=filename /
+local name=md5value /
+local name=sha1value /
+
basename file=${file} property=filename /
-checksum file=${file} property=value /
-echo file=${file}.md5
message=${value}${md5sum.binary-prefix}${filename} /
+checksum algorithm=MD5 file=${file} property=md5value /
+checksum algorithm=SHA-1 file=${file} property=sha1value /
+
+echo file=${file}.md5
message=${md5value}${md5sum.binary-prefix}${filename} /
+echo file=${file}.sha1
message=${sha1value}${md5sum.binary-prefix}${filename} /
/target
/project
Modified: tomcat/tc6.0.x/trunk/extras.xml
URL:
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/extras.xml?rev=1660738r1=1660737r2=1660738view=diff
==
--- tomcat/tc6.0.x/trunk/extras.xml (original)
+++ tomcat/tc6.0.x/trunk/extras.xml Wed Feb 18 21:58:05 2015
@@ -376,14 +376,19 @@
get src=${sourcefile} dest=${destfile} /
/target
- !-- Helper target, used to create a md5 checksum file --
+ !-- Helper target, used to create checksum files --
!-- Requires 'file' as a parameter. --
target name=md5sum
fail unless=file /
-fail if=filename /
-fail if=value /
+local name=filename /
+local name=md5value /
+local name=sha1value /
+
basename file=${file} property=filename /
-checksum file=${file} property=value /
-echo file=${file}.md5
message=${value}${md5sum.binary-prefix}${filename} /
+checksum algorithm=MD5 file=${file} property=md5value /
+checksum algorithm=SHA-1 file=${file} property=sha1value /
+
+echo file=${file}.md5
message=${md5value}${md5sum.binary-prefix}${filename} /
+echo file=${file}.sha1
message=${sha1value}${md5sum.binary-prefix}${filename} /
/target
/project
Modified: tomcat/tc6.0.x/trunk/webapps/docs/changelog.xml
URL:
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/webapps/docs/changelog.xml?rev=1660738r1=1660737r2=1660738view=diff
==
--- tomcat/tc6.0.x/trunk/webapps/docs/changelog.xml (original)
+++ tomcat/tc6.0.x/trunk/webapps/docs/changelog.xml Wed Feb 18 21:58:05 2015
@@ -116,6 +116,14 @@
/fix
/changelog
/subsection
+ subsection name=Other
+changelog
+ add
+bug57344/bug: Provide sha1 checksum files for Tomcat downloads.
+(kkolinko)
+ /add
+/changelog
+ /subsection
/section
section name=Tomcat 6.0.43 (markt) rtext=released 2014-11-22
subsection name=Catalina
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 57540] report TLS protocol version
https://bz.apache.org/bugzilla/show_bug.cgi?id=57540 --- Comment #20 from Rainer Jung rainer.j...@kippdata.de --- Some attributes are known in the AJP 1.3 protocol and their names are marshalled on the wire with hex abbreviations. Those must be known by the receiver as well otherwise it is a protocol violation. So new attributes can't simply get new hex abbreviations because then we would have a compativbility problem with old receivers. For general (not known) attributes there's the option to send their name as clear text. That's what we do here. -- 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 57559] Decoded Request URI used for Asynchronous dispatch
https://bz.apache.org/bugzilla/show_bug.cgi?id=57559 --- Comment #3 from cg.throwa...@mailinator.com --- (In reply to Konstantin Kolinko from comment #2) Previous discussion of this issue, ~8 months ago (June 2014): Decoded URL set on asynchronous request http://tomcat.markmail.org/thread/e33tqu7ayp2fguh4 Yeah, I did find this discussion but it wasn't very clear what conclusion you guys came to. There was talk of opening a bug but I couldn't find any when I searched so I figured I would open this one. (In reply to Mark Thomas from comment #1) I'll raise this with the Servlet EG to see if the wording of this can be changed/improved but - as far as Tomcat is concerned - this is a WONTFIX. Note if the EG opt for the behavior you are asking for I'll re-open this issue. Thanks for the detailed reply. I'm still a bit confused about the outcome though... are you saying that this *is* a Tomcat bug but it won't be fixed (hence the WONTFIX resolution), or that it *isn't* a bug because you believe Tomcat's current behaviour is what the servlet spec intended, or something else entirely? -- 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 57344] [PATCH] Provide sha1 checksum files for Tomcat downloads
https://bz.apache.org/bugzilla/show_bug.cgi?id=57344 Konstantin Kolinko knst.koli...@gmail.com changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #8 from Konstantin Kolinko knst.koli...@gmail.com --- The patch applied to 6.0 in r1660738, will be in 6.0.44 onwards. -- 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 57558] validator ant task throws NoClassDefFoundError - Tomcat 8.0.18
https://bz.apache.org/bugzilla/show_bug.cgi?id=57558 Konstantin Kolinko knst.koli...@gmail.com changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Konstantin Kolinko knst.koli...@gmail.com --- Fixed in Tomcat 6 by r1660788 and will be in 6.0.44 onwards. -- 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: r1660792 - in /tomcat/tc6.0.x/trunk: ./ STATUS.txt java/org/apache/coyote/Request.java webapps/docs/changelog.xml
Author: kkolinko Date: Thu Feb 19 04:19:11 2015 New Revision: 1660792 URL: http://svn.apache.org/r1660792 Log: Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=57581 Change statistics byte counter in coyote Request object to be long to allow values above 2Gb. (RequestInfo.getRequestBytesReceived() already exposes it as long to JMX.) I am changing the setter method as well. It is never called, removed from Tomcat 7 onwards. Modified: tomcat/tc6.0.x/trunk/ (props changed) tomcat/tc6.0.x/trunk/STATUS.txt tomcat/tc6.0.x/trunk/java/org/apache/coyote/Request.java tomcat/tc6.0.x/trunk/webapps/docs/changelog.xml Propchange: tomcat/tc6.0.x/trunk/ -- --- svn:mergeinfo (original) +++ svn:mergeinfo Thu Feb 19 04:19:11 2015 @@ -1,3 +1,3 @@ -/tomcat/tc7.0.x/trunk:1224802,1243045,1298635,1304471,1311997,1312007,1331772,1333164,1333176,1348992,1354866,1371298,1371302,1371620,1402110,1409014,1413553,1413557,1413563,1430083,1438415,1446641-1446660,1447013,1453106,1453119,1484919,1486877,1500065,1503852,1505844,1513151,1521040,1526470,1536524,1539176-1539177,1544469,1544473,1552805,1558894,1558917,1561368,1561382,1561386,1561552,1561561,1561636,1561641,1561643,1561737,1562748,1564317,1568922,1570163,1577328,1577464-1577465,1578814,1586659,1586897,1586960,1588199,1588997,1589740,1589851,1589997,1590019,1590028,1590337,1590492,1590651,1590838,1590845,1590848,1590912,1593262,1593288,1593371,1593835,1594230,1595174,1595366,1600956,1601333,1601856,1601909,1609079,1609606,1617364,1617374,1617433,1617457-1617458,1624249,1626579,1627420,1627469,1632586,1637686,1637711,1640675,1642045,1643515,1643540,1643572,1643585-1643586,1643642,1643647,1644019,1648817,1656301,1658815 -/tomcat/tc8.0.x/trunk:1637685,1637709,1640674,1641726,1641729-1641730,1643513,1643539,1643571,1643581-1643582,1644018,1648816,1656300,1658801-1658803,1658811 -/tomcat/trunk:601180,606992,612607,630314,640888,652744,653247,656018,666232,673796,673820,677910,683969,683982,684001,684081,684234,684269-684270,685177,687503,687645,689402,690781,691392,691805,692748,693378,694992,695053,695311,696780,696782,698012,698227,698236,698613,699427,699634,701355,709294,709811,709816,710063,710066,710125,710205,711126,711600,712461,712467,713953,714002,718360,719119,719124,719602,719626,719628,720046,720069,721040,721286,721708,721886,723404,723738,726052,727303,728032,728768,728947,729057,729567,729569,729571,729681,729809,729815,729934,730250,730590,731651,732859,732863,734734,740675,740684,742677,742697,742714,744160,744238,746321,746384,746425,747834,747863,748344,750258,750291,750921,751286-751287,751289,751295,752323,753039,757335,757774,758249,758365,758596,758616,758664,759074,761601,762868,762929,762936-762937,763166,763183,763193,763228,763262,763298,763302,763325,763599,763611,763654,763681,763706,764985,764997,765662,768335,769979,770716,770 809,770876,772872,776921,776924,776935,776945,777464,777466,777576,777625,778379,778523-778524,781528,781779,782145,782791,783316,783696,783724,783756,783762,783766,783863,783934,784453,784602,784614,785381,785688,785768,785859,786468,786487,786490,786496,786667,787627,787770,787985,789389,790405,791041,791184,791194,791224,791243,791326,791328,791789,792740,793372,793757,793882,793981,794082,794673,794822,795043,795152,795210,795457,795466,797168,797425,797596,797607,802727,802940,804462,804544,804734,805153,809131,809603,810916,810977,812125,812137,812432,813001,813013,813866,814180,814708,814876,815972,816252,817442,817822,819339,819361,820110,820132,820874,820954,821397,828196,828201,828210,828225,828759,830378-830379,830999,831106,831774,831785,831828,831850,831860,832214,832218,833121,833545,834047,835036,835336,836405,881396,881412,883130,883134,883146,883165,883177,883362,883565,884341,885038,885231,885241,885260,885901,885991,886019,888072,889363,889606,889716,890139,890265 ,890349-890350,890417,891185-891187,891583,892198,892341,892415,892464,892555,892812,892814,892817,892843,892887,893321,893493,894580,894586,894805,894831,895013,895045,895057,895191,895392,895703,896370,896384,897380-897381,897776,898126,898256,898468,898527,898555,898558,898718,898836,898906,899284,899348,899420,899653,899769-899770,899783,899788,899792,899916,899918-899919,899935,899949,903916,905020,905151,905722,905728,905735,907311,907513,907538,907652,907819,907825,907864,908002,908721,908754,908759,909097,909206,909212,909525,909636,909869,909875,909887,910266,910370,910442,910471,910485,910974,915226,915737,915861,916097,916141,916157,916170,917598,917633,918093,918489,918594,918684,918787,918792,918799,918803,918885,919851,919914,920025,920055,920298,920449,920596,920824,920840,921444,922010,926716,927062,927621,928482,928695,928732,928798,931709,932357,932967,935105,935983,939491,939551,940064,941356,941463,943112,944409,944416,945231,945808,945835,945841,946686,948057,95
[Bug 57601] New: DefaultServlet returns no content when included during a HEAD request
https://bz.apache.org/bugzilla/show_bug.cgi?id=57601 Bug ID: 57601 Summary: DefaultServlet returns no content when included during a HEAD request Product: Tomcat 8 Version: trunk Hardware: All OS: All Status: NEW Severity: normal Priority: P5 Component: Catalina Assignee: dev@tomcat.apache.org Reporter: jboy...@apache.org During a HEAD request, when a RequestDispatcher include is handled by the DefaultServlet the content of the static resource is not written to the HttpServletResponse. If the including servlet has wrapped the response before performing the include it will not receive the content of the resource. This causes an issue for the JSTL c:import tag when a relative url is used in order to retrieve the resource, for example for use with the x:parse tag. Bug 37466 describes this case. It is also a problem for other requests where the response headers may be affected by this lack of content causing different header values to be returned for GET vs. HEAD methods. For example, the Content-Length header does not account for bytes that are emitted by the included resource. -- 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: r1660793 - in /tomcat/tc6.0.x/trunk: ./ STATUS.txt java/org/apache/jasper/runtime/ProtectedFunctionMapper.java java/org/apache/jasper/security/SecurityClassLoad.java webapps/docs/changelog
Author: kkolinko Date: Thu Feb 19 04:30:33 2015 New Revision: 1660793 URL: http://svn.apache.org/r1660793 Log: Simplify code in ProtectedFunctionMapper class of Jasper runtime. Modified: tomcat/tc6.0.x/trunk/ (props changed) tomcat/tc6.0.x/trunk/STATUS.txt tomcat/tc6.0.x/trunk/java/org/apache/jasper/runtime/ProtectedFunctionMapper.java tomcat/tc6.0.x/trunk/java/org/apache/jasper/security/SecurityClassLoad.java tomcat/tc6.0.x/trunk/webapps/docs/changelog.xml Propchange: tomcat/tc6.0.x/trunk/ -- --- svn:mergeinfo (original) +++ svn:mergeinfo Thu Feb 19 04:30:33 2015 @@ -1,3 +1,3 @@ -/tomcat/tc7.0.x/trunk:1224802,1243045,1298635,1304471,1311997,1312007,1331772,1333164,1333176,1348992,1354866,1371298,1371302,1371620,1402110,1409014,1413553,1413557,1413563,1430083,1438415,1446641-1446660,1447013,1453106,1453119,1484919,1486877,1500065,1503852,1505844,1513151,1521040,1526470,1536524,1539176-1539177,1544469,1544473,1552805,1558894,1558917,1561368,1561382,1561386,1561552,1561561,1561636,1561641,1561643,1561737,1562748,1564317,1568922,1570163,1577328,1577464-1577465,1578814,1586659,1586897,1586960,1588199,1588997,1589740,1589851,1589997,1590019,1590028,1590337,1590492,1590651,1590838,1590845,1590848,1590912,1593262,1593288,1593371,1593835,1594230,1595174,1595366,1600956,1601333,1601856,1601909,1609079,1609606,1617364,1617374,1617433,1617457-1617458,1624249,1626579,1627420,1627469,1632586,1637686,1637711,1640675,1642045,1643515,1643540,1643572,1643585-1643586,1643642,1643647,1644019,1648817,1656301,1658815,1659523 +/tomcat/tc7.0.x/trunk:1224802,1243045,1298635,1304471,1311997,1312007,1331772,1333164,1333176,1348992,1354866,1371298,1371302,1371620,1402110,1409014,1413553,1413557,1413563,1430083,1438415,1446641-1446660,1447013,1453106,1453119,1484919,1486877,1500065,1503852,1505844,1513151,1521040,1526470,1536524,1539176-1539177,1544469,1544473,1552805,1558894,1558917,1561368,1561382,1561386,1561552,1561561,1561636,1561641,1561643,1561737,1562748,1564317,1568922,1570163,1577328,1577464-1577465,1578814,1586659,1586897,1586960,1588199,1588997,1589740,1589851,1589997,1590019,1590028,1590337,1590492,1590651,1590838,1590845,1590848,1590912,1593262,1593288,1593371,1593835,1594230,1595174,1595366,1600956,1601333,1601856,1601909,1609079,1609606,1617364,1617374,1617433,1617457-1617458,1624249,1626579,1627420,1627469,1632586,1637686,1637711,1640675,1642045,1643515,1643540,1643572,1643585-1643586,1643642,1643647,1644019,1648817,1656301,1658815,1659523,1659564 /tomcat/tc8.0.x/trunk:1637685,1637709,1640674,1641726,1641729-1641730,1643513,1643539,1643571,1643581-1643582,1644018,1648816,1656300,1658801-1658803,1658811,1659522 /tomcat/trunk:601180,606992,612607,630314,640888,652744,653247,656018,666232,673796,673820,677910,683969,683982,684001,684081,684234,684269-684270,685177,687503,687645,689402,690781,691392,691805,692748,693378,694992,695053,695311,696780,696782,698012,698227,698236,698613,699427,699634,701355,709294,709811,709816,710063,710066,710125,710205,711126,711600,712461,712467,713953,714002,718360,719119,719124,719602,719626,719628,720046,720069,721040,721286,721708,721886,723404,723738,726052,727303,728032,728768,728947,729057,729567,729569,729571,729681,729809,729815,729934,730250,730590,731651,732859,732863,734734,740675,740684,742677,742697,742714,744160,744238,746321,746384,746425,747834,747863,748344,750258,750291,750921,751286-751287,751289,751295,752323,753039,757335,757774,758249,758365,758596,758616,758664,759074,761601,762868,762929,762936-762937,763166,763183,763193,763228,763262,763298,763302,763325,763599,763611,763654,763681,763706,764985,764997,765662,768335,769979,770716,770 809,770876,772872,776921,776924,776935,776945,777464,777466,777576,777625,778379,778523-778524,781528,781779,782145,782791,783316,783696,783724,783756,783762,783766,783863,783934,784453,784602,784614,785381,785688,785768,785859,786468,786487,786490,786496,786667,787627,787770,787985,789389,790405,791041,791184,791194,791224,791243,791326,791328,791789,792740,793372,793757,793882,793981,794082,794673,794822,795043,795152,795210,795457,795466,797168,797425,797596,797607,802727,802940,804462,804544,804734,805153,809131,809603,810916,810977,812125,812137,812432,813001,813013,813866,814180,814708,814876,815972,816252,817442,817822,819339,819361,820110,820132,820874,820954,821397,828196,828201,828210,828225,828759,830378-830379,830999,831106,831774,831785,831828,831850,831860,832214,832218,833121,833545,834047,835036,835336,836405,881396,881412,883130,883134,883146,883165,883177,883362,883565,884341,885038,885231,885241,885260,885901,885991,886019,888072,889363,889606,889716,890139,890265
Re: Reg: Bug 56438
Hi Mark, Below are my observations during my research on the bug: 1) I downloaded recent trunk and ran the ant command so that the build/bin/lib folders are generated. 2) I created a simple web application and exported to WAR file which is of 3.4 MB size including 10 required jar files. 3) I enabled debugging as mentioned in bug: org.apache.tomcat.util.scan.StandardJarScanner.level = FINE org.apache.catalina.startup.Catalina.level = INFO 4) I deployed the WAR file using trunk/output/build/bin/catalina.bat file. Deployment is successful and i could see my application running. One Log message observed is: 19-Feb-2015 04:30:45.958 INFO [localhost-startStop-1] org.apache.jasper.servlet.TldScanner.scanJars At least one JAR was scanned for TLDs yet contained no TLDs. Enable debug logging for this logger for a complete list of JARs that were scanned but no TLDs were found in them. Skipping unneeded JARs during scanning can improve startup time and JSP compilation time. 19-Feb-2015 04:30:47.144 INFO [main] org.apache.catalina.startup.Catalina.start Server startup in 2680 ms Even though i kept 10jars only 5 jars got scanned and don't see the issue reproduced. My assumptions on Bug: Deploy simple WAR taking longer time due to tomcat 7.0 JAR scanning is taking more time. Enhancement requested is: If some jar file is missing then add a log message in log file saying add it under JarsToSkip. Please correct me if my understanding about the bug is wrong. Thanks, Pravallika(VIN) On Wed, Feb 18, 2015 at 12:30 PM, Pravallika Peddi reachme.va...@gmail.com wrote: Sure Mark, I will try and let you know. On Tue, Feb 17, 2015 at 4:20 PM, Mark Thomas ma...@apache.org wrote: On 17/02/2015 06:42, Pravallika Peddi wrote: Hi Mark, Its regarding the another bug that you shared to me: https://bz.apache.org/bugzilla/show_bug.cgi?id=56438 This bug involves migration from 5.5 to 7.0, and i am new to migration of Tomcat releases. Hence can you assign me some other issues which can handle with code directly? Or please let me know the search criteria to find out the right issues based on my expertise. Do some more research on that issue. Migration was just the point in time where the user discovered the issue with the current Tomcat behaviour. You should be able to replicate the problem with a very simple web application with trunk (or just add JARs to one of the web applications that ships with Tomcat). Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 57581] request.getBytesRead() should be long
https://bz.apache.org/bugzilla/show_bug.cgi?id=57581 --- Comment #2 from Konstantin Kolinko knst.koli...@gmail.com --- Fixed in Tomcat 6 by r1660792. The fix will be in 6.0.44 onwards. -- 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: Question about taglibs. Issue 37466
On Feb 18, 2015, at 3:10 AM, Stephan van Loendersloot (LIST) step...@republika.nl wrote: Hi Konstantin, Jeremy, Yes I can provide a simple example shortly... Apologies for breaking the first rule of questioning: provide all details about operating system, container, libraries, etc. Would it be best if I continue this discussion here or at Jira? I reopened 37466[1]. Please add your example as an attachment there. Thanks Jeremy [1] https://bz.apache.org/bugzilla/show_bug.cgi?id=37466 signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [VOTE] Release Apache Tomcat 8.0.20
2015-02-18 15:56 GMT+03:00 Konstantin Kolinko knst.koli...@gmail.com: 2015-02-17 16:49 GMT+03:00 Mark Thomas ma...@apache.org: On 16/02/2015 14:09, Konstantin Kolinko wrote: 2015-02-15 21:46 GMT+03:00 Mark Thomas ma...@apache.org: The proposed Apache Tomcat 8.0.20 release is now available for voting. The proposed 8.0.20 release is: [ ] Broken - do not release [ ] Stable - go ahead and release as 8.0.20 I am abstaining for now. Using JDK 7u76, win, 32-bit Unit tests pass. Smoke testing: I see an issue with numberwriter example. Test: 1) go to /examples/servlets/nonblocking/numberwriter with a web browser 2) look into access log Expected: status 200 Actual: status 500 for APR, NIO, NIO2. (BIO is OK) NIO sometimes show status 200. NIO+HTTPS shows status 200. How frequently do you see this? I've just tried repeating this with NIO on Windows (64-bit OS, 32-bit u76 JDK, 8.0.x) without success. I've tired a few other OS / JDK combinations that are less like your environment and I haven't been able to repeat this there either. I am observing this consistently. Though as it disappeared with HTTPS connector it depends on timing. I configured HTTPS Nio2 connector and I observe this issue there as well. I enabled FINE logging for Coyote and I am seeing the following messages for a single request: For APR connector: [[[ 18-Feb-2015 15:57:47.014 FINE [http-apr-127.0.0.1-8083-exec-2] org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.register Register Catalina:type=RequestProcessor,worker=http-apr-127.0.0.1-8083,name=HttpRequest1 18-Feb-2015 15:57:47.023 FINE [http-apr-127.0.0.1-8083-exec-2] org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process Socket: [org.apache.tomcat.util.net.AprEndpoint$AprSocketWrapper@1342088:86309568], Status in: [OPEN_READ], State out: [LONG] 18-Feb-2015 15:57:47.051 FINE [http-apr-127.0.0.1-8083-exec-2] org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process Socket: [org.apache.tomcat.util.net.AprEndpoint$AprSocketWrapper@1342088:86309568], Status in: [OPEN_READ], State out: [LONG] 18-Feb-2015 15:57:47.110 FINE [http-apr-127.0.0.1-8083-exec-3] org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process Socket: [org.apache.tomcat.util.net.AprEndpoint$AprSocketWrapper@1342088:86309568], Status in: [OPEN_WRITE], State out: [LONG] 18-Feb-2015 15:57:47.137 FINE [http-apr-127.0.0.1-8083-exec-4] org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process Socket: [org.apache.tomcat.util.net.AprEndpoint$AprSocketWrapper@1342088:86309568], Status in: [OPEN_WRITE], State out: [LONG] 18-Feb-2015 15:57:47.144 FINE [http-apr-127.0.0.1-8083-exec-5] org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process Socket: [org.apache.tomcat.util.net.AprEndpoint$AprSocketWrapper@1342088:86309568], Status in: [OPEN_WRITE], State out: [LONG] 18-Feb-2015 15:57:47.154 FINE [http-apr-127.0.0.1-8083-exec-6] org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process Socket: [org.apache.tomcat.util.net.AprEndpoint$AprSocketWrapper@1342088:86309568], Status in: [OPEN_WRITE], State out: [LONG] 18-Feb-2015 15:57:47.175 FINE [http-apr-127.0.0.1-8083-exec-7] org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process Socket: [org.apache.tomcat.util.net.AprEndpoint$AprSocketWrapper@1342088:86309568], Status in: [OPEN_WRITE], State out: [LONG] 18-Feb-2015 15:57:47.184 FINE [http-apr-127.0.0.1-8083-exec-8] org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process Socket: [org.apache.tomcat.util.net.AprEndpoint$AprSocketWrapper@1342088:86309568], Status in: [OPEN_WRITE], State out: [LONG] 18-Feb-2015 15:57:47.193 FINE [http-apr-127.0.0.1-8083-exec-9] org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process Socket: [org.apache.tomcat.util.net.AprEndpoint$AprSocketWrapper@1342088:86309568], Status in: [OPEN_WRITE], State out: [LONG] 18-Feb-2015 15:57:47.206 FINE [http-apr-127.0.0.1-8083-exec-10] org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process Socket: [org.apache.tomcat.util.net.AprEndpoint$AprSocketWrapper@1342088:86309568], Status in: [OPEN_WRITE], State out: [LONG] 18-Feb-2015 15:57:47.292 FINE [http-apr-127.0.0.1-8083-exec-1] org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process Socket: [org.apache.tomcat.util.net.AprEndpoint$AprSocketWrapper@1342088:86309568], Status in: [OPEN_WRITE], State out: [LONG] 18-Feb-2015 15:57:47.298 FINE [http-apr-127.0.0.1-8083-exec-2] org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process Socket: [org.apache.tomcat.util.net.AprEndpoint$AprSocketWrapper@1342088:86309568], Status in: [OPEN_WRITE], State out: [LONG] 18-Feb-2015 15:57:47.304 FINE [http-apr-127.0.0.1-8083-exec-3] org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process Socket: [org.apache.tomcat.util.net.AprEndpoint$AprSocketWrapper@1342088:86309568], Status in: [OPEN_WRITE], State out: [LONG] 18-Feb-2015
Re: svn commit: r1660609 - in /tomcat/trunk/java/org/apache/coyote/http11/upgrade: UpgradeProcessor.java UpgradeServletOutputStream.java
On 18/02/2015 12:14, ma...@apache.org wrote:
Author: markt
Date: Wed Feb 18 12:14:24 2015
New Revision: 1660609
URL: http://svn.apache.org/r1660609
Log:
registered is guarded by registeredLock so there is no need for it to be
volatile.
Simplify the process of triggering the first call to onWritePossible
Hmm. I've been running a test with this plus a bunch of possibly
unnecessary sync expansions looping over the suspect test for over an
hour now without any failures.
This patch does fix a logic problem but I thought it was one that would
result in multiple write registrations rather than a missed registration.
I'm going to look at this more closely until either I convince myself
that this change could fix the 'missed write registration' problem or
one of the tests fails.
Mark
Modified:
tomcat/trunk/java/org/apache/coyote/http11/upgrade/UpgradeProcessor.java
tomcat/trunk/java/org/apache/coyote/http11/upgrade/UpgradeServletOutputStream.java
Modified:
tomcat/trunk/java/org/apache/coyote/http11/upgrade/UpgradeProcessor.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/coyote/http11/upgrade/UpgradeProcessor.java?rev=1660609r1=1660608r2=1660609view=diff
==
--- tomcat/trunk/java/org/apache/coyote/http11/upgrade/UpgradeProcessor.java
(original)
+++ tomcat/trunk/java/org/apache/coyote/http11/upgrade/UpgradeProcessor.java
Wed Feb 18 12:14:24 2015
@@ -99,7 +99,6 @@ public class UpgradeProcessor implements
public final SocketState upgradeDispatch(SocketStatus status) {
if (status == SocketStatus.OPEN_READ) {
upgradeServletInputStream.onDataAvailable();
-upgradeServletOutputStream.checkWriteDispatch();
} else if (status == SocketStatus.OPEN_WRITE) {
upgradeServletOutputStream.onWritePossible();
} else if (status == SocketStatus.STOP) {
Modified:
tomcat/trunk/java/org/apache/coyote/http11/upgrade/UpgradeServletOutputStream.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/coyote/http11/upgrade/UpgradeServletOutputStream.java?rev=1660609r1=1660608r2=1660609view=diff
==
---
tomcat/trunk/java/org/apache/coyote/http11/upgrade/UpgradeServletOutputStream.java
(original)
+++
tomcat/trunk/java/org/apache/coyote/http11/upgrade/UpgradeServletOutputStream.java
Wed Feb 18 12:14:24 2015
@@ -55,12 +55,7 @@ public class UpgradeServletOutputStream
private volatile WriteListener listener = null;
// Guarded by registeredLock
-private volatile boolean registered = false;
-
-// Use to track if a dispatch needs to be arranged to trigger the first
call
-// to onWritePossible. If the socket gets registered for write while
this is
-// set then this will be ignored.
-private volatile boolean writeDispatchRequired = false;
+private boolean registered = false;
private volatile ClassLoader applicationLoader = null;
@@ -110,7 +105,10 @@ public class UpgradeServletOutputStream
}
// Container is responsible for first call to onWritePossible() but
only
// need to do this if setting the listener for the first time.
-writeDispatchRequired = true;
+synchronized (registeredLock) {
+registered = true;
+socketWrapper.addDispatch(DispatchType.NON_BLOCKING_WRITE);
+}
this.listener = listener;
this.applicationLoader =
Thread.currentThread().getContextClassLoader();
@@ -265,16 +263,4 @@ public class UpgradeServletOutputStream
}
}
}
-
-
-void checkWriteDispatch() {
-synchronized (registeredLock) {
-if (writeDispatchRequired) {
-writeDispatchRequired = false;
-if (!registered) {
-
socketWrapper.addDispatch(DispatchType.NON_BLOCKING_WRITE);
-}
-}
-}
-}
}
-
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
svn commit: r1660609 - in /tomcat/trunk/java/org/apache/coyote/http11/upgrade: UpgradeProcessor.java UpgradeServletOutputStream.java
Author: markt
Date: Wed Feb 18 12:14:24 2015
New Revision: 1660609
URL: http://svn.apache.org/r1660609
Log:
registered is guarded by registeredLock so there is no need for it to be
volatile.
Simplify the process of triggering the first call to onWritePossible
Modified:
tomcat/trunk/java/org/apache/coyote/http11/upgrade/UpgradeProcessor.java
tomcat/trunk/java/org/apache/coyote/http11/upgrade/UpgradeServletOutputStream.java
Modified:
tomcat/trunk/java/org/apache/coyote/http11/upgrade/UpgradeProcessor.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/coyote/http11/upgrade/UpgradeProcessor.java?rev=1660609r1=1660608r2=1660609view=diff
==
--- tomcat/trunk/java/org/apache/coyote/http11/upgrade/UpgradeProcessor.java
(original)
+++ tomcat/trunk/java/org/apache/coyote/http11/upgrade/UpgradeProcessor.java
Wed Feb 18 12:14:24 2015
@@ -99,7 +99,6 @@ public class UpgradeProcessor implements
public final SocketState upgradeDispatch(SocketStatus status) {
if (status == SocketStatus.OPEN_READ) {
upgradeServletInputStream.onDataAvailable();
-upgradeServletOutputStream.checkWriteDispatch();
} else if (status == SocketStatus.OPEN_WRITE) {
upgradeServletOutputStream.onWritePossible();
} else if (status == SocketStatus.STOP) {
Modified:
tomcat/trunk/java/org/apache/coyote/http11/upgrade/UpgradeServletOutputStream.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/coyote/http11/upgrade/UpgradeServletOutputStream.java?rev=1660609r1=1660608r2=1660609view=diff
==
---
tomcat/trunk/java/org/apache/coyote/http11/upgrade/UpgradeServletOutputStream.java
(original)
+++
tomcat/trunk/java/org/apache/coyote/http11/upgrade/UpgradeServletOutputStream.java
Wed Feb 18 12:14:24 2015
@@ -55,12 +55,7 @@ public class UpgradeServletOutputStream
private volatile WriteListener listener = null;
// Guarded by registeredLock
-private volatile boolean registered = false;
-
-// Use to track if a dispatch needs to be arranged to trigger the first
call
-// to onWritePossible. If the socket gets registered for write while this
is
-// set then this will be ignored.
-private volatile boolean writeDispatchRequired = false;
+private boolean registered = false;
private volatile ClassLoader applicationLoader = null;
@@ -110,7 +105,10 @@ public class UpgradeServletOutputStream
}
// Container is responsible for first call to onWritePossible() but
only
// need to do this if setting the listener for the first time.
-writeDispatchRequired = true;
+synchronized (registeredLock) {
+registered = true;
+socketWrapper.addDispatch(DispatchType.NON_BLOCKING_WRITE);
+}
this.listener = listener;
this.applicationLoader =
Thread.currentThread().getContextClassLoader();
@@ -265,16 +263,4 @@ public class UpgradeServletOutputStream
}
}
}
-
-
-void checkWriteDispatch() {
-synchronized (registeredLock) {
-if (writeDispatchRequired) {
-writeDispatchRequired = false;
-if (!registered) {
-socketWrapper.addDispatch(DispatchType.NON_BLOCKING_WRITE);
-}
-}
-}
-}
}
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 57592] numberwriter example: Response status 500, asyncOperation() not valid for request with state DISPATCHED
https://bz.apache.org/bugzilla/show_bug.cgi?id=57592 --- Comment #4 from Konstantin Kolinko knst.koli...@gmail.com --- Created attachment 32491 -- https://bz.apache.org/bugzilla/attachment.cgi?id=32491action=edit localhost_access_log.2015-02-18.txt - Access Log - 8.0.18 -- 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 57592] numberwriter example: Response status 500, asyncOperation() not valid for request with state DISPATCHED
https://bz.apache.org/bugzilla/show_bug.cgi?id=57592 --- Comment #5 from Konstantin Kolinko knst.koli...@gmail.com --- Created attachment 32492 -- https://bz.apache.org/bugzilla/attachment.cgi?id=32492action=edit catalina.2015-02-18.log - Log - 8.0.18 -- 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 57540] report TLS protocol version
https://bz.apache.org/bugzilla/show_bug.cgi?id=57540 --- Comment #16 from Christopher Schultz ch...@christopherschultz.net --- I've got an updated patch with AJP support that I'm testing now. -- 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 57540] report TLS protocol version
https://bz.apache.org/bugzilla/show_bug.cgi?id=57540 Christopher Schultz ch...@christopherschultz.net changed: What|Removed |Added Attachment #32486|0 |1 is obsolete|| -- 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 57592] numberwriter example: Response status 500, asyncOperation() not valid for request with state DISPATCHED
https://bz.apache.org/bugzilla/show_bug.cgi?id=57592 --- Comment #9 from Konstantin Kolinko knst.koli...@gmail.com --- Created attachment 32496 -- https://bz.apache.org/bugzilla/attachment.cgi?id=32496action=edit hs_err_pid3936.log - Tomcat 9 @1660633 - Crash Log -- 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 57540] report TLS protocol version
https://bz.apache.org/bugzilla/show_bug.cgi?id=57540 Christopher Schultz ch...@christopherschultz.net changed: What|Removed |Added Attachment #32487|0 |1 is obsolete|| --- Comment #17 from Christopher Schultz ch...@christopherschultz.net --- Created attachment 32493 -- https://bz.apache.org/bugzilla/attachment.cgi?id=32493action=edit Updated patch Updated patch to support AJP connections (only with mod_jk 1.2.41 and higher, and with an as-yet-unspecified version of mod_proxy_ajp). -- 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 57592] numberwriter example: Response status 500, asyncOperation() not valid for request with state DISPATCHED
https://bz.apache.org/bugzilla/show_bug.cgi?id=57592 Konstantin Kolinko knst.koli...@gmail.com changed: What|Removed |Added OS||All --- Comment #6 from Konstantin Kolinko knst.koli...@gmail.com --- Testing the current Tomcat 9 trunk @1660633 Configuration is the same, minus BIO connectors that are not implemented in trunk. HTTP: 8082: Nio, 8083: Apr, 8084: Nio2 HTTPS: 9443: Nio, 10443: Nio2. None for APR. Using Java 8u31. HTTP connectors: response status OK (200). Seeing some EOF exceptions in FINE logging. The one from APR connectors seems odd. The JVM crashed when I was trying to access the Nio HTTPS connector, but the crash is in APR connector code. It tried to process timeout on a keep-alive request. -- 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 57592] numberwriter example: Response status 500, asyncOperation() not valid for request with state DISPATCHED
https://bz.apache.org/bugzilla/show_bug.cgi?id=57592 --- Comment #8 from Konstantin Kolinko knst.koli...@gmail.com --- Created attachment 32495 -- https://bz.apache.org/bugzilla/attachment.cgi?id=32495action=edit catalina.2015-02-18.log - Tomcat 9 @1660633 - Log -- 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 57592] numberwriter example: Response status 500, asyncOperation() not valid for request with state DISPATCHED
https://bz.apache.org/bugzilla/show_bug.cgi?id=57592 --- Comment #7 from Konstantin Kolinko knst.koli...@gmail.com --- Created attachment 32494 -- https://bz.apache.org/bugzilla/attachment.cgi?id=32494action=edit localhost_access_log.2015-02-18.txt - Tomcat 9 @1660633 - Access Log -- 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] Release Apache Tomcat 8.0.20
Mark, On 2/15/15 1:46 PM, Mark Thomas wrote: The proposed Apache Tomcat 8.0.20 release is now available for voting. The main changes since 8.0.18 are: - Fix a performance regression in the new resources implementation when signed JARs are used in a web application. - Fix several bugs that could cause multiple registrations for write events for a single socket when using Servlet 3.0 async. Typically, the side effects of these multiple registrations would be exceptions appearing in the logs. - Enhance the bean factory used for JNDI resources. The new attribute forceString allows to support non-standard string argument property setters. There is also the usual collection of bug fixes, new features and performance improvements. For full details, see the changelog: http://svn.us.apache.org/repos/asf/tomcat/tc8.0.x/trunk/webapps/docs/changelog.xml It can be obtained from: https://dist.apache.org/repos/dist/dev/tomcat/tomcat-8/v8.0.20/ The Maven staging repo is: https://repository.apache.org/content/repositories/orgapachetomcat-1036/ The svn tag is: http://svn.apache.org/repos/asf/tomcat/tc8.0.x/tags/TOMCAT_8_0_20/ The proposed 8.0.20 release is: [ ] Broken - do not release [X] Stable - go ahead and release as 8.0.20 No problems in an active multi-user development environment. Details: * Environment * Java (build): java version 1.7.0_76 Java(TM) SE Runtime Environment (build 1.7.0_76-b13) Java HotSpot(TM) 64-Bit Server VM (build 24.76-b04, mixed mode) * Java (test): java version 1.7.0_76 Java(TM) SE Runtime Environment (build 1.7.0_76-b13) Java HotSpot(TM) 64-Bit Server VM (build 24.76-b04, mixed mode) * OS: Linux 2.6.32-312-ec2 x86_64 * cc: cc (Debian 4.7.2-5) 4.7.2 * make: GNU Make 3.81 * OpenSSL: OpenSSL 1.0.1e 11 Feb 2013 * APR: 1.4.6 * * Valid MD5 signature for apache-tomcat-8.0.20.zip * Valid GPG signature for apache-tomcat-8.0.20.zip * Valid MD5 signature for apache-tomcat-8.0.20.tar.gz * Valid GPG signature for apache-tomcat-8.0.20.tar.gz * Valid MD5 signature for apache-tomcat-8.0.20.exe * Valid GPG signature for apache-tomcat-8.0.20.exe * Valid MD5 signature for apache-tomcat-8.0.20-src.zip * Valid GPG signature for apache-tomcat-8.0.20-src.zip * Valid MD5 signature for apache-tomcat-8.0.20-src.tar.gz * Valid GPG signature for apache-tomcat-8.0.20-src.tar.gz * * Binary Zip and tarball: Same * Source Zip and tarball: Same * * Building dependencies returned: 0 * tcnative builds cleanly * Tomcat builds cleanly * Junit Tests: FAILED * * Tests that failed: (multicast is known not to work in my environment) org.apache.catalina.session.TestStandardSession.APR.txt org.apache.catalina.session.TestStandardSession.BIO.txt org.apache.catalina.session.TestStandardSession.NIO.txt org.apache.catalina.session.TestStandardSession.NIO2.txt org.apache.catalina.tribes.group.TestGroupChannelMemberArrival.APR.txt org.apache.catalina.tribes.group.TestGroupChannelMemberArrival.BIO.txt org.apache.catalina.tribes.group.TestGroupChannelMemberArrival.NIO.txt org.apache.catalina.tribes.group.TestGroupChannelMemberArrival.NIO2.txt org.apache.catalina.tribes.group.TestGroupChannelSenderConnections.APR.txt org.apache.catalina.tribes.group.TestGroupChannelSenderConnections.BIO.txt org.apache.catalina.tribes.group.TestGroupChannelSenderConnections.NIO.txt org.apache.catalina.tribes.group.TestGroupChannelSenderConnections.NIO2.txt org.apache.catalina.tribes.group.TestGroupChannelStartStop.APR.txt org.apache.catalina.tribes.group.TestGroupChannelStartStop.BIO.txt org.apache.catalina.tribes.group.TestGroupChannelStartStop.NIO.txt org.apache.catalina.tribes.group.TestGroupChannelStartStop.NIO2.txt org.apache.catalina.tribes.group.interceptors.TestNonBlockingCoordinator.APR.txt org.apache.catalina.tribes.group.interceptors.TestNonBlockingCoordinator.BIO.txt org.apache.catalina.tribes.group.interceptors.TestNonBlockingCoordinator.NIO.txt org.apache.catalina.tribes.group.interceptors.TestNonBlockingCoordinator.NIO2.txt org.apache.catalina.tribes.group.interceptors.TestOrderInterceptor.APR.txt org.apache.catalina.tribes.group.interceptors.TestOrderInterceptor.BIO.txt org.apache.catalina.tribes.group.interceptors.TestOrderInterceptor.NIO.txt org.apache.catalina.tribes.group.interceptors.TestOrderInterceptor.NIO2.txt org.apache.catalina.tribes.group.interceptors.TestTcpFailureDetector.APR.txt org.apache.catalina.tribes.group.interceptors.TestTcpFailureDetector.BIO.txt org.apache.catalina.tribes.group.interceptors.TestTcpFailureDetector.NIO.txt org.apache.catalina.tribes.group.interceptors.TestTcpFailureDetector.NIO2.txt -chris signature.asc Description: OpenPGP digital signature
Re: [VOTE] Release Apache Tomcat 8.0.20
2015-02-17 16:49 GMT+03:00 Mark Thomas ma...@apache.org: On 16/02/2015 14:09, Konstantin Kolinko wrote: 2015-02-15 21:46 GMT+03:00 Mark Thomas ma...@apache.org: The proposed Apache Tomcat 8.0.20 release is now available for voting. The proposed 8.0.20 release is: [ ] Broken - do not release [ ] Stable - go ahead and release as 8.0.20 I am abstaining for now. Using JDK 7u76, win, 32-bit Unit tests pass. Smoke testing: I see an issue with numberwriter example. Test: 1) go to /examples/servlets/nonblocking/numberwriter with a web browser 2) look into access log Expected: status 200 Actual: status 500 for APR, NIO, NIO2. (BIO is OK) NIO sometimes show status 200. NIO+HTTPS shows status 200. How frequently do you see this? I've just tried repeating this with NIO on Windows (64-bit OS, 32-bit u76 JDK, 8.0.x) without success. I've tired a few other OS / JDK combinations that are less like your environment and I haven't been able to repeat this there either. As this is reproducible for 8.0.18, I filed it into Bugzilla. I am attaching the logs there. https://bz.apache.org/bugzilla/show_bug.cgi?id=57592 Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1660608 - /tomcat/trunk/java/org/apache/coyote/Response.java
Author: markt
Date: Wed Feb 18 12:07:32 2015
New Revision: 1660608
URL: http://svn.apache.org/r1660608
Log:
Fix typo
Modified:
tomcat/trunk/java/org/apache/coyote/Response.java
Modified: tomcat/trunk/java/org/apache/coyote/Response.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/coyote/Response.java?rev=1660608r1=1660607r2=1660608view=diff
==
--- tomcat/trunk/java/org/apache/coyote/Response.java (original)
+++ tomcat/trunk/java/org/apache/coyote/Response.java Wed Feb 18 12:07:32 2015
@@ -584,7 +584,7 @@ public final class Response {
action(ActionCode.DISPATCH_WRITE, null);
synchronized (nonBlockingStateLock) {
// Ensure we don't get multiple write registrations if
-// ServletOutoutStream.isReady() returns false during a call to
+// ServletOutputStream.isReady() returns false during a call to
// onDataAvailable()
registeredForWrite = true;
// Need to set the fireListener flag otherwise when the
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 57592] numberwriter example: Response status 500, asyncOperation() not valid for request with state DISPATCHED
https://bz.apache.org/bugzilla/show_bug.cgi?id=57592 --- Comment #2 from Konstantin Kolinko knst.koli...@gmail.com --- Created attachment 32489 -- https://bz.apache.org/bugzilla/attachment.cgi?id=32489action=edit localhost_access_log.2015-02-18.txt - Access Log - 8.0.20 -- 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 57592] numberwriter example: Response status 500, asyncOperation() not valid for request with state DISPATCHED
https://bz.apache.org/bugzilla/show_bug.cgi?id=57592 --- Comment #3 from Konstantin Kolinko knst.koli...@gmail.com --- Created attachment 32490 -- https://bz.apache.org/bugzilla/attachment.cgi?id=32490action=edit catalina.2015-02-18.log - Log - 8.0.20 -- 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] Release Apache Tomcat 8.0.20
2015-02-17 16:49 GMT+03:00 Mark Thomas ma...@apache.org: On 16/02/2015 14:09, Konstantin Kolinko wrote: 2015-02-15 21:46 GMT+03:00 Mark Thomas ma...@apache.org: The proposed Apache Tomcat 8.0.20 release is now available for voting. The proposed 8.0.20 release is: [ ] Broken - do not release [ ] Stable - go ahead and release as 8.0.20 I am abstaining for now. Using JDK 7u76, win, 32-bit Unit tests pass. Smoke testing: I see an issue with numberwriter example. Test: 1) go to /examples/servlets/nonblocking/numberwriter with a web browser 2) look into access log Expected: status 200 Actual: status 500 for APR, NIO, NIO2. (BIO is OK) NIO sometimes show status 200. NIO+HTTPS shows status 200. How frequently do you see this? I've just tried repeating this with NIO on Windows (64-bit OS, 32-bit u76 JDK, 8.0.x) without success. I've tired a few other OS / JDK combinations that are less like your environment and I haven't been able to repeat this there either. I am observing this consistently. Though as it disappeared with HTTPS connector it depends on timing. I configured HTTPS Nio2 connector and I observe this issue there as well. I enabled FINE logging for Coyote and I am seeing the following messages for a single request: [[[ 18-Feb-2015 15:51:16.372 FINE [http-nio2-127.0.0.1-8084-exec-2] org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.register Register Catalina:type=RequestProcessor,worker=http-nio2-127.0.0.1-8084,name=HttpRequest1 18-Feb-2015 15:51:16.378 FINE [http-nio2-127.0.0.1-8084-exec-2] org.apache.coyote.http11.AbstractNioInputBuffer.parseRequestLine Received [GET /examples/servlets/nonblocking/numberwriter HTTP/1.1 Host: localhost:8084 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:35.0) Gecko/20100101 Firefox/35.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: ru-RU,ru;q=0.8,en-US;q=0.5,en;q=0.3 Accept-Encoding: gzip, deflate Connection: keep-alive Cache-Control: max-age=0 ] 18-Feb-2015 15:51:16.611 FINE [http-nio2-127.0.0.1-8084-exec-2] org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process Socket: [org.apache.tomcat.util.net.Nio2Endpoint$Nio2SocketWrapper@851105:org.apache.tomcat.util.net.Nio2Channel@406c4:sun.nio.ch.WindowsAsynchronousSocketChannelImpl[connected local=/127.0.0.1:8084 remote=/127.0.0.1:51890]], Status in: [OPEN_READ], State out: [LONG] 18-Feb-2015 15:51:16.663 FINE [http-nio2-127.0.0.1-8084-exec-2] org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process Socket: [org.apache.tomcat.util.net.Nio2Endpoint$Nio2SocketWrapper@851105:org.apache.tomcat.util.net.Nio2Channel@406c4:sun.nio.ch.WindowsAsynchronousSocketChannelImpl[connected local=/127.0.0.1:8084 remote=/127.0.0.1:51890]], Status in: [OPEN_READ], State out: [LONG] 18-Feb-2015 15:51:16.865 FINE [http-nio2-127.0.0.1-8084-exec-4] org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process Socket: [org.apache.tomcat.util.net.Nio2Endpoint$Nio2SocketWrapper@851105:org.apache.tomcat.util.net.Nio2Channel@406c4:sun.nio.ch.WindowsAsynchronousSocketChannelImpl[connected local=/127.0.0.1:8084 remote=/127.0.0.1:51890]], Status in: [OPEN_WRITE], State out: [LONG] 18-Feb-2015 15:51:16.894 FINE [http-nio2-127.0.0.1-8084-exec-6] org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process Socket: [org.apache.tomcat.util.net.Nio2Endpoint$Nio2SocketWrapper@851105:org.apache.tomcat.util.net.Nio2Channel@406c4:sun.nio.ch.WindowsAsynchronousSocketChannelImpl[connected local=/127.0.0.1:8084 remote=/127.0.0.1:51890]], Status in: [OPEN_WRITE], State out: [LONG] 18-Feb-2015 15:51:16.917 FINE [http-nio2-127.0.0.1-8084-exec-8] org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process Socket: [org.apache.tomcat.util.net.Nio2Endpoint$Nio2SocketWrapper@851105:org.apache.tomcat.util.net.Nio2Channel@406c4:sun.nio.ch.WindowsAsynchronousSocketChannelImpl[connected local=/127.0.0.1:8084 remote=/127.0.0.1:51890]], Status in: [OPEN_WRITE], State out: [LONG] 18-Feb-2015 15:51:16.940 FINE [http-nio2-127.0.0.1-8084-exec-10] org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process Socket: [org.apache.tomcat.util.net.Nio2Endpoint$Nio2SocketWrapper@851105:org.apache.tomcat.util.net.Nio2Channel@406c4:sun.nio.ch.WindowsAsynchronousSocketChannelImpl[connected local=/127.0.0.1:8084 remote=/127.0.0.1:51890]], Status in: [OPEN_WRITE], State out: [LONG] 18-Feb-2015 15:51:16.957 FINE [http-nio2-127.0.0.1-8084-exec-2] org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process Socket: [org.apache.tomcat.util.net.Nio2Endpoint$Nio2SocketWrapper@851105:org.apache.tomcat.util.net.Nio2Channel@406c4:sun.nio.ch.WindowsAsynchronousSocketChannelImpl[connected local=/127.0.0.1:8084 remote=/127.0.0.1:51890]], Status in: [OPEN_WRITE], State out: [LONG] 18-Feb-2015 15:51:16.975 FINE [http-nio2-127.0.0.1-8084-exec-4] org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process Socket:
[Bug 57592] numberwriter example: Response status 500, asyncOperation() not valid for request with state DISPATCHED
https://bz.apache.org/bugzilla/show_bug.cgi?id=57592 --- Comment #1 from Konstantin Kolinko knst.koli...@gmail.com --- Created attachment 32488 -- https://bz.apache.org/bugzilla/attachment.cgi?id=32488action=edit server.xml server.xml - Tomcat 8.0.20. Custom configuration of Connectors (different port numbers and protocols) and of AccessLogValve (logging port number) logging.properties: added org.apache.coyote.level=FINE -- 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: svn commit: r1660609 - in /tomcat/trunk/java/org/apache/coyote/http11/upgrade: UpgradeProcessor.java UpgradeServletOutputStream.java
2015-02-18 14:19 GMT+01:00 Mark Thomas ma...@apache.org: Hmm. I've been running a test with this plus a bunch of possibly unnecessary sync expansions looping over the suspect test for over an hour now without any failures. This patch does fix a logic problem but I thought it was one that would result in multiple write registrations rather than a missed registration. I'm going to look at this more closely until either I convince myself that this change could fix the 'missed write registration' problem or one of the tests fails. No problem with watching the CI results for some time and see if it works. I tried fiddling with the write notification code some time ago, since it's different from 8.x, but I ran into problems, so I won't make any changes to it until it gets stable. Rémy
svn commit: r1660618 - /tomcat/trunk/java/org/apache/coyote/http11/upgrade/UpgradeServletOutputStream.java
Author: markt
Date: Wed Feb 18 12:53:44 2015
New Revision: 1660618
URL: http://svn.apache.org/r1660618
Log:
Handle the unlikely case of setting the write listener from a non-container
thread.
Modified:
tomcat/trunk/java/org/apache/coyote/http11/upgrade/UpgradeServletOutputStream.java
Modified:
tomcat/trunk/java/org/apache/coyote/http11/upgrade/UpgradeServletOutputStream.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/coyote/http11/upgrade/UpgradeServletOutputStream.java?rev=1660618r1=1660617r2=1660618view=diff
==
---
tomcat/trunk/java/org/apache/coyote/http11/upgrade/UpgradeServletOutputStream.java
(original)
+++
tomcat/trunk/java/org/apache/coyote/http11/upgrade/UpgradeServletOutputStream.java
Wed Feb 18 12:53:44 2015
@@ -21,6 +21,7 @@ import java.io.IOException;
import javax.servlet.ServletOutputStream;
import javax.servlet.WriteListener;
+import org.apache.coyote.ContainerThreadMarker;
import org.apache.juli.logging.Log;
import org.apache.juli.logging.LogFactory;
import org.apache.tomcat.util.ExceptionUtils;
@@ -107,7 +108,11 @@ public class UpgradeServletOutputStream
// need to do this if setting the listener for the first time.
synchronized (registeredLock) {
registered = true;
-socketWrapper.addDispatch(DispatchType.NON_BLOCKING_WRITE);
+if (ContainerThreadMarker.isContainerThread()) {
+socketWrapper.addDispatch(DispatchType.NON_BLOCKING_WRITE);
+} else {
+socketWrapper.registerWriteInterest();
+}
}
this.listener = listener;
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 37466] c:import doesn't work with HEAD requests
https://bz.apache.org/bugzilla/show_bug.cgi?id=37466 Jeremy Boynes jboy...@apache.org changed: What|Removed |Added Status|RESOLVED|REOPENED Version|unspecified |1.2.1 Resolution|FIXED |--- --- Comment #10 from Jeremy Boynes jboy...@apache.org --- The patch in r495005 attempts to address this by wrapping the HttpServletRequest and overriding the getMethod() call to always return GET. The works on Tomcat when importing a static resource as it causes the DefaultServlet to return content (when the method is HEAD DefaultServlet always returns no content). However, it breaks other servlets that may rely on the method, for example, a servlet that overrides doPost(). -- 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 57592] New: numberwriter example: Response status 500, asyncOperation() not valid for request with state DISPATCHED
https://bz.apache.org/bugzilla/show_bug.cgi?id=57592 Bug ID: 57592 Summary: numberwriter example: Response status 500, asyncOperation() not valid for request with state DISPATCHED Product: Tomcat 8 Version: 8.0.18 Hardware: PC Status: NEW Severity: normal Priority: P5 Component: Connectors Assignee: dev@tomcat.apache.org Reporter: knst.koli...@gmail.com First noted this when testing 8.0.20 release candidate, but this is also reproducible with 8.0.18 and 8.0.17. http://markmail.org/message/rkkdl6publsievvi Steps to reproduce: 1) go to /examples/servlets/nonblocking/numberwriter with a web browser 2) look into access log Expected: status 200 Actual: status 500 for APR, NIO, NIO2. (BIO is OK) This issue depends on timing. E.g. it reproduces for me consistently with HTTP connector, but not HTTPS connector. It does not reproduce in some other configurations. 3) Add the following line to logging.properties to enable FINE logging for Coyote: org.apache.coyote.level=FINE The following is observed in the log: for Nio 2, Tomcat 8.0.20: [[[ 18-Feb-2015 15:51:17.155 FINE [http-nio2-127.0.0.1-8084-exec-4] org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process Socket: [org.apache.tomcat.util.net.Nio2Endpoint$Nio2SocketWrapper@851105:org.apache.tomcat.util.net.Nio2Channel@406c4:sun.nio.ch.WindowsAsynchronousSocketChannelImpl[connected local=/127.0.0.1:8084 remote=/127.0.0.1:51890]], Status in: [OPEN_WRITE], State out: [LONG] 18-Feb-2015 15:51:17.169 FINE [http-nio2-127.0.0.1-8084-exec-10] org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process Socket: [org.apache.tomcat.util.net.Nio2Endpoint$Nio2SocketWrapper@851105:org.apache.tomcat.util.net.Nio2Channel@406c4:sun.nio.ch.WindowsAsynchronousSocketChannelImpl[connected local=/127.0.0.1:8084 remote=/127.0.0.1:51890]], Status in: [OPEN_WRITE], State out: [ASYNC_END] 18-Feb-2015 15:51:17.170 FINE [http-nio2-127.0.0.1-8084-exec-10] org.apache.coyote.http11.AbstractHttp11Processor.asyncDispatch Unable to write async data. java.lang.IllegalStateException: Calling [asyncOperation()] is not valid for a request with Async state [DISPATCHED] at org.apache.coyote.AsyncStateMachine.asyncOperation(AsyncStateMachine.java:207) at org.apache.coyote.http11.AbstractHttp11Processor.asyncDispatch(AbstractHttp11Processor.java:1658) at org.apache.coyote.http11.Http11Nio2Processor.asyncDispatch(Http11Nio2Processor.java:155) at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:650) at org.apache.coyote.http11.Http11Nio2Protocol$Http11ConnectionHandler.process(Http11Nio2Protocol.java:177) at org.apache.tomcat.util.net.Nio2Endpoint$SocketProcessor.doRun(Nio2Endpoint.java:1087) at org.apache.tomcat.util.net.Nio2Endpoint$SocketProcessor.run(Nio2Endpoint.java:1046) at org.apache.tomcat.util.net.Nio2Endpoint.processSocket0(Nio2Endpoint.java:598) at org.apache.tomcat.util.net.Nio2Endpoint.processSocket(Nio2Endpoint.java:583) at org.apache.coyote.http11.InternalNio2OutputBuffer$2.completed(InternalNio2OutputBuffer.java:199) at org.apache.coyote.http11.InternalNio2OutputBuffer$2.completed(InternalNio2OutputBuffer.java:165) at sun.nio.ch.Invoker.invokeUnchecked(Invoker.java:126) at sun.nio.ch.Invoker$2.run(Invoker.java:218) at sun.nio.ch.AsynchronousChannelGroupImpl$1.run(AsynchronousChannelGroupImpl.java:112) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) at java.lang.Thread.run(Thread.java:745) 18-Feb-2015 15:51:17.183 FINE [http-nio2-127.0.0.1-8084-exec-10] org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process Socket: [org.apache.tomcat.util.net.Nio2Endpoint$Nio2SocketWrapper@851105:org.apache.tomcat.util.net.Nio2Channel@406c4:sun.nio.ch.WindowsAsynchronousSocketChannelImpl[connected local=/127.0.0.1:8084 remote=/127.0.0.1:51890]], Status in: [OPEN_WRITE], State out: [CLOSED] ]]] For APR connector, Tomcat 8.0.20 [[[ 18-Feb-2015 15:57:47.524 FINE [http-apr-127.0.0.1-8083-exec-6] org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process Socket: [org.apache.tomcat.util.net.AprEndpoint$AprSocketWrapper@1342088:86309568], Status in: [OPEN_WRITE], State out: [LONG] 18-Feb-2015 15:57:47.529 FINE [http-apr-127.0.0.1-8083-exec-7] org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process Socket: [org.apache.tomcat.util.net.AprEndpoint$AprSocketWrapper@1342088:86309568], Status in: [OPEN_WRITE], State out: [ASYNC_END] 18-Feb-2015 15:57:47.530 FINE [http-apr-127.0.0.1-8083-exec-7] org.apache.coyote.http11.AbstractHttp11Processor.asyncDispatch Unable to write async data.
Re: svn commit: r1660609 - in /tomcat/trunk/java/org/apache/coyote/http11/upgrade: UpgradeProcessor.java UpgradeServletOutputStream.java
On 18/02/2015 14:01, Rémy Maucherat wrote: 2015-02-18 14:19 GMT+01:00 Mark Thomas ma...@apache.org: Hmm. I've been running a test with this plus a bunch of possibly unnecessary sync expansions looping over the suspect test for over an hour now without any failures. This patch does fix a logic problem but I thought it was one that would result in multiple write registrations rather than a missed registration. I'm going to look at this more closely until either I convince myself that this change could fix the 'missed write registration' problem or one of the tests fails. No problem with watching the CI results for some time and see if it works. I tried fiddling with the write notification code some time ago, since it's different from 8.x, but I ran into problems, so I won't make any changes to it until it gets stable. Progress. I can reproduce a variant (where no messages are sent) of this this easily with a debugger now. Next up, finding the root cause followed by a fix. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 57540] report TLS protocol version
https://bz.apache.org/bugzilla/show_bug.cgi?id=57540
--- Comment #18 from Rainer Jung rainer.j...@kippdata.de ---
Comment on attachment 32493
-- https://bz.apache.org/bugzilla/attachment.cgi?id=32493
Updated patch
The part for java/org/apache/coyote/ajp looks fine to me.
The rest also, but I didn't inspect it very thoroughly.
For testing with stable mod_jk (without the recent addition), something like
SSLOptions StdEnvVars
RewriteEngine On
RewriteCond %{SSL:SSL_PROTOCOL} (.+)
RewriteRule . - [ENV=AJP_SSL_PROTOCOL:%1]
JkEnvVar AJP_SSL_PROTOCOL
should simulate the behavior.
You can check the httpd side of this by adding %{SSL_PROTOCOL}e and
%{AJP_SSL_PROTOCOL}e to the LogFormat of your access log. Only if these two
vars show useful values in the access log, has the Tomcat side (using your
patch) a chance of working for AJP.
--
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] Release Apache Taglibs 1.2.3
2015-02-18 1:24 GMT+09:00 Jeremy Boynes jboy...@apache.org: Ping? On Feb 13, 2015, at 7:46 AM, Jeremy Boynes jboy...@apache.org wrote: Please could we have a third set of eyes on this release. Thanks Jeremy On Feb 10, 2015, at 8:40 PM, Jeremy Boynes jboy...@apache.org wrote: The proposed Apache Taglibs 1.2.3 release is now available for voting. It can be obtained from: https://dist.apache.org/repos/dist/dev/tomcat/taglibs/taglibs-standard-1.2.3/ The Maven staging repo is: https://repository.apache.org/content/repositories/orgapachetomcat-1034/ The SVN tag is: http://svn.apache.org/repos/asf/tomcat/taglibs/standard/tags/taglibs-standard-1.2.3/ The proposed 1.2.3 release is: [ ] Broken - do not release [X] Stable - go ahead and release as 1.2.3 Stable Tested on my hand-made app. (use core library). Works fine. Thanks Jeremy -- Keiichi.Fujino
svn commit: r1660788 - in /tomcat/tc6.0.x/trunk: ./ STATUS.txt bin/catalina-tasks.xml webapps/docs/changelog.xml
Author: kkolinko
Date: Thu Feb 19 04:07:52 2015
New Revision: 1660788
URL: http://svn.apache.org/r1660788
Log:
Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=57558
Add missing JARs in Ant task definition. Expand the pattern in
catalina-tasks.xml to include all jars in ${catalina.home}/lib.
This adds catalina.jar required by the validate task, as well as optional
i18n jars.
Merged r1658815 from tomcat/tc7.0.x/trunk.
Modified:
tomcat/tc6.0.x/trunk/ (props changed)
tomcat/tc6.0.x/trunk/STATUS.txt
tomcat/tc6.0.x/trunk/bin/catalina-tasks.xml
tomcat/tc6.0.x/trunk/webapps/docs/changelog.xml
Propchange: tomcat/tc6.0.x/trunk/
--
--- svn:mergeinfo (original)
+++ svn:mergeinfo Thu Feb 19 04:07:52 2015
@@ -1,3 +1,3 @@
-/tomcat/tc7.0.x/trunk:1224802,1243045,1298635,1304471,1311997,1312007,1331772,1333164,1333176,1348992,1354866,1371298,1371302,1371620,1402110,1409014,1413553,1413557,1413563,1430083,1438415,1446641-1446660,1447013,1453106,1453119,1484919,1486877,1500065,1503852,1505844,1513151,1521040,1526470,1536524,1539176-1539177,1544469,1544473,1552805,1558894,1558917,1561368,1561382,1561386,1561552,1561561,1561636,1561641,1561643,1561737,1562748,1564317,1568922,1570163,1577328,1577464-1577465,1578814,1586659,1586897,1586960,1588199,1588997,1589740,1589851,1589997,1590019,1590028,1590337,1590492,1590651,1590838,1590845,1590848,1590912,1593262,1593288,1593371,1593835,1594230,1595174,1595366,1600956,1601333,1601856,1601909,1609079,1609606,1617364,1617374,1617433,1617457-1617458,1624249,1626579,1627420,1627469,1632586,1637686,1637711,1640675,1642045,1643515,1643540,1643572,1643585-1643586,1643642,1643647,1644019,1648817,1656301
-/tomcat/tc8.0.x/trunk:1637685,1637709,1640674,1641726,1641729-1641730,1643513,1643539,1643571,1643581-1643582,1644018,1648816,1656300
-/tomcat/trunk:601180,606992,612607,630314,640888,652744,653247,656018,666232,673796,673820,677910,683969,683982,684001,684081,684234,684269-684270,685177,687503,687645,689402,690781,691392,691805,692748,693378,694992,695053,695311,696780,696782,698012,698227,698236,698613,699427,699634,701355,709294,709811,709816,710063,710066,710125,710205,711126,711600,712461,712467,713953,714002,718360,719119,719124,719602,719626,719628,720046,720069,721040,721286,721708,721886,723404,723738,726052,727303,728032,728768,728947,729057,729567,729569,729571,729681,729809,729815,729934,730250,730590,731651,732859,732863,734734,740675,740684,742677,742697,742714,744160,744238,746321,746384,746425,747834,747863,748344,750258,750291,750921,751286-751287,751289,751295,752323,753039,757335,757774,758249,758365,758596,758616,758664,759074,761601,762868,762929,762936-762937,763166,763183,763193,763228,763262,763298,763302,763325,763599,763611,763654,763681,763706,764985,764997,765662,768335,769979,770716,770
809,770876,772872,776921,776924,776935,776945,777464,777466,777576,777625,778379,778523-778524,781528,781779,782145,782791,783316,783696,783724,783756,783762,783766,783863,783934,784453,784602,784614,785381,785688,785768,785859,786468,786487,786490,786496,786667,787627,787770,787985,789389,790405,791041,791184,791194,791224,791243,791326,791328,791789,792740,793372,793757,793882,793981,794082,794673,794822,795043,795152,795210,795457,795466,797168,797425,797596,797607,802727,802940,804462,804544,804734,805153,809131,809603,810916,810977,812125,812137,812432,813001,813013,813866,814180,814708,814876,815972,816252,817442,817822,819339,819361,820110,820132,820874,820954,821397,828196,828201,828210,828225,828759,830378-830379,830999,831106,831774,831785,831828,831850,831860,832214,832218,833121,833545,834047,835036,835336,836405,881396,881412,883130,883134,883146,883165,883177,883362,883565,884341,885038,885231,885241,885260,885901,885991,886019,888072,889363,889606,889716,890139,890265
,890349-890350,890417,891185-891187,891583,892198,892341,892415,892464,892555,892812,892814,892817,892843,892887,893321,893493,894580,894586,894805,894831,895013,895045,895057,895191,895392,895703,896370,896384,897380-897381,897776,898126,898256,898468,898527,898555,898558,898718,898836,898906,899284,899348,899420,899653,899769-899770,899783,899788,899792,899916,899918-899919,899935,899949,903916,905020,905151,905722,905728,905735,907311,907513,907538,907652,907819,907825,907864,908002,908721,908754,908759,909097,909206,909212,909525,909636,909869,909875,909887,910266,910370,910442,910471,910485,910974,915226,915737,915861,916097,916141,916157,916170,917598,917633,918093,918489,918594,918684,918787,918792,918799,918803,918885,919851,919914,920025,920055,920298,920449,920596,920824,920840,921444,922010,926716,927062,927621,928482,928695,928732,928798,931709,932357,932967,935105,935983,939491,939551,940064,941356,941463,943112,944409,944416,945231,945808,945835,945841,946686,948057,95
