hive-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sankar Hariappan (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (HIVE-20682) Async query execution can potentially fail if shared sessionHive is closed by master thread.
Date Tue, 23 Oct 2018 12:01:00 GMT

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

Sankar Hariappan updated HIVE-20682:
------------------------------------
    Attachment:     (was: HIVE-20682.01.patch)

> Async query execution can potentially fail if shared sessionHive is closed by master
thread.
> --------------------------------------------------------------------------------------------
>
>                 Key: HIVE-20682
>                 URL: https://issues.apache.org/jira/browse/HIVE-20682
>             Project: Hive
>          Issue Type: Bug
>          Components: HiveServer2
>    Affects Versions: 3.1.0, 4.0.0
>            Reporter: Sankar Hariappan
>            Assignee: Sankar Hariappan
>            Priority: Major
>              Labels: pull-request-available
>         Attachments: HIVE-20682.01.patch
>
>
> *Problem description:*
> The master thread initializes the *sessionHive* object in *HiveSessionImpl* class when we
open a new session for a client connection and by default all queries from this connection shares
the same sessionHive object. 
> If the master thread executes a *synchronous* query, it closes the sessionHive object
(referred via thread local hiveDb) if  {{Hive.isCompatible}} returns false and sets new Hive
object in thread local HiveDb but doesn't change the sessionHive object in the session. Whereas,
*asynchronous* query execution via async threads never closes the sessionHive object and
it just creates a new one if needed and sets it as their thread local hiveDb.
> So, the problem can happen in the case where an *asynchronous* query is being executed
by async threads refers to sessionHive object and the master thread receives a *synchronous*
query that closes the same sessionHive object. 
> Also, each query execution overwrites the thread local hiveDb object to sessionHive object
which potentially leaks a metastore connection if the previous synchronous query execution
re-created the Hive object.
> *Possible Fix:*
> We shall maintain an Atomic reference counter in the Hive object. We increment the
counter when somebody sets it in thread local hiveDb and decrement it when somebody releases it. Only
when the counter is down to 0, we should close the connection.
> Couple of cases to release the thread local hiveDb:
>  * When synchronous query execution in master thread re-creates Hive object due to config
change. We also, need to update the sessionHive object in the current session as we releases
it from thread local hiveDb of master thread.
>  * When async thread exits after completing execution or due to exception.
> If the session is getting closed, it is guaranteed that the reference counter is down
to 0 as we forcefully close all the async operations and so we can close the connection there.
> cc [~pvary]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Mime
View raw message