svn commit: r1125651 - /tomcat/jk/trunk/native/common/jk_connect.c
Author: timw Date: Sat May 21 08:57:48 2011 New Revision: 1125651 URL: http://svn.apache.org/viewvc?rev=1125651&view=rev Log: Switching read byte counters to unsigned types to ensure we don't get int wrapping when counting the bytes read. Previously MAX_LINGER_BYTES (32768) was > INT_MAX. Modified: tomcat/jk/trunk/native/common/jk_connect.c Modified: tomcat/jk/trunk/native/common/jk_connect.c URL: http://svn.apache.org/viewvc/tomcat/jk/trunk/native/common/jk_connect.c?rev=1125651&r1=1125650&r2=1125651&view=diff == --- tomcat/jk/trunk/native/common/jk_connect.c (original) +++ tomcat/jk/trunk/native/common/jk_connect.c Sat May 21 08:57:48 2011 @@ -712,8 +712,8 @@ int jk_shutdown_socket(jk_sock_t sd, jk_ char buf[64]; char *sb = NULL; int rc = 0; -int rd = 0; -int rp = 0; +size_t rd = 0; +size_t rp = 0; int save_errno; int timeout = MS_TO_LINGER; time_t start = time(NULL); - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 50839] Closing connection on the client side (browser) during unfinished transmission result in 100% CPU slike for 30 sec during socket shutdownd in jk_connect.c
https://issues.apache.org/bugzilla/show_bug.cgi?id=50839 --- Comment #10 from Tim Whittington 2011-05-21 09:29:41 UTC --- After a hunt through the revisions between 1.2.30 and 1.2.31, it appears that [1] introduced this bug. The counter of bytes read on each attempt to read lingering bytes was not reset in the loop after this change, resulting in the loop reading lingering bytes not exiting normally if there were >= 512 lingering bytes to start with. This also explains the total lingering byte count wrapping into negative numbers. I had already fixed this at the same time as introducing the lingering byte limits. [1] https://svn.apache.org/viewvc?view=revision&sortby=date&revision=998108 -- 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 51234] NumberFormatException in fmt:formatNumber tag
https://issues.apache.org/bugzilla/show_bug.cgi?id=51234 --- Comment #4 from Alexander Kupcov 2011-05-21 09:50:32 UTC --- Thanks for the link to the specification JSTL, but... >From javadoc ( http://download.oracle.com/javase/1.4.2/docs/api/java/lang/Double.html#valueOf%28java.lang.String%29) : = cut === FloatValue: Signopt NaN Signopt Infinity Signopt FloatingPointLiteral where Sign and FloatingPointLiteral are as defined in §3.10.2 of the Java Language Specification. = end of cut === well, look at the The Java Language Specification: = cut === 3.10.2 Floating-Point Literals See §4.2.3 for a general discussion of the floating-point types and values. A floating-point literal has the following parts: a whole-number part, a decimal point (represented by an ASCII period character), a fractional part, an exponent, and a type suffix. The exponent, if present, is indicated by the ASCII letter e or E followed by an optionally signed integer. At least one digit, in either the whole number or the fraction part, and either a decimal point, an exponent, or a float type suffix are required. All other parts are optional. A floating-point literal is of type float if it is suffixed with an ASCII letter F or f; otherwise its type is double and it can optionally be suffixed with an ASCII letter D or d. FloatingPointLiteral: Digits . Digitsopt ExponentPartopt FloatTypeSuffixopt . Digits ExponentPartopt FloatTypeSuffixopt Digits ExponentPart FloatTypeSuffixopt Digits ExponentPartopt FloatTypeSuffix ExponentPart: ExponentIndicator SignedInteger ExponentIndicator: one of e E = end of cut === I think that's enough. As a result, I think, JSTL ignores (or the developers have missed this point) ExponentIndicator in floating point numbers. What do you think maybe it's worth to fix a mistake? -- 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: r1125656 - in /tomcat/jk/trunk/native/common: jk_ajp_common.c jk_ajp_common.h
Author: timw
Date: Sat May 21 10:00:54 2011
New Revision: 1125656
URL: http://svn.apache.org/viewvc?rev=1125656&view=rev
Log:
https://issues.apache.org/bugzilla/show_bug.cgi?id=41923
Propagate client abort to Tomcat by hard closing the AJP connection on an
client write error, which will abort the AJP response write.
Modified:
tomcat/jk/trunk/native/common/jk_ajp_common.c
tomcat/jk/trunk/native/common/jk_ajp_common.h
Modified: tomcat/jk/trunk/native/common/jk_ajp_common.c
URL:
http://svn.apache.org/viewvc/tomcat/jk/trunk/native/common/jk_ajp_common.c?rev=1125656&r1=1125655&r2=1125656&view=diff
==
--- tomcat/jk/trunk/native/common/jk_ajp_common.c (original)
+++ tomcat/jk/trunk/native/common/jk_ajp_common.c Sat May 21 10:00:54 2011
@@ -780,7 +780,15 @@ static void ajp_abort_endpoint(ajp_endpo
{
JK_TRACE_ENTER(l);
if (shutdown == JK_TRUE && IS_VALID_SOCKET(ae->sd)) {
-jk_shutdown_socket(ae->sd, l);
+if (ae->hard_close) {
+/* Force unclean connection close to communicate client write
errors
+ * back to Tomcat by aborting AJP response writes.
+ */
+jk_close_socket(ae->sd, l);
+}
+else {
+jk_shutdown_socket(ae->sd, l);
+}
}
ae->worker->s->connected--;
ae->sd = JK_INVALID_SOCKET;
@@ -2403,6 +2411,7 @@ static int JK_METHOD ajp_service(jk_endp
p->left_bytes_to_send = s->content_length;
p->reuse = JK_FALSE;
+p->hard_close = JK_FALSE;
s->secret = aw->secret;
@@ -2479,6 +2488,7 @@ static int JK_METHOD ajp_service(jk_endp
if (aw->recovery_opts & RECOVER_ABORT_IF_CLIENTERROR) {
/* Mark the endpoint for shutdown */
p->reuse = JK_FALSE;
+p->hard_close = JK_TRUE;
}
}
else if (err == JK_FATAL_ERROR) {
@@ -2514,6 +2524,7 @@ static int JK_METHOD ajp_service(jk_endp
if (aw->recovery_opts & RECOVER_ABORT_IF_CLIENTERROR) {
/* Mark the endpoint for shutdown */
p->reuse = JK_FALSE;
+p->hard_close = JK_TRUE;
}
}
else if (err == JK_CLIENT_WR_ERROR) {
@@ -2528,6 +2539,7 @@ static int JK_METHOD ajp_service(jk_endp
if (aw->recovery_opts & RECOVER_ABORT_IF_CLIENTERROR) {
/* Mark the endpoint for shutdown */
p->reuse = JK_FALSE;
+p->hard_close = JK_TRUE;
}
}
else if (err == JK_FATAL_ERROR) {
@@ -2720,6 +2732,7 @@ static int ajp_create_endpoint_cache(ajp
}
p->ep_cache[i]->sd = JK_INVALID_SOCKET;
p->ep_cache[i]->reuse = JK_FALSE;
+p->ep_cache[i]->hard_close = JK_FALSE;
p->ep_cache[i]->last_access = now;
jk_open_pool(&(p->ep_cache[i]->pool), p->ep_cache[i]->buf,
sizeof(p->ep_cache[i]->buf));
Modified: tomcat/jk/trunk/native/common/jk_ajp_common.h
URL:
http://svn.apache.org/viewvc/tomcat/jk/trunk/native/common/jk_ajp_common.h?rev=1125656&r1=1125655&r2=1125656&view=diff
==
--- tomcat/jk/trunk/native/common/jk_ajp_common.h (original)
+++ tomcat/jk/trunk/native/common/jk_ajp_common.h Sat May 21 10:00:54 2011
@@ -382,6 +382,10 @@ struct ajp_endpoint
jk_sock_t sd;
int reuse;
+/* Used with RECOVER_ABORT_IF_CLIENTERROR to hard abort
+ write of AJP response on client write errors */
+int hard_close;
+
jk_endpoint_t endpoint;
jk_uint64_t left_bytes_to_send;
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1125657 - /tomcat/jk/trunk/xdocs/miscellaneous/changelog.xml
Author: timw Date: Sat May 21 10:01:01 2011 New Revision: 1125657 URL: http://svn.apache.org/viewvc?rev=1125657&view=rev Log: Updating changelog to separate fix for 50839 from change to cap lingering byte reads. 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=1125657&r1=1125656&r2=1125657&view=diff == --- tomcat/jk/trunk/xdocs/miscellaneous/changelog.xml (original) +++ tomcat/jk/trunk/xdocs/miscellaneous/changelog.xml Sat May 21 10:01:01 2011 @@ -44,11 +44,17 @@ - -50839: Cap the lingering bytes that will be read + +AJP: Cap the lingering bytes that will be read when shutting down an AJP socket at 32k to prevent CPU spikes in the web server when a client aborts on a large response body. -Also reduce total linger time to 2s.(timw) +Also reduce total linger time to 2s. (timw) + + +50839AJP: Fix 30sec CPU spike due to incorrect counting +of lingering bytes causing a busy loop when a client aborts +connection during a response write. +Fixes regression in 1.2.31. (timw) Docs: Improve load balancer documentation. (rjung) - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1125658 - /tomcat/jk/trunk/xdocs/miscellaneous/changelog.xml
Author: timw Date: Sat May 21 10:01:08 2011 New Revision: 1125658 URL: http://svn.apache.org/viewvc?rev=1125658&view=rev Log: Changelog for 41923. 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=1125658&r1=1125657&r2=1125658&view=diff == --- tomcat/jk/trunk/xdocs/miscellaneous/changelog.xml (original) +++ tomcat/jk/trunk/xdocs/miscellaneous/changelog.xml Sat May 21 10:01:08 2011 @@ -44,6 +44,11 @@ + +41923AJP: Close AJP connection to Tomcat on client write +error when recovery_options 4 is specified, aborting the response +write on the Tomcat side. (timw) + AJP: Cap the lingering bytes that will be read when shutting down an AJP socket at 32k to prevent CPU spikes - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 41923] Tomcat doesnt recognized client abort
https://issues.apache.org/bugzilla/show_bug.cgi?id=41923 Tim Whittington changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Comment #6 from Tim Whittington 2011-05-21 10:02:33 UTC --- recovery_options 4 has for a long time explicitly flagged the AJP connection to be closed, although that's also the case for all other errors during a request/response cycle. The closing of the socket was of the form of a clean shutdown though, with the response stream from Tomcat -> mod_jk being drained while the socket was shut down. This meant that Tomcat never experienced a write error, even when the client aborted the connection to the proxying web server. In general, this is a limitation of the AJP protocol (there is no mod_jk -> Tomcat communication during the writing of a response, and so no way to feed back errors). I've made changes to hard close the AJP socket (without draining the response first) when recovery_options 4 is specified. This should propagate the write error back to the Tomcat side in most cases, but at the cost of a socket being left in TIME_WAIT each time. Without recovery_options 4 specified, the AJP socket will be cleanly shutdown - although the fixes to bug 50839 will mean the AJP socket will still be uncleanly closed if the response exceeds 32k. I wouldn't rely on catching client aborts on the Tomcat side for anything meaningful (even leaving aside the difficulty in distinguishing a client abort from any other IOException in the Java API), but at least the behaviour matches the documentation to some degree now. Anything more advanced would require an enhancement to the AJP protocol. This change will be 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
DO NOT REPLY [Bug 51235] Access Violation in httpd.exe originating in mod_jk code while getting sessionid from headers
https://issues.apache.org/bugzilla/show_bug.cgi?id=51235
--- Comment #7 from Rainer Jung 2011-05-21 12:47:12
UTC ---
Can you compile the module yourself?
If yes, it would be helpful if you could test the following patch:
Index: jk/native/common/jk_lb_worker.c
===
--- jk/native/common/jk_lb_worker.c (revision 1125686)
+++ jk/native/common/jk_lb_worker.c (working copy)
@@ -470,6 +470,9 @@
strcat(result, ";");
strncat(result, id_start, sz);
}
+if (!*id_end) {
+break;
+}
id_start = id_end;
}
}
The line numbers are for mod_jk 1.2.28, but the same patch applies to newer
versions with some offset.
Regards,
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 51235] Access Violation in httpd.exe originating in mod_jk code while getting sessionid from headers
https://issues.apache.org/bugzilla/show_bug.cgi?id=51235 Rainer Jung changed: What|Removed |Added Status|NEW |NEEDINFO -- 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 50839] Closing connection on the client side (browser) during unfinished transmission result in 100% CPU slike for 30 sec during socket shutdownd in jk_connect.c
https://issues.apache.org/bugzilla/show_bug.cgi?id=50839 --- Comment #11 from Serhiy 2011-05-21 18:53:12 UTC --- Tim, Issue was in the 1.2.31. You stated you've fixed that. Now I'm a little confused... Which version of the conector has fix? Thanks, Serhiy -- 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: r1125778 - /tomcat/trunk/TOMCAT-7-RELEASE-PLAN.txt
Author: markt Date: Sat May 21 19:49:42 2011 New Revision: 1125778 URL: http://svn.apache.org/viewvc?rev=1125778&view=rev Log: Remove out of date status file. Remainign todos are in bugzilla Removed: tomcat/trunk/TOMCAT-7-RELEASE-PLAN.txt - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1125780 - /tomcat/trunk/PROPOSALS.txt
Author: markt Date: Sat May 21 19:51:37 2011 New Revision: 1125780 URL: http://svn.apache.org/viewvc?rev=1125780&view=rev Log: Remove 6.1.x wish list If there is any interest in these, they can be added as enhancement requests in Bugzilla Removed: tomcat/trunk/PROPOSALS.txt - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
ClassNotFoundException for JSP files
Hi all, I'm running TomCat 6.0.26 on a Win2008 machine. I'm running three web-apps on a single instance. After a few hours of running, I start getting java.lang.ClassNotFoundException when trying to access certain JSP files. Other JSP files are accessible. I get this exception for pages on all three web-apps. I checked with jconsole, and their are really no JSP compiled classes in memory for the pages I try to access. After restarting TomCat, I manage to access these pages. Another thing to note is that one of my web-apps is writing a lot of logs to catalina - on purpose. Any ideas? is it a memory problem? I'm thinking of working with separate TomCat instances per web-app. Thanks
RE: ClassNotFoundException for JSP files
> From: Tom Wolf [mailto:tw...@hotmail.com] > Subject: ClassNotFoundException for JSP files > I'm running TomCat 6.0.26 on a Win2008 machine. This is not an appropriate topic for the developer's list. You already posted on the appropriate list earlier; have some patience - and learn how to spell Tomcat. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 46221] Leak WebappClassLoader with commons-logging and log4j
https://issues.apache.org/bugzilla/show_bug.cgi?id=46221 --- Comment #11 from Sylvain Laurent 2011-05-21 21:46:36 UTC --- I cannot reproduce the problem with tc 7.0.14 nor 6.0.29. Is it really worth fixing this in tc 5 ? -- 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 50839] Closing connection on the client side (browser) during unfinished transmission result in 100% CPU slike for 30 sec during socket shutdownd in jk_connect.c
https://issues.apache.org/bugzilla/show_bug.cgi?id=50839 --- Comment #12 from Tim Whittington 2011-05-21 22:48:42 UTC --- The fix for this issue and the change to cap the lingering bytes/time, will both be 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
Re: [PROPOSAL] Move to svnpubsub for /dist/tomcat
+1 On Thu, May 19, 2011 at 1:38 AM, Mark Thomas wrote: > All, > > We have the option to move to svnpubsub for managing our releases. > Rather than copying artefacts to people.a.o and then waiting for rsync > (every around 2 hours) we would commit the artefacts to svn and a commit > hook would update the /dist/tomcat area on the www servers immediately. > > If folks would like to go this route, I am happy to do the work on our > end to migrate /dist/tomcat to svnpubsub. > > 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
