[
https://issues.apache.org/jira/browse/ZOOKEEPER-2060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14171597#comment-14171597
]
Flavio Junqueira commented on ZOOKEEPER-2060:
---------------------------------------------
After having a second look, it doesn't look like there is a deadlock.
Constructing the debug string is taking longer and longer because the size of
the queuedBuffer is growing when throttled. Also, if we turn debug on, then we
should see the problem again, and I was thinking that we should make this
message trace level rather than debug.
These days we use string formatting like in:
{noformat}
LOG.warn("Unable to truncate {}", itr.logFile);
{noformat}
to avoid the unnecessary string construction. In this case, by checking if
debug/trace is enabled, we avoid the call to hexDump compared to doing the
string formatting, so I think it is a plus to do it this way.
> Deadlock in NettyServerCnxnFactory
> ----------------------------------
>
> Key: ZOOKEEPER-2060
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2060
> Project: ZooKeeper
> Issue Type: Bug
> Components: server
> Affects Versions: 3.4.6, 3.5.0
> Reporter: Ian Dimayuga
> Assignee: Ian Dimayuga
> Fix For: 3.4.7, 3.5.1
>
> Attachments: ZOOKEEPER-2060.patch, ZOOKEEPER-2060_deadlock_jstack.txt
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> In NettyServerCnxnFactory, high throughput triggers a deadlock.
> This is caused by a channel-buffer-dumping debug statement in
> NettyServerCnxnFactory.java that is executed regardless of log level.
> This code path only executes when the server is throttling, but when it does
> it encounters a race and occasional deadlock between the channel buffer and
> NettyServerCnxn (jstack attached).
> The proposed fix adds the debug logging guard to this statement, similar to
> other existing statements.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
