You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geode.apache.org by "Bruce Schuchardt (JIRA)" <ji...@apache.org> on 2017/03/02 23:35:45 UTC
[jira] [Commented] (GEODE-1793) Flaky:
LocatorDUnitTest.testStartTwoLocatorsOneWithSSLAndTheOtherNonSSL
[ 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)