Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Plain View
Zookeeper >> mail # user >> Session refused, zxid too high


+
Simon Doherty 2012-08-30, 22:53
+
Patrick Hunt 2012-08-31, 16:54
+
Ted Dunning 2012-08-31, 19:56
+
Patrick Hunt 2012-08-31, 20:34
+
Patrick Hunt 2012-08-31, 22:12
+
Mahadev Konar 2012-08-31, 23:29
+
Simon Doherty 2012-09-02, 21:46
+
Ted Dunning 2012-09-03, 19:21
+
Simon Doherty 2012-09-03, 21:38
Copy link to this message
-
Re: Session refused, zxid too high
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 <[EMAIL PROTECTED]>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 <[EMAIL PROTECTED]> 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 <[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
> >>
>
+
Simon Doherty 2012-09-03, 22:20