[
https://issues.apache.org/jira/browse/GEODE-5299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Rhomberg reassigned GEODE-5299:
---------------------------------------
Assignee: Patrick Rhomberg
> Correct failure resulting from potential race condition in
> geode-wan:CreateRegionCommandDUnitTest
> -------------------------------------------------------------------------------------------------
>
> Key: GEODE-5299
> URL: https://issues.apache.org/jira/browse/GEODE-5299
> Project: Geode
> Issue Type: Test
> Reporter: Patrick Rhomberg
> Assignee: Patrick Rhomberg
> Priority: Major
>
> A recent commit contains the line the effective sequence:
> {noformat}
> locator = lsRule.startLocatorVM(0);
> server1 = lsRule.startServerVM(1, locator.getPort());
> server2 = lsRule.startServerVM(2, locator.getPort());
> gfsh.connectAndVerify(locator); String regionName =
> testName.getMethodName();
> String gatewaySenderName = "gatewaySender";
> IgnoredException.addIgnoredException("could not get remote locator
> information");
> gfsh.executeAndAssertThat(
> "create gateway-sender --parallel=true
> --remote-distributed-system-id=2 --id="
> + gatewaySenderName)
> .statusIsSuccess();
> locator.waitTilGatewaySendersAreReady(1);
> {noformat}
> Notably, the {{waitTilGatewaySendersAreReady}} expects to find 1 gateway
> mbean from the two servers on which the gateway will be created.
> However, the underlying implementation of the method expects to find
> *exactly* 1 bean, meaning that if the gateway creation and bean registration
> occurs before the {{wait*}} method is called, the test will fail to a hang
> despite correct execution.
> The true root cause of this error is likely the ambiguity in the method and
> variable naming. Consider renaming this method and related to be explicitly
> clear to future developers that these methods have exact expectation.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
