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 Tue, 08 May 2012 18:47:33 GMT
On Tue, May 8, 2012 at 11:01 AM, Mladen Turk <mturk@apache.org> wrote:

> On 05/08/2012 07:09 PM, Costin Manolache wrote:
>
>> IMHO neither 'graceful shutdown' nor 'deploy' are best served by not
>> accepting connections:
>> - for 'graceful' - a number of connections will get to backlog and
>> timeout,
>>
>
> Not sure if ServerSocket.close() would cause cascade close of all
> accepted sockets that are still running. If not, even pause could
> just close the socket and then init if needed.
> In that case clients will not fill the backlog.


You may still want to accept requests for existing sessions.

Both 'graceful shutdown' and app deploy are important cases - it's just
that current 'pause()' is not that good for either of them, if you really
want to cleanup...

Maybe an option to return 503 or custom status/headers - so people can
adjust to various LBs.

Costin


>
>
>  which is bad for the user. A better solution would be to support an option
>> to accept and return immediately ( maybe with a way to do this only for
>> requests not matching any existing session ). I never worked with a LB
>> that
>>  detects status based only on not accepting connections and timeout.
>>
>>
> Hmm, right, a valid option if LB won't get confused.
>
>
>
>> Besides that - is there any other use for pause() ? Maybe that's what
>> should be removed/replaced :-). The behavior ( delay/timeout all TCP
>> connections until backlog is full, then reject ) doesn't seem ideal.
>>
>>
> Agreed. A 'pause' or invalidating backed node should be done in LB.
> We are doing that in mod_jk, mod_proxy, mod_cluster, etc.
> If LB wrongly instructs the clients to connect to a node that is going to
> get shutdown we can't do much about it. Client will experience one
> or other type of connection failures.
>




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