On 08/05/2012 21:33, Mladen Turk wrote:
> On 05/08/2012 08:54 PM, Mark Thomas wrote:
>> On 08/05/2012 19:47, Costin Manolache wrote:
>>> You may still want to accept requests for existing sessions.
>>>
>>> Both 'graceful shutdown' and app deploy are important cases - it's just
>>> that current 'pau
On 05/08/2012 08:54 PM, Mark Thomas wrote:
On 08/05/2012 19:47, Costin Manolache wrote:
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
On 08/05/2012 21:09, Costin Manolache wrote:
> On Tue, May 8, 2012 at 11:54 AM, Mark Thomas wrote:
>> pause() on the connector means something very different to pause in the
>> reverse proxy. In the connector pause means:
>> - stop processing new connections
>> - close existing connections
>> - k
On Tue, May 8, 2012 at 11:54 AM, Mark Thomas wrote:
> On 08/05/2012 19:47, Costin Manolache wrote:
> > 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 eithe
On 08/05/2012 19:47, Costin Manolache wrote:
> 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 opt
On Tue, May 8, 2012 at 11:01 AM, Mladen Turk 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 su
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 sock
Thanks for looking it up :-)
+1 on removing it anyways - but it would be good to add some javadocs on
the pause() method, I never understood the use case.
IMHO neither 'graceful shutdown' nor 'deploy' are best served by not
accepting connections:
- for 'graceful' - a number of connections will ge
On 05/08/2012 12:28 PM, Mark Thomas wrote:
The only downside I can see is if someone wants zero backlog on
pause. That is no longer going to be possible.
According to javadocs setting socket's backlog to zero means 'OS default'
so this is not reliable anyhow.
Regards
--
^TM
-
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 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 h
On Mon, May 7, 2012 at 11:05 PM, Mladen Turk wrote:
> On 05/08/2012 01:13 AM, Costin Manolache wrote:
>
>> On Mon, May 7, 2012 at 3:44 PM, Mladen Turk wrote:
>>
>> On 05/07/2012 11:05 PM, Costin Manolache wrote:
>>>
>>> By 'unlockAccept' you mean the socket connection made to the acceptor to
>
On 05/08/2012 01:13 AM, Costin Manolache wrote:
On Mon, May 7, 2012 at 3:44 PM, Mladen Turk 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()
On Mon, May 7, 2012 at 3:44 PM, Mladen Turk 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 clo
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, m
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.
Costin
On Mon, May 7, 2012 at 9:24 AM, Mladen Turk wrote:
On 05/07/2012 08:48 PM, Mark Thomas wrote:
I'm not entirely clear on what you are proposing. Can you provide a
proposed patch for this?
Sure.
Need to port that to trunk and new AbstractEndpoint.
Attached is a patch for something similar to tomcat7 :)
just to get an idea.
AFAICT this is not
On 07/05/2012 17:24, Mladen Turk wrote:
> Hi
>
> Did some testing and removing unlockAccept works equally
> fine (and in some circumstances pause/continue and even shutdown is much
> faster).
> Using a simple socket close on stop/destroy and monitoring
> for pause 'after' acceptSocket() by not han
18 matches
Mail list logo
