[JBoss JIRA] (DROOLS-3566) DMN:Detailed interactions for creating and managing DRDs
by Guilherme Gomes (Jira)
[ https://issues.jboss.org/browse/DROOLS-3566?page=com.atlassian.jira.plugi... ]
Guilherme Gomes commented on DROOLS-3566:
-----------------------------------------
OK, [~uxdlc] Thanks :-)
> DMN:Detailed interactions for creating and managing DRDs
> --------------------------------------------------------
>
> Key: DROOLS-3566
> URL: https://issues.jboss.org/browse/DROOLS-3566
> Project: Drools
> Issue Type: Task
> Components: DMN Editor
> Reporter: Elizabeth Clayton
> Assignee: Elizabeth Clayton
> Priority: Major
> Labels: UX, UXTeam, drools-tools
> Attachments: contextual-menu.png
>
>
> Canvas node actions related to grouping and assigning to DRDs.
> * As a user I want to easily select and group nodes on the canvas so that I can add them to a DRD or to create a new DRD.
> (TBD) As a user I want to be able to be able to use the Navigator tree to create DRD's and assign canvas nodes, so that I can easily modify my graph views.
> Notes:
> Navigator Tree actions TBD:
> * Drag nodes to DRDs.
> * Contextual menu for tree objects?
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (JGRP-2391) BindException on Windows
by Otmar Humbel (Jira)
[ https://issues.jboss.org/browse/JGRP-2391?page=com.atlassian.jira.plugin.... ]
Otmar Humbel commented on JGRP-2391:
------------------------------------
I was bitten by that error too, and can confirm that it is fixed with 4.1.7.Final.
Thanks a lot!
> BindException on Windows
> ------------------------
>
> Key: JGRP-2391
> URL: https://issues.jboss.org/browse/JGRP-2391
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.1.0, 4.1.1, 4.1.2, 4.1.3, 4.1.4, 4.1.5, 4.1.6
> Environment: Openjdk 13
> Microsoft Windows 10
> Reporter: Thorsten Marx
> Assignee: Bela Ban
> Priority: Major
> Fix For: 4.1.7
>
> Attachments: jgroups.patch
>
>
> After updating to jgroups 4.1.6 i get the following BindException
> {code}
> java.net.BindException: Cannot assign requested address: Cannot bind
> at java.base/java.net.TwoStacksPlainDatagramSocketImpl.bind0(Native Method)
> at java.base/java.net.TwoStacksPlainDatagramSocketImpl.bind0(TwoStacksPlainDatagramSocketImpl.java:114)
> at java.base/java.net.AbstractPlainDatagramSocketImpl.bind(AbstractPlainDatagramSocketImpl.java:117)
> at java.base/java.net.TwoStacksPlainDatagramSocketImpl.bind(TwoStacksPlainDatagramSocketImpl.java:98)
> at java.base/java.net.DatagramSocket.bind(DatagramSocket.java:395)
> at java.base/java.net.MulticastSocket.<init>(MulticastSocket.java:176)
> at org.jgroups.util.DefaultSocketFactory.createMulticastSocket(DefaultSocketFactory.java:92)
> at org.jgroups.stack.DiagnosticsHandler.startUDP(DiagnosticsHandler.java:180)
> at org.jgroups.stack.DiagnosticsHandler.start(DiagnosticsHandler.java:122)
> at org.jgroups.protocols.TP.startDiagnostics(TP.java:1031)
> at org.jgroups.protocols.TP.start(TP.java:938)
> at org.jgroups.protocols.UDP.start(UDP.java:295)
> at org.jgroups.stack.ProtocolStack.startStack(ProtocolStack.java:888)
> at org.jgroups.JChannel.startStack(JChannel.java:980)
> at org.jgroups.JChannel._preConnect(JChannel.java:844)
> at org.jgroups.JChannel.connect(JChannel.java:349)
> at org.jgroups.JChannel.connect(JChannel.java:343)
> at com.thorstenmarx.webtools.cluster.JGroupsTest.simple(JGroupsTest.java:43)
> {code}
> It seems to be caused by https://stackoverflow.com/questions/14086740/how-to-create-a-new-multicas...
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (WFLY-12486) Memory leak in OpenTracing when deployment is redeployed multiple times
by Emmanuel Hugonnet (Jira)
[ https://issues.jboss.org/browse/WFLY-12486?page=com.atlassian.jira.plugin... ]
Emmanuel Hugonnet reassigned WFLY-12486:
----------------------------------------
Assignee: Emmanuel Hugonnet (was: Jeff Mesnil)
> Memory leak in OpenTracing when deployment is redeployed multiple times
> -----------------------------------------------------------------------
>
> Key: WFLY-12486
> URL: https://issues.jboss.org/browse/WFLY-12486
> Project: WildFly
> Issue Type: Bug
> Components: MP OpenTracing
> Affects Versions: 17.0.0.Final, 17.0.1.Final
> Reporter: Jan Stourac
> Assignee: Emmanuel Hugonnet
> Priority: Critical
> Attachments: memory-leak-bad.png, memory-leak-good.png
>
>
> There seems to be a memory leak when a deployment is redeployed multiple times (100 times in our test). This is very similar to what has been described in WFLY-10991. Also first commit this started to happen is [this one|https://github.com/wildfly/wildfly/commit/74170b5f49dd83f6b9ebd489f85...] - JaegerTracing and Apache Thrift dependencies update. Thus I selected MP OpenTracing component for this issue.
> Test and deployment is same as is described in WFLY-10991.
> Size of the extra heap in use is about 27MB plus when compared to the initial size before multiple redeploy operations.
> I've tried to check manually via [visualVM|https://visualvm.github.io/] tool. Screenshot with suspicious jaegertracing instances are attached - there are much more jaegertracing class instances with new version of Jager Tracing and Apache Thrift dependencies, which is suspicious.
> Interesting thing is that when microprofile-opentracing-smallrye subsystem is removed via:
> {code}
> /subsystem=microprofile-opentracing-smallrye:remove()
> {code}
> the memory leak is still present. This is kind of confusing to me.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (WFLY-12718) Clustering: replicated-cache sampling errors
by Tommasso Borgato (Jira)
[ https://issues.jboss.org/browse/WFLY-12718?page=com.atlassian.jira.plugin... ]
Tommasso Borgato commented on WFLY-12718:
-----------------------------------------
both issues show a change in behavior from WildFly-17 and WildFly-18
> Clustering: replicated-cache sampling errors
> --------------------------------------------
>
> Key: WFLY-12718
> URL: https://issues.jboss.org/browse/WFLY-12718
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 18.0.0.Final
> Reporter: Tommasso Borgato
> Assignee: Paul Ferraro
> Priority: Blocker
>
> The issue is about replicated-cache in fail-over tests.
> WildFly is started in clustered mode using a replicated cache for replicating HTTP session data across cluster nodes; all 4 nodes in the cluster are initialized with the following cli script:
> {noformat}
> embed-server --server-config=standalone-ha.xml
> /subsystem=jgroups/channel=ee:write-attribute(name=stack,value=tcp)
> /subsystem=infinispan/cache-container=web/replicated-cache=testRepl:add()
> /subsystem=infinispan/cache-container=web/replicated-cache=testRepl/component=locking:write-attribute(name=isolation, value=REPEATABLE_READ)
> /subsystem=infinispan/cache-container=web/replicated-cache=testRepl/component=transaction:write-attribute(name=mode, value=BATCH)
> /subsystem=infinispan/cache-container=web/replicated-cache=testRepl/store=file:add()
> /subsystem=infinispan/cache-container=web:write-attribute(name=default-cache, value=testRepl)
> {noformat}
> The test is run with wildfly-18.0.0.Final.zip;
> The same tests run with version wildfly-17.0.1.Final.zip do not have any problem;
> hence this looks like a regression;
> As usual, we test that the serial value stored in the scattered cache is incremented at every call: when this is not true, we say we have a sampling error;
> Here are the runs that exhibit this issue:
> - **22.82% Fail Rate with WildFly-18 ** [eap-7.x-clustering-http-session-shutdown-repl#23|https://eap-qe-jenkins.r...]
> - **0% Fail Rate with WildFly-17 ** [eap-7.x-clustering-http-session-shutdown-repl#24|https://eap-qe-jenkins.r...]
> We also repeated the tests to make sure it can be reproduced:
> - **22.75% Fail rate with WildFly-18 ** [eap-7.x-clustering-http-session-shutdown-repl#26|https://eap-qe-jenkins.r...]
> - **0% Fail Rate with WildFly-17 ** [eap-7.x-clustering-http-session-shutdown-repl#25|https://eap-qe-jenkins.r...]
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (WFLY-12718) Clustering: replicated-cache sampling errors
by Tommasso Borgato (Jira)
[ https://issues.jboss.org/browse/WFLY-12718?page=com.atlassian.jira.plugin... ]
Tommasso Borgato updated WFLY-12718:
------------------------------------
Affects Testing: Regression
> Clustering: replicated-cache sampling errors
> --------------------------------------------
>
> Key: WFLY-12718
> URL: https://issues.jboss.org/browse/WFLY-12718
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 18.0.0.Final
> Reporter: Tommasso Borgato
> Assignee: Paul Ferraro
> Priority: Blocker
>
> The issue is about replicated-cache in fail-over tests.
> WildFly is started in clustered mode using a replicated cache for replicating HTTP session data across cluster nodes; all 4 nodes in the cluster are initialized with the following cli script:
> {noformat}
> embed-server --server-config=standalone-ha.xml
> /subsystem=jgroups/channel=ee:write-attribute(name=stack,value=tcp)
> /subsystem=infinispan/cache-container=web/replicated-cache=testRepl:add()
> /subsystem=infinispan/cache-container=web/replicated-cache=testRepl/component=locking:write-attribute(name=isolation, value=REPEATABLE_READ)
> /subsystem=infinispan/cache-container=web/replicated-cache=testRepl/component=transaction:write-attribute(name=mode, value=BATCH)
> /subsystem=infinispan/cache-container=web/replicated-cache=testRepl/store=file:add()
> /subsystem=infinispan/cache-container=web:write-attribute(name=default-cache, value=testRepl)
> {noformat}
> The test is run with wildfly-18.0.0.Final.zip;
> The same tests run with version wildfly-17.0.1.Final.zip do not have any problem;
> hence this looks like a regression;
> As usual, we test that the serial value stored in the scattered cache is incremented at every call: when this is not true, we say we have a sampling error;
> Here are the runs that exhibit this issue:
> - **22.82% Fail Rate with WildFly-18 ** [eap-7.x-clustering-http-session-shutdown-repl#23|https://eap-qe-jenkins.r...]
> - **0% Fail Rate with WildFly-17 ** [eap-7.x-clustering-http-session-shutdown-repl#24|https://eap-qe-jenkins.r...]
> We also repeated the tests to make sure it can be reproduced:
> - **22.75% Fail rate with WildFly-18 ** [eap-7.x-clustering-http-session-shutdown-repl#26|https://eap-qe-jenkins.r...]
> - **0% Fail Rate with WildFly-17 ** [eap-7.x-clustering-http-session-shutdown-repl#25|https://eap-qe-jenkins.r...]
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (WFLY-12718) Clustering: replicated-cache sampling errors
by Tommasso Borgato (Jira)
[ https://issues.jboss.org/browse/WFLY-12718?page=com.atlassian.jira.plugin... ]
Tommasso Borgato updated WFLY-12718:
------------------------------------
Description:
The issue is about replicated-cache in fail-over tests.
WildFly is started in clustered mode using a replicated cache for replicating HTTP session data across cluster nodes; all 4 nodes in the cluster are initialized with the following cli script:
{noformat}
embed-server --server-config=standalone-ha.xml
/subsystem=jgroups/channel=ee:write-attribute(name=stack,value=tcp)
/subsystem=infinispan/cache-container=web/replicated-cache=testRepl:add()
/subsystem=infinispan/cache-container=web/replicated-cache=testRepl/component=locking:write-attribute(name=isolation, value=REPEATABLE_READ)
/subsystem=infinispan/cache-container=web/replicated-cache=testRepl/component=transaction:write-attribute(name=mode, value=BATCH)
/subsystem=infinispan/cache-container=web/replicated-cache=testRepl/store=file:add()
/subsystem=infinispan/cache-container=web:write-attribute(name=default-cache, value=testRepl)
{noformat}
The test is run with wildfly-18.0.0.Final.zip;
The same tests run with version wildfly-17.0.1.Final.zip do not have any problem;
hence this looks like a regression;
As usual, we test that the serial value stored in the scattered cache is incremented at every call: when this is not true, we say we have a sampling error;
Here are the runs that exhibit this issue:
- **22.82% Fail Rate with WildFly-18 ** [eap-7.x-clustering-http-session-shutdown-repl#23|https://eap-qe-jenkins.r...]
- **0% Fail Rate with WildFly-17 ** [eap-7.x-clustering-http-session-shutdown-repl#24|https://eap-qe-jenkins.r...]
We also repeated the tests to make sure it can be reproduced:
- **22.75% Fail rate with WildFly-18 ** [eap-7.x-clustering-http-session-shutdown-repl#26|https://eap-qe-jenkins.r...]
- **0% Fail Rate with WildFly-17 ** [eap-7.x-clustering-http-session-shutdown-repl#25|https://eap-qe-jenkins.r...]
was:
The issue is about replicated-cache in fail-over tests.
WildFly is started in clustered mode using a replicated cache for replicating HTTP session data across cluster nodes; all 4 nodes in the cluster are initialized with the following cli script:
{noformat}
embed-server --server-config=standalone-ha.xml
/subsystem=jgroups/channel=ee:write-attribute(name=stack,value=tcp)
/subsystem=infinispan/cache-container=web/replicated-cache=testRepl:add()
/subsystem=infinispan/cache-container=web/replicated-cache=testRepl/component=locking:write-attribute(name=isolation, value=REPEATABLE_READ)
/subsystem=infinispan/cache-container=web/replicated-cache=testRepl/component=transaction:write-attribute(name=mode, value=BATCH)
/subsystem=infinispan/cache-container=web/replicated-cache=testRepl/store=file:add()
/subsystem=infinispan/cache-container=web:write-attribute(name=default-cache, value=testRepl)
{noformat}
The test is run with wildfly-18.0.0.Final.zip;
The same tests run with version wildfly-17.0.1.Final.zip do not have any problem;
hence this looks like a regression;
As usual, we test that the serial value stored in the scattered cache is incremented at every call: when this is not true, we say we have a sampling error;
Here are the runs that exhibit this issue:
- **22.82% Fail Rate** [eap-7.x-clustering-http-session-shutdown-repl#23|https://eap-qe-jenkins.r...]
- **0% Fail Rate** [eap-7.x-clustering-http-session-shutdown-repl#24|https://eap-qe-jenkins.r...]
> Clustering: replicated-cache sampling errors
> --------------------------------------------
>
> Key: WFLY-12718
> URL: https://issues.jboss.org/browse/WFLY-12718
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 18.0.0.Final
> Reporter: Tommasso Borgato
> Assignee: Paul Ferraro
> Priority: Blocker
>
> The issue is about replicated-cache in fail-over tests.
> WildFly is started in clustered mode using a replicated cache for replicating HTTP session data across cluster nodes; all 4 nodes in the cluster are initialized with the following cli script:
> {noformat}
> embed-server --server-config=standalone-ha.xml
> /subsystem=jgroups/channel=ee:write-attribute(name=stack,value=tcp)
> /subsystem=infinispan/cache-container=web/replicated-cache=testRepl:add()
> /subsystem=infinispan/cache-container=web/replicated-cache=testRepl/component=locking:write-attribute(name=isolation, value=REPEATABLE_READ)
> /subsystem=infinispan/cache-container=web/replicated-cache=testRepl/component=transaction:write-attribute(name=mode, value=BATCH)
> /subsystem=infinispan/cache-container=web/replicated-cache=testRepl/store=file:add()
> /subsystem=infinispan/cache-container=web:write-attribute(name=default-cache, value=testRepl)
> {noformat}
> The test is run with wildfly-18.0.0.Final.zip;
> The same tests run with version wildfly-17.0.1.Final.zip do not have any problem;
> hence this looks like a regression;
> As usual, we test that the serial value stored in the scattered cache is incremented at every call: when this is not true, we say we have a sampling error;
> Here are the runs that exhibit this issue:
> - **22.82% Fail Rate with WildFly-18 ** [eap-7.x-clustering-http-session-shutdown-repl#23|https://eap-qe-jenkins.r...]
> - **0% Fail Rate with WildFly-17 ** [eap-7.x-clustering-http-session-shutdown-repl#24|https://eap-qe-jenkins.r...]
> We also repeated the tests to make sure it can be reproduced:
> - **22.75% Fail rate with WildFly-18 ** [eap-7.x-clustering-http-session-shutdown-repl#26|https://eap-qe-jenkins.r...]
> - **0% Fail Rate with WildFly-17 ** [eap-7.x-clustering-http-session-shutdown-repl#25|https://eap-qe-jenkins.r...]
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years