[
https://issues.apache.org/jira/browse/GEODE-8195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bill Burcham updated GEODE-8195:
--------------------------------
Description:
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}
was:
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.
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}
> 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
> 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)
