tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <cos...@gmail.com>
Subject Re: Purpose of unlockAccept
Date Mon, 07 May 2012 23:13:53 GMT
On Mon, May 7, 2012 at 3:44 PM, Mladen Turk <mturk@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.



> 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 ?


>
> 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 ?

I agree it's too complex - maybe you can remove all the waiting at the end
and hardcode all options. Deferred accept handling still needed.


Costin



>
>
> Regards
> --
> ^TM
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.**org<dev-unsubscribe@tomcat.apache.org>
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message