Mailing-List: contact dev-help@zookeeper.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@zookeeper.apache.org
Date: Sun, 6 Nov 2016 05:21:58 +0000 (UTC)
From: "Michael Han (JIRA)" <jira@apache.org>
To: dev@zookeeper.apache.org
Message-ID: <JIRA.13017814.1478206350000.202300.1478409718525@Atlassian.JIRA>
In-Reply-To: <JIRA.13017814.1478206350000@Atlassian.JIRA>
References: <JIRA.13017814.1478206350000@Atlassian.JIRA> <JIRA.13017814.1478206350073@arcas>
Subject: [jira] [Updated] (ZOOKEEPER-2627) Remove ZRWSERVERFOUND from C
 client and replace handle_error with something more semantically explicit
 for r/w server reconnect.
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Sun, 06 Nov 2016 05:22:00 -0000


     [ https://issues.apache.org/jira/browse/ZOOKEEPER-2627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Han updated ZOOKEEPER-2627:
-----------------------------------
    Attachment: ZOOKEEPER-2627.patch

> Remove ZRWSERVERFOUND from C client and replace handle_error with something more semantically explicit for r/w server reconnect.
> --------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: ZOOKEEPER-2627
>                 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2627
>             Project: ZooKeeper
>          Issue Type: Bug
>          Components: c client
>    Affects Versions: 3.5.2
>            Reporter: Michael Han
>            Assignee: Michael Han
>             Fix For: 3.5.3
>
>         Attachments: ZOOKEEPER-2627.patch, ZOOKEEPER-2627.patch
>
>
> While working on ZOOKEEPER-2014, I noticed a discrepancy between Java and C client regarding the error codes definition. There is a {noformat}ZRWSERVERFOUND = -122{noformat} definition in C client which is not present in Java client's KeeperException.Code definitions. 
> This discrepancy was introduced by ZOOKEEPER-827, where the C client logic was simulating the Java client's logic when doing a read/write server search while client is in read only mode. Once client finds a valid read/write server, client will try to disconnect and reconnect with this read/write server, as we always prefer r/w server in ro mode. The way Java client is doing this disconnect/reconnect process is by throwing a RWServerFoundException (instead of a KeeperException) to set the client in disconnected state, then wait for client reconnect with r/w server address set before throwing the exception. C client did similar but instead of having an explicitly disconnect / clean up routine, the client was relying on handle_error to do the job where ZRWSERVERFOUND was introduced.
> I propose we remove ZRWSERVERFOUND error code from C client and use an explicit routine instead of handle_error when we do r/w server search in C client for two reasons:
> * ZRWSERVERFOUND is not something ZK client users would need to know. It's a pure implementation detail that's used to alter the connection state of the client, and ZK client users have no desire nor need to handle such errors, as R/W server scanning and connect is handled transparently by ZK client library.
> * To maintain consistency between Java and C client regarding error codes definition. Without removing this from C client, we would need to replace RWServerFoundException in Java client with a new KeeperException, and again with the reason mentioned above, we don't need a KeeperException for this because such implementation detail does not have to be exposed to end users (unless, we provided alternative for users to opt-out automate R/W server switching when in read only mode which we don't.).


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