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.
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.