zookeeper-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (ZOOKEEPER-2926) Data inconsistency issue due to the flaw in the session management
Date Tue, 16 Jan 2018 19:08:00 GMT

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

ASF GitHub Bot commented on ZOOKEEPER-2926:
-------------------------------------------

Github user lvfangmin commented on the issue:

    https://github.com/apache/zookeeper/pull/447
  
    @anmolnar I also find it's hard to track when using overwriting the commit, I'll use stack
instead.
    
    For the tests, I need to inject some failure in the Quorum being set up, that's why I
need the customized way I'm doing in my code, I think I prefer to create a separate test class.


> Data inconsistency issue due to the flaw in the session management
> ------------------------------------------------------------------
>
>                 Key: ZOOKEEPER-2926
>                 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2926
>             Project: ZooKeeper
>          Issue Type: Bug
>          Components: server
>    Affects Versions: 3.5.3, 3.6.0
>            Reporter: Fangmin Lv
>            Assignee: Fangmin Lv
>            Priority: Critical
>
> The local session upgrading feature will upgrade the session locally before receving
a quorum commit of creating global session. It's possible that the server shutdown before
the creating session request being sent to leader, if we retained the ZKDatabase or there
is Snapshot happened just before shutdown, then only this server will have the global session.

> If that server didn't become leader, then it will have more global sessions than others,
and those global sessions won't expire as the leader doesn't know it's existence. If the server
became leader, it will accept the client renew session request and the client is allowed to
create ephemeral nodes, which means other servers only have ephemeral nodes but not that global
session. If there is follower going to have SNAP sync with it, then it will also have the
global session. If the server without that global session becomes new leader, it will check
and delete those dangling ephemeral node before serving traffic. These could introduce the
issues that the ephemeral node being exist on some servers but not others. 
> There is dangling global session issue even without local session feature, because on
leader it will update the ZKDatabase when processing ConnectionRequest and in the PrepRequestProcessor
before it's quorum committed, which also has this risk.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Mime
View raw message