tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Maher <>
Subject Re: mod_jk timeout?
Date Tue, 28 Oct 2003 06:04:52 GMT
> 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?


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message