Re: mod_jk 1.2.14.1 core dump
On 8/28/05, Jean-frederic Clere [EMAIL PROTECTED] wrote: David Rees wrote: I'm getting a core dump on my SGI IRIX machine using mod_jk 1.2.14.1 in jk_lb_worker.c line 605. The stack trace is below. This happens on any JK request I try. Going back to 1.2.11 works fine. Any ideas? When does it happend? It happens the first time I try a request which is mapped to a Tomcat instance. Instead of the page getting served up by Tomcat, I get a blank page. Tomcat is 5.5.9 if it matters. -Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
mod_jk 1.2.14.1 core dump
I'm getting a core dump on my SGI IRIX machine using mod_jk 1.2.14.1 in jk_lb_worker.c line 605. The stack trace is below. This happens on any JK request I try. Going back to 1.2.11 works fine. Any ideas? -Dave 0 service(e = 0x1035afe8, s = 0x7fff2b28, l = 0x10281f68, is_error = 0x7fff1af4) [/tmp/jakarta-tomcat-connectors-1.2.14.1-src/jk/native/common/jk_lb_worker.c:605, 0x4315080] 1 jk_handler(r = 0x103719a0) [/tmp/jakarta-tomcat-connectors-1.2.14.1-src/jk/native/apache-2.0/mod_jk.c:1889, 0x4305648] 2 ap_run_handler(r = 0x103719a0) [/tmp/httpd-2.0.54/server/config.c:152, 0x1008b624] 3 ap_invoke_handler(r = 0x103719a0) [/tmp/httpd-2.0.54/server/config.c:364, 0x1008c390] 4 ap_process_request(r = 0x103719a0) [/tmp/httpd-2.0.54/modules/http/http_request.c:249, 0x10071990] 5 ap_process_http_connection(c = 0x10365460) [/tmp/httpd-2.0.54/modules/http/http_core.c:251, 0x10070f78] 6 ap_run_process_connection(c = 0x10365460) [/tmp/httpd-2.0.54/server/connection.c:43, 0x100a3e94] 7 ap_process_connection(c = 0x10365460, csd = 0x10365378) [/tmp/httpd-2.0.54/server/connection.c:176, 0x100a4568] 8 child_main(child_num_arg = 0) [/tmp/httpd-2.0.54/server/mpm/prefork/prefork.c:610, 0x1007c444] 9 make_child(s = 0x102941c0, slot = 0) [/tmp/httpd-2.0.54/server/mpm/prefork/prefork.c:704, 0x1007c6ac] 10 startup_children(number_to_start = 5) [/tmp/httpd-2.0.54/server/mpm/prefork/prefork.c:722, 0x1007c75c] 11 ap_mpm_run(_pconf = 0x1025aac0, plog = 0x1028cb88, s = 0x102941c0) [/tmp/httpd-2.0.54/server/mpm/prefork/prefork.c:941, 0x1007cda0] 12 main(argc = 3, argv = 0x7fff2f44) [/tmp/httpd-2.0.54/server/main.c:618, 0x100b1c48] 13 __start() [/xlv55/kudzu-apr12/work/irix/lib/libc/libc_n32_M3/csu/crt1text.s:177, 0x1004b9e8] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: *SPAM* Session Affinity after Graceful Apache restart? [was Re: Adding working dynamically with mod_jk status?]
On 6/7/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Does anyone know (David, Mladen?) what will happen to session affinity is this situation? ie with Apache in front of several tomcats using mod_jk, when Apache is restarted gracefully using apache -k restart (Windows) will session affinity be preserved across the restart? ie will browsers with a session open with a particular Tomcat continue being directed to that particular Tomcat after the restart? Session affinity is determined by the suffix of the jsessionid cookie which is stored on the client, so yes, session affinity will be retained across Apache restarts (graceful or not). -Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Graceful restart on Windows [was Re: Adding working dynamically with mod_jk status?]
On 6/1/05, Bernard [EMAIL PROTECTED] wrote: I follow this sequence because mod_jk returns a server error if it cannot connect to Tomcat. To avoid this during Tomcat restarts, you need to have 2 Tomcat instances running and set them up with mod_jk to load balance across them. -Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Adding working dynamically with mod_jk status?
Yes, it should be possible on Windows as well. You may have to invoke apache.exe manually on that platform, I am not familiar with Apache on Windows. Apache docs or a google search should tell you more. -Dave On 5/31/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: That sounds perfectbut I've got to work on Windows too. Do you know if there's a way to do it on Win? On 5/25/05, [EMAIL PROTECTED] wrote: Is this still true if we were to define extra workers that are marked as disabled at startup? Could we then point them to any new servers as they are added and enable them without a restart? I know it's not very clean, but would it work? We'd *really* like to find a way around having to force a restart. Have you seen if a graceful restart of Apache works for you? Graceful restarts of Apache have worked for me in the past to add new workers without dropping requests. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Graceful restart on Windows [was Re: Adding working dynamically with mod_jk status?]
On 5/31/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: After some more digging, it *appears* that apache -k restart WILL do a graceful restart of Apache2 on Windoze. Can anyone confirm this please? And are there any gotcha's to watch out for? Can someone explain exactly how this works? eg if I am in the middle of a chunk (or series) of work with a web browser and one of the tomcats, will it restart in the middle of that? On Unix, it will let any running threads/processes finish processing any existing requests before killing them. Replacment threads/processes will be started up to take all new requests from that point on. Best to test it to make sure, I have not tested it personally on Windows or any other threaded Apache MPM. -Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Adding working dynamically with mod_jk status?
On 5/25/05, [EMAIL PROTECTED] wrote: Is this still true if we were to define extra workers that are marked as disabled at startup? Could we then point them to any new servers as they are added and enable them without a restart? I know it's not very clean, but would it work? We'd *really* like to find a way around having to force a restart. Have you seen if a graceful restart of Apache works for you? Graceful restarts of Apache have worked for me in the past to add new workers without dropping requests. -Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANN] Jakarta Tomcat Connectors 1.2.7-beta-2 released
Looks like more bad newlines were added to jk/native/apache-2.0/mod_jk.c in this release. -Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Newline Patch for JTC 1.2.7-beta
I had a few problems compiling on SGI as it's compiler doesn't like the mix of windows/unix style line feeds present in a couple files. Not sure if they'll show up in this patch, but at least the patch will show where the windows style newlines are. -Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Question about new mod_jk jk_lb_worker.c
Rainer Jung wrote, On 11/16/2004 1:11 AM: Unfortunately I don't understand. Trying to combine rotatelogs with mod_jk.log in the following way (apache 1.3): Doh. I've been using Apache 2 for so long I forgot that it doesn't work with Apache 1.3. It does work using Apache 2 / mod_jk. -Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Question about new mod_jk jk_lb_worker.c
Rainer Jung wrote, On 11/14/2004 7:31 AM: 0) Any ideas on rotating the mod_jk log file? Use cronolog http://cronolog.org/ or the rotatelogs program included with Apache. -Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/native/common jk_ajp13_worker.c
[EMAIL PROTECTED] wrote, On 11/10/2004 7:24 AM:
mturk 2004/11/10 07:24:17
Modified:jk/native/common jk_ajp13_worker.c
Log:
Use new TRACE/DEBUG logging.
Also skip checking for memory allocation.
If we can not allocate enough memory it's better to core dump
then try to continue. At some point we'll core dump anyhow, so
why waste CPU cycles on things that are unrecoverable?
--- jk_ajp13_worker.c 8 Oct 2004 07:50:39 - 1.15
+++ jk_ajp13_worker.c 10 Nov 2004 15:24:17 - 1.16
@@ -74,11 +75,17 @@
aw-name = strdup(name);
+ /* Lets core dump for every malloc.
+ If we can not allocate few bytes what's the purpose
+ to keep anyhow and waste cpr cycles
+ */
+#if 0
if (!aw-name) {
free(aw);
jk_log(l, JK_LOG_ERROR, In ajp13_worker_factory, malloc
failed\n);
return JK_FALSE;
}
+#endif
aw-proto = AJP13_PROTO;
aw-login = NULL;
Are you sure it's a good idea to wait until it crashes rather than fail
in a controlled method? How much overhead is there to check aw-name
for NULL? Can't be much...
-Dave
Revision ChangesPath
1.16 +13 -3 jakarta-tomcat-connectors/jk/native/common/jk_ajp13_worker.c
Index: jk_ajp13_worker.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_ajp13_worker.c,v
retrieving revision 1.15
retrieving revision 1.16
diff -u -r1.15 -r1.16
--- jk_ajp13_worker.c 8 Oct 2004 07:50:39 - 1.15
+++ jk_ajp13_worker.c 10 Nov 2004 15:24:17 - 1.16
@@ -59,8 +59,9 @@
{
ajp_worker_t *aw = (ajp_worker_t *) malloc(sizeof(ajp_worker_t));
-jk_log(l, JK_LOG_DEBUG, Into ajp13_worker_factory\n);
-
+#ifdef JK_TRACE
+jk_log(l, JK_LOG_TRACE, enter ajp13_worker_factory\n);
+#endif
if (name == NULL || w == NULL) {
jk_log(l, JK_LOG_ERROR, In ajp13_worker_factory, NULL parameters\n);
return JK_FALSE;
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Dates for 5.0.29 and 5.5.2
Shapira, Yoav wrote, On 9/9/2004 5:46 AM: Take a look at the changelog in CVS. Thanks, found the changelog here in CVS in case anyone else wants to look as well, took me a while to find it: http://cvs.apache.org/viewcvs.cgi/jakarta-tomcat-catalina/webapps/docs/changelog.xml?sortby=dateonly_with_tag=TOMCAT_5_0 -Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Dates for 5.0.29 and 5.5.2
Shapira, Yoav wrote: We don't need 5.0.29 already. But it's had a number of small bug fixes and enhancements over 5.0.28. We can wait longer -- this is why I asked What bugs and enhancements have been made since 5.0.28? -Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Hi!
Shapira, Yoav wrote, On 8/31/2004 11:34 AM: Welcome ;) The web site shows latest stable version, and 5.0.28 has yet to be voted as such. Shouldn't the release notes in the email announcement say that explicity in the subject? IIRC, previous releases happenned that way... http://marc.theaimsgroup.com/?l=tomcat-devm=108756354217665w=2 Would have prevented this confusion. In fact, I first thought that 5.0.28 was stable, I didn't even see the last paragraph saying that voting on the stability of the release would happen in another week. -Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Where's 4.1.31?
Jeanfrancois Arcand wrote, On 8/20/2004 9:45 AM: Althrough I agree with peoples that can't move to Tomcat 5, Tomcat 5 has been available for more that 1 year. That will be good for Tomcat if people migrate from 4.1.x to 5 and find bugs (that way they will not be carried into 5.5/6). Although I would love to upgrade all of my sites to Tomcat 5, unfortunately there is one particular showstopper for me in the behavior difference between Tomcat 4 and 5. Specifically, it is the fact that TC5 no longer pauses request processing during a context reload while TC4 does. While this behavior could be worked around with load-balanced Tomcats, until mod_jk (or the Apache proxy module improvements) support dynamic reconfiguration, having to make a class change during operations can be disruptive. Currently, if you wish to disable a Tomcat using mod_jk, you have to at least have Apache gracefully restart, which is not always very graceful. IMO, if there are enough commiters willing to make/support another 4.1 release, let them! -Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Fwd: Re: Some benchs results : WAS: Invitation to HTTPD commiters in tomcat-dev]
Remy Maucherat wrote, On 7/28/2004 7:54 AM: One thing I noticed when looking at Tomcat 5.0.x is that its default, static-file-delivering servlet does a stat(2) of each path prefix leading up to the file. A standard installation of Apache 2.x, with FollowSymlinks enabled, doesn't do these stat calls, for obvious performance reasons. Is the stat'ing of all the directories leading up to the requested file in Tomcat intentional (it *is* valuable in some environments for security purposes), or is it just a side-effect of the implementation? I really have no idea what this stuff means. stat is a Unix system call which retrives the status information of a file or directory. Each stat call can potentially hit the disk, so this can be a very expensive system call to make if you have deep directory trees and could explain some of the performance differences between Apache and Tomcat. -Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Simple Sticky LB WAS: Invitation to HTTPD commiters in tomcat-dev
Remy Maucherat wrote, On 7/21/2004 11:33 PM: The changes would have to be simple, and non intrusive performance wise. Otherwise, I'm going to prefer AJP ;) Speaking about performance, did anyone do a comparison of mod_proxy against mod_jk to see how good/bad it is ? This is really important information IMO, and I don't see how a decision can be made without it. I did a couple quick tests using a few different sized static documents using ab, Tomcat 5.0.27, Apache 2.0.50 both on the same single CPU machine. Depending on the document size, mod_proxy was anywhere from 50% (very small document of a few bytes) to 10% (30k document) slower than mod_jk. By comparison, going directly to Tomcat about twice as fast as using mod_jk, and going directly to Apache is another 30% faster than that. Watching CPU utilization when switching between mod_jk and mod_proxy showed that Tomcat uses a lot more CPU when using mod_proxy than when using mod_jk. So while the performance hit isn't negligible, it's not too bad. It does show that it will be worthwhile to a proxy_ajp_module, but at the same time I think that using plain http provides more than enough performance for the majority of users out there, and you can't argue with the fact that the work will benefit a lot more than just Tomcat and lessen development time. I could see people using the proposed load-balancing functionality along with mod_proxy to balance requests to clusters of many other application servers (PHP, perl, CGI, etc) as well. -Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Some JK2 ideas v.2
[EMAIL PROTECTED] wrote: There is a learning cliff with mod_jk2 that many I feel try to climb, and don't make it. They then tomcat gives them a bad taste. KISS - the easier it is to do a simple config (and at the same time have flexibility to do a complicated one) the better. That is the reason I have stuck with mod_jk instead of moving to mod_jk2, a quick look at the mod_jk2 docs makes my eyes glaze over, and mod_jk works just fine for my usage... -Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Some JK2 ideas
Henri Gomez wrote: My idea is about a new module, only Apache 2.x for now, which will make use of SetEnv, SetEnvIf, BrowserMath and Location directives to redirect some URLs to tomcats via AJP. This sounds like a great idea. It would be easy to configure, and I would love to be able to completely configure the connector in the httpd.conf instead of having to use a seperate properties file for the connector. -Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk 1.0.26 release ?
nyhgan wrote: Tomcat 3.3.2 and jk1.2.5 is what I am using now and it runs fine. The problem described emails below only occurs if you use jk1.2.x with Tomcat 5.x (or 4.x). And because of this reasonI can't upgrade my Tomcat to Tomcat5.x. This sounds like more of a problem in your application or in TC 4 or 5 which your application triggers than a connector bug to me... What do the Tomcat logs say? Does restarting Apache fix the problem, or does restarting Tomcat fix the problem? -Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Time for JkMountExclude in jk 1.2.x ?
Henri Gomez wrote, On 7/13/2004 3:27 AM: What about adding support for JkMountExclude : I would suggest leaving it for the next release of mod_jk, unless it is simple and there is little chance of it adding any regressions. -Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ready for mod_jk 1.2.6 release?
Rainer Jung wrote: the last release of mod_jk 1.2.x (1.2.5) is more than 9 months old. Since then there have been important improvements (CPing/CPong and recovery_options). Especially recovery_options is very useful in transparent administration (start/stop) of cluster nodes. I would like to see one. I am already using CVS to get the new features and bug fixes, but an official release would be nice. -Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.next] Progress
Remy Maucherat wrote, On 7/2/2004 2:13 AM: Jeanfrancois Arcand wrote: Remy Maucherat wrote: Speaking of which, does anyone know any OSes (besides Windows) which lock files ? NFS sometimes lock file (I did see a similar problem with Solaris) Thanks for the tip. I'll code in Windows by default, and add a flag to enable/disable then, since I don't think there's a way to determine if something is coming from NFS. Although you can lock files over NFS on Unix systems, it should behave no differently than if you were to lock the file on any other filesystem. In other words, unless you explicitly lock the file and check that the file is locked (as locks are only advisory on Unix, they don't stop you from performing any operations if you really want to) you should not have any of the same file locking issues on Unix that you do on Windows. See the the flock and fcntl man pages for more information on Unix file locking. -Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Movie
Remy Maucherat wrote: I'm going to unsubscribe Gal from tomcat-dev for now, since a lot of spam is coming through this old email. Subscribe again if you'd like to be on the list (but with a slightly different email so we don't get the spam ;) ). (Apache really needs to add competent spam filtering ...) Getting mail servers to start using something like SPF (http://spf.pobox.com/) would go a long ways to keeping all these forged emails with viruses from being spread around. Seems like large mailing lists would be a great candidate for running SPF checks on incoming email. -Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: XXX Funny movie
Shapira, Yoav wrote: I've put [EMAIL PROTECTED] on the deny list for tomcat-dev, so no more messages from that address should get through. I've also emailed [EMAIL PROTECTED] to let him know of this and ask him to contact us after cleaning up his computer. It looks to me that the headers of the email are forged, so I doubt that [EMAIL PROTECTED] is the one actually sending the emails. -Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: XXX Funny movie
Shapira, Yoav wrote: It looks to me that the headers of the email are forged, so I doubt that [EMAIL PROTECTED] is the one actually sending the emails. You're most likely right, but I looked through the headers, couldn't find anything else, and so went ahead. It seems OK so far. Yeah, at least it got the SPAM to stop coming through. :-) -Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Losing line numbers in stracktraces
Hans Verschoor wrote: I have a problem reading stacktrace info when Tomcat throws an exception caused by a servlet or a class calld by a servlet I have my classes compiled into in the . WEB-INF/classes directory and (so far) I use no war or jar. When an exception is thrown the stacktrace does not show line numbers but Unknown source, which is not so handy. The classes are compiled correctly, in other circumstances the line numbers DO appear in stacktraces using the same classes. I am a relative newbie, so my questions are: 1. Do I need to configure the webapploader explicitly ? 2. Do I need some switch on de java statement when starting tomcat ? Make sure you compile your classes with the -g flag to javac. Otherwise, line numbers will be optimized out. -Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Returned mail: Delivery Failed
Shapira, Yoav wrote: I wouldn't call the current situation as moderated so much as managed. Is there a reason that the developers list allows posting from non-subscribers? Or are these troubled addresses actually fully subscribed? All these addresses are fully subscribed (i.e. they responded to the subscription confirmation message). Only subscribed addresses may post here. Note that most of these auto-responders are brain-dead enough that anyone can unsubscribe them by sending a blank message to the following addresses: [EMAIL PROTECTED] Replace tomcat-dev with tomcat-user for auto-responders spamming that list. Unfortunately, as easy as it is to unsubscribe these addresses, they can become subscribed again so they need to be blacklisted. Yoav, you currently handle blacklisting of these addresses, correct? -Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk 1.2.6 and hung tomcat
Mike Charnoky wrote: Is there a concise reference for this problem? It is intrinsically a tomcat issue or is it a problem with a badly behaved app? How can I determine what is causing the hang? Is there something in the archives that I am completely missing? In my case, Tomcat hangs were caused by JVM problems and not related to Tomcat itself. This and badly behaved apps causing OOM conditions are probably the most common failure modes. The new code in the JK connectors allow mod_jk to ping Tomcat with a short timeout before sending a request there to determine if Tomcat is alive or not. This is useful when you have multiple Tomcats running, not quite as useful if you only have one Tomcat running but will keep Apache processes from waiting around forever for a response from a hung Tomcat. Also: Any news on when mod_jk 1.2.6 will be available? Are the new config parameters merely a band-aid or a real solution? Last I heard, the next release of mod_jk will be worked on after the JK developers have released the next version of mod_jk2. This should happen in the next few weeks. It is a real solution, not a band-aid. -Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: jk2 buglets II
[EMAIL PROTECTED] wrote: This seemed to be an issue with tomcat 4.1.24. Using 4.1.29 resolves this issue. Thanks for the pointers, especially the one to open my eyes and check which tomcat version I was using. While you're at it, you should upgrade to 4.1.30 which fixes some memory leaks and other minor issues which could crop up as well. -Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jk2 buglets II
[EMAIL PROTECTED] wrote, On 2/23/2004 8:37 AM: We seem to have another buglet with mod_jk2 2.0.2. We seem to be unable to recreate the bug using ab, but when one of our busiest servers has been running for a few hours we get apache children stuck (at times upto 100 children are blocked, which is how we found the issue as the server appeared slow). Does restarting the Tomcat instance free up the stuck processes? -Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: jk2 buglets II
On Mon, February 23, 2004 1at 0:28 am, [EMAIL PROTECTED] wrote: Does restarting the Tomcat instance free up the stuck processes? Yup. Apache seems to recover fine, as the socket gets reset. OK, can you figure out what Tomcat is doing when these processes get stuck? It seems that you may have some threads hanging up in Tomcat. Apache will wait forever for a response from Tomcat, or until the connection is broken. -Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/native/common jk_ajp_common.c
Umm, tab police? ;-) -Dave [EMAIL PROTECTED] wrote, On 2/17/2004 2:38 AM: hgomez 2004/02/17 02:38:25 Modified:jk/native/common jk_ajp_common.c - /* communication with tomcat has been interrupted AFTER - * headers have been sent to the client. - * headers (and maybe parts of the body) have already been - * sent, therefore the response is complete in a sense - * that nobody should append any data, especially no 500 error - * page of the webserver! - * - * BUT if you retrun JK_TRUE you have a 200 (OK) code in your - * in your apache access.log instead of a 500 (Error). - * Therefore return FALSE/FALSE - * return JK_TRUE; - */ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/native/common jk_ajp_common.c
Attached is a patch which cleans it up.
-Dave
David Rees wrote, On 2/17/2004 8:28 AM:
Umm, tab police? ;-)
-Dave
[EMAIL PROTECTED] wrote, On 2/17/2004 2:38 AM:
hgomez 2004/02/17 02:38:25
Modified:jk/native/common jk_ajp_common.c
- /* communication with tomcat has been interrupted
AFTER - * headers have been sent to the client.
- * headers (and maybe parts of the body) have
already been
- * sent, therefore the response is complete in
a sense
- * that nobody should append any data, especially
no 500 error - * page of the webserver!
- *
- * BUT if you retrun JK_TRUE you have a 200 (OK)
code in your
- * in your apache access.log instead of a 500
(Error). - * Therefore return FALSE/FALSE
- * return JK_TRUE; - */
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--- jk_ajp_common.c.orig2004-02-17 08:29:48.741514459 -0800
+++ jk_ajp_common.c 2004-02-17 08:33:47.518132894 -0800
@@ -658,28 +658,28 @@
inttimeout,
jk_logger_t *l)
{
- fd_set rset;
- fd_set eset;
- struct timeval tv;
- int rc;
-
- FD_ZERO(rset);
- FD_ZERO(eset);
- FD_SET(ae-sd, rset);
- FD_SET(ae-sd, eset);
+fd_set rset;
+fd_set eset;
+struct timeval tv;
+int rc;
+
+FD_ZERO(rset);
+FD_ZERO(eset);
+FD_SET(ae-sd, rset);
+FD_SET(ae-sd, eset);
- tv.tv_sec = timeout / 1000;
- tv.tv_usec = (timeout % 1000) * 1000;
+tv.tv_sec = timeout / 1000;
+tv.tv_usec = (timeout % 1000) * 1000;
- rc = select(ae-sd + 1, rset, NULL, eset, tv);
+rc = select(ae-sd + 1, rset, NULL, eset, tv);
if ((rc 1) || (FD_ISSET(ae-sd, eset)))
- {
- jk_log(l, JK_LOG_ERROR, Error ajp13:is_input_event: error during
select [%d]\n, rc);
- return JK_FALSE;
- }
-
- return ((FD_ISSET(ae-sd, rset)) ? JK_TRUE : JK_FALSE) ;
+{
+jk_log(l, JK_LOG_ERROR, Error ajp13:is_input_event: error during select
[%d]\n, rc);
+return JK_FALSE;
+}
+
+return ((FD_ISSET(ae-sd, rset)) ? JK_TRUE : JK_FALSE) ;
}
@@ -687,46 +687,46 @@
* Handle the CPING/CPONG initial query
*/
int ajp_handle_cping_cpong(ajp_endpoint_t *ae,
- int timeout,
+ inttimeout,
jk_logger_t*l)
{
- int cmd;
- jk_msg_buf_t * msg;
+intcmd;
+jk_msg_buf_t * msg;
+
+msg = jk_b_new(ae-pool);
+jk_b_set_buffer_size(msg, 16);/* 16 is way too large but I'm lazy :-) */
+jk_b_reset(msg);
+jk_b_append_byte(msg, AJP13_CPING_REQUEST);
- msg = jk_b_new(ae-pool);
- jk_b_set_buffer_size(msg, 16); /* 16 is way too large but I'm lazy :-) */
- jk_b_reset(msg);
- jk_b_append_byte(msg, AJP13_CPING_REQUEST);
-
- /* Send CPing query */
- if (ajp_connection_tcp_send_message(ae, msg, l) != JK_TRUE)
- {
- jk_log(l, JK_LOG_ERROR, Error ajp13:cping: can't send cping query\n);
- return JK_FALSE;
- }
-
- /* wait for Pong reply for timeout milliseconds
-*/
- if (ajp_is_input_event(ae, timeout, l) == JK_FALSE)
- {
- jk_log(l, JK_LOG_ERROR, Error ajp13:cping: timeout in reply pong\n);
- return JK_FALSE;
- }
-
- /* Read and check for Pong reply
-*/
- if (ajp_connection_tcp_get_message(ae, msg, l) != JK_TRUE)
- {
- jk_log(l, JK_LOG_ERROR, Error ajp13:cping: awaited reply cpong, not
received\n);
- return JK_FALSE;
- }
-
- if ((cmd = jk_b_get_byte(msg)) != AJP13_CPONG_REPLY) {
- jk_log(l, JK_LOG_ERROR, Error ajp13:cping: awaited reply cpong,
received %d instead\n, cmd);
- return JK_FALSE;
- }
+/* Send CPing query */
+if (ajp_connection_tcp_send_message(ae, msg, l) != JK_TRUE)
+{
+jk_log(l, JK_LOG_ERROR, Error ajp13:cping: can't send cping query\n);
+return JK_FALSE;
+}
+
+/* wait for Pong reply for timeout milliseconds
+ */
+if (ajp_is_input_event(ae, timeout, l) == JK_FALSE)
+{
+jk_log(l, JK_LOG_ERROR, Error ajp13:cping: timeout in reply pong\n);
+return JK_FALSE;
+}
+
+/* Read and check for Pong reply
+ */
+if (ajp_connection_tcp_get_message(ae, msg, l) != JK_TRUE)
+{
+jk_log(l, JK_LOG_ERROR
Re: cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_vm_default.c
Henri, If you want to use shorter lines, you can wrap long lines and still compile. For example (in case my patch gets stripped): printf(This is a ) very long line.\n); -Dave [EMAIL PROTECTED] wrote, On 2/13/2004 12:46 AM: hgomez 2004/02/13 00:46:37 Modified:jk/native2/common jk_vm_default.c Log: Make line longer but GCC more happy with it :) Revision ChangesPath 1.31 +2 -4 jakarta-tomcat-connectors/jk/native2/common/jk_vm_default.c Index: jk_vm_default.c === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_vm_default.c,v retrieving revision 1.30 retrieving revision 1.31 diff -u -r1.30 -r1.31 --- jk_vm_default.c 30 Oct 2003 20:08:36 - 1.30 +++ jk_vm_default.c 13 Feb 2004 08:46:37 - 1.31 @@ -438,14 +438,12 @@ token = strtok(NULL, PATH_SEPARATOR_STR); } env-l-jkLog(env, env-l, JK_LOG_INFO, - jni.guessJvmDll() could not find %s in the \ - LD_LIBRARY_PATH\n, + jni.guessJvmDll() could not find %s in the LD_LIBRARY_PATH\n, jvm); return NULL; } env-l-jkLog(env, env-l, JK_LOG_INFO, - jni.guessJvmDll() LD_LIBRARY_PATH \ - environment var is not set\n); + jni.guessJvmDll() LD_LIBRARY_PATH environment var is not set\n); return NULL; #else return jvm; --- jk_vm_default.c 2004-02-13 01:11:35.030758871 -0800 +++ jk_vm_default.c.orig2004-02-13 01:11:56.446292854 -0800 @@ -438,14 +438,12 @@ token = strtok(NULL, PATH_SEPARATOR_STR); } env-l-jkLog(env, env-l, JK_LOG_INFO, - jni.guessJvmDll() could not find %s in the - LD_LIBRARY_PATH\n, + jni.guessJvmDll() could not find %s in the LD_LIBRARY_PATH\n, jvm); return NULL; } env-l-jkLog(env, env-l, JK_LOG_INFO, - jni.guessJvmDll() LD_LIBRARY_PATH - environment var is not set\n); + jni.guessJvmDll() LD_LIBRARY_PATH environment var is not set\n); return NULL; #else return jvm; - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_vm_default.c
David Rees wrote, On 2/13/2004 1:14 AM: If you want to use shorter lines, you can wrap long lines and still compile. For example (in case my patch gets stripped): printf(This is a ) very long line.\n); Oops, my patch was reversed. Here's a good one. -Dave --- jk_vm_default.c.orig2004-02-13 01:11:56.446292854 -0800 +++ jk_vm_default.c 2004-02-13 01:11:35.030758871 -0800 @@ -438,12 +438,14 @@ token = strtok(NULL, PATH_SEPARATOR_STR); } env-l-jkLog(env, env-l, JK_LOG_INFO, - jni.guessJvmDll() could not find %s in the LD_LIBRARY_PATH\n, + jni.guessJvmDll() could not find %s in the + LD_LIBRARY_PATH\n, jvm); return NULL; } env-l-jkLog(env, env-l, JK_LOG_INFO, - jni.guessJvmDll() LD_LIBRARY_PATH environment var is not set\n); + jni.guessJvmDll() LD_LIBRARY_PATH + environment var is not set\n); return NULL; #else return jvm; - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_vm_default.c
Henri Gomez wrote, On 2/13/2004 3:08 AM: Are you sure it will works on non gcc compiler ? I'd like to see Jean-Frederic opinion :) (exotic os/hardware) Does not look like it does, but at least now you'll know that if you're writing gcc specific code you can do it. ;-) The only non-gcc compiler I have access to is SGI's MIPSpro 7.2.1 where it does work there. Too bad not all compilers support it, it can make code a lot more readable. -Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-4.0 RELEASE-NOTES-4.1.txt
[EMAIL PROTECTED] wrote, On 1/25/2004 5:16 AM: RCS file: /home/cvs/jakarta-tomcat-4.0/RELEASE-NOTES-4.1.txt,v retrieving revision 1.81 retrieving revision 1.82 diff -u -r1.81 -r1.82 @@ -1066,6 +1105,8 @@ [4.1.27] #21984 HandlerReqest: Fix potential Dos condition when given a mal-formed URI. + +[4.1.20] Upgrade to Connectors from Tomcat 5.0.18. I think you meant 4.1.30 here, not 20. ;) -Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Mod_Jk2 Enhancement - Bugzilla Option?
NormW wrote, On 1/17/2004 12:27 PM: Good morning Developers. Recent testing of mod_jk2 status pages revealed the information was being returned to the client in about 42 byte chunks on a LAN that supports 1500 byte packets. I would like to submit a request for the chunk size to be increased or adapted automatically (via apr?) but the Bugzilla database doesn't have provision for the jk modules, only Tomcat versions. Any recommendation please? Use the Native:JK component for your bug report. -Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
TC 5.0.17: Relative context path no longer works
In previous versions of Tomcat, I've used a relative context path like this to setup the manager webapp: Context path=/manager docBase=../server/webapps/manager debug=0 privileged=true/ If I use the absolute path to the manager directory everything is OK. I couldn't find any mention of this in the changelog. However, this no longer works in 5.0.17 and I get a ClassNotFoundException. I can provide stack traces if it would help. The exact same config works fine in 5.0.16. BTW, someone needs to add 5.0.17 as a Tomcat Version to bugzilla. -Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: TC 5.0.17: Relative context path no longer works
On Wed, January 14, 2004 at 4:29 pm, Remy Maucherat wrote: David Rees wrote: In previous versions of Tomcat, I've used a relative context path like this to setup the manager webapp: Context path=/manager docBase=../server/webapps/manager debug=0 privileged=true/ This works for me. Yeah, yeah, but I recommend you don't file a bug about this unless you are really sure about it (and please give detailed examples). OK, some more details: Running RH 7.3 with JDK 1.4.2_03-b02. What OS do you develop on? I'll try windows. I'll strip down my config and do more testing... -Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: TC 5.0.17: Relative context path no longer works
On Wed, January 14, 2004 at 4:52 pm, David Rees wrote: Running RH 7.3 with JDK 1.4.2_03-b02. What OS do you develop on? I'll try windows. I'll strip down my config and do more testing... Just tested on Windows XP, and JDK 1.4.2_03-b02 where it works with the relative path. I also tested on Fedora Core 1 (same JDK as RH7.3) and IRIX with JDK 1.4.1_02 which all failed with the same ClassNotFoundException. So it appears to be a Unix specific issue and I think I've figured out why it fails. I re-tar the tarball and move a number of files out of the way to make it easier for me to deploy on my servers. This time, I moved the TC/webapps dir out of the way as usual, but forgot to recreate it. So the appBase for my Host/ was invalid. It is interesting that going to /manager/ resulted in TC displaying the proper directory index but couldn't load the manager servlets, didn't warn me that the appBase was missing, and for some reason worked on Windows. -Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: TC 5.0.17: Relative context path no longer works
On Wed, January 14, 2004 at 4:56 pm, Remy Maucherat wrote: I'll strip down my config and do more testing... I don't see the point: this should be trivial. Either the manager webapp works or it doesn't. It seems to me like it does ;-) Yeah, it works, and I did something dumb that I don't usually do. However, the bug seems to be that the Host doesn't check the appBase dir to see if it exists and complain loudly if it doesn't (as noted in my other email). -Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 5.next + 4.1.x future
Costin Manolache wrote: Jan-Henrik Haukeland wrote: Remy Maucherat [EMAIL PROTECTED] writes: My opinion is that NIO is going to be really useless. Eh, hello!? Oh, okay if it's not important that Tomcat scale and perform well it may be useless. But, really, before NIO it was hopeless to try and write a scalable and fast tcp server application in Java. Tomcat's current connection handling with blocing all over the place and thundering herd problem doesn't scale or work very well under heavy load. Only thing you can save is the static servlet - but for that you are better off using a real server or a cache. But as Remy mentioned: Static content is handled with a regular (well, almost) servlet, and all those requests have to go through the filter pipeline (ie, user components). This is the exact same problem when having Apache serve static files. So unless you break the spec, you still will need to spawn a thread to process static content through the filter pipeline. If that happens to be OK for your application, then you are right, better to use a real server or cache in front of your application (like Squid www.squid-cache.org). -Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 5.next + 4.1.x future
On Fri, December 12, 2003 at 2:12 pm, Adam Fisk wrote: I'd be happy to send my data to the group if people are interested. Aside from memory, I was surprised to find that the effect on CPU was negligible (not much of a benefit from no context-switching between threads) -- CPU was virtually the same in both cases. So, the scaling benefits on Windows basically come from not having to allocate more memory to new threads. I'm unfortunately not as familiar with the Tomcat code as I'd like to be, but I assume it makes intelligent use of thread pooling, which may even the memory benefits of NIO negligible. At the same time, though, NIO may remove some of the constraints introduced by thread pooling, possibly allowing Tomcat to handle heavier loads without blowing up. An optimized NIO server would if anything out-perform a blocking server, but maybe by not that much. On current Linux systems, once you start getting 500+ processes/threads active on a typical machine, you will find that context switching starts taking up a significant amount of system time, especially if you decide to run any system moniting tools (like ps, or top). This is better with the upcoming 2.6 kernels, but still doesn't scale to thousands of active threads very well. However, given that you need a thread anyway to server any dynamic content, I don't see NIO helping that much for your typical web application. I could see NIO helping scale the serving of static content which would be useful where people are using Tomcat standalone. Maybe someone can prove me wrong. ;-) -Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 5.0.X Benchmarks Was: [VOTE] New builds
On Wed, October 29, 2003 1at 1:41 am, Mladen Turk wrote: AFAICT the 5.0.14 is production quality version, much more stable and faster, at least for the applications I'm using. Just upgraded the application (ESRI ArcIMS) from IIS/Jrun to Tomcat 5.0.14, and it's lot faster. I'll post some benchmarks if anyone interested. I'd love to see some benchmarks. I'll have to try TC 5.0.X with some of my applications to see if it improves performance over 4.1.X for me as well. -Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: New builds ?
On Fri, October 24, 2003 1at 1:27 am, Remy Maucherat wrote: Remy Maucherat wrote: OTOH, there has been a few useful fixes and tweaks since 5.0.13 in the 5.0 branch, so I'll tag a new 5.0.14 at the end of the week (these .13 builds are all cursed :-D). Ok, tomorrow or Sunday :) (I've been a bit sick this week, so I'm slow) Any word? ;-) -Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: New builds ?
Remy Maucherat wrote: So, what do we do with 4.1.28 ? AFAIK, no significant issue has been found with this build, with minor tweaks being made since then in the connectors. Is a 4.1.29 needed, or is it simply people forgot about that build ? Comments ? I've been using 4.1.29 for development without any issues for a few days now. Just one minor annoyance, I get this message twice when starting Tomcat up: CoyoteConnector Coyote can't register jmx for protocol Now that new versions of commons dbcp and pool have been released, upgrading to the latest may be a good idea and an excuse to retag 4.1.30. I don't think you'll get many testers until it's called beta, though. Other than that, looks good! -Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: New builds ?
Remy Maucherat wrote: David Rees wrote: I've been using 4.1.29 for development without any issues for a few days now. Just one minor annoyance, I get this message twice when starting Tomcat up: CoyoteConnector Coyote can't register jmx for protocol Very good point. I'll tag new 4.1.30 and 5.0.14 builds tomorrow. Hopefully more people will vote next time :) Anyone have any idea on what's causing that message from Coyote to end up in the cataline log file? -Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Restart automatically Tomcat
On Mon, October 6, 2003 at 2:41 am, Slimane Amar sent the following I'm using Tomcat 4.1.24 et i want after it fails it restarts automatically to have a high availability. Is it possible with only Tomcat ? If using Unix, check out these tools: http://cr.yp.to/daemontools.html Specifically, look at the svscan and supervise tools. I use these tools to manage all my Tomcat instances as well as a lot of other applications. -Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [next] What's next ?
On Thu, October 2, 2003 at 8:56 am, Shapira, Yoav sent the following 3. Provide a complete working configuration example for a cluster of tomcat servers with a front-end tomcat as well, i.e. a pure tomcat-only solution. We already have the jvmRoute mechanism, but I think it needs more examples/documentation so that people start using it. So you want to do a HTTP load balancer ? I think this would be a really good project for the commons. I had something even simpler in mind: - A cluster of backend tomcat servers - A single tomcat front-end server, with one filter mapped to /* that has configurable rules on how to direct requests to the backend servers. (e.g. string match in URL rules, remote address rules, etc.) But as someone mentioned, I also think an HTTP load-balancer was discussed as a future version of ajp1[3-4]. I should search the archives for those threads. Going a bit further with what you said, it seems that all that is required is a load balancing filter and some documentation written to support it. The load balancing filter itself should probably go into the commons project as it should would work with any servlet container. -Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [next] What's next ?
On Thu, October 2, 2003 1at 0:33 am, Filip Hanik sent the following - Java or native load balancer, with session affinity support. This could be the perfect commons project, and is not really related to Tomcat After looking into it, writing a load balancer in Java will only cause the load balancer to become a bottleneck nothing else, Java doesn't offer enough low level to be able to do TCP load balancing well. Well, the typical bottleneck in a dynamic application isn't TCP bandwidth/connections, but the CPU power required to process requests. I think a TCP load balancer would be useful for a large number of people, but may not belong to the Tomcat project unless it is designed specifically to integrate with Tomcat. This may be the case anyway as the load balancer would have to match the jvmRoute with the appropriate container. -Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: connectors documents
On Wed, October 1, 2003 at 1:18 am, Mark Lowe sent the following Despite using tomcat for 3-4 years jakarta connectors has remained the moving goal post. I dont usually have the pleasure of having to get tomcat and apache talking to one another, but i do now. snip Subject is really for tomcat-users list. Post the question there and I'll try to answer. -Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta Tomcat 4.1 XSS vulnerability
Anyone know how serious this is?
It also appears to affect Tomcat 4.1.27 when using mod_jk as well. Below
is a sample trace of a HTTP session.
-Dave
telnet localhost 8080
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
GET /666%0a%0ascriptalert(asdf);/script666.jsp HTTP/1.0
Host: localhost
HTTP/1.1 404 /666
scriptalert(asdf);/script666.jsp
Content-Type: text/html;charset=ISO-8859-1
Content-Language: en-US
Date: Mon, 29 Sep 2003 18:39:23 GMT
Server: Apache Coyote/1.0
Connection: close
htmlheadtitleApache Tomcat/4.1.27 - Error
report/titleSTYLE!--H1{font-family : sans-serif,Arial,Tahoma;color :
white;background-color : #0086b2;} H3{font-family :
sans-serif,Arial,Tahoma;color : white;background-color : #0086b2;}
BODY{font-family : sans-serif,Arial,Tahoma;color : black;background-color
: white;} B{color : white;background-color : #0086b2;} HR{color :
#0086b2;} --/STYLE /headbodyh1HTTP Status 404 - /666
lt;scriptgt;alert(quot;asdfquot;);lt;/scriptgt;666.jsp/h1HR
size=1 noshadepbtype/b Status report/ppbmessage/b u/666
lt;scriptgt;alert(quot;asdfquot;);lt;/scriptgt;666.jsp/u/ppbdescription/b
uThe requested resource (/666
lt;scriptgt;alert(quot;asdfquot;);lt;/scriptgt;666.jsp) is not
available./u/pHR size=1 noshadeh3Apache
Tomcat/4.1.27/h3/body/htmlConnection closed by foreign host.
On Sun, September 28, 2003 at 3:14 am, Kan Ogawa sent the following
Jakarta Tomcat 4.1 cross-site scripting vulnerability, which was
reported last year, is not yet resolved.
http://www.securityfocus.com/archive/82/288502/2002-08-16/2002-08-22/0
I verified this vulnerability on Tomcat 4.1.27 with Coyote HTTP/1.1
connector.
http://localhost:8080/666%0a%0ascriptalert(asdf);/script666.jsp
On the other hand, on Tomcat 5.0, it was not reproduced.
Do you neglect to resolve it to Tomcat 4.x, Tomcat committers?
Regards,
--
Kan Ogawa
[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Jakarta Tomcat 4.1 XSS vulnerability
On Mon, September 29, 2003 1at 1:57 am, Shapira, Yoav sent the following I'm not a big security buff, but three things come to mind: - The original post with the exploit is more than a year old, yet we haven't heard anything about this actually used maliciously -- how come? Can't answer this one myself... - Is it really a vulnerability? What can you get from this exploit? You can hijack the user's session or steal information from a user's cookie pretty easily with a XSS flaw such as this one. All I see is tomcat returning a 404 (not found) response with the javascript specified in the GET request, but javascript is executed on the client anyhow, so who cares? - What would the fix be? Not include the requested URL in the default 404 response page? That's not the problem. If you look at the trace in my previous post, the problem is that the javascript was printed out un-encoded before any of the response headers. You can try plugging in the URL in your browser (just tack on 666%0a%0ascriptalert(asdf);/script666.jsp a URL) and you will receive a Javascript alert asdf. Malicious users could obviously write something much more malicious than a simple alert used as the example. -Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta Tomcat 4.1 XSS vulnerability
On Mon, September 29, 2003 1at 2:32 pm, Bill Barker sent the following Remy has already patched the HTTP Connector for this one (both Tomcat 45). I believe that the patch still needs to be ported to the JK2 Connector. Thanks for the update, Bill. Hope to see Tomcat 4.1.28 out soon, look like we could be seeing it as soon as next week. Thanks, Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Jakarta Tomcat 4.1 XSS vulnerability
On Mon, September 29, 2003 1at 2:34 pm, Shapira, Yoav sent the following Howdy, This is interesting, hopefully you won't mind educating me a bit further... Not at all, but keep in mind I haven't studied all that much myself... ;-) - Is it really a vulnerability? What can you get from this exploit? You can hijack the user's session or steal information from a user's cookie pretty easily with a XSS flaw such as this one. How would you hijack the user's session? By that do you mean just getting the session ID from the JSESSION cookie on the user's hard-drive? Once you are able to insert arbritrary Javascript into a page, you could use that power to submit a request to your own website with the JSESSION cookie details. So an example scenario would look like this: 1. User has session open to www.unsecurebank.com. 2. User receives email from malicious user saying Buy my product here! but is actually a link to www.unsecurebank.com. The link exploits the XSS vulnerability and uses Javascript to send the cookie information back to the malicous user's website. 3. Malicous user now has access to www.unsecurebank.com. If www.unsecurebank.com also stored sensitive information in any cookies, the malicious user would now have that information as well! In this cause, www.unsecurebank.com could also perform IP address confirmation along with the JSESSION id, but this is only reliable when using HTTPS/SSL. -Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Jakarta Tomcat 4.1 XSS vulnerability
On Mon, September 29, 2003 1at 2:49 pm, Shapira, Yoav sent the following Howdy, OK, makes sense. Thanks for the examples! Glad I could help. Hopefully you (and others) can use this information while designing web applications to avoid similar XSS issues in the future even if they are relatively unlikely to be exploited. -Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk does not detect a hung Tomcat
Henri Gomez said: This won't work with the pre-fork MPM, since each Apache child will have its own idea of the timing. The only way that it could tell that a Tomcat failed is to try the request and fail :). The idea needs to be flushed out some more. But we should be able to track enough data about how a worker is performing to make some simple Well the code is ready, native (jk), java (tc 3.3 + jtc) and I've updated documentations. Added PING/PONG support in ajp13, and make use of select() to determine if there is something to read. I attached a copy of jk_ajp_common.c for review but I'd like to commit the code before HEAD diverge. Since the new functionnalities are off by default it shouldn't hurt ;) You work fast, Henri. ;-) If you want, I can test it out tomorrow. If you can give me patches for Tomcat 4.1.27 and mod_jk, I'll see if I can get it compiled and run some quick tests. -Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/xdocs/common AJPv13.xml
I think there's a typo-o in here, looks like the text for the PONG REPLY will read as follows: The reply to a PING request. yet. The attached patch should fix it (Against rev 1.5) -Dave [EMAIL PROTECTED] said: /home/cvs/jakarta-tomcat-connectors/jk/xdocs/common/AJPv13.xml,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- AJPv13.xml 28 Nov 2002 08:52:48 - 1.4 +++ AJPv13.xml 25 Sep 2003 15:22:34 - 1.5 @@ -252,6 +252,11 @@ tdShutdown/td tdThe web server asks the container to shut itself down./td /tr + tr +td8/td +tdPing/td +tdThe web server asks the container to respond quickly with a Pong./td + /tr /table /p @@ -284,6 +289,12 @@ td6/td tdGet Body Chunk/td tdGet further data from the request if it hasn't all been transferred +yet./td + /tr + tr +td8/td +tdPong Reply/td +tdThe reply to a PING request. yet./td /tr /table - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/xdocs/common AJPv13.xml
David Rees said: I think there's a typo-o in here, looks like the text for the PONG REPLY will read as follows: The reply to a PING request. yet. The attached patch should fix it (Against rev 1.5) -Dave Doesn't look like my attachment made it. Here it is inline. -Dave --- AJPv13.xml Thu Sep 25 08:53:19 2003 +++ AJPv13.xml~ Thu Sep 25 08:52:26 2003 @@ -294,7 +294,8 @@ tr td8/td tdPong Reply/td -tdThe reply to a PING request./td +tdThe reply to a PING request. +yet./td /tr /table /p - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk does not detect a hung Tomcat
Henri Gomez said: Henri Gomez a écrit : Nope since you don't have to just test at protocol level but also on higher level, for instance check the full chain, up to servlet handling. It's easy to simulate this behavior by sending a STOP signal to Tomcat. I've also attached a log from mod_jk showing the problem. I marked the point at which processing in mod_jk stopped until I sent a CONT signal to tomcat. Does mod_jk2 have this same problem? Is there any interest in fixing this? Does anyone have a workaround for this issue? Well, if you have a hung tomcat, you're probably allready in serious trouble. No, actually in my case I wasn't. I had two Tomcats running, as one was prone to locking up due to a JVM or application bug. With a 50-50 load distribution between two Tomcats, this left me with 1/2 of the requests getting stuck and clients waiting forever and tying up Apache processes. Eventually, a DOS will be the result if action is not taken in time. If mod_jk noticed it wasn't really alive, this wouldn't be an issue at all. Anyway, if we add stuff like time-out in ajp request, you could be stuck with long running servlets. Also jk read request in a blocking mode for performance and adding timeout here is not an option. Agreed that we wouldn't want a timeout normally to handle normal long running servlet processes, but if there was a PING/PONG added to the protocol there should be a timeout to prevent the above situation. When I worked on ajp13++ (ajp14) protocol, I added a more secure auth mecanism at connection time. Since there is a bidirectionnal communication, jk could detect that even if the connection is open, the remote didn't respond and so fall back to the next in cluster configuration. But on allready established connections, the problem persist. Or we should add a PING/PONG before sending any request to tomcat. It could be done as optional but I work on it only if many users make such requirements if many users ask for such feature ;) Well, you've got one so far. ;-) Adding a configurable option to have mod_jk verify (PING/PONG) that Tomcat is actually responding before using the connection would solve the problem and I can't imagine that it would add a lot of complexity to the code as well. If I wasn't so rusty with my C programming and had some spare time, I would offer to help code it up. ;-) In any case, I'll be more than happy to help test. Thanks, Dave -Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
mod_jk does not detect a hung Tomcat
I posted this to tomcat-users last week, but didn't get a reply... I'm hoping to get some feedback from the connectors developers on this issue I occasionally run into... I've got a setup where I've got two load balanced Tomcats running off of Apache and mod_jk. I've got a problem where one of the Tomcats will occasionally hang, but not die. This means that it will accept new connections, but will not actually process anything. This renders all clients using the hung Tomcat completely stuck as they are not switched over to the other Tomcat. mod_jk seems to assume that if it can connect to Tomcat, it must be ready to respond to requests. It seems that some sort of connection test (with a short socket timeout) would be appropriate to validate that the connection is actually responding. While this would increase the latency of each request a bit, it would improve the reliability. Is there any provision in the AJP13 protocol to allow for testing of connections before sending a request over it? It's easy to simulate this behavior by sending a STOP signal to Tomcat. I've also attached a log from mod_jk showing the problem. I marked the point at which processing in mod_jk stopped until I sent a CONT signal to tomcat. Does mod_jk2 have this same problem? Is there any interest in fixing this? Does anyone have a workaround for this issue? Thanks, Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 4.1.27: manager reload of context fails to redeploy WEB-INF/lib and WEB-INF/classes
Remy Maucherat wrote: David Rees wrote: I just entered this bug: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22096 I can reproduce it. Right now, I can't isolate the root cause. Surprised it wasn't caught before the release. I doubt this was introduced between 4.1.26 and 4.1.27, so there should have been plenty of time to catch it indeed. One problem is that the reload mechanism is overly complex, so historically, there has been a significant amount of bugs in it. In 5.0.x, all the custom logic is now replaced by stop + start (which is marginally slower, but is *a lot* simpler). Not being familiar with the workings of the manager app, but if it's a lot easier implement a simple stop/start the context when reloading, why not do so in 4.1.x like TC 5? I doubt anyone will notice a tiny performance hit when doing reloads, especially since it's broken anyway. ;-) Wish I had time to dig into Tomcat internals. -Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
4.1.27: manager reload of context fails to redeploy WEB-INF/lib and WEB-INF/classes
I just entered this bug: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22096 Surprised it wasn't caught before the release. -Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release mod_jk 1.2.5
Henri Gomez said: The correct behaviour will be to use in_addr_t, but it don't works on iSeries (even if it's defined, I couldn't find the correct include). To fix the problem we could use a #define BSD64 ? to make use of in_addr_t until we make more works ? Just provide the correct defined var for BSD/SPARC64 If that's the case, wouldn't it be better to provide a #define for iSeries since in_addr_t works for most platforms? -Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: java Date related classes synchronization bottlenecks
David Cassidy said: I've done some tests with the below code hope this helps David, Could you give this version a try, and run it for 1 million iterations instead of just 10k? I'll be posting my results shortly for a couple of different machines shortly. The new version keeps the theoretical overall run time constant by keeping the overall amount of work the same while you vary the thread count. So if you supply arguments 1 and 1 million, and then 2 and 1 million, in the first case 1 thread will go through 1 million iterations, in the second case each of the two threads will only go throgh 500,000 iterations. Saves you division. ;-) Glenn, it would be interesting for you to modify the code to remove the synchronization issue and then re-run the quick benchmark. -Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: java Date related classes synchronization bottlenecks
Here are the results from the last version of the TestDatePerf program I sent out. Below are the results from 3 different systems when run for 1 million iterations. Here's how I interpret the results: The program verifies the synchronization performance issue. Dual-CPU machines take a huge performance hit when going from 1-2 processes fighting for the same synchronized lock. The dual processor machine always performs worse than the single processor with more than 1 thread running and doesn't start catching up until 16 threads are running. I did a few test runs when running 2 threads and watching the output from top, I noticed that both CPUs were not kept busy (as expected). Out of curiosity, I also tweaked the progrom and took out the call to Timestamp.toString() and replaced it with some non-synchronized code. This code scaled almost perfectly when going from 1 to 2 threads on the dual-cpu systems (run-time cut very close to 1/2) and increasing the number of threads to 16 showed very little performance deviation over the 2 thread case. So it looks like the bottleneck is real and depending on CPU performance I would guess that you would start seeing when when you start making a few thousand calls a second to these methods. -Dave Each system ran the following: time java TestJavaPerf threads 100 with threads values of 1, 2, 4, 8, 16. All Linux systems on on kernel 2.4.20. It would interesting to see if recent 2.5.x kernels perform better as they reported have improved multi-thread performance in the latest development kernels. System 1: Duron 600MHz, Sun Java 1.4.2, RedHat Linux System 2: PIII 500MHz, Sun Java 1.4.2, RedHat Linux System 3: Dual PIII 500MHz, Sun Java 1.4.2, RedHat Linux System 4: Dual Mips R10k 225MHz, SGI Java 1.4.1 SGI IRIX Sys# Threads Real User Sys 1160.3 59.6 0.2 1278.2 72.8 5.3 14 122.0 93.1 28.8 18 152.1 105.0 47.0 116 184.4 121.6 62.7 Sys# Threads Real User Sys 2180.5 80.2 0.3 22 108.0 111.2 3.2 24 177.2 141.5 34.4 28 290.1 200.3 88.5 216 325.2 220.0 103.9 Sys# Threads Real User Sys 3180.4 80.2 0.4 32 249.3 221.3 94.8 34 289.8 244.0 124.8 38 309.8 257.6 130.5 316 325.4 264.4 132.2 Sys# Threads Real User Sys 41 197.0 186.9 1.5 42 289.7 487.5 8.9 44 1148.9 996.9 267.0 48 1734.8 1086.0 284.3 416 1717.2 1058.4 284.8 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: java Date related classes synchronization bottlenecks
On Fri, Jul 11, 2003 at 10:10:21AM -0700, James Courtney wrote:
I didn't see an attachment that time. Thanks as this is interesting
stuff for Java development of any kind, not just Tomcat!
Stupid me. Is attached now.
-Dave
import java.sql.*;
import java.util.*;
public class TestDatePerf
extends Thread
{
int iterations;
Timestamp date = null;
public TestDatePerf(int iterations) {
this.iterations = iterations;
date = new Timestamp(System.currentTimeMillis());
}
public void run() {
for (int i = 0; i iterations; i++) {
date.toString();
}
}
public static void main(String args[]) {
int threads = Integer.parseInt(args[0]);
int iterations = Integer.parseInt(args[1]);
for (int i = 0; i threads; i++) {
TestDatePerf tdp = new TestDatePerf((int)iterations/threads);
tdp.start();
}
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: java Date related classes synchronization bottlenecks
On Fri, Jul 11, 2003 at 08:57:54AM -0700, David Rees wrote: System 4: Dual Mips R10k 225MHz, SGI Java 1.4.1 SGI IRIX I was mistaken about the CPU freq of this machine, it really has 2 R10k 180MHz CPUs, not 225MHz. -Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [4.1.25] Tag today
Glenn, This is quite interesting. How many concurrent threads need to be running before this bottleneck starts to become a significant issue? Does a simple test case which simply starts up a number of threads which all use one of the classes shown below display the problem nicely? I'd guess that one workaround would be to start up multiple instances of Tomcat on a single server (which it appears you have already tried) and make sure you have enough memory for all of them. -Dave On Thu, Jul 10, 2003 at 03:27:19AM -0500, Glenn Nielsen wrote: Remy, It can wait, go ahead with the release. But the FileLogger's use of java.sql.Timestamp is a bottleneck, I have the thread dump stack traces to prove that it is. Right now the biggest problem I have with Tomcat scaling is with this type of synchronization bottleneck. I have thread dump stack traces where two thirds of the threads are waiting on the same synchronization bottleneck related to use of one or more of the following classes: java.util.Date java.util.TimcZone.getDefault() java.util.Calendar.getInstance() java.text.SimpleDateFormat java.sql.Date java.sql.Time java.sql.Timestamp They all hit the same synchronization bottleneck. And I have multiple code bases that have to go through this bottleneck; Tomcats FileLogger which gets used a great deal for the Connector log when Tomcat is heavily loaded, the MySQL Connector/J JDBC driver, and I have customer web application code which hits this also. Due to scaling problems I setup a second app server and load balancing. It still did not scale well because of the above synchronization bottleneck. Both app servers became overloaded due to this bottleneck. I now think the best solution might be a commons project to provide alternate solutions for the above date related classes designed so that this synchronization bottleneck is avoided. Regards, Glenn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: java Date related classes synchronization bottlenecks
On Thu, Jul 10, 2003 at 05:46:06PM -0500, Glenn Nielsen wrote:
Now use jar to unarchive the src.jar file in your java SDK.
Take a look at the java.sql.Timestamp.toString() method which the FileLogger
above uses.
To verify this look at the source for java.util.Date.getField().
Yes, that looks bad (looking at 1.4.2 src)! It appears that avoiding calls to the
Timestamp.toString() is really to be avoided if possible.
And there are many other synchronization bottlenecks in the following Date
related classes:
java.util.Calendar.getInstance()
java.util.Date
java.util.TimeZone.getDefault()
java.sql.Date
java.sql.Time
java.sql.Timestamp
I took a look at some of these, these don't appear to be as bad as the
Timestamp.toString().
I did a quick google of Date performance issues and didn't find
anything. Is this a well known bottleneck in multi-threaded
applications?
Does a simple test case which simply starts up a number of threads which
all use one of the classes shown below display the problem nicely?
I am sure it would, I haven't had time to write one up yet.
I wrote a simple multithreaded program which makes calls to
Timestamp.toString() and varied the number of threads running and the
number of calls. On a single CPU system (a Duron 600), scaling from
1-20 threads performed as I expected, with the 20 thread iteration
taking only slightly longer than the single thread iteration.
However, when running this on a dual-cpu system (PIII 500), going from
1 to 2 treads took over twice as long for the same overall number of
calls to Timestamp.toString(). From 4-20 threads overall time
slightly increased most likely due to the overhead of scheduling
multiple threads.
You must be running on a multiple-CPU system as it doesn't appear to be
a bottle-neck (except for the fact that it's a slow operation) on a
single-cpu machine and only one multi-cpu machines.
Given that this is the case, a temporary fix in your case would be to
run as many Tomcat's as you have processors on that particular machine
(assuming you have enough memory)
-Dave
import java.sql.*;
import java.util.*;
public class TestDatePerf
extends Thread
{
int iterations;
Timestamp date = null;
public TestDatePerf(int iterations) {
this.iterations = iterations;
date = new Timestamp(System.currentTimeMillis());
}
public void run() {
for (int i = 0; i iterations; i++) {
date.toString();
}
}
public static void main(String args[]) {
for (int i = 0; i Integer.parseInt(args[0]); i++) {
TestDatePerf tdp = new TestDatePerf(Integer.parseInt(args[1]));
tdp.start();
}
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Remaining Tomcat 3.3 Issues
On Wed, Sep 12, 2001 at 03:19:15PM -0400, Larry Isaacs wrote: One of the main aspects of this issue is for me to become informed as to the state of Tomcat 3.3's mod_jk with respect to this. Tomcat 3.3's mod_jk.c has: s-req_uri = r-uri; which, by the statement below, appears to be rewrite enabled. This might explain why it works for Bill. I recall there being a discussion on tomcat-dev a while back about this, but I don't recall the final resolution, or if there was one. Formally establishing this resolution for Tomcat 3.3 was my reason for including item 11. Look at this thread (which I started) titled: [TC3.2.3][PATCH] mod_jk / mod_rewrite bug fix You can see the whole thread here: http://marc.theaimsgroup.com/?t=9978407791w=2r=1 -Dave
Re: cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/util SessionIdGenerator.java
On Wed, Sep 05, 2001 at 02:42:14AM -, [EMAIL PROTECTED] wrote: marcsaeg01/09/04 19:42:14 Modified:src/share/org/apache/tomcat/startup Tag: tomcat_32 Tomcat.java src/share/org/apache/tomcat/util Tag: tomcat_32 SessionIdGenerator.java Log: Switch back to the default PRNG seed generator to avoid security weakness in the manual seed generator. The PRNG is now initialized when the container starts so that we don't take the hit on the first request. Submitted by: Kevin E. Fu ([EMAIL PROTECTED]) Does this prevent Tomcat from accepting requests until after the PRNG is initialized? If so, IMHO Tomcat should accept requests ASAP, even if it can't completely serve them until the PRNG is accepted. Isn't that better than rejecting requests? -Dave
Re: Another funny thought this time about PHP
On Wed, Sep 05, 2001 at 05:38:56AM +0200, Deacon Marcus wrote: Hi, Some of my co-workers are pushing for php support. While I'm strongly opposing the idea (who needs php when jsp is available? imo that's plain ridicilous), I thought, is it - theoretically - or would it be possible - to set up Tomcat + Apache in a way where instead of standard model, all files processed by Apache except those meant for Tomcat, reverse the roles - make Apache slave of Tomcat, and use it only for, for example, php, while using Tomcat for everything else including static content. You could easily do this by mapping *.php to a servlet, and have the servlet translate the requests to Apache. Not sure why you'd want to do this, isn't the performance hit with Apache in front of Tomcat negligible? -Dave
Re: [TC3.2.3][PATCH] mod_jk / mod_rewrite bug fix
On Tue, Aug 14, 2001 at 11:49:43PM -0400, Keith Wannamaker wrote:
Try ap_escape_uri
That does the trick.
Here's the patch which gets things working again, thanks for all the help.
Hopefully this will get applied soon. Is there any 3.2.4 release planned to
fix the small number of bugs/problems in 3.2.3 (I also recall bumping into
some issues with error documents and getting into infinite loops which were
fixed)
Thanks,
Dave
--- mod_jk.c.orig Tue Jun 19 15:44:57 2001
+++ mod_jk.cTue Aug 14 22:42:32 2001
@@ -358,13 +358,12 @@
s-method = (char *)r-method;
s-content_length = get_content_length(r);
s-query_string = r-args;
-s-req_uri = r-unparsed_uri;
-if (s-req_uri != NULL) {
- char *query_str = strchr(s-req_uri, '?');
- if (query_str != NULL) {
- *query_str = 0;
- }
-}
+/*
+ * The 2.2 servlet spec errata says the uri from
+ * HttpServletRequest.getRequestURI() should remain encoded.
+ * [http://java.sun.com/products/servlet/errata_042700.html]
+ */
+s-req_uri = ap_escape_uri(r-pool, r-uri);
s-is_ssl = JK_FALSE;
s-ssl_cert = NULL;
Re: [TC3.2.3][PATCH] mod_jk / mod_rewrite bug fix
On Wed, Aug 15, 2001 at 08:58:00AM -0700, [EMAIL PROTECTED] wrote: And, the whole question is what does Tomcat see the request as? I could make a case that it should never know about the unparsed_uri, but only the uri that httpd finally resolved to and that mod_jk picked up. -- justin If we treat apache as a web server, that cooperates with tomcat but can do at least what a proxy is allowed to do by the HTTP spec ( i.e. alter the request, etc ) - then we are fine ( except the life is interesting again, and a lot of work to do including this fix ). This is the way I expect it to behave, but as Keith pointed out, it may be useful to have this as a configuration option. -Dave
[TC3.2.3][PATCH] mod_jk / mod_rewrite bug fix
Hi,
I came across the need to use mod_rewrite to rewrite some URLs I was sending
to Tomcat.
After playing with it a bit (I had it working a while ago) and finding that
Tomcat was not receiving the rewritten URLs no matter what I did, I took a
look at the source to native/apache1.3/mod_jk.c. Not being much of an
Apache hacker, the variables were descriptive enough to tell me to make this
change to the file:
--- mod_jk.c.orig Tue Aug 14 17:58:21 2001
+++ mod_jk.cTue Aug 14 18:04:58 2001
@@ -358,7 +358,7 @@
s-method = (char *)r-method;
s-content_length = get_content_length(r);
s-query_string = r-args;
-s-req_uri = r-unparsed_uri;
+s-req_uri = r-uri;
if (s-req_uri != NULL) {
char *query_str = strchr(s-req_uri, '?');
if (query_str != NULL) {
After this change my URLs were getting rewritten as expected again.
Can we apply this change to the tree if there's nothing wrong with it for
the next release? This problem has affected a large number of users, just
take a look at the tomcat-dev/user archives.
It seems that this change was made to satisfy the errata at
http://java.sun.com/products/servlet/errata_042700.html, but is it the
correct fix if we're intentionally munging the request?
Thanks,
Dave
Re: [TC3.2.3][PATCH] mod_jk / mod_rewrite bug fix
On Tue, Aug 14, 2001 at 10:20:26PM -0400, Keith Wannamaker wrote: Unfortunately there are people who were breaking because we didn't follow the spec. The better way to fix it is to create an inverse function for ap_parse_uri(request_rec *r, const char *uri) [http_protocol.c] in mod_jk... one that would 'unparse' the munged r-uri rewrite and use it instead of r-unparsed_uri. Hi, OK, are you volunteering to write it? ;-) If not, I'll have to take a look when I get some time and see if I can figure it out. As an aside, it appears that Tomcat 3.3 remains broken in this regard, as it uses r-uri instead of r-unparsed_uri. -Dave
Re: [TC3.2.3][PATCH] mod_jk / mod_rewrite bug fix
On Tue, Aug 14, 2001 at 11:05:38PM -0400, Keith Wannamaker wrote: | This breaks query strings. | | r-uri contains only the path portion of the URL. r-unparsed_uri | contains the URL in its virgin format - as sent by the client. No, I don't believe this is quite right. getRequestURI() in a servlet should return r-unparsed_uri minus a query string. Setting s-uri = r-uri doesn't break query strings.. but it *does* break the encoding of the uri. So tc 3.3 is currently broken as is mod_webapp (unless the string is encoded on the java side in TC4). However, Justin, I think your suggestion is the correct solution: s-req_uri = ap_encode_uri(r-pool, r-uri); David, or anyone else interested too, would you try this with some corner test cases and see if it lives up to expectation? I gave it a shot and it compiled fine, but got this error at runtime: Cannot load /usr/local/apache/libexec/mod_jk.so into server: /usr/local/apache/libexec/mod_jk.so: undefined symbol: ap_encode_uri Any hints? I'm new at Apache module hacking. -Dave
Re: Problem with ThreadPool.java
On Thu, Jul 26, 2001 at 03:07:55PM -0700, Renato Weiner wrote:
I was running some volume tests with Tomcat 3.2.3 using the 'ab'
application that comes with apache. I simulated diffent loads of
concurrent users. If set the concurrency to 5 it runs fine my
Servlets, but if I set to more than 8, I got an exception in the
ThreadPool. Here is the message:
2001-07-26 19:00:14 - ThreadPool: Caught exception executing org.apache.tomcat.s
ervice.TcpWorkerThread@799ff5, terminating thread - java.util.NoSuchElementExcep
tion
at java.util.Vector.lastElement(Vector.java:454)
at org.apache.tomcat.util.ThreadPool.runIt(ThreadPool.java:234)
at org.apache.tomcat.service.TcpWorkerThread.runIt(PoolTcpEndpoint.java:
405)
at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java
:501)
at java.lang.Thread.run(Thread.java:484)
The error is reproducable. If anybody send a patch I can test it.
I found the problem, below is the simplest patch to fix it, although not
100% correct. I'll explain why in a few minutes.
-Dave
--- ThreadPool.java.origSun Apr 22 19:16:03 2001
+++ ThreadPool.java Thu Jul 26 16:35:47 2001
@@ -197,7 +197,7 @@
// Obtain a free thread from the pool.
synchronized(this) {
-if(currentThreadsBusy == currentThreadCount) {
+if(currentThreadsBusy = currentThreadCount) {
// All threads are busy
if(currentThreadCount maxThreads) {
// Not all threads were open,
Re: Problem with ThreadPool.java
On Thu, Jul 26, 2001 at 04:35:59PM -0700, David Rees wrote:
I found the problem, below is the simplest patch to fix it, although not
100% correct. I'll explain why in a few minutes.
Never mind, I should have looked at openThreads first. As far as I can
tell, the ThreadPool works as advertised, except in the following case
(which wouldn't cause any stack traces). A
Say maxThreads is 100, currentThreadsBusy is 95 and minSpareThreads is 10
and currentThreadCount is 96.
Wouldn't you expect ThreadPool to open up 5 new Threads to attempt to keep
10 threads open in the checkSpareControllers function?
Anyway, my last patch shouldn't make a difference in preventing that
exception unless something weird is going on synchronization wise.
Can you try this patch to get more information on what's going on when the
exception occurs?
-Dave
--- ThreadPool.java.origSun Apr 22 19:16:03 2001
+++ ThreadPool.java Thu Jul 26 17:01:41 2001
@@ -231,9 +231,18 @@
}
// If we are here it means that there is a free thred. Take
it.
-c = (ControlRunnable)pool.lastElement();
-pool.removeElement(c);
-currentThreadsBusy++;
+try {
+c = (ControlRunnable)pool.lastElement();
+pool.removeElement(c);
+currentThreadsBusy++;
+} catch (Exception e) {
+loghelper.log(Unexcpected Exception, e);
+loghelper.log(maxThreads: + maxThreads);
+loghelper.log(currentThreadCount: +
currentThreadCount);
+loghelper.log(currentThreadsBusy: +
currentThreadsBusy);
+loghelper.log(minSpareThreads: + minSpareThreads);
+loghelper.log(Current Pool Size: + pool.size());
+}
}
c.runIt(r);
}
Re: [DOC] Re: [3.2] JSP Compiling Classpath issues -- finding WEB-INF/class es
On Fri, Jul 20, 2001 at 12:47:51PM -0500, David Haraburda wrote: I don't think unsetting your CLASSPATH is necessary, especially since other applications may rely on it. I would guess that most problems occur when: 1) You add things you have in your WEB-INF/classes to your CLASSPATH (thus causing them to be loaded by the system class loader, not the Tomcat web app class loader, which causes problems) or, as the case would appear to be with the POET sdk referred to before, 2) Your web application requires a certain JAR that you have placed in your WEB-INF/lib directory, but unbeknownst to you, there is actually another JAR (perhaps an older version of the software) sitting in your classpath, which gets loaded first. Remember, a classloader always asks it's parent classloader to load a resource first, and then only loads it itself if the parent cannot find it. Just make sure things your web application requires are in your WEB-INF/libs directory, and not in your classpath. Craig McClanahan has two good posts about this: http://mikal.org/interests/java/tomcat/archive/view?mesg=22444 http://mikal.org/interests/java/tomcat/archive/view?mesg=8512 Thanks for the tips, what you've described is the exact behavior I've experienced. I just haven't had the time to read up about classloaders and the order which classes are loaded. As far as logging goes, you may want to check out the Logger elements is your server.xml file. They provide a good way to keep your terminal un-cluttered. :-) Crap, I never really noticed this one before: Logger name=tc_log verbosityLevel = INFORMATION / Is there any other tricks I've been missing for a while with Tomcat? (I know, getting off-topic for tomcat-dev) Thanks, -Dave
Re: [DOC] Re: [3.2] JSP Compiling Classpath issues -- finding WEB-INF/class es
On Fri, Jul 20, 2001 at 06:22:21AM -0700, Rob S. wrote: A, maybe I should add this to the INSTALL.txt file - unset your CLASSPATH before starting TC? I've logged into my fair share of *nix boxes where the admins have conveniently set a system-wide CLASSPATH containing an XML parser, etc. I think it's the safe thing to do. I think Tomcat 3.3 and Tomcat 4 both do this by default. For Tomcat 3.2.X, I do this in custom startup scripts which make startup/shutdown a lot easier if you're maintaining multiple copies of Tomcat per host. I also modify bin/tomcat.sh to redirect stdout/err to log files instead of cluttering the terminal. If anyone is interested, I can send copies of the scripts and the patch to tomcat.sh... I would at least like to see the stdout/err patch integrated into Tomcat, I just don't know if there's much interest in including it into Tomcat 3.2. -Dave
Re: [3.2] JSP Compiling Classpath issues -- finding WEB-INF/classes
(Sorry about the double-qoute, I missed the original message) -Original Message- From: Will England [mailto:[EMAIL PROTECTED]] Sent: Thursday, July 19, 2001 10:49 AM To: [EMAIL PROTECTED] Subject: [3.2] JSP Compiling Classpath issues -- finding WEB-INF/classes Greetings! Over on tomcat-users, theres been a discussion on JSP's finding the WEB-INF/classes directory when compiling. They can't. From searches, I understand this issue has come up before in regards to the Coocon project. The root problem is that Jasper cannot find classes located in WEB-INF/classes of the web application that the JSP's belong to. This occurs when a JSP is either first deployed or the TOMCAT_HOME/work directory is cleared, requiring a recompile of the JSP's. The system is Tomcat 3.2 under Apache with mod_jk, running on SunOS 2.7 with JDK 1.2. I have noticed the same problem while doing some development using Tomcat 3.2.[23]. I worked around it by making sure that I unset the classpath before calling startup.sh, then things seemed to work properly and classes were found as expected. It seems that certain combinations of classes in different ares (CLASSPATH, WEB-INF/lib, or other) will break things, but I haven't pinned it down, so it could simply be user stupidity. -Dave
Re: Tomcat 3.2.2 and Error page 404
On Wed, Jul 04, 2001 at 11:53:05AM -0700, Renato Weiner wrote: Hi all, I know this has been discussed, but I can't find an ultimate answer on this topic. I'm running Tomcat 3.2.2, I have latest the StaticInterceptor.java from CVS. If I configure my web.xml with a dynamic 404 error ( let's sat 404.jsp ) that doesn't exist, I got an endless loop: 2001-07-04 02:10:17 - Ctx( : ): 404 R( + /servlet/xxx + null) JSP file not found 2001-07-04 02:10:17 - Ctx( : ): Get real path /404.jsp /home/client1/404.jsp /home/client1 2001-07-04 02:10:17 - Ctx( : ): Get real path /404.jsp /home/client1/404.jsp /home/client1 2001-07-04 02:10:17 - Ctx( : ): Get real path /404.jsp /home/client1/404.jsp /home/client1 Do anybody has a solution for this ? I have hit this myself. The only solution is to make sure that the error pages you define in face do exist. I haven't had time to look into root cause of this myself, but I'm not familiar with the Tomcat source anyway... -Dave
Re: Problem+Fix concerning static error pages in Tomcat 3.2.2
A related bug to this is a nasty stack overflow error if an error page that you define is not found. It's pretty easy to reproduce, just add this to your web.xml: error-page error-code404/error-code location/some-nonexistant-file.jsp/location /error-page Then try to access a non-existant file. Tomcat will go into an infinite loop until the stack overflows. -Dave On Wed, May 30, 2001 at 04:23:19PM -0500, Marc Saegesser wrote: This was broken in 3.2.1 and unfortunately is still broken in 3.2.2 due to the commit problem I mentioned earlier. Since this isn't a regression failure and there is a work-around we'll log it as a bug and fix it in 3.2.3. -Original Message- From: Marc Saegesser [mailto:[EMAIL PROTECTED]] Bloody hell. This bug was fixed a couple months ago and then got whacked by a late commit to StaticInterceptor.java. I take partial responsibility because I reviewed that commit and missed the problem. I'll try to get this taken care of this evening.
Re: Bug 1006, what's next ?
On Tue, Mar 20, 2001 at 07:03:04AM -0800, [EMAIL PROTECTED] wrote: I had a (long) weekend without computers. But I still found one and read the mail once - and your report is very serious and important ( and not easy to fix ). You have (at least ) my full attention. The read timeout will be checked in soon - but the general problem ( with a servlet hanging a thread ) is very hard to resolve (or I don't know any good solution ). We could stop setting an upper limit on the thread count ( we still have the OS upper limit ), and we could also use the (dangerous, deprecated) suspend/terminate on the thread that is taking too much time. Have you tried any fix ? The timeout will not resolve the "bursts" ( and high-loaded servers ) - unless it is very short. BTW, this is not a tomcat-specific problem ( I would guess Apache does have the same issue - and we need to find how they deal with that ). Apache sets limits on the maximum (at least in 1.3.X, not sure about 2.X) number of processes which can be running at a time, this prevents the machine from getting hosed, but doesn't prevent a DOS from a determined attacker. I'm not sure if Apache implements any other methods to prevent this type of DOS. -Dave
Re: cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/request StaticInterceptor.java
On Fri, Mar 16, 2001 at 11:42:00PM -, [EMAIL PROTECTED] wrote: arieh 01/03/16 15:42:00 Modified:src/share/org/apache/tomcat/request Tag: tomcat_32 StaticInterceptor.java Log: Add support for docbase localization lookup. Maybe I'm missing something here, but should this have been committed to the tomcat_32 branch when the code is frozen for 3.2.2? -Dave
Re: Proposal for implementation of lookup of localized web-resources
On Wed, Mar 14, 2001 at 08:19:16AM -0700, Arieh Markel wrote: file-based:(path/filebasename[locale].filetype) 1. docbase/dir/.../index_fr_CA.html 2. docbase/dir/.../index_fr.html 3. docbase/dir/.../index_en_US.html 4. docbase/dir/.../index_en.html 5. docbase/dir/.../index.html Why not use the same setup that Apache uses? If you ever plan on integrating Tomcat/Apache, this will make the transition painless. Apache uses this by default I believe: 1. docbase/dir/.../index.html.fr 2. docbase/dir/.../index.html.en 3. docbase/dir/.../index.html You can read more about it here: http://httpd.apache.org/docs/content-negotiation.html -Dave
Re: cvs commit: jakarta-tomcat/src/shell tomcat.sh
On Thu, Mar 15, 2001 at 07:33:19AM -, [EMAIL PROTECTED] wrote: costin 01/03/14 23:33:19 - added -noout option to redirect the stdout/stderr to a file Great, I've been modifying my tomcat scripts to do this by hand forever. - save the PID of the java process in conf/tomcat.pid ( of course, you don't need this because tomcat never hangs, but just in case :-) Shouldn't the pid file be saved in the logs directory as it seems to be customary to do so? (Apache puts it's .pid file in the log dir) -Dave
RE: TC 3.2 - Better logging messages when something bad happens?
Thanks for the reply, From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] David Rees wrote: Anyone have any technical comments on the message below? I think that printing a stack dump in this case can be very useful, but someone else may have a different view. For developers, you certainly want to be able to see the stack traces. However, many developers do *not* want such cruft showing to users -- so it was made configurable (thanks to the efforts of Larry Isaacs) -- see the ContextManager attribute called "showDebugInfo" in the conf/server.xml file. It looks like this case was missed. I'm +1 on adding a stack trace, but it should be made conditional just like other stack traces are. OK, I'll see if I can get some time to create a proper patch for this case, then (unless someone beats me to it, I probably won't have time until after X-Mas) -Dave
RE: Class reloading problems (TC 3.x)
Sorry, for Tomcat 3.x you're stuck restarting Tomcat after updating beans or servlets. Take a look at this post from Craig which may shed more light on the subject: http://marc.theaimsgroup.com/?l=tomcat-userm=97562988801936w=2 I don't know if this is something Costin has any ideas about for the Tomcat 3.x tree. -Dave -Original Message- From: Allen Akers [mailto:[EMAIL PROTECTED]] Sent: Tuesday, December 19, 2000 7:45 AM To: [EMAIL PROTECTED] Subject: Class reloading problems I saw a message on here a while back about problems with class reloading for accessory classes within a context, but never saw a resolution for the problem. I am having this problem currently when trying to save an object to the servlet context for use by multiple servlets. When the class is changed and recompiled, I get ClassCastExceptions on every subsequent attempt to retrieve it due to the use of a new Classloader and Tomcat has to be restarted to resolve this problem. I was hoping to find someone else who had resolved this problem before I started going about researching it any further. Thanks. Allen Akers Programmer Analyst Strategic Web and Voice Development [EMAIL PROTECTED]
RE: future questions
From: Jon Stevens [mailto:[EMAIL PROTECTED]] snip p.s. Costin, I had a great idea. I'm going to forward to you all of the personal email based Tomcat support questions that I get. Have fun answering them. :-) How about forwarding them or pointing them to the tomcat-user list where these questions will be answered? -Dave
RE: [MY_OPINION] Tomcat 3.x
-Original Message- From: Jon Stevens [mailto:[EMAIL PROTECTED]] on 12/18/2000 10:01 AM, "Greg Bailey" [EMAIL PROTECTED] wrote: As a use of Tomcat 3.1 on several production machines, may I say "thanks" also to Costin and everyone else who supports 3.1 (and 3.1.1, 3.2, 3.2.1, etc.) We are in no position to jump to 4.0 just because its trendy and has more "development activity"... Thanks again, -Greg Bailey I wish people would pay more attention to what the overall issues are instead of focusing on entirely the wrong things. That isn't what I was saying at all. The issue is the idea of a 3.3 and I'm not saying to "jump" to 4.0. Please look at all the information available to you about what is happening before commenting again. It really is part of the same issue. Because Greg is not willing to jump to 4.0, the idea of continuing development on the 3.x branch (work towards 3.3) is welcome and reassuring. There will likely be some issues with porting applications to 4.0 which can't be easily resolved. I see no problems with Costin (and others) continuing work on the 3.3 release, especially considering his recent comments about doing development on Tomcat with the Apache group: Costin said (quoting Jon): simply fork what you are doing into another project that is hosted somewhere else. It's the second time an Apache member is asking me to go somewhere else. Believe me, right now it's my biggest wish - I've had more than enough ! The way I see it, having Costin stopping work on the 3.x tree won't free up any substantial amount of resources for the 4.x tree. Costin doesn't seem to be planning on any future development on Tomcat after 3.3 is done! Either way, what does it matter if Costin is doing development work on the 3.x tree under Apache or under his own project? Frankly, I am disappointed in the development process of Tomcat. I posted a simple documentation patch (See bug report 528) two weeks ago for the FAQ included with the Tomcat 3.x and posted a couple messages about it. I haven't heard a thing about it and saw the release of 3.2.1 come and go without the documentation fix. -Dave
RE: [MY_OPINION] Tomcat 3.x
Hi Craig, -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Frankly, I am disappointed in the development process of Tomcat. I posted a simple documentation patch (See bug report 528) two weeks ago for the FAQ included with the Tomcat 3.x and posted a couple messages about it. I haven't heard a thing about it and saw the release of 3.2.1 come and go without the documentation fix. The reason this occurred is that a significant security bug was found, warranting an *immediate* 3.2.1 release that bypassed the usual testing cycle that a beta should go through. This wasn't the only thing that didn't make it -- but security issues are serious and need to be dealt with. I understand why it didn't get through when I re-mentioned it right before the release, that is completely understandable. The problem as I see it is that the bug report was in BugRat for a week (in addition to a normal post to tomcat-dev) before Tomcat 3.2.1 was released; plenty of time IMHO for such a simple documentation patch to be committed. Normal processing of bug fixes and patches on the "tomcat_32" tree is now feasible for a 3.2.2 release. Hint: I am not the only committer on this project -- others are welcome to help integrate changes too. Right, I'm not about you specifically, Craig (I think you're doing good work on the 4.x tree and are usually very responsive on the tomcat-user/dev lists), but I really would have expected one of the committers to pick up the patch. I would just hate to see someone else pound their head against a wall for a few hours because of incorrect documentation. Anyway, slightly off-subject now. I'm curious to hear your reply to Jon's post. -Dave
RE: [MY_OPINION] Tomcat 3.x
From: Jon Stevens [mailto:[EMAIL PROTECTED]] There are no issues with porting to 4.0. I just took an app developed on 3.x and moved it to 4.0 without any problems. Maybe for your app it ported over, but for others (specifically those working with XML and parsers other than the one bundled with Tomcat 4.x) do have problems with it. Realistically I expect most applications to port over without any changes, but I expect a handful to experience some problem related to this. Ok, so great...3.3 is done and Costin disappears. What happens then? I wait around for someone else to pick up the effort while everyone else is working on and using 4.0? No, Costin specifically said he'd be continuing maintenance and bug fixes on the 3.x tree after his refactoring is done. (Sorry, don't have his quote handy) Frankly, I am disappointed in the development process of Tomcat. I posted a simple documentation patch (See bug report 528) two weeks ago for the FAQ included with the Tomcat 3.x and posted a couple messages about it. I haven't heard a thing about it and saw the release of 3.2.1 come and go without the documentation fix. HELLO! DUHH! I think it is so funny that you mention this. Lets see, I see Craig and Remy constantly adding patches to Tomcat 4.0 as soon as they come in, but because we have this split of effort working on two tree's, your patches probably have gotten overlooked because people were way to busy working on the fact that we have a forked development tree. My point is that it is way to confusing for a volunteer organization to support this split tree like this and it needs to stop! Alright, you got me on this one. :-) Although I might point out that there seems to be at least one full time paid employee on the project. :-) -Dave
RE: [MY_OPINION] Tomcat 3.x
Hi Jon, From: Jon Stevens [mailto:[EMAIL PROTECTED]] Of course not. That is why I'm suggesting to move away from it for the future and opening the discussion of that now. Would you rather that we continue to follow down this path of split trees forever? Would you rather that all of our users are consistently confused? I have learned long and hard over the years that you just can't please everyone. It is a sad thing indeed. It is amazing to me how you guys can just sit back and actually think that what Costin is doing to the overall project and the users is a good thing! :-( Another 2 cents from me... :-) Based upon your arguments I do agree that focusing development work on the 4.x tree is the way to go. After reading your message on "example case of my hell", I can see why you're keen on keeping the Tomcat tree in one piece. (Although you didn't quote the best example, as the problem that user was experiencing with the /admin context was part of tightening up the security holes in Tomcat, users are now forced to supply a username/password to gain access to the /admin context. Didn't Craig mention that in the release notes?) From my perspective, development (besides bug fixes) on the 3.x branch only makes sense as long as the 4.x branch isn't stable. But seeing as the 4.x branch is approaching beta-release phase, I would agree that the time to stop enhancements to the 3.x tree is rapidly approaching if not past already. As for what to do with the work done on the "3.3" release (which looks like it may be ready around the same time as the 4.0 release), forking it does not seem like a bad idea if only to save developers the support headaches. I'm sure that the committers will make the appropriate decision. -Dave
RE: cvs commit:jakarta-tomcat/src/examples/WEB-INF/classes/examples ShowSource.java
(Don't ask me what I think of stupid operating systems that accept "//" in a pathname and simply ignore them like Linux does ... grrr). SGI IRIX 6.5.8 and FreeBSD 4.1-STABLE also behave the same way, I would expect all Unix machines to do the same. -Dave
