On 05/08/2012 01:13 AM, Costin Manolache wrote:
On Mon, May 7, 2012 at 3:44 PM, Mladen Turk<mt...@apache.org> 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.
Regards
--
^TM
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org