Description of problem: Problem occure only when HornetQ is installed. HornetQ hot redeploy of configuration triggers some sort of redeployment that closes JbpmConfiguration but doesn't 'open it' again. That results into BpmProcessor being broken and in some cases processes cannot be deployed. See steps to Reproduce for more info. Version-Release number of selected component (if applicable): HornetQ and EDS both present in SOA P 5.2 GA How reproducible: With SOA P 5.2 GA only. See the steps. Steps to Reproduce: 1. cd into bpm_orchestration1 2. ant deployProcess 3. modify deploy/hornetq/hornetq-configuration.xml and save (this will trigger redeploy) 4. now 'ant deployProcess' won't even deploy the process - exception is JbpmConfiguration(jbpm.cfg.xml) is closed Actual results: Expected results: Additional info:
I am setting this bug as a blocker. According to the PRD for SOA P 5.3, HornetQ is no longer in a technical preview.
GSS considers this of interest, calls it 'medium', and agrees it should be a blocker.
Associated HornetQ JIRA: https://issues.jboss.org/browse/JBPAPP-8710
Technical note added. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: Users encounter a problem when using HornetQ with JBPM. When HornetQ is hot deployed, an error occurs causing JBPM to crash. This causes some processes to remain undeployed.
Technical note updated. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. Diffed Contents: @@ -1 +1 @@ -Users encounter a problem when using HornetQ with JBPM. When HornetQ is hot deployed, an error occurs causing JBPM to crash. This causes some processes to remain undeployed.+Users encounter a problem when using HornetQ with jBPM. When HornetQ is hot deployed, an error occurs causing jBPM to crash. This causes some processes to remain undeployed.
Technical note updated. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. Diffed Contents: @@ -1 +1 @@ -Users encounter a problem when using HornetQ with jBPM. When HornetQ is hot deployed, an error occurs causing jBPM to crash. This causes some processes to remain undeployed.+Users encountered a problem when using HornetQ with jBPM. When HornetQ was hot deployed, an error occurred causing jBPM to crash. This caused some processes to remain undeployed.
Removed the JbpmConfiguration.close() from JbpmService. This allows the JbpmService to restart without causing the exception that the jbpm.cfg.xml is closed.
Tom Cunningham <tcunning> updated the status of jira JBESB-3828 to Resolved
Tom Cunningham <tcunning> updated the status of jira JBESB-3828 to Closed
Created attachment 597908 [details] Server log showing error
Verified. Works in ER5. No regression introduced.
It seems that it still breaks something (attaching logs). It doesn't work for ContentBasedRouter. Steps to reproduce: - run simple_cbr quickstart - modify HQ config - run simple_cbr_quickstart exception is very similar: e org.jboss.soa.esb.actions.ActionProcessingException: org.jboss.soa.esb.services.routing.MessageRouterException: Could not load lifecycle data. Resource already destroyed at org.jboss.soa.esb.actions.ContentBasedWiretap.process(ContentBasedWiretap.java:190) at org.jboss.soa.esb.actions.ContentBasedRouter.process(ContentBasedRouter.java:58) at org.jboss.soa.esb.listeners.message.ActionProcessingPipeline.processPipeline(ActionProcessingPipeline.java:665) at org.jboss.soa.esb.listeners.message.ActionProcessingPipeline.processPipeline(ActionProcessingPipeline.java:612) at org.jboss.soa.esb.listeners.message.ActionProcessingPipeline.process(ActionProcessingPipeline.java:442) at org.jboss.soa.esb.listeners.message.MessageAwareListener$TransactionalRunner.run(MessageAwareListener.java:587) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:662) Caused by: org.jboss.soa.esb.services.routing.MessageRouterException: Could not load lifecycle data. Resource already destroyed at org.jboss.internal.soa.esb.services.routing.cbr.JBossRulesRouter.route(JBossRulesRouter.java:141) at org.jboss.internal.soa.esb.services.routing.cbr.JBossRulesRouter.route(JBossRulesRouter.java:120) at org.jboss.soa.esb.actions.ContentBasedWiretap.executeRules(ContentBasedWiretap.java:202) at org.jboss.soa.esb.actions.ContentBasedWiretap.process(ContentBasedWiretap.java:174) ... 8 more Caused by: org.jboss.internal.soa.esb.services.rules.RuleServiceException: Could not load lifecycle data. Resource already destroyed at org.jboss.internal.soa.esb.services.rules.DroolsRuleService.getRuleBaseStateForFileBasedRules(DroolsRuleService.java:258) at org.jboss.internal.soa.esb.services.rules.DroolsRuleService.executeStatelessRules(DroolsRuleService.java:99) at org.jboss.internal.soa.esb.services.rules.RuleServiceCallHelper.executeStateless(RuleServiceCallHelper.java:291) at org.jboss.internal.soa.esb.services.rules.RuleServiceCallHelper.executeRulesService(RuleServiceCallHelper.java:283) at org.jboss.internal.soa.esb.services.routing.cbr.JBossRulesRouter.route(JBossRulesRouter.java:135) ... 11 more Caused by: org.jboss.soa.esb.lifecycle.LifecycleResourceException: Resource already destroyed at org.jboss.soa.esb.lifecycle.LifecycleResource.getLifecycleResource(LifecycleResource.java:113) at org.jboss.internal.soa.esb.services.rules.DroolsRuleService.getRuleBaseStateForFileBasedRules(DroolsRuleService.java:221) ... 15 more
Created attachment 598822 [details] Logs after the fix 01
I have been investigating this over the last few days and now understand what is happening. Both of these issues are related but are not the same, they are different effects/bugs which are triggered after the redeployment of the ESB artifacts. The MC redeploys all the artifacts by transitioning them through the destruction/creation lifecycle but retains the associated ClassLoader. The first issue is caused by the termination of the JbpmService and is already fixed by Tom and Marco's work in JBESB-3828. The gpd-deployer war should also have redeployed, in theory it was missing a dependency, but the Web Deployer explicitly disallows redeployment under these circumstances. The call to JbpmConfiguration.close() is irreversible and, due to the potential reuse of ClassLoaders, can no longer be used safely within the codebase. The second issue is caused by the lifecycle resources. Termination of the ESB deployments cause their associated resources to be cleaned and destroyed, in order to prevent leakage and allow for earlier detection of threads still using the old classloader, but this also prevents them functioning when the ClassLoader is reused during the redeploy. Unfortunately we have no known way of distinguishing whether the artifacts are transitioning through a redeploy or undeploy/deploy as they go through the same lifecycle phases (create, start, stop, destroy).
Kevin Conner <kevin.conner> updated the status of jira JBESB-3833 to Closed
Kevin Conner <kevin.conner> made a comment on jira JBESB-3833 Changes added in revision 38145.
Kevin Conner <kevin.conner> updated the status of jira JBESB-3833 to Reopened
Please verify this issue on 5.3.0 CR1.
Verified that both fixes are present and the redeployment breaks less functionalities. There still seems to be some problems caused by the redeployment. These will be investigated in different bugreport (https://bugzilla.redhat.com/show_bug.cgi?id=843719).