geode-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF subversion and git services (Jira)" <>
Subject [jira] [Commented] (GEODE-7088) Possible ConcurrentModificationException while client queue image is copied
Date Tue, 27 Aug 2019 16:31:00 GMT


ASF subversion and git services commented on GEODE-7088:

Commit bbe598dda24bc207523111889517c81aa3a92b21 in geode's branch refs/heads/release/1.10.0
from Ryan McMahon
[;h=bbe598d ]

GEODE-7088: Using ConcurrentSets for interested clients

(cherry picked from commit 174af1d23fb7e09eb2bc2fa55479df854850fadb)

> Possible ConcurrentModificationException while client queue image is copied
> ---------------------------------------------------------------------------
>                 Key: GEODE-7088
>                 URL:
>             Project: Geode
>          Issue Type: Bug
>          Components: client queues
>            Reporter: Ryan McMahon
>            Assignee: Ryan McMahon
>            Priority: Major
>          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

View raw message