"bstansberry(a)jboss.com" wrote : "emuckenhuber" wrote : Hmm graceful
shutdown should not be part of the MC bean lifecycle, as it would then always shutdown in
a graceful manner. This should be an optional way to shutdown AS - triggered with a
different signal or management action.
| | Additionally with the graceful shutdown there will most likely be a timeout which
then is going just stop AS. This does not seem to fit very well with MC lifecycle actions,
since we would basically need to interrupt a action during a state transition (pre_stop
-> stop).
|
| With the acceptor concept we should be able to deal with these issues even though
we're essentially using the MC lifecycle.
|
| The acceptors can all be registered with a central management bean that can set a
property as to how long they should wait to return from stop(). -1, don't do anything,
just return, 0 wait as long as it takes, > 0, wait that long. The default is -1 or
something configurable at the server level. The management console sets to something else
if a graceful shutdown is invoked.
As I wrote this it felt hacky, and it is. Emanuel, your instincts and Jason's are
right; this isn't really an MC issue. It's a step in the shutdown process that
occurs before the normal undeployment process starts. If we have a bunch of acceptors,
whatever is controlling the shutdown can tell them to stop; we don't need the MC to do
it. That is back to the original design we discussed in Westford.
"jason.greene(a)redhat.com" wrote : Let me give an example. Someone defines a
service A, which supports remote invocation. There is no dependency between service A and
the EJB container (Service B), because it doesn't make sense (they have nothing to do
with each other). Then instance SFSB Foo of Service B *dynamically* decides to call
service A during an invocation. Then during "graceful" shutdown, service A is
stopped first.
Jason, are you concerned about solving this case (eventually), or are you just using it to
make a point about dependencies? Segregating internal calls from those coming via remote
endpoints, and then closing off the remote endpoints before stopping/undeploying anything
will handle most such cases. The only ones it won't are where Service B makes a remote
call to non-HA Service A, even though both are deployed locally. Which case is IMHO out of
scope. :-)
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4267561#...
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&a...