[JBoss JIRA] (DROOLS-3431) [DMN Designer] Error after reopening
by Michael Anstis (Jira)
[ https://issues.jboss.org/browse/DROOLS-3431?page=com.atlassian.jira.plugi... ]
Michael Anstis edited comment on DROOLS-3431 at 12/13/18 8:10 AM:
------------------------------------------------------------------
Hi [~karreiro], can I have your opinion on this please :-)
The issue appears to be that when you first run the workbench and create a file the "Decision Navigator" dock is setup and the (Application Scoped) {{DecisionNavigatorObserver}} instantiated *after* the diagram has been opened and the session created (as it is not first referenced until after Stunner completes loading the diagram and creating the session).
When you then close the editor and re-open the file, the (Stunner) mechanism that opens the diagram and creates the session fires {{CanvasElementAddedEvent}} events that are received by {{DecisionNavigatorObserver}} *before* the Dock has its content set to the "open" session. This leads to the NPE in {{DecisionNavigatorBaseItemFactory.diagramUUID()}} reported by [~jomarko].
Now... I [changed|https://github.com/kiegroup/kie-wb-common/commit/89b09561595a063a...] {{DecisionNavigatorBaseItemFactory}} to use the "diagram UUID" as the parent of all base nodes instead of their parent when I added the Decision Service node (as this addition meant a Node's parent was not always the diagram).
Do you think it best I find a different approach for getting a "root UUID" for base items in the Decision Navigator. I assume *any* string will do and I don't really need to lookup a UUID for the diagram or any node for that matter.
was (Author: manstis):
Hi [~karreiro], can I have your opinion on this please :-)
The issue appears to be that when you first run the workbench and create a file the "Decision Navigator" dock is setup and the (Application Scoped) {{DecisionNavigatorObserver}} instantiated *after* the diagram has been opened and the session created. When you then close the editor and re-open the file, the (Stunner) mechanism that opens the diagram and creates the session fires {{CanvasElementAddedEvent}} events that are received by {{DecisionNavigatorObserver}} before the Dock has its content set to the "open" session. This leads to the NPE in {{DecisionNavigatorBaseItemFactory.diagramUUID()}} reported by [~jomarko].
Now... I [changed|https://github.com/kiegroup/kie-wb-common/commit/89b09561595a063a...] {{DecisionNavigatorBaseItemFactory}} to use the "diagram UUID" as the parent of all base nodes instead of their parent when I added the Decision Service node (as this addition meant a Node's parent was not always the diagram).
Do you think it best I find a different approach for getting a "root UUID" for base items in the Decision Navigator. I assume *any* string will do and I don't really need to lookup a UUID for the diagram or any node for that matter.
> [DMN Designer] Error after reopening
> ------------------------------------
>
> Key: DROOLS-3431
> URL: https://issues.jboss.org/browse/DROOLS-3431
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Affects Versions: 7.16.0.Final
> Reporter: Jozef Marko
> Assignee: Michael Anstis
> Priority: Critical
> Labels: drools-tools
> Attachments: Screenshot from 2018-12-13 08-09-38.png, reopen.error.log
>
>
> There appears an unexpected error dialog when user reopen stored dmn diagram. Secodn reopening works fine. See the steps to reproduce and attached error.
> This was spotted during [DROOL-3286 PR Review|https://github.com/kiegroup/kie-wb-common/pull/2344] however not sure if it is related.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (DROOLS-3431) [DMN Designer] Error after reopening
by Michael Anstis (Jira)
[ https://issues.jboss.org/browse/DROOLS-3431?page=com.atlassian.jira.plugi... ]
Michael Anstis commented on DROOLS-3431:
----------------------------------------
Hi [~karreiro], can I have your opinion on this please :-)
The issue appears to be that when you first run the workbench and create a file the "Decision Navigator" dock is setup and the (Application Scoped) {{DecisionNavigatorObserver}} instantiated *after* the diagram has been opened and the session created. When you then close the editor and re-open the file, the (Stunner) mechanism that opens the diagram and creates the session fires {{CanvasElementAddedEvent}} events that are received by {{DecisionNavigatorObserver}} before the Dock has its content set to the "open" session. This leads to the NPE in {{DecisionNavigatorBaseItemFactory.diagramUUID()}} reported by [~jomarko].
Now... I [changed|https://github.com/kiegroup/kie-wb-common/commit/89b09561595a063a...] {{DecisionNavigatorBaseItemFactory}} to use the "diagram UUID" as the parent of all base nodes instead of their parent when I added the Decision Service node (as this addition meant a Node's parent was not always the diagram).
Do you think it best I find a different approach for getting a "root UUID" for base items in the Decision Navigator. I assume *any* string will do and I don't really need to lookup a UUID for the diagram or any node for that matter.
> [DMN Designer] Error after reopening
> ------------------------------------
>
> Key: DROOLS-3431
> URL: https://issues.jboss.org/browse/DROOLS-3431
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Affects Versions: 7.16.0.Final
> Reporter: Jozef Marko
> Assignee: Michael Anstis
> Priority: Critical
> Labels: drools-tools
> Attachments: Screenshot from 2018-12-13 08-09-38.png, reopen.error.log
>
>
> There appears an unexpected error dialog when user reopen stored dmn diagram. Secodn reopening works fine. See the steps to reproduce and attached error.
> This was spotted during [DROOL-3286 PR Review|https://github.com/kiegroup/kie-wb-common/pull/2344] however not sure if it is related.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 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 edited comment on DROOLS-3412 at 12/13/18 8:03 AM:
-----------------------------------------------------------------------
Hi, sure that's fine for me :). Thanks! I should also be able to run a larger scale test next week in case the fix is available by then.
was (Author: christianl):
Hi, sure that's fine for me :). Thanks!
> 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, 7 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 commented on DROOLS-3412:
---------------------------------------------
Hi, sure that's fine for me :). Thanks!
> 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, 7 months
[JBoss JIRA] (DROOLS-3412) Performance degradation with session pools
by Tibor Zimányi (Jira)
[ https://issues.jboss.org/browse/DROOLS-3412?page=com.atlassian.jira.plugi... ]
Tibor Zimányi commented on DROOLS-3412:
---------------------------------------
[~christianl] Hi, I checked your PR in kie-benchmarks and found that the listeners are not cleared when a KieSession is reset. I created a PR with a fix here [1]. If the fix is ok and gets merged, I will let you know, so you can retest.
[1] https://github.com/kiegroup/drools/pull/2195
> 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, 7 months
[JBoss JIRA] (WFLY-6609) STOMP netty connector failing when a messaging cluster node drops out.
by Miroslav Novak (Jira)
[ https://issues.jboss.org/browse/WFLY-6609?page=com.atlassian.jira.plugin.... ]
Miroslav Novak resolved WFLY-6609.
----------------------------------
Fix Version/s: 12.0.0.Final
Resolution: Done
Based on reading the description this was solved long time ago. At least since Wildfly12.
> STOMP netty connector failing when a messaging cluster node drops out.
> ----------------------------------------------------------------------
>
> Key: WFLY-6609
> URL: https://issues.jboss.org/browse/WFLY-6609
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 10.0.0.Final
> Reporter: Chris Orser
> Assignee: Jeff Mesnil
> Priority: Major
> Fix For: 12.0.0.Final
>
>
> If a client uses STOMP to publish or subscribe to the messaging server the client will cease to function when a messaging server node drops out of the cluster. They will only work again once the cluster has been fully terminated and at least one instance is brought back online.
> The error I received when sending messages:
> "AMQ339001: Destination does not exist: <queue_name>"
> lead me to a bug report ARTEMIS-358
> I built an Artemis 1.3 snapshot and the problem has been solved. I don't know if that particular bug was the cause but they have addressed the issue in an upcoming version of Artemis.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (WFLY-6609) STOMP netty connector failing when a messaging cluster node drops out.
by Miroslav Novak (Jira)
[ https://issues.jboss.org/browse/WFLY-6609?page=com.atlassian.jira.plugin.... ]
Miroslav Novak closed WFLY-6609.
--------------------------------
> STOMP netty connector failing when a messaging cluster node drops out.
> ----------------------------------------------------------------------
>
> Key: WFLY-6609
> URL: https://issues.jboss.org/browse/WFLY-6609
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 10.0.0.Final
> Reporter: Chris Orser
> Assignee: Jeff Mesnil
> Priority: Major
> Fix For: 12.0.0.Final
>
>
> If a client uses STOMP to publish or subscribe to the messaging server the client will cease to function when a messaging server node drops out of the cluster. They will only work again once the cluster has been fully terminated and at least one instance is brought back online.
> The error I received when sending messages:
> "AMQ339001: Destination does not exist: <queue_name>"
> lead me to a bug report ARTEMIS-358
> I built an Artemis 1.3 snapshot and the problem has been solved. I don't know if that particular bug was the cause but they have addressed the issue in an upcoming version of Artemis.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months