[
https://issues.apache.org/jira/browse/ZOOKEEPER-642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804802#action_12804802
]
Patrick Hunt commented on ZOOKEEPER-642:
----------------------------------------
@dale basically we are asking to be woken up in a certain amount of time (in
ms), and we are woken up later than we asked for. This is
to be expected on heavily loaded system, we are logging in order to provide
some insight (say you see a bunch of these, then
some session timeout, it might be useful). I agree though, in general not
particularly useful, bit then in some cases it might be.
The selection of 10ms is a mistake though (esp as some systems don't have very
good resolution on timing). It should be larger, perhaps
scaled relative to the timeout. We could output as debug, but then it would
essentially never be avail when you wanted it. We could
latch (only output the first N logs of this type) but then it would get lost
over time. Perhaps we could do something where we output
a max of once every minute (as warn, debug the rest of the time). Might be a
good tradeoff (increase the check from 10ms at the same
time).
> "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
> results?
> 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
> tickTime=2000
> # The number of ticks that the initial
> # synchronization phase can take
> initLimit=10
> # The number of ticks that can pass between
> # sending a request and getting an acknowledgement
> syncLimit=5
> # the directory where the snapshot is stored.
> dataDir=/mnt/zookeeper
> # the port at which the clients will connect
> clientPort=2181
> server.1=hbase.1:2888:3888
> server.2=hbase.2:2888:3888
> server.3=hbase.3:2888:3888
> server.4=hbase.4:2888:3888
> server.5=hbase.5:2888:3888
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
