drill-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DRILL-5701) drill.connections.rpc.<user/control/data>.<encrypted/unencrypted> metric not behaving correctly
Date Tue, 22 Aug 2017 22:23:00 GMT

    [ https://issues.apache.org/jira/browse/DRILL-5701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16137499#comment-16137499

ASF GitHub Bot commented on DRILL-5701:

Github user sohami commented on a diff in the pull request:

    --- Diff: exec/java-exec/src/test/java/org/apache/drill/exec/rpc/user/security/TestUserBitKerberos.java
    @@ -137,6 +142,41 @@ public Void run() throws Exception {
         test("SELECT * FROM cp.`region.json` LIMIT 5");
    +  @Test
    +  public void testUnecryptedConnectionCounter() throws Exception {
    +    final Properties connectionProps = new Properties();
    +    connectionProps.setProperty(DrillProperties.SERVICE_PRINCIPAL, krbHelper.SERVER_PRINCIPAL);
    +    connectionProps.setProperty(DrillProperties.KERBEROS_FROM_SUBJECT, "true");
    +    final Subject clientSubject = JaasKrbUtil.loginUsingKeytab(krbHelper.CLIENT_PRINCIPAL,
    +        krbHelper.clientKeytab.getAbsoluteFile());
    +    Subject.doAs(clientSubject, new PrivilegedExceptionAction<Void>() {
    +      @Override
    +      public Void run() throws Exception {
    +        updateClient(connectionProps);
    +        return null;
    +      }
    +    });
    +    // Run few queries using the new client
    +    testBuilder()
    +        .sqlQuery("SELECT session_user FROM (SELECT * FROM sys.drillbits LIMIT 1)")
    +        .unOrdered()
    +        .baselineColumns("session_user")
    +        .baselineValues(krbHelper.CLIENT_SHORT_NAME)
    +        .go();
    +    // Check encrypted counters value
    --- End diff --
    Updated the test description for explaining the logic behind different count values. Also
rebase PR on latest apache master. This test will change based on the [PR for DRILL-5721](https://github.com/apache/drill/pull/919)
since for local fragment's on Foreman node status update will happen locally and hence there
won't be any Control Connection created from a Drillbit to itself. I will update the test
based on which commit makes in first.

> 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

View raw message