drill-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Arina Ielchiieva (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (DRILL-5701) drill.connections.rpc.<user/control/data>.<encrypted/unencrypted> metric not behaving correctly
Date Fri, 25 Aug 2017 11:43:00 GMT

     [ https://issues.apache.org/jira/browse/DRILL-5701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Arina Ielchiieva updated DRILL-5701:
    Reviewer: Karthikeyan Manivannan

> 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

View raw message