Patrick Hunt updated ZOOKEEPER-642:
Fix Version/s: (was: 3.1.2)
unfortunately it's not configurable & I'm not sure why 10 was chosen (nothing
src to indicate.
What type of ec2 instance is this, small? Is this at all correlated with the
client/clienthost having increased workload?
I think we should make some sort of change here, not sure what. Perhaps this
should be a % of timeout rather than fixed. Or perhaps made configurable.
we might make this debug (or switch to debug if > some number output in a
> "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.3.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.