Larry Reisler wrote:
Agreed, the root cause is a bug in the Java part of Tomcat.
However, but it points to a weakness of mod_jk, that if mod_jk hits
the connection timeout on a socket and the server does not shut down
the socket in a timely manner, all AJP requests in the httpd process
grind to a halt for at least two seconds.
I hope I said that before: this is one of the things we plan for JK3,
i.e. having separate threads for maointenance tasks and maybe
communication tasks related to state information, which should not be
piggy-packed on usual request handling.
JK is multi-platform and we want to avoid multi-platform thread
programming without a wrapper lib. So with JK3 we want to introduce a
dependency on the APR libs, which will help us implementing those features.
Regards,
Rainer
Larry
-----Original Message----- From: jean-frederic clere
[mailto:[EMAIL PROTECTED] Sent: Wednesday, November 28, 2007 10:21
AM To: Tomcat Developers List Cc: Rainer Jung; Larry Reisler Subject:
Re: FW: Delays in mod_jk
Larry Reisler wrote:
Rainer --
I recently changed replaced the version of JBOSS Web we were using
to JBOSSWEB_2_0_0_GA_CP04. It included several patches to the AJP
code. That appears to have solved the problem. The FIN packets
from the back end come back immediately now. I'm guessing that the
fix to JBPAPP-366 (http://jira.jboss.org/jira/browse/JBPAPP-366)
fixed this too.
I still see the mod_jk architecture as problematic
JBPAPP-366 is http://svn.apache.org/viewvc?rev=589062&view=rev that
was a bug in the JAVA part not in mod_jk.
Cheers
Jean-Frederic
-- it would be better if cleaning up the sockets would occur on a
different thread and without the critical section locked.
Larry
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
