[
https://issues.jboss.org/browse/DROOLS-3412?page=com.atlassian.jira.plugi...
]
Mario Fusco commented on DROOLS-3412:
-------------------------------------
We have some jmh benchmarks for the sesssion pool and we didn't find any similar
performance issue. See
https://github.com/kiegroup/kie-benchmarks/tree/7f60e47cba510214cb86cb4bc...
It would be great if you could provide some similar benchmark to demonstrate the problem
that you're reporting.
Also I'm a bit confused about your description because you wrote
"Skip dispose (because of pool != null in the dispose method), reset the session and
go back to 2 for the next facts"
but in the code you linked you're actually calling the dispose, which by the way is
the correct thing to do because in that case it puts the session back into the pool.
Finally, looking at your code, it is also possible that you could have a memory leak on
your side, because you are setting the same global and inserting the same dataStore
instance into each session. However I cannot be sure of this, so my suggestion is to
provide a jmh based benchmark (using your rules and domain classes if necessary)
reproducing this performance problem, so we could investigate it further.
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)