[ 
https://issues.apache.org/jira/browse/GEODE-8195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17146649#comment-17146649
 ] 

ASF subversion and git services commented on GEODE-8195:
--------------------------------------------------------

Commit 64b727e105117d806b6e680ec5f2b0f9bbce0afd in geode's branch 
refs/heads/support/1.13 from Bruce Schuchardt
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=64b727e ]

GEODE-8195: ConcurrentModificationException from LocatorMembershipListenerImpl 
(#5306)

I've replaced the "for" loop using an implicit Iterator with one using an
explicit Iterator so that its safe "remove()" method can be used.  The
Iterator method is stated as being the only safe way to modify the
collection while iterating over its contents.

I've also modified a test to validate the fix.  The test forces a
failure to send two messages to an address.  The failures are then
handled in the code that was throwing the
ConcurrentModificationException and, since there are two failures,
it causes two removals to be performedon the failedMessages collection.

(cherry picked from commit 3cda1b1a213f2195ff0b97361883f6a6c3972b14)


> ConcurrentModificationException from 
> LocatorMembershipListenerImpl$DistributeLocatorsRunnable.run
> -------------------------------------------------------------------------------------------------
>
>                 Key: GEODE-8195
>                 URL: https://issues.apache.org/jira/browse/GEODE-8195
>             Project: Geode
>          Issue Type: Bug
>          Components: membership
>            Reporter: Bill Burcham
>            Assignee: Bruce J Schuchardt
>            Priority: Major
>
> this WAN code in 
> {{LocatorMembershipListenerImpl$DistributeLocatorsRunnable.run}}:
> {code}
>             Set<LocatorJoinMessage> joinMessages = entry.getValue();
>             for (LocatorJoinMessage locatorJoinMessage : joinMessages) {
>               if (retryMessage(targetLocator, locatorJoinMessage, attempt)) {
>                 joinMessages.remove(locatorJoinMessage);
>               } else {
> {code}
> modifies the {{joinMessages}} set as it is iterating over the set, resulting 
> in a {{ConcurrentModificationException}}.
> This bug will cause (inter-site) notification of locators (of the presence of 
> a new locator) to fail early if retry is necessary. If we have to retry 
> notifying any locator, and we succeed, we’ll throw the 
> {{ConcurrentModificationException}} and stop trying to notify any of the 
> other locators. See the _Discovery For Multi-Site Systems_ section of the 
> [Overview of Multi-Site 
> Caching|https://geode.apache.org/docs/guide/14/topologies_and_comm/topology_concepts/multisite_overview.html]
>  documentation for an overview of the locator's role in WAN.
> Here is a scratch file that illustrates the issue, throwing 
> {{ConcurrentModificationException}}:
> {code}
> import java.util.HashSet;
> import java.util.Set;
> class Scratch {
>   public static void main(String[] args) {
>     final Set<String> joinMessages = new HashSet<>();
>     joinMessages.add("one");
>     joinMessages.add("two");
>     for( final String entry:joinMessages ) {
>       if (entry.equals("one"))
>         joinMessages.remove(entry);
>     }
>   }
> }
> {code}
> From looking at the Geode code, {{joinMessages}} is not used outside the loop 
> so there is no need to modify it at all—I think we can simply remove this 
> line:
> {code}
>                 joinMessages.remove(locatorJoinMessage);
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Reply via email to