Bug 862296 - IllegalArgumentException when opening Business Central
IllegalArgumentException when opening Business Central
Product: JBoss Enterprise BRMS Platform 5
Classification: JBoss
Component: jBPM 5, jBPM Console (Show other bugs)
BRMS 5.3.0.GA
Unspecified Unspecified
high Severity high
: ER4
: BRMS 5.3.1 GA
Assigned To: Maciej Swiderski
Lukáš Petrovický
Depends On:
  Show dependency treegraph
Reported: 2012-10-02 10:44 EDT by Martin Weiler
Modified: 2016-07-31 21:14 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Business Central was no longer able to be used when a process with a faulty script task was deployed after the fireAllRules method had been initialized. This occurred because the underlying knowledge session was not completely initialized as it was interrupted by the exception. This has been fixed by ensuring the exception thrown on the session initialization does not break the initialization. This result logs the session initialization exceptions on fireAllRules and continues with an unbroken session initialization.
Story Points: ---
Clone Of:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
kverlaen: needinfo+

Attachments (Terms of Use)
Repository export to reproduce the problem (208.86 KB, application/zip)
2012-10-02 10:44 EDT, Martin Weiler
no flags Details

External Trackers
Tracker ID Priority Status Summary Last Updated
JBoss Issue Tracker JBPM-3722 Major Resolved jbpm-console throws null pointer reading process instance 2014-08-07 05:38:16 EDT

  None (edit)
Description Martin Weiler 2012-10-02 10:44:47 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:

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- 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.
Comment 1 Maciej Swiderski 2012-10-03 12:08:07 EDT
added link to jira issue for reference and some comments
Comment 2 JBoss JIRA Server 2012-10-05 12:20:53 EDT
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.
Comment 3 JBoss JIRA Server 2012-10-05 12:24:11 EDT
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
Comment 4 JBoss JIRA Server 2012-10-05 12:27:05 EDT
Maciej Swiderski <swiderski.maciej@gmail.com> made a comment on jira JBPM-3722

simple reproducer process
Comment 8 Maciej Swiderski 2012-10-17 01:35:11 EDT
Alessandro, Martin, could you let me know what data base was used when this issue was encountered?
Comment 9 Martin Weiler 2012-10-17 03:02:11 EDT

the issue was raised by a consultant who has preparing a demo. No database specific configuration was applied, as the default database was used.

Comment 10 JBoss JIRA Server 2012-10-17 13:14:24 EDT
Maciej Swiderski <swiderski.maciej@gmail.com> updated the status of jira JBPM-3722 to Resolved
Comment 11 JBoss JIRA Server 2012-10-17 13:14:24 EDT
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.
Comment 12 Maciej Swiderski 2012-10-17 13:24:03 EDT
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
Comment 13 Zuzana Krejčová 2012-10-18 07:07:11 EDT
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.
Comment 14 Zuzana Krejčová 2012-10-30 09:06:16 EDT
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.
Comment 15 Maciej Swiderski 2012-11-02 08:53:31 EDT
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.
Comment 16 Douglas Hoffman 2012-11-08 22:37:48 EST
I have updated the doc text for the Release Notes. Thanks for the information.

- Doug
Comment 17 Zuzana Krejčová 2012-11-13 05:05:20 EST
Verified on EAP6 and PostgreSQL 9.1.

Note You need to log in before you can comment on or make changes to this bug.