[
https://issues.apache.org/jira/browse/HADOOP-10357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13920059#comment-13920059
]
Larry McCay commented on HADOOP-10357:
--------------------------------------
Hi Daryn - thanks for the comments. Yes, it is a real leak. Usecase background:
this is a sccenario where - say a webapp - is authenticating every user through
UGI and attempting a doAs for JDBC access to HS2.
The problem lies in the fact that we are holding on to an instance of UGI for
the doAs that has a static metrics registry map inside. Inside of UGI
initialize UgiInstrumentation instance is acquired through a create method that
creates and registers the ugiInstrumentation in the static registry. This is
all fine - except for the fact that there is a new UGI instance for every hive
connection and each of those have initialize called and a new
ugiInstrumentation class is registered into the static registry. Therefore, we
end up with UgiI's for every connection. The metrics themselves - consisting of
char[]'s, byte[]'s, etc accumulate overtime and we eventually OOM.
I just realized that I haven't posted the VisualVM screen capture yet. I will
dig that up.
We need to make sure that the new metrics implementation that is in the 2 line
isn't leaking yet.
> Memory Leak in UserGroupInformation.doAs for JDBC Connection to Hive
> --------------------------------------------------------------------
>
> Key: HADOOP-10357
> URL: https://issues.apache.org/jira/browse/HADOOP-10357
> Project: Hadoop Common
> Issue Type: Bug
> Components: security
> Affects Versions: 1.2.0
> Reporter: Larry McCay
>
> When using UGI.doAs in order to make a connection there appears to be a
> memory leak involving the UGI that is used for the doAs and the UGI held by
> TUGIAssumingTransport.
> When using this approach to establishing a JDBC connection in an environment
> that will serve many users and requests client side eventually runs out of
> memory.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
