[
https://issues.apache.org/jira/browse/HIVE-20682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sankar Hariappan updated HIVE-20682:
------------------------------------
Description:
*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:*
The *sessionHive* object could be shared my multiple threads and so it
shouldn't be allowed to be closed by any query execution threads when they
re-create the Hive object due to changes in Hive configurations. But the Hive
objects created by query execution threads should be closed when the thread
exits.
So, it is proposed to have an *isAllowClose* flag (default: *true*) in Hive
object which should be set to *false* for *sessionHive* and would be forcefully
closed when the session is closed or released.
cc [~pvary]
was:
*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]
> 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, HIVE-20682.02.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:*
> The *sessionHive* object could be shared my multiple threads and so it
> shouldn't be allowed to be closed by any query execution threads when they
> re-create the Hive object due to changes in Hive configurations. But the Hive
> objects created by query execution threads should be closed when the thread
> exits.
> So, it is proposed to have an *isAllowClose* flag (default: *true*) in Hive
> object which should be set to *false* for *sessionHive* and would be
> forcefully closed when the session is closed or released.
> cc [~pvary]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
