[ 
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:

    https://github.com/apache/drill/pull/894#discussion_r134616629
  
    --- 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
(v6.4.14#64029)

Reply via email to