Patrick Hunt commented on ZOOKEEPER-642:
tickTime is used by the servers, not really impacts the clients
the clients have a "timeout" value they use when connecting to the servers,
this establishes the session timeout.
What I was suggesting on the link you listed was changing the timeout, not the
tickTime. 2 sec is pretty low for timeout.
However in your case none of this matters. The "deadline exceeded" message you
are seeing is purely an OS issue.
1) we select(..., deadline)
2) when we wake up from select we check how close we are to the deadline, if
this is exceeded by > 10ms then we log a warning.
In your case the deadline is being exceeded by a significant amount, this is a
warning because it could impact the ability
of the client to maintain connectivity with the server.
> "exceeded deadline by N ms" floods logs
> Key: ZOOKEEPER-642
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-642
> Project: Zookeeper
> Issue Type: Bug
> Components: c client
> Affects Versions: 3.2.1
> Environment: virtualized linux - ec2 - ubuntu
> Reporter: Dale Johnson
> Fix For: 3.4.0
> More important zookeeper warnings are drown out by the following several
> times per minute:
> 2010-01-12 17:39:57,227:22317(0x4147eb90):zoo_w...@zookeeper_interest@1335:
> Exceeded deadline by 13ms
> Perhaps this is an issue with the way virtualized systems manage gettimeofday
> Maybe the current 10ms threshold could be pushed up a bit. I notice that 95%
> of the messages are below 50ms.
> Is there an obvious configuration change that I can make to fix this?
> config file below:
> # The number of milliseconds of each tick
> # The number of ticks that the initial
> # synchronization phase can take
> # The number of ticks that can pass between
> # sending a request and getting an acknowledgement
> # the directory where the snapshot is stored.
> # the port at which the clients will connect
This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.