On 05/08/2012 01:13 AM, Costin Manolache wrote:
On Mon, May 7, 2012 at 3:44 PM, Mladen Turkmt...@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
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 Turkmt...@apache.org wrote:
On 05/07/2012 11:05 PM, Costin Manolache wrote:
By 'unlockAccept' you mean the socket connection made
On 05/08/2012 08:34 AM, Costin Manolache wrote:
On Mon, May 7, 2012 at 11:05 PM, Mladen Turkmt...@apache.org 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
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 Turkmt...@apache.org 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 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
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
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
On Tue, May 8, 2012 at 11:01 AM, Mladen Turk mt...@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
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 option to
On Tue, May 8, 2012 at 11:54 AM, Mark Thomas ma...@apache.org 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
On 08/05/2012 21:09, Costin Manolache wrote:
On Tue, May 8, 2012 at 11:54 AM, Mark Thomas ma...@apache.org 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
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: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 'pause()' is not
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 handling single
connection received after pause
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
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
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,
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
18 matches
Mail list logo
