[
https://issues.apache.org/jira/browse/GEODE-1793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15893251#comment-15893251
]
Bruce Schuchardt commented on GEODE-1793:
-----------------------------------------
I managed to get this test to fail & see that the second locator, in vm_2, was
supposed to shut down but instead it created its own cluster:
{noformat}
[vm2] [info 2017/03/02 15:19:56.969 PST <RMI TCP Connection(1)-10.118.32.92>
tid=0x13] Starting membership services
[vm2] [info 2017/03/02 15:19:56.979 PST <RMI TCP Connection(1)-10.118.32.92>
tid=0x13] JGroups channel created (took 9ms)
[vm2] [info 2017/03/02 15:19:56.980 PST <RMI TCP Connection(1)-10.118.32.92>
tid=0x13] GemFire P2P Listener started on /10.118.32.92:39824
[vm2] [info 2017/03/02 15:19:56.980 PST <Geode Failure Detection Server thread
0> tid=0x21c] Started failure detection server thread on /10.118.32.92:59150.
[vm2] [info 2017/03/02 15:19:56.980 PST <RMI TCP Connection(1)-10.118.32.92>
tid=0x13] Peer locator is connecting to local membership services with ID
trout(2830:locator)<ec>:32771
[vm2] [info 2017/03/02 15:19:57.164 PST <RMI TCP Connection(1)-10.118.32.92>
tid=0x13] This member is becoming the membership coordinator with address
trout(2830:locator)<ec>:32771
{noformat}
It was correctly configured with two locator addresses and its SSL
configuration appeared to be okay. The other locator, in vm_1, correctly had
SSL disabled. The SSL locator was unable to recover from the non-SSL locator:
{noformat}
[vm2] [info 2017/03/02 15:19:56.961 PST <RMI TCP Connection(1)-10.118.32.92>
tid=0x13] GemFire peer location service starting. Other locators:
trout.gemstone.com[46843] Locators preferred as coordinators: false Network
partition detection enabled: false View persistence file: locator0view.dat
[vm2] [info 2017/03/02 15:19:56.961 PST <RMI TCP Connection(1)-10.118.32.92>
tid=0x13] Peer locator attempting to recover from
trout.gemstone.com/10.118.32.92:46843
[vm2] [info 2017/03/02 15:19:56.963 PST <RMI TCP Connection(1)-10.118.32.92>
tid=0x13] Peer locator was unable to recover state from this locator
[vm2] [info 2017/03/02 15:19:56.963 PST <RMI TCP Connection(1)-10.118.32.92>
tid=0x13] recovery file not found:
/export/trout1/users/bschuchardt/devel/gfdev/open/geode-core/build/distributedTest/dunit/vm2/locator0view.dat
[vm2] [info 2017/03/02 15:19:56.963 PST <RMI TCP Connection(1)-10.118.32.92>
tid=0x13] Starting distributed system
{noformat}
So this appears to be a problem with Geode, not the test. It is the Geode
functionality that is "flaky", working most of the time but not 100%.
> Flaky: LocatorDUnitTest.testStartTwoLocatorsOneWithSSLAndTheOtherNonSSL
> -----------------------------------------------------------------------
>
> Key: GEODE-1793
> URL: https://issues.apache.org/jira/browse/GEODE-1793
> Project: Geode
> Issue Type: Bug
> Components: locator
> Reporter: Udo Kohlmeyer
> Assignee: Galen O'Sullivan
> Priority: Minor
>
> This test fails due to something not cleaning itself properly. Undetermined
> what the problem is, but it will run perfectly by itself everytime, but once
> run inside of the TestClass it fails
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
