Bug 805899
| Summary: | BaseTransaction.rollback - no transaction! occurs occasionally when multiple threads use persistence | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [JBoss] JBoss Enterprise BRMS Platform 5 | Reporter: | Jiri Svitak <jsvitak> | ||||||
| Component: | jBPM 5 | Assignee: | Marco Rietveld <mrietvel> | ||||||
| Status: | CLOSED WONTFIX | QA Contact: | Jiri Svitak <jsvitak> | ||||||
| Severity: | high | Docs Contact: | |||||||
| Priority: | unspecified | ||||||||
| Version: | BRMS 5.3.0.GA | CC: | atangrin, brms-jira, kverlaen, lpetrovi, mbaluch, rzhang, smcgowan, tschloss | ||||||
| Target Milestone: | --- | ||||||||
| Target Release: | BRMS 5.3.0.GA | ||||||||
| Hardware: | Unspecified | ||||||||
| OS: | Unspecified | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2012-12-05 11:57:52 UTC | Type: | Bug | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Attachments: |
|
||||||||
I have created a pull request with a test case. You have to run for example 100 loops to see that sometimes the exception is thrown. https://github.com/droolsjbpm/jbpm/pull/66 *** Bug 803831 has been marked as a duplicate of this bug. *** I've gone through the tests today. As far as I can tell, the bug that's showing up in the logs is because the test -- even though Thread.join() was being used -- was ending before the threads using persistence were done. This meant that the @After method was called in which, among other things, the Bitronix transaction manager was cleaned up -- while the test threads were still running. Once I made sure that the tests waited until the threads completed, then this bug no longer happened. A bug that I did see is that not all threads were started and/or completed -- regardless of whether persistence was used or not. But this seems to be related to the amount of memory/thread limits being used in the JVM. --- In short, I'd like to reject and close this bug because I can not find any evidence that there is a problem with concurrency and persistence. If you find anything that says otherwise, please let me know. Otherwise, I would like to close this bug by the end of the week. I do not agree. The @After method is called only after the whole test. Exceptions were occurring randomly during the test. What you say would mean that @After method is called after each loop, which is not true. Maybe the problem will occur also without persistence, but I thought that since the exception comes from transactions, then it's persistence dependent problem. If these problems are still occuring with you, could you do the following for me? - Add a System.out.println (or similar) to the @After method so that we know exactly when it fires in the test. - Please than also attach a log to this bug of the test failing. Thanks! Jiri, See the attached test-log for an exception that occurs. This exception occurs because there are 2 knowledge sessions and is a known bug. Fixing this bug is out of scope for BRMS 5.3 -- I've checked this with Mark. It is currently not recommended to run multiple processes on different knowledge sessions. If there is only one knowledge session, then there is a synchronized method that ensures that each process's persistence logic happens in isolation -- and not simultaneously with the persistence logic of another process. However, if there are multiple knowledge sessions, there is no way to ensure that different processes (on the different knowledge sessions) don't simultaneously interact with the database. When they do simultaneously interact with the database, there's a possible deadlock situation that's shown in the log I attached: one knowledge session/process has a lock on the SessionInfo table while the other one has a lock on the ProcessInstanceInfo table. I haven't been able to recreate the bug/stacktrace that this bug is about. Created attachment 578116 [details]
Test Log output from ProcessMultiThreadPersistenceTest
Thanks for your findings about this issue. If this issue is not going to be fixed in BRMS 5.3.0, then at least documentation about multithreading should be updated to exactly describe what is the jBPM capable of. I've updated the documentation. Update status to ON_QA. Please verify them against ER6. Confirmed that not picked in ER6. Change status back. This bug won't be fixed in BRMS 5.3.x. If the problem will be found in future versions, a new bug will be reported. Closing the bug. |
Created attachment 571973 [details] Hudson job log with exception This exception occurs only sometimes when running multiple threads with persistence: [java] Caused by: java.lang.IllegalStateException: BaseTransaction.rollback [com.arjuna.ats.internal.jta.transaction.arjunacore.notx] [com.arjuna.ats.internal.jta.transaction.arjunacore.notx] no transaction! [java] at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.rollback(BaseTransaction.java:161) [java] at org.drools.persistence.jta.JtaTransactionManager.rollback(JtaTransactionManager.java:191) [java] ... 7 more The whole test log is attached. Tests starts three threads. Threads share persistence configuration (persistence tested with MySQL and Oracle). Every thread runs 100 loops. Each loop runs two or three process instances and waits for their completion. user-task thread uses test handler for completing work items. Transactions (com.arjuna) are handled by jbpm, no explicit call of start(), commit() or rollback(). This one is difficult to reproduce, because it looks like a concurrency issue.