zookeeper-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ted Dunning <ted.dunn...@gmail.com>
Subject Re: Session refused, zxid too high
Date Mon, 03 Sep 2012 19:21:03 GMT
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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message