ZK guarantees that you never "go back in time". As such zk clients remember the last zxid they saw from the ZK service. If a client disconnects and reconnects to a new server in the ensemble it checks to see if the server is at the same point, or subsequent to, the last zxid seen by the client. If the client has seen updates later (more recent) than the server it will disconnect and reconnect to another server in the ensemble.
Likely here you had clients running against a service, then shutdown the service and cleared out the datadirs and restarted the service (ie reset). In which case the service starts at zxid 0 while the client has seen much larger. Notice the server is at "0x9ba". That's the most common scenario that I see with this. Another option is that you have a server which is not part of the service (ie misconfigured) and some of the serving ensemble has a high zxid, while this server is not participating in the quorum. Patrick On Thu, Aug 30, 2012 at 3:53 PM, Simon Doherty <[email protected]> wrote: > The following message has started turning up in our Zookeeper log. > > INFO Refusing session request for client /127.0.0.1:59992 as it has > seen zxid 0x636c65616e2d7374 our last zxid is 0x9ba client must try > another server (org.apache.zookeeper.server.NIOServerCnxn) > > I am using Zookeeper with the Kafka message queue. My Zookeeper version is > > zookeeper.version=3.3.3-1073969, built on 02/23/2011 22:27 GMT > > I suspect this may be a problem with my Kakfa client, but I'm > wondering under what circumstances this situation occurs in Zookeeper, > and what we can do about it when it arises. > > Thanks > > > > Simon
