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 <[email protected]>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 <[email protected]> > wrote: > > Nice debugging Pat! Really interesting! :) > > > > thanks > > mahadev > > > > On Fri, Aug 31, 2012 at 3:12 PM, Patrick Hunt <[email protected]> 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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> > wrote: > >>>> > >>>>> > seen zxid 0x636c65616e2d7374 our last zxid is 0x9ba client >
