Re: Please help me to understand ReadOnly Zookeeper behaviors

[Thawan Kooburat <th...@fb.com>]

I don't have answers for your questions but I can explain a bit more about
how RO server works.

Essentially,  it allow the servers to start serving request while there is
no leader. I guessed that since there is no leader, the system won't'
change any state during this period (no new txn, no session expire).
During the period, client also try to ping all server to see if there is
any machine which is not in RO mode and will try to connect to it if it
find one. 

When the quorum is about to form, the servers restart and run in normal
mode.  

I believe RO mode is intended for use case where you want higher read
availability but it might not do what you expected so you should try it
first. A major enhancement for RO functionality is ZOOKEEPER-1607 which is
still work-in-progress.
     

-- 
Thawan Kooburat





On 9/26/13 6:33 AM, "Rakesh R" <ra...@huawei.com> wrote:

>Hi, 
>
>There is a typo in my previous query. Please read my doubt as follows:
>
>In both the cases, ReadOnlyZKServer is not able to serve the client
>requests. Because of this user appln is not getting the real advantage of
>CONNECTEDREADONLY state.
>Is this the expected behavior ? Also please validate my scenario and I
>would appreciate any help.
>
>-Rakesh
>
>-----Original Message-----
>From: Rakesh R [mailto:rakeshr@huawei.com]
>Sent: 26 September 2013 14:40
>To: user@zookeeper.apache.org; zookeeper-user@hadoop.apache.org
>Subject: Please help me to understand ReadOnly Zookeeper beahviors
>
>Hi,
>
>I'm just analyzing the ReadOnlyZKServer and r-o client behaviors.  From
>the docs I am thinking of 'read-only' ZooKeeper server is like, it will
>serves read requests as long as the client can contact a server.
>I've few clarifications about some of its behaviors.  Please take a look
>at below cases:
>
>case-1
>--------
>1) Started quorum of three servers and all having r-o mode enabled - zk1,
>zk2, zk3. Also assume I've an appln running in zk3 server machine.
>2) Make zk3 down. Assume the appln running in zk3 host/machine, has
>created a zkcilent1 with r-o true.(As zk3 is down, not aware about
>zkcilent1 session)
>3) After this, say my appln machine got partitioned and assume now zk3
>server is restarted. zkclient1 will be trying to contact zk3 server as
>both are running in same machine and got partitioned.
>
>Behavior:
>zk3 server is expiring the zkclient1 session as its not aware about its
>creation. I'm thinking this is due to a condition in zkserver,
>zkclient1's zxid is 0x and sametime zk3 server doesn't know about this
>zkclient1 session and expiring it.
>
>
>case-2
>---------
>1) Started quorum of three servers and all having r-o mode enabled. zk1,
>zk2, zk3. Also assume I've an appln running in zk3 server machine.
>2) Assume the appln running in zk3 host/machine, has created a zkcilent1
>with r-o true.
>3) Create ephemeralnode1 using the zkclient1
>4) Make zk3 down.
>5) Create one more ephemeralnode2 using the zkclient1. (As zk3 is down,
>it wont be aware about this)
>6) After this, say zk3 server machine got partitioned and assume now zk3
>server is restarted. zkclient1 will be trying to contact zk3 server as
>both are running in same machine and got partitioned.
>
>Behavior:
>zk3 server is ignoring the zkclient1 connection request saying 'Refusing
>session request for client...must try another server'. Zkclient1 remains
>in CONNECTING state.
>This is because, zk3 server is behind the zkclient1 session transaction
>zxid.
>
>
>In both the cases, as expected ReadOnlyZKServer is not able to serve the
>client requests and user appln would not get the real advantage of
>CONNECTEDREADONLY in case of partitioning.
>Is this the expected behavior of r-o clients ? Also please validate my
>scenario and I would appreciate any help.
>
>
>Thanks & Regards,
>Rakesh R