[
https://issues.apache.org/jira/browse/GEODE-6267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16743391#comment-16743391
]
Barry Oglesby commented on GEODE-6267:
--------------------------------------
I found something else while debugging this leak.
If the ClentHealthMonitor unregisters the CacheClientProxy, most of
closeTransientFields is short-circuited. This is the normal code path.
In this code path, terminateDispatching calls closeSocket before calling
closeTransientFields. In the finally block, closeTransientFields is called.
{noformat}
java.lang.Exception: Stack trace
at java.lang.Thread.dumpStack(Thread.java:1333)
at
org.apache.geode.internal.cache.tier.sockets.CacheClientProxy.closeTransientFields(CacheClientProxy.java:965)
at
org.apache.geode.internal.cache.tier.sockets.CacheClientProxy.terminateDispatching(CacheClientProxy.java:945)
at
org.apache.geode.internal.cache.tier.sockets.CacheClientProxy.close(CacheClientProxy.java:794)
at
org.apache.geode.internal.cache.tier.sockets.CacheClientNotifier.closeDeadProxies(CacheClientNotifier.java:1712)
at
org.apache.geode.internal.cache.tier.sockets.CacheClientNotifier.unregisterClient(CacheClientNotifier.java:724)
at
org.apache.geode.internal.cache.tier.sockets.ClientHealthMonitor.unregisterClient(ClientHealthMonitor.java:270)
at
org.apache.geode.internal.cache.tier.sockets.ServerConnection.handleTermination(ServerConnection.java:958)
at
org.apache.geode.internal.cache.tier.sockets.ServerConnection.handleTermination(ServerConnection.java:878)
at
org.apache.geode.internal.cache.tier.sockets.ServerConnection.run(ServerConnection.java:1229)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at
org.apache.geode.internal.cache.tier.sockets.AcceptorImpl.lambda$initializeServerConnectionThreadPool$3(AcceptorImpl.java:613)
at
org.apache.geode.internal.logging.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:121)
{noformat}
Since closeSocket has already been called interminateDispatching,
closeTransientFields short-circuits the rest of the method:
{noformat}
if (!closeSocket()) {
// The thread who closed the socket will be responsible to
// releaseResourcesForAddress and clearClientInterestList
return;
}
{noformat}
This means that these methods aren't called:
{noformat}
releaseCommBuffer
releaseResourcesForAddress
{noformat}
I addressed this issue in my changes as well.
> Subjects are not logged out when a client departs causing a memory leak
> -----------------------------------------------------------------------
>
> Key: GEODE-6267
> URL: https://issues.apache.org/jira/browse/GEODE-6267
> Project: Geode
> Issue Type: Bug
> Components: security
> Reporter: Barry Oglesby
> Assignee: Barry Oglesby
> Priority: Major
>
> When a client with security enabled connects to a server, the
> IntegratedSecurityService logs in a Subject. This causes a SimpleSession to
> be created.
> The Subject is stored in ClientUserAuths.uniqueIdVsSubject.
> Here is a stack showing the SimpleSession creation:
> {noformat}
> [warning 2019/01/08 18:02:42.993 PST server1 <ServerConnection on port 40401
> Thread 0> tid=0x4e] SimpleSession.<init> invoked:
> java.lang.Exception
> at org.apache.shiro.session.mgt.SimpleSession.<init>(SimpleSession.java:99)
> at
> org.apache.shiro.session.mgt.SimpleSessionFactory.createSession(SimpleSessionFactory.java:44)
> at
> org.apache.shiro.session.mgt.DefaultSessionManager.newSessionInstance(DefaultSessionManager.java:163)
> at
> org.apache.shiro.session.mgt.DefaultSessionManager.doCreateSession(DefaultSessionManager.java:154)
> at
> org.apache.shiro.session.mgt.AbstractValidatingSessionManager.createSession(AbstractValidatingSessionManager.java:136)
> at
> org.apache.shiro.session.mgt.AbstractNativeSessionManager.start(AbstractNativeSessionManager.java:99)
> at
> org.apache.shiro.mgt.SessionsSecurityManager.start(SessionsSecurityManager.java:152)
> at
> org.apache.shiro.subject.support.DelegatingSubject.getSession(DelegatingSubject.java:336)
> at
> org.apache.shiro.subject.support.DelegatingSubject.getSession(DelegatingSubject.java:312)
> at
> org.apache.shiro.mgt.DefaultSubjectDAO.mergePrincipals(DefaultSubjectDAO.java:204)
> at
> org.apache.shiro.mgt.DefaultSubjectDAO.saveToSession(DefaultSubjectDAO.java:166)
> at org.apache.shiro.mgt.DefaultSubjectDAO.save(DefaultSubjectDAO.java:147)
> at
> org.apache.shiro.mgt.DefaultSecurityManager.save(DefaultSecurityManager.java:383)
> at
> org.apache.shiro.mgt.DefaultSecurityManager.createSubject(DefaultSecurityManager.java:350)
> at
> org.apache.shiro.mgt.DefaultSecurityManager.createSubject(DefaultSecurityManager.java:183)
> at
> org.apache.shiro.mgt.DefaultSecurityManager.login(DefaultSecurityManager.java:283)
> at
> org.apache.shiro.subject.support.DelegatingSubject.login(DelegatingSubject.java:256)
> at
> org.apache.geode.internal.security.IntegratedSecurityService.login(IntegratedSecurityService.java:139)
> at
> org.apache.geode.internal.cache.tier.sockets.HandShake.verifyCredentials(HandShake.java:1688)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.setCredentials(ServerConnection.java:1044)
> at
> org.apache.geode.internal.cache.tier.sockets.command.PutUserCredentials.cmdExecute(PutUserCredentials.java:52)
> at
> org.apache.geode.internal.cache.tier.sockets.BaseCommand.execute(BaseCommand.java:163)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.doNormalMsg(ServerConnection.java:797)
> at
> org.apache.geode.internal.cache.tier.sockets.LegacyServerConnection.doOneMessage(LegacyServerConnection.java:85)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.run(ServerConnection.java:1179)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at
> org.apache.geode.internal.cache.tier.sockets.AcceptorImpl$4$1.run(AcceptorImpl.java:641)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
> When the client disconnects, the ClientUserAuths is cleaned up (in cleanup),
> but the Subjects are not logged out.
> With subscription-enabled=true, an additional Subject is created and stored
> in the CacheClientProxy subject. This Subject is not logged out either.
> Here is a stack showing the SimpleSession creation:
> {noformat}
> [warning 2019/01/08 18:02:43.023 PST server1 <Client Queue Initialization
> Thread 0> tid=0x52] SimpleSession.<init> invoked:
> java.lang.Exception
> at org.apache.shiro.session.mgt.SimpleSession.<init>(SimpleSession.java:99)
> at
> org.apache.shiro.session.mgt.SimpleSessionFactory.createSession(SimpleSessionFactory.java:44)
> at
> org.apache.shiro.session.mgt.DefaultSessionManager.newSessionInstance(DefaultSessionManager.java:163)
> at
> org.apache.shiro.session.mgt.DefaultSessionManager.doCreateSession(DefaultSessionManager.java:154)
> at
> org.apache.shiro.session.mgt.AbstractValidatingSessionManager.createSession(AbstractValidatingSessionManager.java:136)
> at
> org.apache.shiro.session.mgt.AbstractNativeSessionManager.start(AbstractNativeSessionManager.java:99)
> at
> org.apache.shiro.mgt.SessionsSecurityManager.start(SessionsSecurityManager.java:152)
> at
> org.apache.shiro.subject.support.DelegatingSubject.getSession(DelegatingSubject.java:336)
> at
> org.apache.shiro.subject.support.DelegatingSubject.getSession(DelegatingSubject.java:312)
> at
> org.apache.shiro.mgt.DefaultSubjectDAO.mergePrincipals(DefaultSubjectDAO.java:204)
> at
> org.apache.shiro.mgt.DefaultSubjectDAO.saveToSession(DefaultSubjectDAO.java:166)
> at org.apache.shiro.mgt.DefaultSubjectDAO.save(DefaultSubjectDAO.java:147)
> at
> org.apache.shiro.mgt.DefaultSecurityManager.save(DefaultSecurityManager.java:383)
> at
> org.apache.shiro.mgt.DefaultSecurityManager.createSubject(DefaultSecurityManager.java:350)
> at
> org.apache.shiro.mgt.DefaultSecurityManager.createSubject(DefaultSecurityManager.java:183)
> at
> org.apache.shiro.mgt.DefaultSecurityManager.login(DefaultSecurityManager.java:283)
> at
> org.apache.shiro.subject.support.DelegatingSubject.login(DelegatingSubject.java:256)
> at
> org.apache.geode.internal.security.IntegratedSecurityService.login(IntegratedSecurityService.java:139)
> at
> org.apache.geode.internal.cache.tier.sockets.HandShake.verifyCredentials(HandShake.java:1688)
> at
> org.apache.geode.internal.cache.tier.sockets.CacheClientNotifier.registerGFEClient(CacheClientNotifier.java:343)
> at
> org.apache.geode.internal.cache.tier.sockets.CacheClientNotifier.registerClient(CacheClientNotifier.java:279)
> at
> org.apache.geode.internal.cache.tier.sockets.AcceptorImpl$ClientQueueInitializerTask.run(AcceptorImpl.java:1844)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at
> org.apache.geode.internal.cache.tier.sockets.AcceptorImpl$3$1.run(AcceptorImpl.java:611)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
> Both of these cause a memory leak of SimpleSessions.
> In my simple test where a client with subscription-enabled=true connects and
> disconnects, 3 SimpleSessions are created. Each additional client
> connect/disconnect causes 3 more SimpleSessions to be created.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
