Close ProcessEngine upon BPM console undeployment

[aguizar]

Regarding JBPM-2881, it seems the process engine is not closed when the BPM console is undeployed. ProcessEngineImpl stops the job executor on close. However, the job dispatcher thread is still running after the web application stops, as evidenced by the following stack trace.

22/06/2010 08:43:28 PM org.apache.catalina.loader.WebappClassLoader loadClass
INFO: Illegal access: this web application instance has been stopped already.
Could not load org.jbpm.pvm.internal.tx.StandardTransaction.
The eventual following stack trace is caused by an  error thrown for debugging purposes
as well as to attempt to terminate the thread which caused the illegal access,
and has no functional impact.
java.lang.IllegalStateException
    at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1402)
    at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1361)
    at org.jbpm.pvm.internal.util.ReflectUtil.classForName(ReflectUtil.java:453)
    at org.jbpm.pvm.internal.wire.descriptor.ObjectDescriptor.construct(ObjectDescriptor.java:141)
    at org.jbpm.pvm.internal.wire.WireContext.construct(WireContext.java:487)
    at org.jbpm.pvm.internal.wire.WireContext.create(WireContext.java:466)
    at org.jbpm.pvm.internal.wire.WireContext.create(WireContext.java:455)
    at org.jbpm.pvm.internal.wire.WireContext.get(WireContext.java:429)
    at org.jbpm.pvm.internal.wire.WireContext.get(WireContext.java:339)
    at org.jbpm.pvm.internal.wire.WireContext.get(WireContext.java:706)
    at org.jbpm.pvm.internal.env.BasicEnvironment.get(BasicEnvironment.java:132)
    at org.jbpm.pvm.internal.env.BasicEnvironment.get(BasicEnvironment.java:123)
    at org.jbpm.pvm.internal.tx.StandardTransactionInterceptor.execute(StandardTransactionInterceptor.java:46)
    at org.jbpm.pvm.internal.svc.EnvironmentInterceptor.executeInNewEnvironment(EnvironmentInterceptor.java:53)
    at org.jbpm.pvm.internal.svc.EnvironmentInterceptor.execute(EnvironmentInterceptor.java:40)
    at org.jbpm.pvm.internal.svc.RetryInterceptor.execute(RetryInterceptor.java:56)
    at org.jbpm.pvm.internal.svc.SkipInterceptor.execute(SkipInterceptor.java:43)
    at org.jbpm.pvm.internal.jobexecutor.DispatcherThread.acquireJobs(DispatcherThread.java:126)
    at org.jbpm.pvm.internal.jobexecutor.DispatcherThread.run(DispatcherThread.java:67)

I did not develop the console integration and lack the knowledge required to place the ProcessEngine.close() call properly. Any pointers in this direction would be very helpful.

[swiderski.maciej]

My first question would be - do we really need to close ProcessEngine upon console undeployment? I can think of few cases where such approach could be dangerous - just because console was down (either by administrator or server failure) whole process engine will be stopped. Is this desired?

In my opinion console shall be treated as optional (non intrusive) component so removing it shall not affect the process engine.

Does it affect only Tomcat?

If it comes to probable solution, we could register listeners (ServletContectListeners) for console to close down process engine on application destroy.

[rebody]

I am agree with Maciej.

It is only happened when ProcessEngine is started as a part of console.  It is the console's job to shutdown the processEngine when it was undeployed.  All we could do on ProcessEngine is catch the Exception and print a log for IllegalStateException.

[aguizar]

My first question would be - do we really need to close ProcessEngine upon console undeployment? I can think of few cases where such approach could be dangerous - just because console was down (either by administrator or server failure) whole process engine will be stopped. Is this desired?

In my opinion console shall be treated as optional (non intrusive) component so removing it shall not affect the process engine.

Does it affect only Tomcat?

The process engine needs to be closed by the module that created it. In JBoss AS this is already covered since jBPM is deployed as a service. The JbpmService bean correctly closes the engine on stop.

In Tomcat the situation is more complicated. Because it lacks the notion of services, the jbpm-console app creates the process engine itself. The  engine cannot be managed by a separate module and shared via JNDI because Tomcat provides a read-only initial context.

In fact, the situation is aggravated due to Configuration.getProcessEngine() returning a shared instance. I take this method to be a formal equivalent of the HibernateUtil class in standalone environments. Unfortunately, it is tempting to call this method from within containers, where it is totally insane. The engine becomes reachable from the entire VM and there is no clear point at which it can be closed.

If it comes to probable solution, we could register listeners (ServletContectListeners) for console to close down process engine on application destroy.

This would be an option if the shared ProcessEngine could be closed on servlet context destruction, which is not possible as said before. If the servlet context listener built its own unshared engine on initialization, it could close it on destruction. Unfortunately such an engine is unreachable for the console integration components. In a typical web app it would be set  as an attribute of the servlet context, but the servlet context itself is unreachable as well.

One promising alternative I want to investigate is the Tomcat custom resource factory. There is prior art in this direction involving the Hibernate session factory.

[swiderski.maciej]

Alejandro Guizar wrote:

The process engine needs to be closed by the module that created it. In JBoss AS this is already covered since jBPM is deployed as a service. The JbpmService bean correctly closes the engine on stop.

I agree if you deploy jbpm and console as stand alone process engine, but what in case when there is application (user webapp) using jbpm and console is only for administration purpose and does not need to be running all the time? Then in my opinion web app should be the owner of the process engine and not the console. This is what I meant in my previous post.

Alejandro Guizar wrote:

If it comes to probable solution, we could register listeners (ServletContectListeners) for console to close down process engine on application destroy.

This would be an option if the shared ProcessEngine could be closed on servlet context destruction, which is not possible as said before. If the servlet context listener built its own unshared engine on initialization, it could close it on destruction. Unfortunately such an engine is unreachable for the console integration components. In a typical web app it would be set  as an attribute of the servlet context, but the servlet context itself is unreachable as well.

I was thinking that it could be treated as configuration option (for example using JVM parameters) if ServletContext shall start and destroy process engine. In such case it won't be only Tomcat specific solution but could be used by any other J2EE application server.

It will be probably used when running jbpm embedded in web application, once the web app is deployed console will use already created process engine.

Alejandro Guizar wrote:

One promising alternative I want to investigate is the Tomcat custom resource factory. There is prior art in this direction involving the Hibernate session factory.

This sounds really good. Looking forward to results of your investigation.

[rebody]

Hi Alejandro,

If you want to prevent close a shared processEngine,  we could igore the Configuration.getProcessEngine(),  and let ServletContextListener to maintain the lifecycle of the processEngine.  Maybe put the processEngine into the ServletContex scope of console webapp is a solution to solve that.

I think this is easier for people to understand and use.