DO NOT REPLY [Bug 46264] Shutting down tomcat with large number of contexts is slow
https://issues.apache.org/bugzilla/show_bug.cgi?id=46264 --- Comment #4 from Pid 2010-11-30 01:41:00 EST --- (In reply to comment #3) > I can confirm my patch still works on Tomcat 6.0.29 Would the java.util.concurrency package not provide a more elegant way of solving this problem? -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 50351] javax.naming.NamingException: No set method found for property: singleton
https://issues.apache.org/bugzilla/show_bug.cgi?id=50351 --- Comment #6 from Flávio Henrique 2010-11-29 17:26:30 EST --- Sure, I will try to do my best, but I am a regular user, not a specialized one. (In reply to comment #4) > I think I have a patch for this. If I attach a binary patch to this bug along > with instructions on how to test it would you be able to test the patch to see > it it fixes the issue? -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 46264] Shutting down tomcat with large number of contexts is slow
https://issues.apache.org/bugzilla/show_bug.cgi?id=46264 --- Comment #3 from Joe Kislo 2010-11-29 15:14:59 EST --- I can confirm my patch still works on Tomcat 6.0.29 -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 46263] Tomcat reloading of context does not update context path
https://issues.apache.org/bugzilla/show_bug.cgi?id=46263 --- Comment #3 from Joe Kislo 2010-11-29 15:07:33 EST --- I can confirm my patch still works on Tomcat 6.0.29 -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 41170] single crlf in header termination crashes app.
https://issues.apache.org/bugzilla/show_bug.cgi?id=41170 Tim Whittington changed: What|Removed |Added Status|NEEDINFO|RESOLVED Resolution||WORKSFORME --- Comment #3 from Tim Whittington 2010-11-29 14:04:08 EST --- Noone has noticed this causing an issue since the report, and the code seems correct on inspection, so I'm closing this for now. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 49511] IIS 7.5 incorrect logging: pfc->pFilterContext is per-connection not per-request
https://issues.apache.org/bugzilla/show_bug.cgi?id=49511 Tim Whittington changed: What|Removed |Added Status|NEEDINFO|RESOLVED Resolution||FIXED --- Comment #7 from Tim Whittington 2010-11-29 13:46:59 EST --- This was fixed in 1.2.31 -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 50363] Chunked encoding is applied to 304 responses with no bodies
https://issues.apache.org/bugzilla/show_bug.cgi?id=50363 Tim Whittington changed: What|Removed |Added Summary|Chunked encoding is applied |Chunked encoding is applied |304 responses with no |to 304 responses with no |bodies |bodies -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 7.0.5
I've only been able to do limited testing, but let's keep the 7 releases ticking over. tim On Thu, Nov 25, 2010 at 7:52 AM, Mark Thomas wrote: > The proposed Apache Tomcat 7.0.5 release is now available for voting. > > It can be obtained from: > http://people.apache.org/~markt/dev/tomcat-7/v7.0.5/ > The svn tag is: > http://svn.apache.org/repos/asf/tomcat/tc7.0.x/tags/TOMCAT_7_0_5/ > > As with previous votes, I have included a stable option below although > my personal inclination is still to vote beta. > > The proposed 7.0.5 release is: > > [ ] Broken - do not release > [ ] Alpha - go ahead and release as 7.0.5 Alpha > [x] Beta - go ahead and release as 7.0.5 Beta > [ ] Stable - go ahead and release as 7.0.5 Stable > > This vote will run until 18.00 UTC Monday 29th November (3 working days). > > Cheers, > > Mark > > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 50370] issue Tomcat is down or refused connection. No response has been sent to the client (yet)
https://issues.apache.org/bugzilla/show_bug.cgi?id=50370 Rainer Jung changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Comment #1 from Rainer Jung 2010-11-29 13:15:21 EST --- Bugzilla is not a support forum. Please start a discussion thread on the Tomcat users list. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 7.0.5
On 24.11.2010 19:52, Mark Thomas wrote: The proposed Apache Tomcat 7.0.5 release is now available for voting. It can be obtained from: http://people.apache.org/~markt/dev/tomcat-7/v7.0.5/ The svn tag is: http://svn.apache.org/repos/asf/tomcat/tc7.0.x/tags/TOMCAT_7_0_5/ As with previous votes, I have included a stable option below although my personal inclination is still to vote beta. The proposed 7.0.5 release is: [ ] Broken - do not release [ ] Alpha - go ahead and release as 7.0.5 Alpha [X] Beta - go ahead and release as 7.0.5 Beta [ ] Stable - go ahead and release as 7.0.5 Stable Sorry, 7 minutes over time :) - Checksums and Signatures OK - Identity between Unix and Windows files and subversion fine (Exceptions: modules in svn tag, two files with EOL issues, but no functional problem; fixed in svn) - Binary download runs fine on Solaris - Source download runs the following ant targets: - default: OK - javadoc: OK, only very few Javadoc errors in HTMLManagerServlet and HostConfig - extras: OK (did not work with 7.0.4, now good) - test: OK; some exceptions, but all tests pass with 0 errors and failures; only exception see below. - release - one test failed because it was to slow: Testsuite: org.apache.tomcat.util.http.mapper.TestMapper Tests run: 3, Failures: 1, Errors: 0, Time elapsed: 3.784 sec Testcase: testAddHost took 0.052 sec Testcase: testMap took 0.024 sec Testcase: testPerformance took 3.689 sec FAILED null junit.framework.AssertionFailedError at org.apache.tomcat.util.http.mapper.TestMapper.testPerformance(TestMapper.java:153) It took 3.7 seconds, allowed are only 3 seconds. Thanks for pushing TC 7! i hope we get another vote to be able to release. Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 50370] issue Tomcat is down or refused connection. No response has been sent to the client (yet)
https://issues.apache.org/bugzilla/show_bug.cgi?id=50370 Thomas changed: What|Removed |Added Priority|P2 |P4 CC||monoli...@gmail.com -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 50370] New: issue Tomcat is down or refused connection. No response has been sent to the client (yet)
https://issues.apache.org/bugzilla/show_bug.cgi?id=50370 Summary: issue Tomcat is down or refused connection. No response has been sent to the client (yet) Product: Tomcat Connectors Version: 1.2.30 Platform: HP OS/Version: Linux Status: NEW Severity: major Priority: P2 Component: mod_jk AssignedTo: dev@tomcat.apache.org ReportedBy: monoli...@gmail.com Hi, We got an issue with the two lastest mod_jk connectors on apache: Server version: Apache/2.2.3 Server built: Mar 4 2010 09:57:54 here are the logs of the previous version of the connector: /var/log/httpd/mod_jk.log-20101122.gz:[Sun Nov 21 09:35:20.289 2010] [15777:1217694016] [error] ajp_get_reply::jk_ajp_common.c (2055): (common-app) Tomcat is down or refused connection. No response has been sent to the client (yet) /var/log/httpd/mod_jk.log-20101122.gz:[Sun Nov 21 17:26:47.905 2010] [15775:1286867264] [error] ajp_get_reply::jk_ajp_common.c (2055): (portal) Tomcat is down or refused connection. No response has been sent to the client (yet) and the recent version: [Mon Nov 29 18:37:23.790 2010] [16889:1209870656] [info] ajp_connection_tcp_get_message::jk_ajp_common.c (1223): (portal) can't receive the response header message from tomcat, network problems or tomcat (192.168.10.10:12009) is down (errno=110) [Mon Nov 29 18:37:23.790 2010] [16889:1209870656] [error] ajp_get_reply::jk_ajp_common.c (2058): (portal) Tomcat is down or refused connection. No response has been sent to the client (yet) [Mon Nov 29 18:37:23.790 2010] [16889:1209870656] [info] ajp_service::jk_ajp_common.c (2543): (portal) sending request to tomcat failed (recoverable), (attempt=1) [Mon Nov 29 18:45:45.752 2010] [16888:1133091136] [info] ajp_connection_tcp_get_message::jk_ajp_common.c (1223): (common-grp) can't receive the response header message from tomcat, network problems or tomcat (192.168.10.10:11009) is down (errno=110) [Mon Nov 29 18:45:45.753 2010] [16888:1133091136] [error] ajp_get_reply::jk_ajp_common.c (2058): (common-grp) Tomcat is down or refused connection. No response has been sent to the client (yet) [Mon Nov 29 18:45:45.753 2010] [16888:1133091136] [info] ajp_service::jk_ajp_common.c (2543): (common-grp) sending request to tomcat failed (recoverable), (attempt=2) [Mon Nov 29 18:45:45.753 2010] [16888:1133091136] [error] ajp_service::jk_ajp_common.c (2562): (common-grp) connecting to tomcat failed. Do you have any idea to correct this issue or the root case of this bug ? Best regards, Thomas -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: DO NOT REPLY [Bug 50339] mod_jk parsing error if workers.properties contains whitespaces
On 11/29/2010 06:08 PM, bugzi...@apache.org wrote:
https://issues.apache.org/bugzilla/show_bug.cgi?id=50339
-strcpy(s,&s[i]);
+for (off = i; '\0' != s[i]; i++); {
+s[i - off] = s[i];
+}
+s[i - off] = s[i];
memmove ;)
It would mean HPUX has a crappy strcpy.
Regards
--
^TM
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1040199 - /tomcat/trunk/build.xml
Author: rjung Date: Mon Nov 29 17:32:21 2010 New Revision: 1040199 URL: http://svn.apache.org/viewvc?rev=1040199&view=rev Log: Add css to text file list. Modified: tomcat/trunk/build.xml Modified: tomcat/trunk/build.xml URL: http://svn.apache.org/viewvc/tomcat/trunk/build.xml?rev=1040199&r1=1040198&r2=1040199&view=diff == --- tomcat/trunk/build.xml (original) +++ tomcat/trunk/build.xml Mon Nov 29 17:32:21 2010 @@ -197,6 +197,7 @@ + - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1040198 - /tomcat/trunk/test/webapp-3.0/WEB-INF/tags/bug49297.tag
Author: rjung
Date: Mon Nov 29 17:31:18 2010
New Revision: 1040198
URL: http://svn.apache.org/viewvc?rev=1040198&view=rev
Log:
Set svn properties.
Modified:
tomcat/trunk/test/webapp-3.0/WEB-INF/tags/bug49297.tag (contents, props
changed)
Modified: tomcat/trunk/test/webapp-3.0/WEB-INF/tags/bug49297.tag
URL:
http://svn.apache.org/viewvc/tomcat/trunk/test/webapp-3.0/WEB-INF/tags/bug49297.tag?rev=1040198&r1=1040197&r2=1040198&view=diff
==
--- tomcat/trunk/test/webapp-3.0/WEB-INF/tags/bug49297.tag (original)
+++ tomcat/trunk/test/webapp-3.0/WEB-INF/tags/bug49297.tag Mon Nov 29 17:31:18
2010
@@ -1,21 +1,21 @@
-<%--
- Licensed to the Apache Software Foundation (ASF) under one or more
- contributor license agreements. See the NOTICE file distributed with
- this work for additional information regarding copyright ownership.
- The ASF licenses this file to You under the Apache License, Version 2.0
- (the "License"); you may not use this file except in compliance with
- the License. You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
---%><%@ tag import="java.util.List" import="java.util.ArrayList"%><%@
-tag body-content="empty" %><%
-// Make sure the imports above do work
-List l = new ArrayList();
-l.add("OK");
+<%--
+ Licensed to the Apache Software Foundation (ASF) under one or more
+ contributor license agreements. See the NOTICE file distributed with
+ this work for additional information regarding copyright ownership.
+ The ASF licenses this file to You under the Apache License, Version 2.0
+ (the "License"); you may not use this file except in compliance with
+ the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+--%><%@ tag import="java.util.List" import="java.util.ArrayList"%><%@
+tag body-content="empty" %><%
+// Make sure the imports above do work
+List l = new ArrayList();
+l.add("OK");
%><%=l.get(0)%>
\ No newline at end of file
Propchange: tomcat/trunk/test/webapp-3.0/WEB-INF/tags/bug49297.tag
--
svn:eol-style = native
Propchange: tomcat/trunk/test/webapp-3.0/WEB-INF/tags/bug49297.tag
--
svn:keywords = Date Author Id Revision
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1040161 - /tomcat/trunk/java/org/apache/coyote/AsyncStateMachine.java
On 29/11/2010 15:57, Konstantin Kolinko wrote: > 2010/11/29 : >> Author: markt >> Date: Mon Nov 29 15:46:13 2010 >> New Revision: 1040161 >> >> URL: http://svn.apache.org/viewvc?rev=1040161&view=rev > Searching for "asyncStateMachine.invalidAsyncState" in that file, > there are more errors like that, starting with > s/startAsync()/asyncStart()/ Fixed. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1040196 - /tomcat/trunk/java/org/apache/coyote/AsyncStateMachine.java
Author: markt
Date: Mon Nov 29 17:23:55 2010
New Revision: 1040196
URL: http://svn.apache.org/viewvc?rev=1040196&view=rev
Log:
Correct method names in log messages
Modified:
tomcat/trunk/java/org/apache/coyote/AsyncStateMachine.java
Modified: tomcat/trunk/java/org/apache/coyote/AsyncStateMachine.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/coyote/AsyncStateMachine.java?rev=1040196&r1=1040195&r2=1040196&view=diff
==
--- tomcat/trunk/java/org/apache/coyote/AsyncStateMachine.java (original)
+++ tomcat/trunk/java/org/apache/coyote/AsyncStateMachine.java Mon Nov 29
17:23:55 2010
@@ -129,7 +129,7 @@ public class AsyncStateMachine {
} else {
throw new IllegalStateException(
sm.getString("asyncStateMachine.invalidAsyncState",
-"startAsync()", state));
+"asyncStart()", state));
}
}
@@ -205,7 +205,7 @@ public class AsyncStateMachine {
} else {
throw new IllegalStateException(
sm.getString("asyncStateMachine.invalidAsyncState",
-"timeoutAsync()", state));
+"asyncTimeout()", state));
}
}
@@ -221,7 +221,7 @@ public class AsyncStateMachine {
} else {
throw new IllegalStateException(
sm.getString("asyncStateMachine.invalidAsyncState",
-"dispatchAsync()", state));
+"asyncDispatch()", state));
}
return doDispatch;
}
@@ -233,7 +233,7 @@ public class AsyncStateMachine {
} else {
throw new IllegalStateException(
sm.getString("asyncStateMachine.invalidAsyncState",
-"dispatchAsync()", state));
+"asyncDispatched()", state));
}
}
@@ -246,7 +246,7 @@ public class AsyncStateMachine {
} else {
throw new IllegalStateException(
sm.getString("asyncStateMachine.invalidAsyncState",
-"dispatchAsync()", state));
+"asyncError()", state));
}
return doDispatch;
}
@@ -285,7 +285,7 @@ public class AsyncStateMachine {
} else {
throw new IllegalStateException(
sm.getString("asyncStateMachine.invalidAsyncState",
-"runAsync()", state));
+"asyncRun()", state));
}
}
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 50353] Calling asyncContext.getResponse() returns null after async timeout
https://issues.apache.org/bugzilla/show_bug.cgi?id=50353 Mark Thomas changed: What|Removed |Added Severity|normal |enhancement --- Comment #2 from Mark Thomas 2010-11-29 12:22:10 EST --- Hmm. This is further complicated by the fact that Tomcat recycles Request and Response objects so they can't be kept around forever. I have added this to me list of things to nag the Servlet EG about. I'm currently neutral on whether or not the current behaviour should change. Switching to an enhancement since I don't see an actual bug (as in non-spec compliant behaviour) here. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 50339] mod_jk parsing error if workers.properties contains whitespaces
https://issues.apache.org/bugzilla/show_bug.cgi?id=50339
--- Comment #2 from Rainer Jung 2010-11-29 12:07:58
EST ---
Can you please try the following patch:
Index: common/jk_map.c
===
--- common/jk_map.c (revision 1032021)
+++ common/jk_map.c (working copy)
@@ -630,6 +630,7 @@
static size_t trim(char *s)
{
size_t i;
+size_t off;
/* check for empty strings */
if (!(i = strlen(s)))
@@ -646,7 +647,10 @@
isspace((int)((unsigned char)s[i])); i++);
if (i > 0) {
-strcpy(s, &s[i]);
+for (off = i; '\0' != s[i]; i++); {
+s[i - off] = s[i];
+}
+s[i - off] = s[i];
}
return strlen(s);
Thanks!
Rainer
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 50352] AsyncListener.onComplete is not called after AsyncContext.complete() is called
https://issues.apache.org/bugzilla/show_bug.cgi?id=50352 Mark Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from Mark Thomas 2010-11-29 12:00:30 EST --- Fixed in 7.0.x and will be included in 7.0.6 onwards. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1040190 - /tomcat/trunk/test/org/apache/catalina/core/TestAsyncContextImpl.java
Author: markt
Date: Mon Nov 29 16:58:31 2010
New Revision: 1040190
URL: http://svn.apache.org/viewvc?rev=1040190&view=rev
Log:
Test case for https://issues.apache.org/bugzilla/show_bug.cgi?id=50352
Modified:
tomcat/trunk/test/org/apache/catalina/core/TestAsyncContextImpl.java
Modified: tomcat/trunk/test/org/apache/catalina/core/TestAsyncContextImpl.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/test/org/apache/catalina/core/TestAsyncContextImpl.java?rev=1040190&r1=1040189&r2=1040190&view=diff
==
--- tomcat/trunk/test/org/apache/catalina/core/TestAsyncContextImpl.java
(original)
+++ tomcat/trunk/test/org/apache/catalina/core/TestAsyncContextImpl.java Mon
Nov 29 16:58:31 2010
@@ -749,4 +749,60 @@ public class TestAsyncContextImpl extend
throw new ServletException("Opps.");
}
}
+
+public void testBug50352() throws Exception {
+// Setup Tomcat instance
+Tomcat tomcat = getTomcatInstance();
+
+// Must have a real docBase - just use temp
+File docBase = new File(System.getProperty("java.io.tmpdir"));
+
+Context ctx = tomcat.addContext("", docBase.getAbsolutePath());
+
+AsyncStartRunnable servlet = new AsyncStartRunnable();
+Wrapper wrapper = Tomcat.addServlet(ctx, "servlet", servlet);
+wrapper.setAsyncSupported(true);
+ctx.addServletMapping("/", "servlet");
+
+ErrorServlet error = new ErrorServlet();
+Tomcat.addServlet(ctx, "error", error);
+ctx.addServletMapping("/stage2", "error");
+
+tomcat.start();
+
+ByteChunk res = getUrl("http://localhost:"; + getPort() + "/");
+
+assertEquals("Runnable-onComplete-", res.toString());
+}
+
+private static final class AsyncStartRunnable extends HttpServlet {
+
+private static final long serialVersionUID = 1L;
+
+@Override
+protected void doGet(HttpServletRequest request,
+HttpServletResponse response)
+throws ServletException, IOException {
+
+final AsyncContext asyncContext =
+request.startAsync(request, response);
+
+asyncContext.addListener(new TrackingListener(false, false, null));
+
+asyncContext.start(new Runnable() {
+
+@Override
+public void run() {
+try {
+Thread.sleep(3 * 1000);
+asyncContext.getResponse().getWriter().write(
+"Runnable-");
+asyncContext.complete();
+} catch (Exception e) {
+e.printStackTrace();
+}
+}
+});
+}
+}
}
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1040189 - in /tomcat/trunk: java/org/apache/coyote/AsyncStateMachine.java webapps/docs/changelog.xml
Author: markt
Date: Mon Nov 29 16:58:05 2010
New Revision: 1040189
URL: http://svn.apache.org/viewvc?rev=1040189&view=rev
Log:
Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=50352
Ensure that AsyncListener.onComplete() is fired when AsyncContext.complete() is
called.
Modified:
tomcat/trunk/java/org/apache/coyote/AsyncStateMachine.java
tomcat/trunk/webapps/docs/changelog.xml
Modified: tomcat/trunk/java/org/apache/coyote/AsyncStateMachine.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/coyote/AsyncStateMachine.java?rev=1040189&r1=1040188&r2=1040189&view=diff
==
--- tomcat/trunk/java/org/apache/coyote/AsyncStateMachine.java (original)
+++ tomcat/trunk/java/org/apache/coyote/AsyncStateMachine.java Mon Nov 29
16:58:05 2010
@@ -148,6 +148,7 @@ public class AsyncStateMachine {
state = AsyncState.DISPATCHED;
return SocketState.ASYNC_END;
} else if (state == AsyncState.COMPLETING) {
+asyncCtxt.fireOnComplete();
state = AsyncState.DISPATCHED;
return SocketState.ASYNC_END;
} else if (state == AsyncState.MUST_DISPATCH) {
Modified: tomcat/trunk/webapps/docs/changelog.xml
URL:
http://svn.apache.org/viewvc/tomcat/trunk/webapps/docs/changelog.xml?rev=1040189&r1=1040188&r2=1040189&view=diff
==
--- tomcat/trunk/webapps/docs/changelog.xml (original)
+++ tomcat/trunk/webapps/docs/changelog.xml Mon Nov 29 16:58:05 2010
@@ -63,6 +63,10 @@
caused by the previous fix for 50159. (markt)
+50352: Ensure that AsyncListener.onComplete()
is
+fired when AsyncContext.complete() is called. (markt)
+
+
50358: Set the correct LifecycleState when stopping
instances
of the deprecated Embedded class. (markt)
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1040161 - /tomcat/trunk/java/org/apache/coyote/AsyncStateMachine.java
2010/11/29 :
> Author: markt
> Date: Mon Nov 29 15:46:13 2010
> New Revision: 1040161
>
> URL: http://svn.apache.org/viewvc?rev=1040161&view=rev
> Log:
> Correct method name in log message
>
> Modified:
> tomcat/trunk/java/org/apache/coyote/AsyncStateMachine.java
>
> Modified: tomcat/trunk/java/org/apache/coyote/AsyncStateMachine.java
> URL:
> http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/coyote/AsyncStateMachine.java?rev=1040161&r1=1040160&r2=1040161&view=diff
> ==
> --- tomcat/trunk/java/org/apache/coyote/AsyncStateMachine.java (original)
> +++ tomcat/trunk/java/org/apache/coyote/AsyncStateMachine.java Mon Nov 29
> 15:46:13 2010
> @@ -166,7 +166,7 @@ public class AsyncStateMachine {
> } else {
> throw new IllegalStateException(
> sm.getString("asyncStateMachine.invalidAsyncState",
> - "asyncLongPoll()", state));
> + "asyncPostProcess()", state));
> }
> }
Searching for "asyncStateMachine.invalidAsyncState" in that file,
there are more errors like that, starting with
s/startAsync()/asyncStart()/
Best regards,
Konstantin Kolinko
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1036595 - in /tomcat/trunk: java/org/apache/catalina/ java/org/apache/catalina/ha/session/ java/org/apache/catalina/session/ test/org/apache/catalina/session/
On 29/11/2010 15:52, Konstantin Kolinko wrote: > 2010/11/29 Mark Thomas : >> Good to see we were thinking along the same lines. I still want to get >> to the bottom of the really poor performance on my Mac. > > Looking at documentation for SecureRandom() constructor, it uses > whatever implementation that it finds first. So, configuration of JRE > might be important. I'm leaning towards making provider and algorithm configurable and defaulting to one that is reasonably quick (i.e. whatever Windows is using which I think is a SHA1 based PRNG). Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1036595 - in /tomcat/trunk: java/org/apache/catalina/ java/org/apache/catalina/ha/session/ java/org/apache/catalina/session/ test/org/apache/catalina/session/
2010/11/29 Mark Thomas : > Good to see we were thinking along the same lines. I still want to get > to the bottom of the really poor performance on my Mac. Looking at documentation for SecureRandom() constructor, it uses whatever implementation that it finds first. So, configuration of JRE might be important. 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: r1040161 - /tomcat/trunk/java/org/apache/coyote/AsyncStateMachine.java
Author: markt
Date: Mon Nov 29 15:46:13 2010
New Revision: 1040161
URL: http://svn.apache.org/viewvc?rev=1040161&view=rev
Log:
Correct method name in log message
Modified:
tomcat/trunk/java/org/apache/coyote/AsyncStateMachine.java
Modified: tomcat/trunk/java/org/apache/coyote/AsyncStateMachine.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/coyote/AsyncStateMachine.java?rev=1040161&r1=1040160&r2=1040161&view=diff
==
--- tomcat/trunk/java/org/apache/coyote/AsyncStateMachine.java (original)
+++ tomcat/trunk/java/org/apache/coyote/AsyncStateMachine.java Mon Nov 29
15:46:13 2010
@@ -166,7 +166,7 @@ public class AsyncStateMachine {
} else {
throw new IllegalStateException(
sm.getString("asyncStateMachine.invalidAsyncState",
-"asyncLongPoll()", state));
+"asyncPostProcess()", state));
}
}
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 50351] javax.naming.NamingException: No set method found for property: singleton
https://issues.apache.org/bugzilla/show_bug.cgi?id=50351 Mark Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #5 from Mark Thomas 2010-11-29 10:41:54 EST --- Thanks for the report. This has been fixed in 7.0.x and will be included in 7.0.6 onwards. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1040158 - in /tomcat/trunk/test/org/apache/naming/resources: TestNamingContext.java TesterObject.java
Author: markt
Date: Mon Nov 29 15:40:11 2010
New Revision: 1040158
URL: http://svn.apache.org/viewvc?rev=1040158&view=rev
Log:
Add a test case for https://issues.apache.org/bugzilla/show_bug.cgi?id=50351
Modified:
tomcat/trunk/test/org/apache/naming/resources/TestNamingContext.java
tomcat/trunk/test/org/apache/naming/resources/TesterObject.java
Modified: tomcat/trunk/test/org/apache/naming/resources/TestNamingContext.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/test/org/apache/naming/resources/TestNamingContext.java?rev=1040158&r1=1040157&r2=1040158&view=diff
==
--- tomcat/trunk/test/org/apache/naming/resources/TestNamingContext.java
(original)
+++ tomcat/trunk/test/org/apache/naming/resources/TestNamingContext.java Mon
Nov 29 15:40:11 2010
@@ -156,4 +156,55 @@ public class TestNamingContext extends T
}
}
}
+
+public void testBeanFactory() throws Exception {
+Tomcat tomcat = getTomcatInstance();
+tomcat.enableNaming();
+
+// Must have a real docBase - just use temp
+StandardContext ctx = (StandardContext)
+tomcat.addContext("", System.getProperty("java.io.tmpdir"));
+
+// Create the resource
+ContextResource cr = new ContextResource();
+cr.setName("bug50351");
+cr.setType("org.apache.naming.resources.TesterObject");
+cr.setProperty("factory", "org.apache.naming.factory.BeanFactory");
+cr.setProperty("foo", "value");
+ctx.getNamingResources().addResource(cr);
+
+// Map the test Servlet
+Bug50351Servlet bug50351Servlet = new Bug50351Servlet();
+Tomcat.addServlet(ctx, "bug50351Servlet", bug50351Servlet);
+ctx.addServletMapping("/", "bug50351Servlet");
+
+tomcat.start();
+
+ByteChunk bc = getUrl("http://localhost:"; + getPort() + "/");
+assertEquals("value", bc.toString());
+}
+
+public final class Bug50351Servlet extends HttpServlet {
+
+private static final long serialVersionUID = 1L;
+
+@Override
+protected void doGet(HttpServletRequest req, HttpServletResponse resp)
+throws ServletException, IOException {
+
+resp.setContentType("text/plain;UTF-8");
+PrintWriter out = resp.getWriter();
+
+try {
+Context ctx = new InitialContext();
+Object obj = ctx.lookup("java:comp/env/bug50351");
+TesterObject to = (TesterObject) obj;
+out.print(to.getFoo());
+} catch (NamingException ne) {
+ne.printStackTrace(out);
+}
+}
+}
+
+
}
Modified: tomcat/trunk/test/org/apache/naming/resources/TesterObject.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/test/org/apache/naming/resources/TesterObject.java?rev=1040158&r1=1040157&r2=1040158&view=diff
==
--- tomcat/trunk/test/org/apache/naming/resources/TesterObject.java (original)
+++ tomcat/trunk/test/org/apache/naming/resources/TesterObject.java Mon Nov 29
15:40:11 2010
@@ -18,8 +18,18 @@ package org.apache.naming.resources;
public class TesterObject {
+private String foo;
+
@Override
public String toString() {
return "This is a test object (" + super.toString() + ").";
}
+
+public void setFoo(String foo) {
+this.foo = foo;
+}
+
+public String getFoo() {
+return this.foo;
+}
}
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1040157 - in /tomcat/trunk: java/org/apache/naming/factory/BeanFactory.java webapps/docs/changelog.xml
Author: markt
Date: Mon Nov 29 15:39:50 2010
New Revision: 1040157
URL: http://svn.apache.org/viewvc?rev=1040157&view=rev
Log:
Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=50351
Fix the regression that broke BeanFactory resources caused by the previous fix
for 50159
Modified:
tomcat/trunk/java/org/apache/naming/factory/BeanFactory.java
tomcat/trunk/webapps/docs/changelog.xml
Modified: tomcat/trunk/java/org/apache/naming/factory/BeanFactory.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/naming/factory/BeanFactory.java?rev=1040157&r1=1040156&r2=1040157&view=diff
==
--- tomcat/trunk/java/org/apache/naming/factory/BeanFactory.java (original)
+++ tomcat/trunk/java/org/apache/naming/factory/BeanFactory.java Mon Nov 29
15:39:50 2010
@@ -149,7 +149,8 @@ public class BeanFactory
String propName = ra.getType();
if (propName.equals(Constants.FACTORY) ||
-propName.equals("scope") || propName.equals("auth")) {
+propName.equals("scope") || propName.equals("auth") ||
+propName.equals("singleton")) {
continue;
}
Modified: tomcat/trunk/webapps/docs/changelog.xml
URL:
http://svn.apache.org/viewvc/tomcat/trunk/webapps/docs/changelog.xml?rev=1040157&r1=1040156&r2=1040157&view=diff
==
--- tomcat/trunk/webapps/docs/changelog.xml (original)
+++ tomcat/trunk/webapps/docs/changelog.xml Mon Nov 29 15:39:50 2010
@@ -56,9 +56,13 @@
Further performance improvements to session ID generation. Remove
legacy
-configuration options that are no longer required.
+configuration options that are no longer required. (markt)
+50351: Fix the regression that broke BeanFactory resources
+caused by the previous fix for 50159. (markt)
+
+
50358: Set the correct LifecycleState when stopping
instances
of the deprecated Embedded class. (markt)
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 50351] javax.naming.NamingException: No set method found for property: singleton
https://issues.apache.org/bugzilla/show_bug.cgi?id=50351 --- Comment #4 from Mark Thomas 2010-11-29 08:57:15 EST --- I think I have a patch for this. If I attach a binary patch to this bug along with instructions on how to test it would you be able to test the patch to see it it fixes the issue? -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1036595 - in /tomcat/trunk: java/org/apache/catalina/ java/org/apache/catalina/ha/session/ java/org/apache/catalina/session/ test/org/apache/catalina/session/
On 29/11/2010 13:41, Tim Funk wrote: > Sorry for the additional noise ... my svn emails are in a different > folder from dev emails. I just noticed ... Good to see we were thinking along the same lines. I still want to get to the bottom of the really poor performance on my Mac. Before I do that, I want to take a look at the recent 7.0.5 bugs to see if any are serious enough to change my vote from Beta. Mark > > svn commit: r1039882 - > /tomcat/trunk/java/org/apache/catalina/session/ManagerBase.java > > -Tim > > On 11/29/2010 7:40 AM, Tim Funk wrote: >> I checked the svn history of why MD5 (hashing was used) and the picture >> is incomplete. (unless someone asks craig since I think he was the >> author) >> >> But it appears like this ... >> Tomcat 3.X use Math.random() and some misc crap to generate its session >> id. It had a comment (paraphrased), "not secure for banking/military use >> for creating session ID. " >> >> Then in tomcat 4.0 - we see the code as it is now. It has always tried >> to use SecureRandom. What is interesting is SecureRandom's javadocs in >> 1.2 (JDK) are different than 1.4. (And maybe 1.3) By the time we get to >> Java 1.4 - SecureRandom is advertised as cryptographically strong. So >> back in the day of 1.2 - there was no guarantee there. Or maybe is >> wasn't cross platform guaranteed. >> >> So back in the day ... you might be able to get a stream of session ids >> ... and then determine where you are in the sequence of random number >> generation. (Recall that randoms aren't really random, its just an >> algorithm on a seed) An "easy" way to thwart this attack - is to hash >> the numbers. Making it orders of magnitude harder determine what the >> numbers generated the session ID. (For this type of deception, any >> hashing function is still OK even with the collision issues) >> >> So that leaves us to where we are now. Interestingly enough ... RFC1750 >> (as listed in the SecureRandom javadoc) discourages the use of current >> time as a seed because the window to guess the seed is now orders of >> magnitude smaller. >> >> Since all instances of Random are self seeding, it may be best (ask you >> local JVM expert for opinion) to allow the JVM to decide the seed. In >> which case - it may go to the hardware, use /dev/urandom, etc. Which >> would be much better than anything we can do. >> >> As for hash or not to hash. I am unsure. If the seed IS quality, and the >> random algorithm is quality - then there is no need to hash. But if we >> allow reality to intervene - then we might accept that some platforms >> might not have a quality seed, or one of the algorithms might come under >> attack and no longer be good. In which case - hashing becomes a good >> defense. >> >> >> So to collect all the thoughts above ... it might be nice to do the >> following >> - Force use of SecureRandom (and still allow it to be extended) >> - Turn hashing off (but leave it as an option) >> - When initializing SecureRandom - do nothing. Let the JVM take care >> of it. >> - Allow /dev/urandom to override the previous statement. >> >> Then if any of the above is unacceptable ... the user can just provide >> their own extended version of SecureRandom. >> >> >> -Tim >> >> On 11/26/2010 1:46 PM, Remy Maucherat wrote: >>> On Thu, 2010-11-25 at 16:33 +, Mark Thomas wrote: I wouldn't call it bad. It doesn't do any harm (apart from adding a very small amount of overhead), and it would help if the random source selected ended up not being that random. I thought the trade-off of protection against bad choices of random sources was worth the minimal overhead added. I'm not against removing it entirely, if there is consensus to do so. >>> >>> MD5 is now known as a bad hash (it was fine at the time the code was >>> written), so does it actually improve anything ? >>> >>> Also, isn't SecureRandom always available now ? This is 10+ years old >>> code, probably. >>> For SecureRandom, yes. I did test this locally and it achieves thread-safety by using an internal sync and it did create a significant bottleneck. That is why I went the parallel route. Reading from a stream has a similar sync so again that is why I went the parallel route. >>> >>> Ok. The internal lock is a much smaller sync than the old sync block, so >>> it would be a bit better. It is possible it is noticeable, though. The >>> question is if this yields a good enough session creation rate. >>> How about this as an approach to reduce the complexity: 1. Remove the MD5 code (optional) 2. Default to /dev/urandom then SecureRandom. Don't fall back to Random. 3. Provide a class that implements Random that reads data from a file 4. If randomFile is specified, use the the class from 3 as the Random source That should reduce the current 3 Queues to one. I doubt it will improve performance much but it should make the code clearer.
DO NOT REPLY [Bug 50360] Server socket still bound after Embedded.stop is invoked
https://issues.apache.org/bugzilla/show_bug.cgi?id=50360 --- Comment #2 from Mark Thomas 2010-11-29 08:47:21 EST --- Connector components can be started and stopped multiple times and setting MUST_DESTROY will break that. Therefore, the patch can't be used in its current form. The Connectors and some of their associated components have non-standard lifecycles and I suspect that a change to one of the associated components will be required to fix this. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 50358] Embedded.stopInternal sets state to STARTING, should be STOPPING
https://issues.apache.org/bugzilla/show_bug.cgi?id=50358 Mark Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from Mark Thomas 2010-11-29 08:42:42 EST --- Thanks for the report. This has been fixed in 7.0.x and will be included in 7.0.6 onwards. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1040111 - in /tomcat/trunk: java/org/apache/catalina/startup/Embedded.java webapps/docs/changelog.xml
Author: markt
Date: Mon Nov 29 13:41:07 2010
New Revision: 1040111
URL: http://svn.apache.org/viewvc?rev=1040111&view=rev
Log:
Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=50358
Set correct state when stopping
Modified:
tomcat/trunk/java/org/apache/catalina/startup/Embedded.java
tomcat/trunk/webapps/docs/changelog.xml
Modified: tomcat/trunk/java/org/apache/catalina/startup/Embedded.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/startup/Embedded.java?rev=1040111&r1=1040110&r2=1040111&view=diff
==
--- tomcat/trunk/java/org/apache/catalina/startup/Embedded.java (original)
+++ tomcat/trunk/java/org/apache/catalina/startup/Embedded.java Mon Nov 29
13:41:07 2010
@@ -845,7 +845,7 @@ public class Embedded extends StandardS
log.debug("Stopping embedded server");
fireLifecycleEvent(STOP_EVENT, null);
-setState(LifecycleState.STARTING);
+setState(LifecycleState.STOPPING);
// Stop our defined Connectors first
for (int i = 0; i < connectors.length; i++) {
Modified: tomcat/trunk/webapps/docs/changelog.xml
URL:
http://svn.apache.org/viewvc/tomcat/trunk/webapps/docs/changelog.xml?rev=1040111&r1=1040110&r2=1040111&view=diff
==
--- tomcat/trunk/webapps/docs/changelog.xml (original)
+++ tomcat/trunk/webapps/docs/changelog.xml Mon Nov 29 13:41:07 2010
@@ -58,6 +58,10 @@
Further performance improvements to session ID generation. Remove
legacy
configuration options that are no longer required.
+
+50358: Set the correct LifecycleState when stopping
instances
+of the deprecated Embedded class. (markt)
+
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1036595 - in /tomcat/trunk: java/org/apache/catalina/ java/org/apache/catalina/ha/session/ java/org/apache/catalina/session/ test/org/apache/catalina/session/
Sorry for the additional noise ... my svn emails are in a different folder from dev emails. I just noticed ... svn commit: r1039882 - /tomcat/trunk/java/org/apache/catalina/session/ManagerBase.java -Tim On 11/29/2010 7:40 AM, Tim Funk wrote: I checked the svn history of why MD5 (hashing was used) and the picture is incomplete. (unless someone asks craig since I think he was the author) But it appears like this ... Tomcat 3.X use Math.random() and some misc crap to generate its session id. It had a comment (paraphrased), "not secure for banking/military use for creating session ID. " Then in tomcat 4.0 - we see the code as it is now. It has always tried to use SecureRandom. What is interesting is SecureRandom's javadocs in 1.2 (JDK) are different than 1.4. (And maybe 1.3) By the time we get to Java 1.4 - SecureRandom is advertised as cryptographically strong. So back in the day of 1.2 - there was no guarantee there. Or maybe is wasn't cross platform guaranteed. So back in the day ... you might be able to get a stream of session ids ... and then determine where you are in the sequence of random number generation. (Recall that randoms aren't really random, its just an algorithm on a seed) An "easy" way to thwart this attack - is to hash the numbers. Making it orders of magnitude harder determine what the numbers generated the session ID. (For this type of deception, any hashing function is still OK even with the collision issues) So that leaves us to where we are now. Interestingly enough ... RFC1750 (as listed in the SecureRandom javadoc) discourages the use of current time as a seed because the window to guess the seed is now orders of magnitude smaller. Since all instances of Random are self seeding, it may be best (ask you local JVM expert for opinion) to allow the JVM to decide the seed. In which case - it may go to the hardware, use /dev/urandom, etc. Which would be much better than anything we can do. As for hash or not to hash. I am unsure. If the seed IS quality, and the random algorithm is quality - then there is no need to hash. But if we allow reality to intervene - then we might accept that some platforms might not have a quality seed, or one of the algorithms might come under attack and no longer be good. In which case - hashing becomes a good defense. So to collect all the thoughts above ... it might be nice to do the following - Force use of SecureRandom (and still allow it to be extended) - Turn hashing off (but leave it as an option) - When initializing SecureRandom - do nothing. Let the JVM take care of it. - Allow /dev/urandom to override the previous statement. Then if any of the above is unacceptable ... the user can just provide their own extended version of SecureRandom. -Tim On 11/26/2010 1:46 PM, Remy Maucherat wrote: On Thu, 2010-11-25 at 16:33 +, Mark Thomas wrote: I wouldn't call it bad. It doesn't do any harm (apart from adding a very small amount of overhead), and it would help if the random source selected ended up not being that random. I thought the trade-off of protection against bad choices of random sources was worth the minimal overhead added. I'm not against removing it entirely, if there is consensus to do so. MD5 is now known as a bad hash (it was fine at the time the code was written), so does it actually improve anything ? Also, isn't SecureRandom always available now ? This is 10+ years old code, probably. For SecureRandom, yes. I did test this locally and it achieves thread-safety by using an internal sync and it did create a significant bottleneck. That is why I went the parallel route. Reading from a stream has a similar sync so again that is why I went the parallel route. Ok. The internal lock is a much smaller sync than the old sync block, so it would be a bit better. It is possible it is noticeable, though. The question is if this yields a good enough session creation rate. How about this as an approach to reduce the complexity: 1. Remove the MD5 code (optional) 2. Default to /dev/urandom then SecureRandom. Don't fall back to Random. 3. Provide a class that implements Random that reads data from a file 4. If randomFile is specified, use the the class from 3 as the Random source That should reduce the current 3 Queues to one. I doubt it will improve performance much but it should make the code clearer. Thoughts? I don't know what the best solution is. /dev/urandom could also only be used as seed only to a SecureRandom, this is more Javaish. So about the MD5, I don't think it is useful anymore. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1036595 - in /tomcat/trunk: java/org/apache/catalina/ java/org/apache/catalina/ha/session/ java/org/apache/catalina/session/ test/org/apache/catalina/session/
On 11/25/2010 05:33 PM, Mark Thomas wrote: How about this as an approach to reduce the complexity: 1. Remove the MD5 code (optional) 2. Default to /dev/urandom then SecureRandom. Don't fall back to Random. 3. Provide a class that implements Random that reads data from a file 4. If randomFile is specified, use the the class from 3 as the Random source That should reduce the current 3 Queues to one. I doubt it will improve performance much but it should make the code clearer. Thoughts? How about using OS.random if APR is present? It will use APR's apr_generate_random_bytes which will OTOH use OS optimal random bytes generation eg, dev random, EGD-socket, CryptGenRandom, ... Regards -- ^TM - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1036595 - in /tomcat/trunk: java/org/apache/catalina/ java/org/apache/catalina/ha/session/ java/org/apache/catalina/session/ test/org/apache/catalina/session/
I checked the svn history of why MD5 (hashing was used) and the picture is incomplete. (unless someone asks craig since I think he was the author) But it appears like this ... Tomcat 3.X use Math.random() and some misc crap to generate its session id. It had a comment (paraphrased), "not secure for banking/military use for creating session ID. " Then in tomcat 4.0 - we see the code as it is now. It has always tried to use SecureRandom. What is interesting is SecureRandom's javadocs in 1.2 (JDK) are different than 1.4. (And maybe 1.3) By the time we get to Java 1.4 - SecureRandom is advertised as cryptographically strong. So back in the day of 1.2 - there was no guarantee there. Or maybe is wasn't cross platform guaranteed. So back in the day ... you might be able to get a stream of session ids ... and then determine where you are in the sequence of random number generation. (Recall that randoms aren't really random, its just an algorithm on a seed) An "easy" way to thwart this attack - is to hash the numbers. Making it orders of magnitude harder determine what the numbers generated the session ID. (For this type of deception, any hashing function is still OK even with the collision issues) So that leaves us to where we are now. Interestingly enough ... RFC1750 (as listed in the SecureRandom javadoc) discourages the use of current time as a seed because the window to guess the seed is now orders of magnitude smaller. Since all instances of Random are self seeding, it may be best (ask you local JVM expert for opinion) to allow the JVM to decide the seed. In which case - it may go to the hardware, use /dev/urandom, etc. Which would be much better than anything we can do. As for hash or not to hash. I am unsure. If the seed IS quality, and the random algorithm is quality - then there is no need to hash. But if we allow reality to intervene - then we might accept that some platforms might not have a quality seed, or one of the algorithms might come under attack and no longer be good. In which case - hashing becomes a good defense. So to collect all the thoughts above ... it might be nice to do the following - Force use of SecureRandom (and still allow it to be extended) - Turn hashing off (but leave it as an option) - When initializing SecureRandom - do nothing. Let the JVM take care of it. - Allow /dev/urandom to override the previous statement. Then if any of the above is unacceptable ... the user can just provide their own extended version of SecureRandom. -Tim On 11/26/2010 1:46 PM, Remy Maucherat wrote: On Thu, 2010-11-25 at 16:33 +, Mark Thomas wrote: I wouldn't call it bad. It doesn't do any harm (apart from adding a very small amount of overhead), and it would help if the random source selected ended up not being that random. I thought the trade-off of protection against bad choices of random sources was worth the minimal overhead added. I'm not against removing it entirely, if there is consensus to do so. MD5 is now known as a bad hash (it was fine at the time the code was written), so does it actually improve anything ? Also, isn't SecureRandom always available now ? This is 10+ years old code, probably. For SecureRandom, yes. I did test this locally and it achieves thread-safety by using an internal sync and it did create a significant bottleneck. That is why I went the parallel route. Reading from a stream has a similar sync so again that is why I went the parallel route. Ok. The internal lock is a much smaller sync than the old sync block, so it would be a bit better. It is possible it is noticeable, though. The question is if this yields a good enough session creation rate. How about this as an approach to reduce the complexity: 1. Remove the MD5 code (optional) 2. Default to /dev/urandom then SecureRandom. Don't fall back to Random. 3. Provide a class that implements Random that reads data from a file 4. If randomFile is specified, use the the class from 3 as the Random source That should reduce the current 3 Queues to one. I doubt it will improve performance much but it should make the code clearer. Thoughts? I don't know what the best solution is. /dev/urandom could also only be used as seed only to a SecureRandom, this is more Javaish. So about the MD5, I don't think it is useful anymore. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1040061 - /tomcat/jk/trunk/xdocs/miscellaneous/changelog.xml
Author: timw Date: Mon Nov 29 10:47:46 2010 New Revision: 1040061 URL: http://svn.apache.org/viewvc?rev=1040061&view=rev Log: Changelog for https://issues.apache.org/bugzilla/show_bug.cgi?id=50363 Modified: tomcat/jk/trunk/xdocs/miscellaneous/changelog.xml Modified: tomcat/jk/trunk/xdocs/miscellaneous/changelog.xml URL: http://svn.apache.org/viewvc/tomcat/jk/trunk/xdocs/miscellaneous/changelog.xml?rev=1040061&r1=1040060&r2=1040061&view=diff == --- tomcat/jk/trunk/xdocs/miscellaneous/changelog.xml (original) +++ tomcat/jk/trunk/xdocs/miscellaneous/changelog.xml Mon Nov 29 10:47:46 2010 @@ -49,6 +49,10 @@ multiple occurances of the route separator character '.' in the session id. (rjung) + +50363: IIS: Prevent chunk encoding of empty message + bodies for 204, 205 and 304 responses. (timw) + - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 50363] Chunked encoding is applied 304 responses with no bodies
https://issues.apache.org/bugzilla/show_bug.cgi?id=50363 Tim Whittington changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED OS/Version||All --- Comment #1 from Tim Whittington 2010-11-29 05:45:33 EST --- Fixed in trunk - will be released in 1.2.32. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1040059 - /tomcat/jk/trunk/native/iis/jk_isapi_plugin.c
Author: timw
Date: Mon Nov 29 10:42:15 2010
New Revision: 1040059
URL: http://svn.apache.org/viewvc?rev=1040059&view=rev
Log:
Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=50363
Handle 204, 205 and 304 responses with empty message bodies correctly (by not
chunk encoding the body).
Modified:
tomcat/jk/trunk/native/iis/jk_isapi_plugin.c
Modified: tomcat/jk/trunk/native/iis/jk_isapi_plugin.c
URL:
http://svn.apache.org/viewvc/tomcat/jk/trunk/native/iis/jk_isapi_plugin.c?rev=1040059&r1=1040058&r2=1040059&view=diff
==
--- tomcat/jk/trunk/native/iis/jk_isapi_plugin.c (original)
+++ tomcat/jk/trunk/native/iis/jk_isapi_plugin.c Mon Nov 29 10:42:15 2010
@@ -993,10 +993,19 @@ static int JK_METHOD start_response(jk_w
len_of_headers += 4; /* extra for colon, space and crlf */
}
+/*
+ * Exclude status codes that MUST NOT include message bodies
+ */
+if ((status == 204) || (status == 205) || (status == 304)) {
+p->chunk_content = JK_FALSE;
+/* Keep alive is still possible */
+if (JK_IS_DEBUG_LEVEL(logger))
+jk_log(logger, JK_LOG_DEBUG, "Response status %d implies
no message body", status );
+}
if (p->chunk_content) {
for (i = 0; i < num_of_headers; i++) {
/* Check the downstream response to see whether
- * it's appropriate the chunk the response content
+ * it's appropriate to chunk the response content
* and whether it supports keeping the connection open.
* This implements the rules for HTTP/1.1 message length
determination
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 50363] New: Chunked encoding is applied 304 responses with no bodies
https://issues.apache.org/bugzilla/show_bug.cgi?id=50363 Summary: Chunked encoding is applied 304 responses with no bodies Product: Tomcat Connectors Version: 1.2.30 Platform: PC Status: NEW Severity: normal Priority: P2 Component: isapi AssignedTo: dev@tomcat.apache.org ReportedBy: t...@apache.org When the ISAPI redirector processes a response to a 304 (or 204/205) response with chunked encoding enabled, and a Content-Length is not specified, chunked encoding is applied to the empty body, which created an invalid response. Under normal operation (e.g. DefaultServlet responses), the closing of the output buffer writes a Content-Length: 0 to the response, which the AJP connectors don't try to remove for 304 etc. responses (the HTTP connectors do). This results in 304 responses with Content-Length: 0 headers, which is valid (if quirky). This issue can be reproduced by setting a 304 response status and explicitly calling response.flushBuffer() to commit the response prior to closing the output buffer. The ISAPI Redirector also isn't handling a similar case for HEAD requests. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
