[JBoss JIRA] (DROOLS-3412) Performance degradation with session pools
by Christian Liebhardt (Jira)
[ https://issues.jboss.org/browse/DROOLS-3412?page=com.atlassian.jira.plugi... ]
Christian Liebhardt commented on DROOLS-3412:
---------------------------------------------
The slow down seems to be caused by increased GC activity. This grap shows the GC behavior of two runs, the frequency in which sessions are created should have been constant:
!gc.png|thumbnail!
> 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)
7 years, 5 months
[JBoss JIRA] (DROOLS-3412) Performance degradation with session pools
by Christian Liebhardt (Jira)
[ https://issues.jboss.org/browse/DROOLS-3412?page=com.atlassian.jira.plugi... ]
Christian Liebhardt updated DROOLS-3412:
----------------------------------------
Attachment: gc.png
> 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)
7 years, 5 months
[JBoss JIRA] (WFCORE-4129) WFLYSRV0266: Server home is set to... info msg in domain for RPM installation
by Lin Gao (Jira)
[ https://issues.jboss.org/browse/WFCORE-4129?page=com.atlassian.jira.plugi... ]
Lin Gao updated WFCORE-4129:
----------------------------
Labels: downstream_dependency (was: )
> WFLYSRV0266: Server home is set to... info msg in domain for RPM installation
> -----------------------------------------------------------------------------
>
> Key: WFCORE-4129
> URL: https://issues.jboss.org/browse/WFCORE-4129
> Project: WildFly Core
> Issue Type: Bug
> Components: Server
> Reporter: Lin Gao
> Assignee: Lin Gao
> Priority: Major
> Labels: downstream_dependency
>
> When EAP is installed via RPM packages and started in domain mode, there are following info messages visible in the {{server.log}}:
> {code}
> [INFO] [line 163] 2018-08-31 11:22:18,251 WARN [org.jboss.as.server] (main) WFLYSRV0266: Server home is set to '/opt/rh/eap7/root/usr/share/wildfly/domain/servers/server-one', but server real home is '/var/opt/rh/eap7/lib/wildfly/domain/servers/server-one' - unpredictable results may occur.
> [INFO] [line 4] 2018-08-31 10:25:47,525 WARN [org.jboss.as.server] (main) WFLYSRV0266: Server home is set to '/opt/rh/eap7/root/usr/share/wildfly/domain/servers/server-two', but server real home is '/var/opt/rh/eap7/lib/wildfly/domain/servers/server-two' - unpredictable results may occur.
> {code}
> Based on the [comment in issue JBEAP-10261|https://issues.jboss.org/browse/JBEAP-10261?focusedCommentId=...], it looks like a side effect of that. So main problem is probably in the startup scripts and not in RPM themselves.
> Even though, those messages are just INFO level, still - I believe that as this is a default RPM installation no such disturbing message takes place in the log. We should either be sure that this kind of installation makes no trouble or we should adjust the installation way itself so such info message does not have to be printed.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 5 months