Restart a FAILED service?

[rgrzywinski]

I am attempting to understand the bounds of the Service lifecycle. I have a Service that throws on startService() (no other service depends on it). When I attempt to restart the service (via the JMX web console), I get no feed back; the service is neither started nor is any error logged. If I execute the "jbossInternalLifecycle()" method with a parameter of "start" (again, via the JMX console) the service is started.

Some fast and dirty debugging shows that start() is called (in ServiceMBeanSupport) which calls server.invoke(...). In here things get fuzzy as I am not familiar with the Invocation process. The bottom line is that jbossInternalStart() is never called.

Is this expected behavior? And if so, what is the motivation behind it?

[rgrzywinski]

Ah ha! I found the root cause:

ServiceController.start() : 340

And a similar "problem" in:

ServiceController.stop() : 426

So the question still stands: is it desired that a failed service cannot be restarted? And if so, why?

I can certainly see where, on initial startup, that you don't want a failed service to continually be re-start()'d while the dependecies are unwound. But after this, shouldn't a restart be allowed? This would allow a defective service to be repaired and restarted. Given ServiceController.start() (minus the offending check for FAILED), a restarted service will then finish starting any dependent services.

[rgrzywinski]

I was just thumbing through JSR77 to see what's the latest word on the FSM for a managed object and JSR 77.5.1.1.1 states:

FAILED (4)
This state indicates that the StateManageable Object has unexpectedly
stopped. On entering this state an SMO must generate an event whose type value is “j2ee.state.failed”. Event notification of the FAILED state is required by all managed objects that implement StateManageable. It may be possible to start an SMO that has entered the FAILED state by calling the start() operation. It may be possible to stop an SMO that has entered the FAILED state by calling the stop() operation. An SMO that cannot succesfully reach the RUNNING or STOPPED state from the FAILED state must reenter the FAILED state after the the attempt to reach the RUNNING or STOPPED state fails and emit another “j2ee.state.failed” event. An SMO that cannot succesfully reach the RUNNING or STOPPED state from the FAILED state requires intervention, such as redeployment, to restore the managed object to the desired state.

So it seems that ServiceController does not meet the JSR77 requirements (since it's not possible to go from FAILED to STOPPED or RUNNING in any way) -- at least by my interpretation of JSR77.

Note that I'm not assuming that ServiceController -should- meet JSR77, I'm simply saying that it does not.

Any feedback is appreciated.

[dimitris]

"rgrzywinski" wrote:
I was just thumbing through JSR77 to see what's the latest word on the FSM for a managed object and JSR 77.5.1.1.1 states:

FAILED (4)
This state indicates that the StateManageable Object has unexpectedly
stopped. On entering this state an SMO must generate an event whose type value is “j2ee.state.failed”. Event notification of the FAILED state is required by all managed objects that implement StateManageable. It may be possible to start an SMO that has entered the FAILED state by calling the start() operation. It may be possible to stop an SMO that has entered the FAILED state by calling the stop() operation. An SMO that cannot succesfully reach the RUNNING or STOPPED state from the FAILED state must reenter the FAILED state after the the attempt to reach the RUNNING or STOPPED state fails and emit another “j2ee.state.failed” event. An SMO that cannot succesfully reach the RUNNING or STOPPED state from the FAILED state requires intervention, such as redeployment, to restore the managed object to the desired state.

So it seems that ServiceController does not meet the JSR77 requirements (since it's not possible to go from FAILED to STOPPED or RUNNING in any way) -- at least by my interpretation of JSR77.

Note that I'm not assuming that ServiceController -should- meet JSR77, I'm simply saying that it does not.

Any feedback is appreciated.

I believe the idea is that if start() (or even create() in jboss) fails with an exception, then something is seriously wrong with the MBean and the MBean needs to be re-deployed. In most cases this is done by altering manually its deployment descriptor, saving, then the deployment scanner takes notice of this and re-deploys the MBean.

Cheers
/Dimitris

[rgrzywinski]

believe the idea is that if start() (or even create() in jboss) fails with an exception, then something is seriously wrong with the MBean and the MBean needs to be re-deployed.

That sounds like a developer excuse more than any form of explanation so let's take a different approach:

Why are services not compliant with the JSR-77 state chart (lifecycle) and what was the motivation behind not allowing failed services to transition to the RUNNING or STOPPED states (e.g. is there some technical limitation in the design of JBoss' services that precludes it)?