[
https://issues.apache.org/jira/browse/ZOOKEEPER-2926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16322340#comment-16322340
]
ASF GitHub Bot commented on ZOOKEEPER-2926:
-------------------------------------------
Github user anmolnar commented on a diff in the pull request:
https://github.com/apache/zookeeper/pull/447#discussion_r160972325
--- Diff: src/java/main/org/apache/zookeeper/server/ZooKeeperServer.java ---
@@ -1187,13 +1187,8 @@ private ProcessTxnResult processTxn(Request request,
TxnHeader hdr,
if (opCode == OpCode.createSession) {
if (hdr != null && txn instanceof CreateSessionTxn) {
CreateSessionTxn cst = (CreateSessionTxn) txn;
- sessionTracker.addGlobalSession(sessionId,
cst.getTimeOut());
- } else if (request != null && request.isLocalSession()) {
- request.request.rewind();
- int timeout = request.request.getInt();
- request.request.rewind();
- sessionTracker.addSession(request.sessionId, timeout);
- } else {
+ sessionTracker.commitSession(sessionId, cst.getTimeOut());
+ } else if (request == null || !request.isLocalSession()) {
--- End diff --
Do you need this check here?
Basically you removed the part of requesting localSession creation, because
it has already happened in PrepRequestProcessor and it's safe to leave the
default 'else' handler as it was.
> 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
(v6.4.14#64029)
