December 2018 - jboss-jira - Jboss List Archives

[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

1
0
0 / 0

[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

1
0
0 / 0

[JBoss JIRA] (DROOLS-3355) Improve Assembler/Weaver API to better support for jBPM and generic runtimes

by Edoardo Vacchi (Jira)

[ https://issues.jboss.org/browse/DROOLS-3355?page=com.atlassian.jira.plugi... ] Edoardo Vacchi updated DROOLS-3355: ----------------------------------- Summary: Improve Assembler/Weaver API to better support for jBPM and generic runtimes (was: Discuss and verify Assembler/Weaver API to better support for jBPM and generic runtimes) > Improve Assembler/Weaver API to better support for jBPM and generic runtimes > ---------------------------------------------------------------------------- > > Key: DROOLS-3355 > URL: https://issues.jboss.org/browse/DROOLS-3355 > Project: Drools > Issue Type: Enhancement > Reporter: Edoardo Vacchi > Assignee: Edoardo Vacchi > Priority: Major > Labels: drools-core > > Current API may be too Drools/Rule-Engine-centric, might want to rethink it -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3355) Discuss and verify Assembler/Weaver API to better support for jBPM and generic runtimes

by Edoardo Vacchi (Jira)

[ https://issues.jboss.org/browse/DROOLS-3355?page=com.atlassian.jira.plugi... ] Edoardo Vacchi updated DROOLS-3355: ----------------------------------- Comment: was deleted (was: https://github.com/kiegroup/drools/pull/2170 https://github.com/kiegroup/droolsjbpm-knowledge/pull/347) > Discuss and verify Assembler/Weaver API to better support for jBPM and generic runtimes > --------------------------------------------------------------------------------------- > > Key: DROOLS-3355 > URL: https://issues.jboss.org/browse/DROOLS-3355 > Project: Drools > Issue Type: Enhancement > Reporter: Edoardo Vacchi > Assignee: Edoardo Vacchi > Priority: Major > Labels: drools-core > > Current API may be too Drools/Rule-Engine-centric, might want to rethink it -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3355) Discuss and verify Assembler/Weaver API to better support for jBPM and generic runtimes

by Edoardo Vacchi (Jira)

[ https://issues.jboss.org/browse/DROOLS-3355?page=com.atlassian.jira.plugi... ] Edoardo Vacchi resolved DROOLS-3355. ------------------------------------ Resolution: Done https://github.com/kiegroup/drools/pull/2170 https://github.com/kiegroup/droolsjbpm-knowledge/pull/347 > Discuss and verify Assembler/Weaver API to better support for jBPM and generic runtimes > --------------------------------------------------------------------------------------- > > Key: DROOLS-3355 > URL: https://issues.jboss.org/browse/DROOLS-3355 > Project: Drools > Issue Type: Enhancement > Reporter: Edoardo Vacchi > Assignee: Edoardo Vacchi > Priority: Major > Labels: drools-core > > Current API may be too Drools/Rule-Engine-centric, might want to rethink it -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3355) Discuss and verify Assembler/Weaver API to better support for jBPM and generic runtimes

by Edoardo Vacchi (Jira)

[ https://issues.jboss.org/browse/DROOLS-3355?page=com.atlassian.jira.plugi... ] Edoardo Vacchi reopened DROOLS-3355: ------------------------------------ > Discuss and verify Assembler/Weaver API to better support for jBPM and generic runtimes > --------------------------------------------------------------------------------------- > > Key: DROOLS-3355 > URL: https://issues.jboss.org/browse/DROOLS-3355 > Project: Drools > Issue Type: Enhancement > Reporter: Edoardo Vacchi > Assignee: Edoardo Vacchi > Priority: Major > Labels: drools-core > > Current API may be too Drools/Rule-Engine-centric, might want to rethink it -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3379) RuntimeService API should not require a KSession to create an instance

by Edoardo Vacchi (Jira)

[ https://issues.jboss.org/browse/DROOLS-3379?page=com.atlassian.jira.plugi... ] Edoardo Vacchi updated DROOLS-3379: ----------------------------------- Sprint: 2018 Week 48-50 > RuntimeService API should not require a KSession to create an instance > ---------------------------------------------------------------------- > > Key: DROOLS-3379 > URL: https://issues.jboss.org/browse/DROOLS-3379 > Project: Drools > Issue Type: Enhancement > Reporter: Edoardo Vacchi > Assignee: Edoardo Vacchi > Priority: Major > Labels: drools-core > > {{<T> T getKieRuntime(Class<T> cls)}} is in {{KieSession}} but in some cases a session is overkill. A KieBase is enough (TBF a package may be enough, but let's go with KieBase for now) -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3379) RuntimeService API should not require a KSession to create an instance

by Edoardo Vacchi (Jira)

[ https://issues.jboss.org/browse/DROOLS-3379?page=com.atlassian.jira.plugi... ] Edoardo Vacchi updated DROOLS-3379: ----------------------------------- Labels: drools-core (was: ) > RuntimeService API should not require a KSession to create an instance > ---------------------------------------------------------------------- > > Key: DROOLS-3379 > URL: https://issues.jboss.org/browse/DROOLS-3379 > Project: Drools > Issue Type: Enhancement > Reporter: Edoardo Vacchi > Assignee: Edoardo Vacchi > Priority: Major > Labels: drools-core > > {{<T> T getKieRuntime(Class<T> cls)}} is in {{KieSession}} but in some cases a session is overkill. A KieBase is enough (TBF a package may be enough, but let's go with KieBase for now) -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 5 months

1
0
0 / 0

[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

1
0
0 / 0

[JBoss JIRA] (WFLY-11478) Add test to cover a messaging subsystem without any internal broker

by ehsavoie Hugonnet (Jira)

[ https://issues.jboss.org/browse/WFLY-11478?page=com.atlassian.jira.plugin... ] ehsavoie Hugonnet updated WFLY-11478: ------------------------------------- Git Pull Request: https://github.com/wildfly/wildfly/pull/11922 (was: https://issues.jboss.org/browse/WFLY-11478) > Add test to cover a messaging subsystem without any internal broker > ------------------------------------------------------------------- > > Key: WFLY-11478 > URL: https://issues.jboss.org/browse/WFLY-11478 > Project: WildFly > Issue Type: Enhancement > Components: JMS, Test Suite > Affects Versions: 15.0.0.Final > Reporter: ehsavoie Hugonnet > Assignee: ehsavoie Hugonnet > Priority: Major > > Currently we don't test the configuration of a simple messaging subsystem without any broker nor connection factory. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 5 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira December 2018