[COLLECTIONS-885] PatriciaTrie submap and range view operations silently mutate trie structure resulting in ConcurrentModificationException for any iterating threads#672
Conversation
…iews with subMap, headMap, tailMap, and prefixMap. Fixes shared usage where even simple read access among multiple iterating threads results in ConcurrentModificationExceptions.
src/main/java/org/apache/commons/collections4/trie/AbstractBitwiseTrie.java
Show resolved
Hide resolved
src/test/java/org/apache/commons/collections4/trie/PatriciaTrieTest.java
Show resolved
Hide resolved
garydgregory
left a comment
There was a problem hiding this comment.
Hello Hello @griffinjm
If I only apply the test side of the patch, all the tests still pass, the new tests should fail. This means a regression could undo whatever the main changes claim to make.
|
Hi @garydgregory |
…oncurrentModificationExceptions thrown by concurrent iterators.
|
@garydgregory I added a threaded test to verify behaviour, that test should fail for the existing main branch and pass for this bugfix branch. |
garydgregory
left a comment
There was a problem hiding this comment.
Hello @griffinjm
Please see my one comment.
src/test/java/org/apache/commons/collections4/trie/PatriciaTrieTest.java
Outdated
Show resolved
Hide resolved
mutate trie structure resulting in ConcurrentModificationException for any iterating threads #672
|
@griffinjm |
|
Great! Thank you @garydgregory |


Some methods in AbstractPatriciaTrie use a pattern where they silently mutate the trie when searching for a key which is not an exact match for an existing key in the Trie. Said methods are invoked by subMap/tailMap/headMap/prefixMap under the hood. This results in CMEs for even simple shared read access.
The referenced modCount is used as a fail-fast mechanism in the iterators.
This fix prevents the issue by instead:
See https://issues.apache.org/jira/browse/COLLECTIONS-885 for all details.