[
https://issues.apache.org/jira/browse/DRILL-5701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16141630#comment-16141630
]
ASF GitHub Bot commented on DRILL-5701:
---------------------------------------
Github user asfgit closed the pull request at:
https://github.com/apache/drill/pull/894
> drill.connections.rpc.<user/control/data>.<encrypted/unencrypted> metric not
> behaving correctly
> -----------------------------------------------------------------------------------------------
>
> Key: DRILL-5701
> URL: https://issues.apache.org/jira/browse/DRILL-5701
> Project: Apache Drill
> Issue Type: Bug
> Affects Versions: 1.11.0
> Reporter: Sorabh Hamirwasia
> Assignee: Sorabh Hamirwasia
> Labels: ready-to-commit
> Fix For: 1.12.0
>
>
> Reported by [~knguyen]
> When sqlline fails to connect to drillbit such as a handshake failure, the
> drill.connections.rpc.user.<encrypted/unencrypted> metric subtracts 2
> counters (one for handshake failure and one when the user exits from
> sqlline). As a result, the metric can end up with a negative value. For
> control connections if the handshake fails then again counters related to
> those are updated incorrectly.
> *Issue Details:*
> With the current implementation to update counter, the connection counter
> will be incremented only when a handshake (Drill + SASL handshake) was
> successful, not with creation of a valid TCP connection. But the counter was
> decremented in the channel closed callback of Netty which will be called when
> TCP connection is teared down. Hence in case when Drill handshake fails even
> though it has a valid TCP connection there won't be any increment. But as
> part of handshake failure the TCP connection will be closed by Netty and that
> results in decrement of the counter, which results in negative value of the
> counter. When using Sqlline as client, if there is failure based on above use
> case then the counter is decremented by 1 value. But later when *quit*
> command is issued in sqlline then internally it again's tries to make another
> connection which will follow the same flow above and will again decrement the
> counter making the negative value of 2. From Drill's perspective the issue is
> we don't increment the connection count with a valid TCP connection but
> decrements it only in close of TCP connection. So with this PR we are
> addressing those issues. Similar was a case for other channel counters as
> well.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
