Red Hat Bugzilla – Bug 862296
IllegalArgumentException when opening Business Central
Last modified: 2016-07-31 21:14:50 EDT
Created attachment 620325 [details] Repository export to reproduce the problem Description of problem: Once a process with a faulty script task has been deployed, business-central can no longer be used, even if the bug in the affected process has been fixed. How reproducible: Always Steps to Reproduce: 1. Import the repository into the BRMS. 2. Export the POJO PricingModel.jar to <BRMS_HOME>/jboss-as/server/default/lib 3. Restart the BRMS server 4. Login to jboss-brms and edit process1 and remove the code "kcontext.getKnowledgeRuntime().insert(_driver);" in the first Script Task 5. Save and build the defaultPackage 6. Login to businses-central and start process1 with 0 for both parameters.Error should be resulted. 7. Go to jboss-brms and edit process1 and add back the code "kcontext.getKnowledgeRuntime().insert(_driver);" in the first Script Task 8. Save and build the defaultPackage 9. Login to businses-central and start process1 with 0 for both parameters. Process instance should be started this time. 10. Restart the BRMS server 11. Login to business-central and then the issue comes out Actual results: After logging into business-central, no operation is possible and the following error can be found in the log file: ERROR [org.drools.persistence.SingleSessionCommandService] (http-127.0.0.1-8080-1) Could not commit session org.drools.RuntimeDroolsException: Unexpected exception executing action org.jbpm.process.instance.event.DefaultSignalManager$SignalAction@2c766624 at org.drools.common.AbstractWorkingMemory.executeQueuedActions(AbstractWorkingMemory.java:978) at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:706) at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:673) at org.jbpm.integration.console.StatefulKnowledgeSessionUtil$2.afterRuleFlowGroupActivated(StatefulKnowledgeSessionUtil.java:361) at org.drools.event.AgendaEventSupport.fireAfterRuleFlowGroupActivated(AgendaEventSupport.java:137) at org.drools.common.RuleFlowGroupImpl.setActive(RuleFlowGroupImpl.java:134) at org.drools.common.DefaultAgenda.activateRuleFlowGroup(DefaultAgenda.java:830) at org.drools.runtime.rule.impl.AgendaImpl.activateRuleFlowGroup(AgendaImpl.java:74) ... Caused by: java.lang.IllegalArgumentException: FactHandle cannot be null at org.drools.common.NamedEntryPoint.retract(NamedEntryPoint.java:507) at org.drools.common.AbstractWorkingMemory.retract(AbstractWorkingMemory.java:919) at org.drools.common.AbstractWorkingMemory.retract(AbstractWorkingMemory.java:907) at org.drools.impl.StatefulKnowledgeSessionImpl.retract(StatefulKnowledgeSessionImpl.java:271) at defaultPackage.Process_defaultPackage_process1.action3(Process_defaultPackage_process1.java:29) at defaultPackage.Process_defaultPackage_process1Action3Invoker.execute(Process_defaultPackage_process1Action3Invoker.java:16) at org.jbpm.workflow.instance.node.ActionNodeInstance.internalTrigger(ActionNodeInstance.java:47) Expected results: Business central working despite the old erroneous process definition.
added link to jira issue for reference and some comments
Maciej Swiderski <swiderski.maciej@gmail.com> made a comment on jira JBPM-3722 here comes more update on the issue. Looks like it is caused by identity id generator which causes commit as soon as process instance is created (ProcessInstanceInfo). After updating persistence configuration to use sequences instead problem does not exist any more and ProcessInstanceInfo is rolled back as expected. Although ProcessInstanceLog remains in the data base even though rollback was issued. That would indicate that following data bases can be affected: DB2, MySQL, MS SQL Server, Sybase and HypersonicSQL (according to hibernate documentation) Recent test performed on latest master built with intaller which deployes on JBoss AS 7.1.1 with JPA2/hibernate 4 configuration. Two data base were tested: - H2 (default) - required change in persistence configuration to make use of sequences and in JPAWorkingMemoryDbLogger to do not flush,clear,close after each operation to avoid record be committed regardless of the rollback - PostgreSQL - without any changes and changes to use sequences Attached is persistence configuration for runtime engine that allows to run mentioned processes with expected results and without any limitations. In addition attaching very simple process that illustrates problem that could be simply used to reproduce problem on data bases that support/rely by default on identity column for id generation. Would be great if someone could give a try with described changes and confirm my findings.
Maciej Swiderski <swiderski.maciej@gmail.com> made a comment on jira JBPM-3722 this is persistence configuration for H2 data base that fixed the problem
Maciej Swiderski <swiderski.maciej@gmail.com> made a comment on jira JBPM-3722 simple reproducer process
Alessandro, Martin, could you let me know what data base was used when this issue was encountered?
Maciej, the issue was raised by a consultant who has preparing a demo. No database specific configuration was applied, as the default database was used. HTH, Martin
Maciej Swiderski <swiderski.maciej@gmail.com> updated the status of jira JBPM-3722 to Resolved
Maciej Swiderski <swiderski.maciej@gmail.com> made a comment on jira JBPM-3722 this issue is caused by limited capabilities of H2 data base - based on investigation performed. Applied changes to db configuration to avoid problems with left inserts after transaction rollback. NOTE: this issue was not reproduced on any "real" data base thus resolving it with workaround for H2 data base.
in addition to comment below, I would like to suggest to perform tests on real data bases (mysql, postgresql, oracle or db2) to confirm this is only issue with embedded db. Tested with H2 and HSQLDB on AS 7.1.1 - works fine with following comments: - data base must be configured as in process db (for instance jdbc:h2:~/jbpm) - BIRT report definitions need to use data source from JNDI as in process db is accessible only from within single process - for hsqldb latest driver version is required as 1.8.0 does not work with hibernate4 commit with changes for H2: https://github.com/droolsjbpm/jbpm/commit/af3ca1ddf96e64134baa2f7c48a7219593d8bb76
I have tried this with BRMS 5.3.1 ER3: (- standalone and the default database - derby) - EAP 6, ee6 bundle, PostgreSQL 9.1 It worked well (both dbs), no changes needed. I'm gonna try MySQL next, as soon as I can.
My bad, it actually does not work with either of these (derby, postgresql, mysql). It just takes a few seconds to manifest - I probably didn't wait long enough the first time. Sorry for that mistake.
Fix applied to ensure that in case of exception is thrown on fireAllRules that is invoked on session initialization will not break the initialization and will not make session not accessible. Although it fixes this issue it revealed another one with handling of business rule tasks (see also bz). Due to the BZ872548 process that was started after fixing script task got stuck on business rule task instead of being moved to user task and caused exception after server restart.
I have updated the doc text for the Release Notes. Thanks for the information. - Doug
Verified on EAP6 and PostgreSQL 9.1.