[
https://issues.apache.org/jira/browse/HIVE-6364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13939592#comment-13939592
]
Jason Dere commented on HIVE-6364:
----------------------------------
Hi Jaideep, when I tried debugging hiveserver2 due to HIVE-6672, it appeared
that there was a thread running for each connection (session). Non-SQL
commands (such as ADD JAR), were being run within this session thread and so
the classloader for the session thread had the JARs loaded. When a SQL command
was executed the session thread would start a new thread, and it appeared that
this new thread was using the same classloader (and had the added JARs in the
classloader's list of URLs). Were you seeing different behavior in your
testing (I was running this on Mac, I think with jdk 1.6, not sure if it would
have been different)?
In the patch, the thread's classloader is getting set to the HiveConf's
classloader .. where is the HiveConf's classloader getting set from? Do we need
to worry about having to make sure this classloader is updated whenever a JAR
is added to the classpath?
> HiveServer2 - Request serving thread should get class loader from existing
> SessionState
> ---------------------------------------------------------------------------------------
>
> Key: HIVE-6364
> URL: https://issues.apache.org/jira/browse/HIVE-6364
> Project: Hive
> Issue Type: Bug
> Components: HiveServer2
> Reporter: Jaideep Dhok
> Attachments: HIVE-6364.1.patch
>
>
> SessionState is created for each session in HS2. If we do any add jars, a
> class loader is set in the SessionState's conf object. This class loader
> should also be set in each thread that serves request of the same session.
> Scenario (both requests are in the same session)-
> {noformat}
> // req 1
> add jar foo.jar // Served by thread th1, this updates class loader and sets
> in SessionState.conf
> // req2 served by th2, such that th1 != th2
> CREATE TEMPORARY FUNCTION foo_udf AS 'some class in foo.jar'
> // This can throw class not found error, because although
> // the new thread (th2) gets the same session state as th1,
> // the class loader is different (Thread.currentThread.getContextClassLoader()
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
