Paul Ferraro wrote:
> CTRL-C.
>
That will shutdown gracefully, triggering all of the appropriate
shutdown events.
Good to know
>>> * Now I have 80 failed clients and 0 active clients !
>> OK - that's weird. Let me try to reproduce this on my end.
>
> OK
>
I could not reproduce this. The only threads that should report errors
are the ones that were currently being processed by that server - these
will not failover to the other server. Though it is unlikely that all
80 threads were all being processed (i.e. not queued) by the server that
you stopped, I'm not sure what else could cause all 80 clients to fail.
Please regurgitate all of the input values you used in the demo app.
OK. I'll try to reproduce this problem and make sure to write down the
exact steps if I can reproduce it.
>>> * If I call Server.shutdown() on node2 (via JMX), then node1 serves
>>> 40 sessions. But why does node1 not pick up the other 40 sessions
>>> from left node2 ? Is this the client, which simply terminates
>>> threads which got a 500 ?
>> Yes
> Why don't we change that, and ignore HTTP error responses ? This way,
> eventually, all clients would fail over to the running node.
>
I should clarify - not all requests failover - only those requests not
yet accepted by target server's connector. It would be dangerous to
failover requests already accepted by the target connector.
Can this be configured ? In mod-jk, there were IIRC 4 configuration
possibilities for retrying
> Agreed. But the graceful shutdown case (maybe complemented with
a
> shutdown hook) should allow us to tell httpd to redirect requests for
> all apps of a given node before the node shuts down.
>
We are doing that. Currently, mod_cluster responds to context and
server STOP_EVENTs. Really, we should be using BEFORE_STOP_EVENT to
notify mod_cluster before any threads are interrupted. I've made this
change in trunk.
OK
--
Bela Ban
Lead JGroups / Clustering Team
JBoss - a division of Red Hat