Mailing-List: contact user-help@zookeeper.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@zookeeper.apache.org
Received-SPF: pass (nike.apache.org: domain of ted.dunning@gmail.com
 designates 74.125.82.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAEk9pkf7rXwG3VoB7hOHvMeNeaKA_MfRCnPmfrTDhjQtSEJw7A@mail.gmail.com>
References: 
 <CAEk9pkfuF1Ek22QT8DPzcXnuj7sx1zSqH8Dy-PC00TeiN4uwWA@mail.gmail.com>
 <CANLc_9Jwieyyig=yg1yVCZaEoBc8SwWj3FqD4x993RYrPoD_PQ@mail.gmail.com>
 <CAJwFCa2NDKOC84oHhCRv6cVDi6O+Rym5v+RVtjm74rBn0Wj_Lg@mail.gmail.com>
 <CANLc_9KKcnOQh-cTVeaS7rDz0K7oaWmPTE50VXqKiTdB=nrCGA@mail.gmail.com>
 <CANLc_9LZwoGqQG0TuiPswmUk1AgCfdTVLfUjD13DYM3VQzeGPQ@mail.gmail.com>
 <CALF7aMQDE6AOKRtHZ+rbUt1VFrZ572bhGVYVm7uHT2ZHTAkpcg@mail.gmail.com>
 <CAEk9pkeP4O2WWiZjWqFHrHDAurDeeRApDtRWsANukmXGXunDeg@mail.gmail.com>
 <CAJwFCa1UHV=FXaN7FeYsvKv0doLtJaQYPU7Jn20zG6-HD6agdQ@mail.gmail.com>
 <CAEk9pkf7rXwG3VoB7hOHvMeNeaKA_MfRCnPmfrTDhjQtSEJw7A@mail.gmail.com>
From: Ted Dunning <ted.dunning@gmail.com>
Date: Mon, 3 Sep 2012 17:40:19 -0400
Message-ID: 
 <CAJwFCa1kWHTv37tq-WrnS+4BMRZcbjo=4MEaGTkKF+V+iRsPqA@mail.gmail.com>
Subject: Re: Session refused, zxid too high
To: user@zookeeper.apache.org
Content-Type: multipart/alternative; boundary=bcaec555503cc1ee0004c8d2fec4

--bcaec555503cc1ee0004c8d2fec4
Content-Type: text/plain; charset=UTF-8

That should come under the general heading of Java client issues.

This is mildly disturbing that this happened at all.  If it persists,
please make more noise.

On Mon, Sep 3, 2012 at 5:38 PM, Simon Doherty <simon.f.doherty@gmail.com>wrote:

> Well, it's part of a clojure client for the Kafka queue called
> kafka-clj, but it uses Netflix's Curator Framework to talk to
> Zookeeper.
>
> The kafka-clj client doesn't seem to be very actively developed, so I
> suspect that the problem is there. (Perhaps some arguments have been
> mixed up somewhere.)
>
> The Curator Framework is developed and used more actively, so it
> should be more reliable. I'll post another message to their mailing
> list. But I don't want to impugn their reliability at the moment. :)
>
> Thanks
>
>
> Simon
>
>
> On Tue, Sep 4, 2012 at 7:21 AM, Ted Dunning <ted.dunning@gmail.com> wrote:
> > Yes.  Is this a C-based client?  If so, memory corruption is less
> > surprising.
> >
> > If java based, then such memory corruption is big news.
> >
> > On Sun, Sep 2, 2012 at 5:46 PM, Simon Doherty <simon.f.doherty@gmail.com
> >wrote:
> >
> >> Thanks very much for your help people!
> >>
> >> So the strange zxid value was supplied by the client during session
> >> start up. That suggests to me that it's a bug in the client I'm using.
> >> Is that true?
> >>
> >> Thanks
> >>
> >>
> >>
> >> Simon
> >>
> >>
> >> On Sat, Sep 1, 2012 at 11:29 AM, Mahadev Konar <mahadev@hortonworks.com
> >
> >> wrote:
> >> >  Nice debugging Pat! Really interesting! :)
> >> >
> >> > thanks
> >> > mahadev
> >> >
> >> > On Fri, Aug 31, 2012 at 3:12 PM, Patrick Hunt <phunt@apache.org>
> wrote:
> >> >> This is interesting, if you convert 0x636c65616e2d7374 to ascii you
> >> >> get "clean-st". Looks like memory corruption to me.
> >> >>
> >> >> Patrick
> >> >>
> >> >> On Fri, Aug 31, 2012 at 1:34 PM, Patrick Hunt <phunt@apache.org>
> wrote:
> >> >>> Good point Ted. Is this a java ZK client or something else? (memory
> >> >>> corruption on client possible?)
> >> >>>
> >> >>> Patrick
> >> >>>
> >> >>> On Fri, Aug 31, 2012 at 12:56 PM, Ted Dunning <
> ted.dunning@gmail.com>
> >> wrote:
> >> >>>> But isn't the larger ZXID pretty stunningly large?
> >> >>>>
> >> >>>> The epoch number is nearly 2 billion and the transaction id is 845
> >> million.
> >> >>>>  These seem implausible from a starting point of 0.
> >> >>>>
> >> >>>> On Fri, Aug 31, 2012 at 12:54 PM, Patrick Hunt <phunt@apache.org>
> >> wrote:
> >> >>>>
> >> >>>>> > seen zxid 0x636c65616e2d7374 our last zxid is 0x9ba client
> >>
>

--bcaec555503cc1ee0004c8d2fec4--