Re: mod_jk timeout?
On Mon, 27 Oct 2003, Henri Gomez wrote:
If the thread on java side is a long running task or a blocking task,
it should be handled by the servlet engine and sus some watchdog
support
should be added in Tomcat.
In you're exemple I didn't know how the thread could be ever finished
!!!
In theory, that's what Thread#interrupt is for. It asks the thread to
shut
down, resulting in setting the #interrupted flag / an
InterruptedException
on potentially blocking calls such as wait() or sleep(). One could
interrupt named jsp like that.
Actually, I was thinking the Thread#join would be better since we could
be in an infinite loop not doing any calls to wait() or sleep(). I was
thinking of implementing a scheme sort of like this:
mod_jk | tomcat
---+--
PING -- received
received -- PONG
[ sleep ~2 seconds ]
received -- PING
PONG -- received
If any side sends a PING and doesn't hear a PONG in 0.1 seconds, it can
assume the other side is dead. This would mean a there would need to
be a separate thread in the tomcat that is simply doing housekeeping or
watch dogging on the status of the connections.
However, dealing correctly with InterruptedExceptions is hard (you
should
leave your objects in a meaningful state) and since
InterruptedException
also is a checked exception, many people choose to
catch(InterruptedException ie) {}, even(?) Sun ORB code does so (not to
speak of my own).
Certainly it can be hard to correctly deal with interruptions, but what
is the alternative. Especially if you are running an untrusted JSP
pages that could contain an infinite loop. Certainly testing for
infinite loops is impossible, or at least NP Complete. And, with many
requests to such a web page, it would be easy to turn it into a denial
of service attack.
Those threads are inevitably lost.
I would think that is the point.
If I was to implement this feature, where should I look for the source
code, and should I simply submit a patch to be reviewed?
Thanks,
-Brian
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk timeout?
Brian Maher a écrit :
On Mon, 27 Oct 2003, Henri Gomez wrote:
If the thread on java side is a long running task or a blocking task,
it should be handled by the servlet engine and sus some watchdog support
should be added in Tomcat.
In you're exemple I didn't know how the thread could be ever finished
!!!
In theory, that's what Thread#interrupt is for. It asks the thread to
shut
down, resulting in setting the #interrupted flag / an
InterruptedException
on potentially blocking calls such as wait() or sleep(). One could
interrupt named jsp like that.
Actually, I was thinking the Thread#join would be better since we could
be in an infinite loop not doing any calls to wait() or sleep(). I was
thinking of implementing a scheme sort of like this:
mod_jk | tomcat
---+--
PING -- received
received -- PONG
[ sleep ~2 seconds ]
received -- PING
PONG -- received
If any side sends a PING and doesn't hear a PONG in 0.1 seconds, it can
assume the other side is dead. This would mean a there would need to
be a separate thread in the tomcat that is simply doing housekeeping or
watch dogging on the status of the connections.
However, dealing correctly with InterruptedExceptions is hard (you should
leave your objects in a meaningful state) and since InterruptedException
also is a checked exception, many people choose to
catch(InterruptedException ie) {}, even(?) Sun ORB code does so (not to
speak of my own).
Certainly it can be hard to correctly deal with interruptions, but what
is the alternative. Especially if you are running an untrusted JSP
pages that could contain an infinite loop. Certainly testing for
infinite loops is impossible, or at least NP Complete. And, with many
requests to such a web page, it would be easy to turn it into a denial
of service attack.
Those threads are inevitably lost.
I would think that is the point.
If I was to implement this feature, where should I look for the source
code, and should I simply submit a patch to be reviewed?
In the ajp13 java side and the jk side, both is jtc.
BTW, there is works on jk2 so it will have to wait a little ;(
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk timeout?
Brian Maher wrote: On Mon, 27 Oct 2003, Henri Gomez wrote: If the thread on java side is a long running task or a blocking task, it should be handled by the servlet engine and sus some watchdog support should be added in Tomcat. In you're exemple I didn't know how the thread could be ever finished !!! In theory, that's what Thread#interrupt is for. It asks the thread to shut down, resulting in setting the #interrupted flag / an InterruptedException on potentially blocking calls such as wait() or sleep(). One could interrupt named jsp like that. Actually, I was thinking the Thread#join would be better since we could be in an infinite loop not doing any calls to wait() or sleep(). I was thinking of implementing a scheme sort of like this: mod_jk | tomcat ---+-- PING -- received received -- PONG [ sleep ~2 seconds ] received -- PING PONG -- received If any side sends a PING and doesn't hear a PONG in 0.1 seconds, it can assume the other side is dead. This would mean a there would need to be a separate thread in the tomcat that is simply doing housekeeping or watch dogging on the status of the connections. This won't work well on the Tomcat side due to Garbage Collection. the JVM will often freeze Tomcat for .1 seconds during GC. And when doing a Full GC can freeze Tomcat for many seconds. Regards, Glenn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk timeout?
Brian Maher a écrit :
I noticed this message from Glenn Nielsen recently on this mailing list:
http://www.mail-archive.com/[EMAIL PROTECTED]/msg47341.html
It appears that hgomez submitted a bunch of code that allows you to
configure a ping/pong mechanism that helps it detect hung tomcats. I'm
very much interested in this code, but wonder if it could also detect an
aborted apache process?
Here is a simple test I performed recently with my server configured
like this: (Apache (1.3.x) ---(mod_jk)-- Tomcat 4.1). On all my
apache requests, I set a hard_timeout() using mod_perl. It is pretty
easy to see that this hard_timeout works fine by looking at apache's
/server-status page. My next test was to see if this hard_timeout()
worked for Tomcat. So, I wrote a simple JSP page as such:
%
while(1) {
Thread.sleep(10);
System.out.println(hi\n);
}
%
When I request this page and tail my log file, I see hi printed over
and over as I would expect to see. However, the disturbing part is that
even after the hard_timeout() has expired, this thread is still
executing (since I see a bunch of hi\n in my log file). I check
apache's /server-status page and the process that was servicing the
request is long gone.
Could this recently submitted ping/pong code also be used from the java
side to detect when the Apache side is no longer servicing the request?
I'd be willing to help make this happen if someone could give me some
guidance.
The timeout support help the native side detect a problem on the java
side, for exemple a HUNG tomcat.
If the thread on java side is a long running task or a blocking task,
it should be handled by the servlet engine and sus some watchdog support
should be added in Tomcat.
In you're exemple I didn't know how the thread could be ever finished !!!
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk timeout?
On Mon, 27 Oct 2003, Henri Gomez wrote:
If the thread on java side is a long running task or a blocking task,
it should be handled by the servlet engine and sus some watchdog support
should be added in Tomcat.
In you're exemple I didn't know how the thread could be ever finished !!!
In theory, that's what Thread#interrupt is for. It asks the thread to shut
down, resulting in setting the #interrupted flag / an InterruptedException
on potentially blocking calls such as wait() or sleep(). One could
interrupt named jsp like that.
However, dealing correctly with InterruptedExceptions is hard (you should
leave your objects in a meaningful state) and since InterruptedException
also is a checked exception, many people choose to
catch(InterruptedException ie) {}, even(?) Sun ORB code does so (not to
speak of my own).
Those threads are inevitably lost.
Matthias
--
Matthias Ernst
Software Engineer
CoreMedia - Smart Content Technology
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
mod_jk timeout?
I noticed this message from Glenn Nielsen recently on this mailing list:
http://www.mail-archive.com/[EMAIL PROTECTED]/msg47341.html
It appears that hgomez submitted a bunch of code that allows you to
configure a ping/pong mechanism that helps it detect hung tomcats. I'm
very much interested in this code, but wonder if it could also detect
an aborted apache process?
Here is a simple test I performed recently with my server configured
like this: (Apache (1.3.x) ---(mod_jk)-- Tomcat 4.1). On all my
apache requests, I set a hard_timeout() using mod_perl. It is pretty
easy to see that this hard_timeout works fine by looking at apache's
/server-status page. My next test was to see if this hard_timeout()
worked for Tomcat. So, I wrote a simple JSP page as such:
%
while(1) {
Thread.sleep(10);
System.out.println(hi\n);
}
%
When I request this page and tail my log file, I see hi printed over
and over as I would expect to see. However, the disturbing part is
that even after the hard_timeout() has expired, this thread is still
executing (since I see a bunch of hi\n in my log file). I check
apache's /server-status page and the process that was servicing the
request is long gone.
Could this recently submitted ping/pong code also be used from the java
side to detect when the Apache side is no longer servicing the request?
I'd be willing to help make this happen if someone could give me some
guidance.
Thanks,
-Brian
P.S. Please note that I am not on the tomcat-dev@ list.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
