[
https://issues.apache.org/jira/browse/ZOOKEEPER-2926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16324396#comment-16324396
]
ASF GitHub Bot commented on ZOOKEEPER-2926:
-------------------------------------------
Github user lvfangmin commented on a diff in the pull request:
https://github.com/apache/zookeeper/pull/447#discussion_r161300774
--- 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 --
Local session creation is happened in ZooKeeperServer when the when
processing connection request, PrepRequestProcessor only deals with the global
sessions.
Local session creation will also send a createSession op into the processor
pipeline, so if we remove the else check, a lot of warning log will show for
local session createSession op, that's not what we wanted.
> 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)
