Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

Switch to Threaded View
Zookeeper >> mail # user >> Behavior when client disconnects


Copy link to this message
-
Re: Behavior when client disconnects
Nice, it looks like that JIRA covers more use cases. Looks like it requires
lot of changes.

For the usecase, I described how about simply calling sync under the hood
when a client disconnects from one server and reconnects to another server
before the session expires or atleast we suggest this as work around on the
client side.

thanks,
Kishore G
On Thu, Dec 5, 2013 at 8:11 AM, Alexander Shraer <[EMAIL PROTECTED]> wrote:

> I think this is https://issues.apache.org/jira/browse/ZOOKEEPER-22
>
> On Wed, Dec 4, 2013 at 8:50 PM, kishore g <[EMAIL PROTECTED]> wrote:
> > Thanks Camille, Is it not violating the assumption that a client reads
> its
> > own write (probably its ok in this case because client never got the ack
> > for write from server)
> >
> > Consider the following simple code where one wants to know if something
> was
> > successfully written.
> >
> > boolean success;
> > try{
> >   zk.write(p)
> >   success= true;
> > }catch(Exception e)
> > {
> >   //cannot assume write did not go through
> >   //read the value and see if you really wrote it
> >   success = zk.exists(p) && zk.readStat(p).owner == me
> > }
> >
> > Looks like if the connection breaks at zk.write(p), success can either be
> > true or false. Probably the only way to make sure write was successful is
> > try writing again when there is exception.
> >
> > Does this make sense?
> >
> > thanks,
> > Kishore G
> >
> >
> >
> >
> >
> >
> >
> > On Wed, Dec 4, 2013 at 6:12 PM, Camille Fournier <[EMAIL PROTECTED]>
> wrote:
> >
> >> As far as I can tell from the code:
> >> c1 will send its last seen zxid to the server that it is trying to
> connect
> >> to. If that zxid is greater than the zxid of the server, the server will
> >> refuse the connection. In this case, if the client has not seen an ack,
> it
> >> is certainly possible that the last zxid seen will be the same as the
> zxid
> >> of the server it is connected to, so it will not see the result of w1
> yet.
> >>
> >> C
> >>
> >>
> >> On Wed, Dec 4, 2013 at 3:37 PM, kishore g <[EMAIL PROTECTED]> wrote:
> >>
> >> > Hi,
> >> >
> >> > Consider the following case
> >> >
> >> >
> >> >    1. Client c1 sends a write(w1) to zk1
> >> >    2. w1 gets ack from zk2 but not yet from zk3, but quorum is reached
> >> >    3. By the time zk1 sends response back to c1, the connection breaks
> >> >    4. c1 did not get the zxid for the latest transaction
> >> >
> >> > Now c1, depending on whether it connects to zk2 or zk3 might see that
> w1
> >> > was successful or failure.  Is this analysis correct or will c1
> >> > automatically invoke a sync under the hoods when it gets disconnected
> and
> >> > connected to another server?
> >> >
> >> > If no, how should one handle this scenario.
> >> > Thanks,
> >> > Kishore G
> >> >
> >>
>
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB