geode-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF subversion and git services (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (GEODE-1542) shared/unordered tcp/ip connection times out, initiating suspicion
Date Wed, 15 Jun 2016 17:23:09 GMT

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

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

Commit 3de21f56a7381cea926be9fe33c8e1a1456c564d in incubator-geode's branch refs/heads/develop
from [~upthewaterspout]
[ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=3de21f5 ]

GEODE-1542: Removing a bogus static import of javafx class

This class picked up a bad import of a javafx class. With openjdk this
causes compile errors.


> shared/unordered tcp/ip connection times out, initiating suspicion
> ------------------------------------------------------------------
>
>                 Key: GEODE-1542
>                 URL: https://issues.apache.org/jira/browse/GEODE-1542
>             Project: Geode
>          Issue Type: Bug
>          Components: membership
>            Reporter: Bruce Schuchardt
>             Fix For: 1.0.0-incubating.M3
>
>
> I recently diagnosed a membership failure that was initiated when one member (N) timed
out its shared/unordered tcp/ip connection to another member (M).  Member M initiated suspect
processing that lead to kicking member N out of the system.  We need to either stop timing
out shared/unordered connections or have an orderly shutdown mechanism so that we don't initiate
suspect processing.
> The final-check that M performed showed something odd.  Member N never logged that it
processed a final check from M.  Member M logged that it had connected to N and read a status
byte from it.  The byte had the value 21, which is not a valid response to a final check (it
should be 0 or 0x7B).
> {noformat}
> Received [21, ent(clientgemfire3_ent_19225:19225)<ec><v1>:1028]
> {noformat}
> I verified that M used the correct tcp/ip port for N, so this is very odd and needs to
be investigated.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message