ATLAS-3092: Atlas Plugin ClassLoader Doesn't Restore Thread ClassLoader#32
ATLAS-3092: Atlas Plugin ClassLoader Doesn't Restore Thread ClassLoader#32rajkrrsingh wants to merge 1 commit intoapache:masterfrom
Conversation
| LOG.debug("==> AtlasPluginClassLoader.activate()"); | ||
| } | ||
|
|
||
| previousLoader = Thread.currentThread().getContextClassLoader(); |
There was a problem hiding this comment.
AtlasPluginClassLoader instance could be used in multiple threads simultaneously. So, saving 'previousLoader' in an instance member is not a safe option. @RMani (Ramesh Mani) is working on addressing the same issue in Ranger via RANGER-2376. I would suggest to wait for his Ranger fix and apply the same in Atlas as well.
There was a problem hiding this comment.
I wonder if it would be safe to save it on a per thread basis then?
There was a problem hiding this comment.
Or just handling this in the HiveHook it self? Then it should all be in the same thread and would be hive specific.
|
This issue is resolved in ATLAS-3092 and fix is merged, so closing the PR. |
4 participants
PROBLEM: Atlas Plugin ClassLoader's MyComponent parent always set to UDFClassLoader after hiveserver2 start even though it is closed, Hiveserver2 can run sessions concurrently with different sessionstate, so if the sessionstate disgraded and associated UDF classloader is closed, MyComponent parent loader still has this closed parent classloader. this can yield into the CNF exception for custom hive udf.
Fix: In this proposed fix, during activate call I am storing current classloader in prevClassloader and during deactivate checking if the plugintype is hive( don't want to break the other components) then setting the Thread current class loader back to the previous one.
Test: Run few test on my reproduce where hive custom udf were failing due to CNF which are succeeded now.