[
https://issues.apache.org/jira/browse/HIVE-20682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16669666#comment-16669666
]
Sankar Hariappan edited comment on HIVE-20682 at 10/31/18 6:59 AM:
-------------------------------------------------------------------
[~maheshk114]
I think there is misunderstanding. There won't be any impact in current usage.
* Reference count of Hive object should be incremented only when some thread
sets it in Thread local. Not for every Hive.get() call.
* It will be decremented when the thread removes it from Thread local. If the
reference count is 0, then current thread will close the MS connection as well.
* If the Thread local is forcefully overwritten without removing the previous
Thread local properly, then the set() method ensures the previous one is
removed gracefully before overwriting with new one.
* So, just like current usage, it is expected to close the Hive object only
once within a thread after setting it in thread local.
Regarding, changes in sessionConf, we need to do the following.
* Reset sessionHive object using new sessionConf. But, the MS connection in
sessionHive object should be closed based on reference count as it might be
referred by some other async thread. All these methods are synchronised and so
no race conditions possible.
* If the previous query execution itself has recreated Thread local due to
config change, then sessionHive should be reset to previous Thread local Hive
itself instead of re-allocating.
Let me update the patch with this change and please review it.
cc [~pvary], [~daijy]
was (Author: sankarh):
[~maheshk114]
I think there is misunderstanding. There won't be any impact in current usage.
* Reference count of Hive object should be incremented only when some thread
sets it in Thread local. Not for every Hive.get() call.
* It will be decremented when the thread removes it from Thread local. If the
reference count is 0, then current thread will close the MS connection as well.
* If the Thread local is forcefully overwritten without removing the previous
Thread local properly, then the set() method ensures the previous one is
removed gracefully before overwriting with new one.
* So, just like current usage, it is expected to close the Hive object only
once within a thread after setting it in thread local.
Regarding, changes in sessionConf, we need to do the following.
* Reset sessionHive object using new sessionConf. But, the MS connection in
sessionHive object should be closed based on reference count as it might be
referred by some other async thread. All these methods are synchronised and so
no race conditions possible.
* Currently, sessionHive stores the sessionConf object reference and the same
sessionConf is updated for any configurations set within the session. This
makes isCompatible() to return true always even if there is MS related config
changes. So, to fix this, we need to recreate sessionConf object when there is
a set command.
Let me update the patch with this change and please review it.
cc [~pvary], [~daijy]
> 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,
> HIVE-20682.03.patch, HIVE-20682.04.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)
