tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Thomas <>
Subject Re: Purpose of unlockAccept
Date Tue, 08 May 2012 10:28:52 GMT
On 08/05/2012 07:41, Mladen Turk wrote:
> On 05/08/2012 08:34 AM, Costin Manolache wrote:
>> On Mon, May 7, 2012 at 11:05 PM, Mladen Turk<>  wrote:
>>> 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.
> The current patch I've send doesn't use timeout.
> If paused a single connection will get accepted but not
> processed thus behaving exactly like backlog.
> Later if continued (pause during deploy) it'll be processed or
> closed (exactly like backlog behaves).
>> 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
>> :-)
> Well, the javadocs for ServerSocket.close() says:
> Closes this socket.
> Any thread currently blocked in accept() will throw a SocketException.

I did some svn / BZ archaeology.

The unlocking of the acceptor was introduced [1] in response to a bug
report [2]. It appears that this was indeed working around a long since
fixed JVM bug [3].

Given this, I have no objections to Mladen's propose changes. I would
ask that a note is added to the docs and the Javadoc that explains that
pausing a socket effectively adds one to the current value of the
backlog. The only downside I can see is if someone wants zero backlog on
pause. That is no longer going to be possible.



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

View raw message