[jboss-jira] [JBoss JIRA] (DROOLS-1364) InMemorySessionFactory has apparent memory leak
Maciej Swiderski (JIRA)
issues at jboss.org
Mon Nov 21 05:49:01 EST 2016
[ https://issues.jboss.org/browse/DROOLS-1364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13325457#comment-13325457 ]
Maciej Swiderski commented on DROOLS-1364:
------------------------------------------
first of all if you use rules only you should not use runtime manager. It's api is meant for jBPM use cases where kie session management is much more advanced (configuration wise). Second of all, you should dispose runtime engine after you're done with it making sure the ksession is then removed from runtime manager properly.
I'd recommend to not use runtime manager when you don't need to use jBPM. Further more, it will decrease number of dependencies that are jBPM specific.
> InMemorySessionFactory has apparent memory leak
> -----------------------------------------------
>
> Key: DROOLS-1364
> URL: https://issues.jboss.org/browse/DROOLS-1364
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.5.0.Final
> Reporter: Eli Israel
> Assignee: Maciej Swiderski
>
> I'm running drools with a runtime manager creating using PerRequest strategy and SessionCache turned on. (I process a LOT of requests but I want each one to be isolated)
> The SessionCache properly gets rid of sessions that have hung around too long, which is great.
> But the InMemorySessionFactory keeps a copy of every session it ever created, which -- it seems to me -- impedes garbage collection of unneeded, old sessions.
> It's possible I'm just reading this wrong, but examinations of running code using VisualVM show a LOT of RightTuple objects hanging around, attached to sessions and their GC root appears to be the InMemorySessionFactory.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
More information about the jboss-jira
mailing list