[
https://issues.apache.org/jira/browse/GEODE-7088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dick Cavender updated GEODE-7088:
---------------------------------
Fix Version/s: 1.11.0
> Possible ConcurrentModificationException while client queue image is copied
> ---------------------------------------------------------------------------
>
> Key: GEODE-7088
> URL: https://issues.apache.org/jira/browse/GEODE-7088
> Project: Geode
> Issue Type: Bug
> Components: client queues
> Reporter: Ryan McMahon
> Assignee: Ryan McMahon
> Priority: Major
> Fix For: 1.10.0, 1.11.0
>
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> The following corner case scenario will result in a
> ConcurrentModificationException which causes the queue image transfer to fail
> and subsequently client registration to fail:
> # Client 1 is currently opening a subscription endpoint with server 1 and
> events are being staged in the client's temporary registration queue
> # One or more of those events also match interest for Client 2 who is
> already fully registered, so the event is put into Client 2's queue (in
> addition to Client 1's temp queue)
> # Client 2 asks server 2 to open a secondary subscription endpoint. Server
> 2 attempts to copy Client 2's queue from server 1. This results in
> serializing all of the events in Client 2's queue.
> # While the image is being transferred, Client 1 finishes registration and
> begins to drain its temporary registration queue. The filter info for each
> event is recalculated which ends up mutating the shared event in Client 2's
> queue.
> # The event has some metadata stored as a non-concurrent set. Recalculating
> the filter info for Client 1 will mutate that set, but the image transfer for
> Client 2 is trying to copy that set simultaneously. This can result in a
> ConcurrentModificationException because the set is not thread safe. Note
> that there no danger in recalculating the filter from Client 2's perspective,
> because it is already in Client 2's queue. As such, Client 2's queue
> transfer should be tolerant of such modifications since they have no
> consequence to it.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
