On Mon, May 7, 2012 at 11:05 PM, Mladen Turk <mt...@apache.org> wrote:
> 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. If you use sessions ( not everyone does ), and if you have huge timeouts. > > > > >> >> 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. Maybe I have false memories, but I think the method was first added because closing the listening socket didn't break the accept call ( in some VMs - that may be long obsolete ). > >> >>> 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. I see, you want a graceful shutdown, with a loadbalancer that uses the fact that the server rejects connections to indicate 'unhealthy' ( instead of some error code ). What about the listen backlog, even if you don't call accept it'll still ACK few connections that will timeout. Sorry, never used pause(), the lbs I know use status code from the health check, and the server is supposed to keep accepting connections until the LB figures things out ( and to be really 'graceful' the LB could keep sending requests for established sessions for a while, but not new sessions ). Well - +1, as long as you're sure the close() not unblocking accept() bug is no longer there ( may have been 10 years ago in 1.1, can't remember :-) 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 > >
