Bug 1152782 - Exception in thread "Periodic Recovery" java.util.ConcurrentModificationException
Summary: Exception in thread "Periodic Recovery" java.util.ConcurrentModificationExcep...
Alias: None
Product: JBoss Enterprise Application Platform 6
Classification: JBoss
Component: Transaction Manager
Version: 6.4.0
Hardware: Unspecified
OS: Unspecified
Target Milestone: DR11
: EAP 6.4.0
Assignee: Michael
QA Contact: Ondrej Chaloupka
Depends On:
Blocks: 1165728
TreeView+ depends on / blocked
Reported: 2014-10-14 23:09 UTC by Ondrej Chaloupka
Modified: 2019-08-19 12:43 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2019-08-19 12:43:47 UTC
Type: Bug

Attachments (Terms of Use)
server.log with ConcurrentModificationException (346.50 KB, text/plain)
2014-10-14 23:09 UTC, Ondrej Chaloupka
no flags Details

System ID Priority Status Summary Last Updated
Red Hat Bugzilla 1103780 None None None Never
Red Hat One Jira Issue Tracker JBTM-2271 Major Closed ConcurrentModificationException exception raised by CMR Recovery module first pass 2016-07-19 07:00:09 UTC

Internal Links: 1103780

Description Ondrej Chaloupka 2014-10-14 23:09:38 UTC
Created attachment 947054 [details]
server.log with ConcurrentModificationException

This error is (probably) the same as it was reported here: https://bugzilla.redhat.com/show_bug.cgi?id=1010242
but for Sybase it seems to be reproducible quite consistently.

We run test where Byteman rule is added to stop XA transaction in prepare phase (BasicAction#prepare).
Then we call 3 ejbs which starts 3 transactions. Those are stuck at prepare.
When all three are prepared to proceed then we unblock the byteman rule and check the results.

In case of Sybase database it happens that during checking of state - before the byteman rule is unblock - the app server came with exception [1] and stays deadlocked.

I expect that this is hardly to obtain such state in standard usage but the code should be clean from ConcurrentModificationException.

ERROR [stderr] (Periodic Recovery) Exception in thread "Periodic Recovery" java.util.ConcurrentModificationException
ERROR [stderr] (Periodic Recovery) 	at java.util.HashMap$HashIterator.nextEntry(HashMap.java:922)
ERROR [stderr] (Periodic Recovery) 	at java.util.HashMap$KeyIterator.next(HashMap.java:956)
ERROR [stderr] (Periodic Recovery) 	at com.arjuna.ats.internal.jta.recovery.arjunacore.CommitMarkableResourceRecordRecoveryModule.periodicWorkFirstPass(CommitMarkableResourceRecordRecoveryModule.java:172)
ERROR [stderr] (Periodic Recovery) 	at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:747)
ERROR [stderr] (Periodic Recovery) 	at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:375)

Comment 1 Ondrej Chaloupka 2014-10-14 23:11:34 UTC
I'm sorry incorrect link to 6.3.0 bugzilla. Correct is:

Comment 3 Ondrej Chaloupka 2014-10-20 08:59:40 UTC
Just checked the code and it seems that the cause is at line:

Item from collection is removed but without iterator would know about it. It's needed to use iterator itself for removing the item.

Comment 4 Michael 2014-10-20 09:18:40 UTC
Good spot. I will raise a JIRA and link it to this case.

Comment 5 Ondrej Chaloupka 2014-11-26 12:25:02 UTC
Codebase changed, concurrent locking for Sybase seems to go away.
Verified for EAP 6.4.0.DR11

Comment 6 JBoss JIRA Server 2014-11-28 10:32:35 UTC
Tom Jenkinson <tom.jenkinson@redhat.com> updated the status of jira JBTM-2271 to Closed

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