That method will use the same thread pool as the MSC service threads, so
using that method for blocking stuff doesn't actually help.
Also worth noting is that all of these rules also apply to listener methods.
The execute() method is, however, good for parallelizing
computation-heavy start/stop tasks, and also for running (non-blocking)
tasks at runtime.
Note that the problem isn't the task duration, it's the fact that an
external factor (meaning, other than available CPU) then takes control
of the state machine execution.
On 04/13/2011 03:48 PM, Brian Stansberry wrote:
Is use of LifecycleContext.execute(Runnable) recommended? For anyone
doing as you say and using LifecycleContext.asynchronous() and
complete(), using that execute() method is going to be a path of least
resistance.
On 4/13/11 2:55 PM, David M. Lloyd wrote:
> When writing MSC service implementations, your start() and stop()
> methods must never block. This means these methods must not:
>
> - Establish or use network connections
> - Wait for network connections
> - Sleep
> - Wait on a condition
> - Wait on a count down latch
> - Call any method which may do any of the above
> - Wait for termination of a thread pool or other service
> - Wait for another service to change state!
>
> If your service start/stop involves any of these tasks, you must use the
> asynchronous start/stop mechanism (context.asynchronous()) and do one of
> the following:
>
> - Initiate your task in start()/stop(), and utilize a callback (NIO,
> ThreadPoolExecutor.terminated(), etc.) to call context.complete() when
> your start/stop completes instead of blocking
> - Delegate your blocking task to a thread pool (Executor) which calls
> context.complete() when done
> - Use proper dependencies instead of explicitly waiting for services in
> your start/stop
>
> Failure to do so can cause startup delays and can even lock up the MSC
> state machine! If you are unsure what the best approach is for your
> problem, ping me in #jboss-as7 or #jboss-msc and I'll help you out.
>
--
- DML