[
https://issues.jboss.org/browse/DROOLS-3412?page=com.atlassian.jira.plugi...
]
Christian Liebhardt edited comment on DROOLS-3412 at 12/7/18 11:19 AM:
-----------------------------------------------------------------------
The reason for this issue seems to be that the InternalProcessRuntime inside
StatefulKnowledgeSessionImpl doesn't get disposed with session pools. It only gets set
to null. For the default case where DummyInternalProcessRuntime is used that works fine.
However in our case (real application, not the example sandbox linked to this ticket)
org.jbpm.process.instance.ProcessRuntimeImpl is used. I did a quick debugging of the
benchmark you linked at that could also explain why this hasn't shown in the benchmark
so far. I will try to come up with an idea how to change the benchmark next week.
was (Author: christianl):
The reason for this issue seems to be that the InternalProcessRuntime inside
StatefulKnowledgeSessionImpl doesn't get disposed with session pools. It only gets set
to null. For the default case where DummyInternalProcessRuntime is used that works fine.
However in our case (real application, not the reproducer linked to this ticket)
org.jbpm.process.instance.ProcessRuntimeImpl is used. I did a quick debugging of the
benchmark you linked at that could also explain why this hasn't shown in the benchmark
so far. I will try to come up with an idea how to change the benchmark next week.
Performance degradation with session pools
------------------------------------------
Key: DROOLS-3412
URL:
https://issues.jboss.org/browse/DROOLS-3412
Project: Drools
Issue Type: Bug
Reporter: Christian Liebhardt
Assignee: Mario Fusco
Priority: Major
Attachments: gc.png
Hello,
We've today updates to Drools 7.15 and as discussed with DROOLS-3228 we changed our
code from calling _StatefulKnowledgeSessionImpl.reset_ ourselves to _KieSessionsPool_.
However we then recognized that our application quickly became slower and slower over time
(roughly after a few minutes of uptime, or a couple of hundred session create/dispose
cycles).
I haven't yet found the reason what is causing the slow down. However I think there
is a difference in how we reset our sessions before session pools and how session pools do
it. Perhaps that is a lead.
*What we did*
# Create a session
# Use the session
# Dispose and reset the session and go back to 2 for the next facts
*What happens with session pools*
# Create a session
# Use the session
# Skip dispose (because of _pool != null_ in the dispose method), reset the session and
go back to 2 for the next facts
So the difference seems to be that with session pools the session doesn't get
disposed before reset it called. If I do the same without session pools then I also see
the same slow down. So it seems that something is left behind and causes a slow down. The
results however seem to be correct, so the right consequences appear to be triggered.
An example on how we use the session pool can be found here:
https://github.com/liebharc/JavaRules/blob/master/src/main/java/com/githu...
Thanks once more for your help.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)