Bug 862296 - IllegalArgumentException when opening Business Central
Summary: IllegalArgumentException when opening Business Central
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: JBoss Enterprise BRMS Platform 5
Classification: JBoss
Component: jBPM 5, jBPM Console
Version: BRMS 5.3.0.GA
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: ER4
: BRMS 5.3.1 GA
Assignee: Kris Verlaenen
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-10-02 14:44 UTC by Martin Weiler
Modified: 2025-02-10 03:20 UTC (History)
2 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2025-02-10 03:20:53 UTC
Type: Bug
Embargoed:
kverlaen: needinfo+


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


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 872548 0 unspecified CLOSED Duplicated main agenda group on session reset 2025-02-10 03:21:03 UTC
Red Hat Issue Tracker JBPM-3722 0 Major Resolved jbpm-console throws null pointer reading process instance 2014-08-07 09:38:16 UTC

Internal Links: 872548

Description Martin Weiler 2012-10-02 14:44:47 UTC
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.

Comment 1 Maciej Swiderski 2012-10-03 16:08:07 UTC
added link to jira issue for reference and some comments

Comment 2 JBoss JIRA Server 2012-10-05 16:20:53 UTC
Maciej Swiderski <swiderski.maciej> 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 16:24:11 UTC
Maciej Swiderski <swiderski.maciej> 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 16:27:05 UTC
Maciej Swiderski <swiderski.maciej> made a comment on jira JBPM-3722

simple reproducer process

Comment 8 Maciej Swiderski 2012-10-17 05:35:11 UTC
Alessandro, Martin, could you let me know what data base was used when this issue was encountered?

Comment 9 Martin Weiler 2012-10-17 07:02:11 UTC
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

Comment 10 JBoss JIRA Server 2012-10-17 17:14:24 UTC
Maciej Swiderski <swiderski.maciej> updated the status of jira JBPM-3722 to Resolved

Comment 11 JBoss JIRA Server 2012-10-17 17:14:24 UTC
Maciej Swiderski <swiderski.maciej> 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 17:24:03 UTC
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 11:07:11 UTC
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 13:06:16 UTC
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 12:53:31 UTC
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-09 03:37:48 UTC
I have updated the doc text for the Release Notes. Thanks for the information.

- Doug

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

Comment 25 Red Hat Bugzilla 2025-02-10 03:20:53 UTC
This product has been discontinued or is no longer tracked in Red Hat Bugzilla.


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