Details
-
Bug
-
Status: Closed
-
Major
-
Resolution: Fixed
-
None
-
None
Description
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.
