tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mladen Turk <>
Subject Re: Purpose of unlockAccept
Date Tue, 08 May 2012 06:05:13 GMT
On 05/08/2012 01:13 AM, Costin Manolache wrote:
> On Mon, May 7, 2012 at 3:44 PM, Mladen Turk<>  wrote:
>> On 05/07/2012 11:05 PM, Costin Manolache wrote:
>>> By 'unlockAccept' you mean the socket connection made to the acceptor to
>>> force the accept() to unblock ? How are you getting the socket accept() to
>>> return, my understanding was that close() or thread interrupt don't work
>>> in
>>> all cases/VMs.
>> Well, my question is why the need to break the accept() call
>> at the first place?
>> I mean if we are in the pause so that all sessions time out
>> the extra connection would in worse case scenario double the
>> cumulative session timeout, so you server might actually go down in
>> 19.9 instead 10 minutes, but who cares.
> Where do the 10 minutes come from ?
> Stopping the server shouldn't take 10 min.

Suppose you can hit pause and wait till all sessions times out.
This allows shutting down the tomcat without loosing
existing connections (graceful shutdown).
Although this is dubious cause sessions can have huge timeouts,
but I suppose this can be useful in some cases.

>> The amount of complexity we are throwing inside unlockAccept is
>> just getting insane, and it's still fragile.
> What about not calling it on pause, but still call it on stop ?

Stop really doesn't needs unlock. Just closing the listening
socket breaks any accept call.

>> Another alternate solution might be to setSoTimeout on
>> accept socket and eat any SocketTimeoutException.
>> It would mean that we would pull out of accept() each 10 seconds,
>> and on busy server it might take more then 10 seconds to unlockAccept
>> anyhow.
> On a busy server unlockAccept() shouldn't have to be called.
> Maybe wait a bit after running=false, and if the accept is still blocked
> call unlockAccept ?

Your comment only proves my concerns about that logic.
We all have our 'own' opinion what should be its purpose.

The point is that on 'stop' we don't need unlock at all.
The socket is going to be closed immediately after it
returns from accept() call, so why bother at the first place.

For real pause (stop accepting connections and wait till all sessions
times out) this can be done safely by setting 10 second timeout
on listening socket. It means that in worse case we would have
session-timeout + 10s.


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

View raw message