Mailing-List: contact dev-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Developers List" <dev@tomcat.apache.org>
Received-SPF: pass (nike.apache.org: domain of costin@gmail.com designates
 209.85.214.173 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <4FA95F93.6080903@apache.org>
References: <4FA7F738.9060401@apache.org>
	<CAP8-Fqn+0yVL8bz3QbGnDmz_PaFxht2zSfVas7JJB4w0GGXzUA@mail.gmail.com>
	<4FA85061.1010301@apache.org>
	<CAP8-FqkgM4NGj8+uPpk+gi3T+qVM8WsmeGoVOejeAFLsF=Ax9A@mail.gmail.com>
	<4FA8B799.9060505@apache.org>
	<CAP8-Fqkp47vZ1--dM4Osb+NY0LBQ5L7FrJogwciAW_OywnckQw@mail.gmail.com>
	<4FA8C033.1070801@apache.org>
	<4FA8F564.5010108@apache.org>
	<CAP8-Fq=kGEVDJrBH1YadFGs68TzQOFUydsvopfvZ9dXLh9HuYw@mail.gmail.com>
	<4FA95F93.6080903@apache.org>
Date: Tue, 8 May 2012 11:47:33 -0700
Message-ID: 
 <CAP8-Fq=gAripg+rMFJEXYAWCtmNJTX7Z5PDwBCZ_9PA2H=mYKg@mail.gmail.com>
Subject: Re: Purpose of unlockAccept
From: Costin Manolache <costin@gmail.com>
To: Tomcat Developers List <dev@tomcat.apache.org>
Content-Type: multipart/alternative; boundary=f46d0444ece5ccf04704bf8ad130

--f46d0444ece5ccf04704bf8ad130
Content-Type: text/plain; charset=UTF-8

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

--f46d0444ece5ccf04704bf8ad130--