Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 882990

Summary:	Two PrepareCommands in parallel cause ConcurrentModificationException
Product:	[JBoss] JBoss Data Grid 6	Reporter:	Radim Vansa <rvansa>
Component:	Infinispan	Assignee:	Tristan Tarrant <ttarrant>
Status:	CLOSED UPSTREAM	QA Contact:	Martin Gencur <mgencur>
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	6.1.0	CC:	jdg-bugs
Target Milestone:	ER9
Target Release:	6.1.0
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2025-02-10 03:27:05 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:

Description Radim Vansa 2012-12-03 15:11:36 UTC

Situation:
1) Node A broadcasts PrepareCommand to nodes B, C
2) Node A leaves cluster, causing new topology to be installed
3) The command arrives to B and C, with lower topology than the current one
4) Both B and C forward the command to node D
5) D executes the two commands in parallel and finds out that A has left, therefore executing RollbackCommand

In AbstractTxLockingInterceptor.visitRollbackCommand we call LockManagerImpl.unlockAll which iterates over the keys and unlocks them. As these two prepares aren't synchronized over the lockedKeys set, one may unlock and remove these keys while the other is iterating through them, causing ConcurrentModificationException.

Comment 1 JBoss JIRA Server 2013-01-14 15:30:18 UTC

Adrian Nistor <anistor> made a comment on jira ISPN-2578

This issue is now possible because of NBST command forwarding. Previously it was impossible to have two commands for the same TX being executed in parallel, so no thread safety was taken into consideration. This leads now to many issues and the one described here is just one instance, so maybe we should try to solve the general case: avoid two TX commands for same global tx id entering the interceptor chain simultaneously, possibly by synchronizing on the cache tx object prior to this. Or maybe just take the simple route of using synchronized collections for the internals of the tx object? Not sure which one is best, but certainly I would not apply a local fix for this ConcurrentModificationException.

Comment 2 JBoss JIRA Server 2013-01-18 19:42:20 UTC

Adrian Nistor <anistor> made a comment on jira ISPN-2578

Integrated. Thanks!

Comment 4 Red Hat Bugzilla 2025-02-10 03:27:05 UTC

This product has been discontinued or is no longer tracked in Red Hat Bugzilla.