hive-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hive QA (JIRA)" <>
Subject [jira] [Commented] (HIVE-16172) Switch to a fairness lock to synchronize HS2 thrift client
Date Fri, 10 Mar 2017 08:37:04 GMT


Hive QA commented on HIVE-16172:

Here are the results of testing the latest attachment:

{color:red}ERROR:{color} -1 due to no test(s) being added or modified.

{color:green}SUCCESS:{color} +1 due to 10336 tests passed

Test results:
Console output:
Test logs:

Executing org.apache.hive.ptest.execution.TestCheckPhase
Executing org.apache.hive.ptest.execution.PrepPhase
Executing org.apache.hive.ptest.execution.ExecutionPhase
Executing org.apache.hive.ptest.execution.ReportingPhase

This message is automatically generated.

ATTACHMENT ID: 12857262 - PreCommit-HIVE-Build

> Switch to a fairness lock to synchronize HS2 thrift client
> ----------------------------------------------------------
>                 Key: HIVE-16172
>                 URL:
>             Project: Hive
>          Issue Type: Bug
>            Reporter: Tao Li
>            Assignee: Tao Li
>         Attachments: HIVE-16172.1.patch
> A synchronized block is used in "org.apache.hive.jdbc.HiveConnection.SynchronizedHandler.invoke(Object,
Method, Object[])" to synchronize the client invocations. The problem is that it does not
guarantee any fairness. One issue we were seeing is that a cancellation request was not able
to be issued to HS2 until all the getOperationStatus() calls are finished from a while loop.
Thus the cancellation cannot take effect.

This message was sent by Atlassian JIRA

View raw message