[
https://issues.apache.org/jira/browse/HIVE-27201?focusedWorklogId=858856&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-858856
]
ASF GitHub Bot logged work on HIVE-27201:
-----------------------------------------
Author: ASF GitHub Bot
Created on: 25/Apr/23 07:55
Start Date: 25/Apr/23 07:55
Worklog Time Spent: 10m
Work Description: deniskuzZ commented on code in PR #4180:
URL: https://github.com/apache/hive/pull/4180#discussion_r1176135981
##########
service/src/java/org/apache/hive/service/cli/session/HiveSessionImpl.java:
##########
@@ -432,6 +432,18 @@ private synchronized void releaseBeforeOpLock(boolean
userAccess) {
sessionState.resetThreadName();
}
+ // We have already set the thread-local Hive belonging to the current
session,
+ // if the thread-local Hive has been changed/updated after running the
operation,
+ // the Hive after should belong to the same session, and we should update
the sessionHive.
+ // The thread-local hive would be recreated only when the underlying
+ // HiveMetaStoreClient is incompatible with the newest session conf.
+ Hive localHive = Hive.getThreadLocal();
+ if (localHive != null && localHive != sessionHive) {
+ // The previous sessionHive would be GC'ed finally, or should we force
close it?
+ sessionHive = localHive;
+ sessionHive.setAllowClose(false);
Review Comment:
isn't this flag already set during open() in SessionState.getHiveDb()?
also shouldn't we call `resetThreadName()` on updated sessionHive?
Issue Time Tracking
-------------------
Worklog Id: (was: 858856)
Time Spent: 7h (was: 6h 50m)
> Inconsistency between session Hive and thread-local Hive may cause HS2
> deadlock
> -------------------------------------------------------------------------------
>
> Key: HIVE-27201
> URL: https://issues.apache.org/jira/browse/HIVE-27201
> Project: Hive
> Issue Type: Bug
> Components: HiveServer2
> Reporter: Zhihua Deng
> Assignee: Zhihua Deng
> Priority: Major
> Labels: pull-request-available
> Time Spent: 7h
> Remaining Estimate: 0h
>
> The HiveServer2’s server handler can switch to process the operation from
> other session, in such case, the Hive cached in ThreadLocal is not the same
> as the Hive in SessionState, and can be referenced by another session.
> If the two handlers swap their sessions to process the DatabaseMetaData
> request, and the HiveMetastoreClientFactory obtains the Hive via Hive.get(),
> then there is a chance that the deadlock can happen.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)