[
https://issues.apache.org/jira/browse/HIVE-25085?focusedWorklogId=596961&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-596961
]
ASF GitHub Bot logged work on HIVE-25085:
-----------------------------------------
Author: ASF GitHub Bot
Created on: 14/May/21 22:21
Start Date: 14/May/21 22:21
Worklog Time Spent: 10m
Work Description: kishendas commented on a change in pull request #2238:
URL: https://github.com/apache/hive/pull/2238#discussion_r632839815
##########
File path: ql/src/java/org/apache/hadoop/hive/ql/session/SessionState.java
##########
@@ -2210,6 +2218,18 @@ public void endScope(String queryId) {
public Map<Object, Object> getQueryCache(String queryId) {
return cache.get(queryId);
}
+
+ public Hive getHiveDb() throws HiveException {
+ if (hiveDb == null) {
+ hiveDb = Hive.createHiveForSession(sessionConf);
+ // Need to setAllowClose to false. For legacy reasons, the Hive object
is stored
+ // in thread local storage. If allowClose is true, the session can get
closed when
+ // the thread goes away which is not desirable when the Hive object is
used across
+ // different queries in the session.
+ hiveDb.setAllowClose(false);
Review comment:
Got it. I see that close() method has a check for allowClose().
##########
File path:
service/src/java/org/apache/hive/service/cli/session/HiveSessionImpl.java
##########
@@ -408,18 +400,10 @@ private synchronized void acquireAfterOpLock(boolean
userAccess) {
// set the thread name with the logging prefix.
sessionState.updateThreadName();
- // If the thread local Hive is different from sessionHive, it means, the
previous query execution in
- // master thread has re-created Hive object due to changes in MS related
configurations in sessionConf.
- // So, it is necessary to reset sessionHive object based on new
sessionConf. Here, we cannot,
- // directly set sessionHive with thread local Hive because if the previous
command was REPL LOAD, then
- // the config changes lives only within command execution not in session
level.
- // So, the safer option is to invoke Hive.get() which decides if to reuse
Thread local Hive or re-create it.
- if (Hive.getThreadLocal() != sessionHive) {
- try {
- setSessionHive();
- } catch (HiveSQLException e) {
- throw new RuntimeException(e);
- }
+ try {
Review comment:
My bad. Did not see if block going away.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
-------------------
Worklog Id: (was: 596961)
Time Spent: 1.5h (was: 1h 20m)
> MetaStore Clients are being shared across different sessions
> ------------------------------------------------------------
>
> Key: HIVE-25085
> URL: https://issues.apache.org/jira/browse/HIVE-25085
> Project: Hive
> Issue Type: Bug
> Components: HiveServer2
> Reporter: Steve Carlin
> Priority: Major
> Labels: pull-request-available
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> The Hive object (and the underlying MetaStoreClient object) seems to be
> getting shared across different sessions. While most operations work, there
> can be occasional glitches.
> One such noted glitch is that when session 1 ends, it closes the connection.
> If session 2 then tries an operation, the first try will fail. Normally this
> can proceed because the RetryingMetaStoreClient will re-establish a new
> connection, but in some operations, the retrying logic will not kick in (by
> design).
> It seems there was an attempt to fix this issue in HIVE-20682. However, this
> implementation seems to be flawed. The HiveSessionImpl object creates a Hive
> object and makes sure all thread queries belonging to the same session will
> run with the same Hive object. The flaw is that the initial Hive Object
> within HiveSessionImpl is created in thread local storage. The thread being
> run at that moment is not session specific. It belongs to a thread pool that
> happens to be handling this specific session.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
