Jackrabbit deadlock due to non thread-safe implementations of StringIndex
Description
Attachments
2
is related to
relates
Activity
Show:
EdGApril 16, 2013 at 9:10 AM
Hello everyone! We are in the process of moving component "Third Party Libraries" to "Infrastructure" in LPS. Please make the necessary adjustments to your filters. Thanks!
Michael SaechangMay 16, 2012 at 3:55 PMEdited
Committed on:
Portal 6.1.x CE GIT ID: 7ffbcfbd152405091762253375f8c8b0322edcb1.
Portal 6.2.x GIT ID: 365a3ccb5a682b0beb73983a6c30f7e4d5ac6c59.
Completed
Details
Assignee
Michael SaechangMichael Saechang(Deactivated)Reporter
Minhchau DangMinhchau DangBranch Version/s
6.1.x6.0.xBackported to Branch
CommittedGit Pull Request
Components
Fix versions
Affects versions
Priority
Medium
Details
Details
Assignee
Michael SaechangReporter
Minhchau DangBranch Version/s
6.1.x
6.0.x
Backported to Branch
Committed
Git Pull Request
Components
Fix versions
Affects versions
Priority
MediumZendesk Support
Linked Tickets
Zendesk Support
Linked Tickets
Zendesk Support
Linked Tickets
Created May 15, 2012 at 9:36 AM
Updated June 24, 2023 at 3:47 PM
Resolved June 1, 2012 at 3:38 PM
Implementations of StringIndex for Jackrabbit are not thread safe, and the implementations indicate in their javadocs that everything using those classes should do their own thread synchronization. However, the problem with that is that the interfaces do not have such a description, so all uses of the interface within the Jackrabbit source code do not do any thread synchronization.
This results in a well-documented infinite loop bug within HashMap, as mentioned in LPS-16142 where Liferay code suffered from the same bug.
Rather than add synchronized blocks to the code using the StringIndex implementations, it should be possible to transparently convert the HashMaps into ConcurrentHashMaps.