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. > 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-unsubscr...@tomcat.apache.org> > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
