[
https://issues.apache.org/jira/browse/DRILL-5701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sorabh Hamirwasia updated DRILL-5701:
-------------------------------------
Description:
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.
was:
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.
> 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
>
> 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)
