You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@zookeeper.apache.org by "Flavio Junqueira (JIRA)" <ji...@apache.org> on 2016/08/09 10:19:22 UTC

[jira] [Commented] (ZOOKEEPER-2440) permanent SESSIONMOVED error after client app reconnects to zookeeper cluster

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

Flavio Junqueira commented on ZOOKEEPER-2440:
---------------------------------------------

Thanks for the patch, [~nerdyyatrice]. I have a couple of comments and questions:

# I'm wondering if we need the second change in {{FinalRequestprocessor}}. If we get a session moved, doesn't it come in the request exception, do we really need to check the sub-results?
# The test case here isn't entirely reliable. I ran it locally without the processor changes and it passes for me. It it not surprising, though. The issue reported here is basically a race between a follower and the leader. To be able to test it reliability, we will need a way to repro reliably the race.
# Sounds like a good idea to update the comment in the {{catch (SessionMovedException e)}} block in line 421.

> permanent SESSIONMOVED error after client app reconnects to zookeeper cluster
> -----------------------------------------------------------------------------
>
>                 Key: ZOOKEEPER-2440
>                 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2440
>             Project: ZooKeeper
>          Issue Type: Bug
>          Components: quorum
>    Affects Versions: 3.5.0
>            Reporter: Ryan Zhang
>            Assignee: Ryan Zhang
>             Fix For: 3.4.9, 3.5.3, 3.6.0
>
>         Attachments: ZOOKEEPER-2440.patch
>
>
> ZOOKEEPER-710 fixed the issue when the request is not a multi request. However, the multi request is handled a little bit differently as the code didn't throw the SESSIONMOVED exception. In addition, the exception is set in the request by the leader so it will be lost in the commit process and by the time the final processor sees it, it will be gone. 



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