[JBoss JIRA] (JGRP-2406) MERGE3 not working with TCP using ForkJoinPool
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-2406?page=com.atlassian.jira.plugin... ]
Bela Ban resolved JGRP-2406.
----------------------------
Resolution: Done
Closing this for now, feel free to re-open for further review.
> MERGE3 not working with TCP using ForkJoinPool
> ----------------------------------------------
>
> Key: JGRP-2406
> URL: https://issues.redhat.com/browse/JGRP-2406
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.1.8
> Reporter: Olivier Peyrusse
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 4.2.1
>
> Attachments: logs.tgz, project.zip, timeline.txt
>
>
> With JDK11, using the TCP protocol with the ForkJoinPool is causing constant failures of MERGE3.
> I consistently observed the following, from the point of view of a member M
> - M asks for other coordinator views. It contacts A and B
> - A and B send their views
> - M waits and timeouts for receiving views and abort the merge
> - immediately after aborting the merge, M process messages containing the views of A and B.
> In [^timeline.txt], you will see the extracts for logs from the various members at play.
> After many experiments, the one parameter causing this issue is in the TCP protocol.
> {code:xml}
> <TCP
> ...
> thread_pool.use_fork_join_pool="true" />
> {code}
> Setting {{thread_pool.use_fork_join_pool}} to true repeatedly produces the problem, while using {{thread_pool.use_fork_join_pool}} with false works fine.
> Project details:
> - as tested within Kubernetes, this project uses KUBE_PING as its discovery protocol
> - to understand the reason for the failed merges, I created the protocol MERGE4, that is MERGE3 with additional logs.
> - [^logs.tgz] contains all logs from the various members involved in the test.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (JGRP-2406) MERGE3 not working with TCP using ForkJoinPool
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-2406?page=com.atlassian.jira.plugin... ]
Bela Ban commented on JGRP-2406:
--------------------------------
[~opeyrusse] OK, I think I know what happened, looking at {{timeline.txt}}.
The FJP has N worker threads, by default the number of cores available. While I'm not very familiar with the FJP, I read that it is a bad idea to submit tasks which can block (e.g. on I/O).
So when the 3 members get a {{VIEW_REQ}}, they send back a {{VIEW_RSP}}. However, that message is not received at all, only *after* the merge request times out. This is an indication that the FJP was exhausted and only processed the {{VIEW_RSP}} messages _after_ the timeout.
With real pools (regular or internal), the rejected messages are either dropped or processed by the internal thread pool or (in the worst case) by spawning a new thread, but they don't block until a worked is available.
So, in a nutshell, I don't recommend use of the FJP. Is there a reason you enabled it?
Note that you can inject your own thread pool into the transport, e.g. in cases where JGroups should use the application's thread pool.
> MERGE3 not working with TCP using ForkJoinPool
> ----------------------------------------------
>
> Key: JGRP-2406
> URL: https://issues.redhat.com/browse/JGRP-2406
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.1.8
> Reporter: Olivier Peyrusse
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 4.2.1
>
> Attachments: logs.tgz, project.zip, timeline.txt
>
>
> With JDK11, using the TCP protocol with the ForkJoinPool is causing constant failures of MERGE3.
> I consistently observed the following, from the point of view of a member M
> - M asks for other coordinator views. It contacts A and B
> - A and B send their views
> - M waits and timeouts for receiving views and abort the merge
> - immediately after aborting the merge, M process messages containing the views of A and B.
> In [^timeline.txt], you will see the extracts for logs from the various members at play.
> After many experiments, the one parameter causing this issue is in the TCP protocol.
> {code:xml}
> <TCP
> ...
> thread_pool.use_fork_join_pool="true" />
> {code}
> Setting {{thread_pool.use_fork_join_pool}} to true repeatedly produces the problem, while using {{thread_pool.use_fork_join_pool}} with false works fine.
> Project details:
> - as tested within Kubernetes, this project uses KUBE_PING as its discovery protocol
> - to understand the reason for the failed merges, I created the protocol MERGE4, that is MERGE3 with additional logs.
> - [^logs.tgz] contains all logs from the various members involved in the test.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (WFLY-13132) Wrong/Incomplete CLUSTER_TOPOLOGY update sent to EJB client
by Richard Achmatowicz (Jira)
[ https://issues.redhat.com/browse/WFLY-13132?page=com.atlassian.jira.plugi... ]
Richard Achmatowicz commented on WFLY-13132:
--------------------------------------------
[~dmlloyd] I had a second look at this today and I believe this is what is going on:
* the <connector/> element in the Remoting subsystem sets up a stream server for the "remote" protocol on the remoting socket; it also creates a RemotingConnectorBindingInfoService to represent the socket used and its protocol
* the <http-connector> element in the Remoting subsystem sets up the Undertow upgrade mechanism (which includes adding metadata to the undertow listener on the http socket, setting up a Remoting ExternalConnectionProvider which is registered as part of an OpenListener which is used to upgrade the channel from http/https to http+remoting and much other stuff) ; it also creates a RemotingConnectorBindingInfoService to represent the socket used and its protocol
* the <remote/> element in the EJB3 subsystem takes these RemotingConnectorBindingInfoService references and use them only to set up the client mappings entry provider service, which is used to populate the c;lient mappings entries on the server; they don't seem to be used at all in setting up the EJBRemoteConnectorService which installs the OpenListener for "jboss.ejb" service connections
So, I think the answer to my first question is "yes" and the answer to the second question is "we only use those connector references to initialise the client mappings service, so when using both "remote" and "remote+http", we need to pass both RemotingConnectorBindingInfoService references in and use them to init the client mappings. I'll find out once its implemented.
> Wrong/Incomplete CLUSTER_TOPOLOGY update sent to EJB client
> -----------------------------------------------------------
>
> Key: WFLY-13132
> URL: https://issues.redhat.com/browse/WFLY-13132
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 19.0.0.Beta2
> Reporter: Joerg Baesner
> Assignee: Richard Achmatowicz
> Priority: Major
> Attachments: playground.zip
>
>
> h2. +Issue+
> h3. +General Client setup:+
> {code:java}
> Properties p = new Properties();
> p.put(Context.INITIAL_CONTEXT_FACTORY, "org.wildfly.naming.client.WildFlyInitialContextFactory");
> p.put(Context.PROVIDER_URL, {see below});
> p.put(Context.SECURITY_PRINCIPAL, USER);
> p.put(Context.SECURITY_CREDENTIALS, PWD);
> Context context = new InitialContext(p);
> {code}
> ----
> h3. +Standard server configuration:+
> {code:xml}
> <subsystem xmlns="urn:jboss:domain:ejb3:5.0">
> ...
> <remote connector-ref="http-remoting-connector" thread-pool-name="default">
> <channel-creation-options>
> <option name="READ_TIMEOUT" value="${prop.remoting-connector.read.timeout:20}" type="xnio"/>
> <option name="MAX_OUTBOUND_MESSAGES" value="1234" type="remoting"/>
> </channel-creation-options>
> </remote>
> ...
> </subsystem>
> ...
> <subsystem xmlns="urn:jboss:domain:remoting:4.0">
> <connector name="remoting-connector" socket-binding="remoting" security-realm="ApplicationRealm">
> <properties>
> <property name="SSL_ENABLED" value="false"/>
> </properties>
> </connector>
> <http-connector name="http-remoting-connector" connector-ref="default" security-realm="ApplicationRealm"/>
> </subsystem>
> {code}
> h5. +invocation from remote client to server with:+
> * {{remote://localhost:4447}}
> * {{remote+http://localhost:8080}}
> h5. +Client side topology update always:+
> {noformat}
> DEBUG (XNIO-1 task-2) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY(15) message from node master:app-cluster-node0, registering cluster ejb to node master:app-cluster-node0
> DEBUG (XNIO-1 task-2) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY(15) message block from master:app-cluster-node0, registering block ::/0 to address 127.0.0.1:8080
> DEBUG (XNIO-1 task-2) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY(15) message from node master:app-cluster-node0, registering cluster ejb to node master:app-cluster-node1
> DEBUG (XNIO-1 task-2) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY(15) message block from master:app-cluster-node0, registering block ::/0 to address 127.0.0.1:8180
> DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received MODULE_AVAILABLE(8) message from node master:app-cluster-node0 for module playground-app/playground-app-web
> DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received MODULE_AVAILABLE(8) message from node master:app-cluster-node0 for module playground-app/playground-app-ejb
> {noformat}
> ----
> h3. +Legacy server configuration:+
> {code:xml}
> <subsystem xmlns="urn:jboss:domain:ejb3:5.0">
> ...
> <remote connector-ref="remoting-connector" thread-pool-name="default">
> <channel-creation-options>
> <option name="READ_TIMEOUT" value="${prop.remoting-connector.read.timeout:20}" type="xnio"/>
> <option name="MAX_OUTBOUND_MESSAGES" value="1234" type="remoting"/>
> </channel-creation-options>
> </remote>
> ...
> </subsystem>
> ...
> <subsystem xmlns="urn:jboss:domain:remoting:4.0">
> <connector name="remoting-connector" socket-binding="remoting" security-realm="ApplicationRealm">
> <properties>
> <property name="SSL_ENABLED" value="false"/>
> </properties>
> </connector>
> <http-connector name="http-remoting-connector" connector-ref="default" security-realm="ApplicationRealm"/>
> </subsystem>
> {code}
> h5. +invocation from remote client to server with:+
> * {{remote://localhost:4447}}
> * {{remote+http://localhost:8080}}
> h5. +Client side topology update always:+
> {noformat}
> DEBUG (XNIO-1 task-2) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY(15) message from node master:app-cluster-node0, registering cluster ejb to node master:app-cluster-node0
> DEBUG (XNIO-1 task-2) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY(15) message block from master:app-cluster-node0, registering block ::/0 to address 127.0.0.1:4447
> DEBUG (XNIO-1 task-2) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY(15) message from node master:app-cluster-node0, registering cluster ejb to node master:app-cluster-node1
> DEBUG (XNIO-1 task-2) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY(15) message block from master:app-cluster-node0, registering block ::/0 to address 127.0.0.1:4547
> DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received MODULE_AVAILABLE(8) message from node master:app-cluster-node0 for module playground-app/playground-app-web
> DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received MODULE_AVAILABLE(8) message from node master:app-cluster-node0 for module playground-app/playground-app-ejb
> {noformat}
> h2. +Conclusion+
> Depending on what is configured as {{connector-ref}} in the {{remote}} of the _ejb3_ subsystem the {{CLUSTER_TOPOLOGY}} update is different. From a client perspective it would be expected that either the {{CLUSTER_TOPOLOGY}} update would _only_ contain destinations that are applicable for the _connector/protocol_ that has been used, or maybe even _ALL_ available destinations, as the client could potentially run a mix of protocols between invocations...
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (DROOLS-5139) [DMN Designer] Decision Navigator does not update Diagram name
by Michael Anstis (Jira)
[ https://issues.redhat.com/browse/DROOLS-5139?page=com.atlassian.jira.plug... ]
Michael Anstis reassigned DROOLS-5139:
--------------------------------------
Assignee: Guilherme Gomes (was: Michael Anstis)
> [DMN Designer] Decision Navigator does not update Diagram name
> --------------------------------------------------------------
>
> Key: DROOLS-5139
> URL: https://issues.redhat.com/browse/DROOLS-5139
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Affects Versions: 7.34.0.Final
> Reporter: Michael Anstis
> Assignee: Guilherme Gomes
> Priority: Major
> Labels: drools-tools
>
> Following changes for https://issues.redhat.com/browse/DROOLS-5137 it became evident that the Decision Navigator does not show updated Diagram names.
> This pre-exists DROOLS-5137 and DROOLS-5060 (i.e. it is not a regression), so this new JIRA has been created.
> * Create a new DMN Diagram
> * Expand Decision Navigator
> * Expand Properties Panel
> * Select _background_ i.e. _diagram_
> * Change name in Properties Panel
> * Decision Navigator does not update
> * Saving, closing and re-opening diagram shows updated name
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (DROOLS-5139) [DMN Designer] Decision Navigator does not update Diagram name
by Michael Anstis (Jira)
[ https://issues.redhat.com/browse/DROOLS-5139?page=com.atlassian.jira.plug... ]
Michael Anstis updated DROOLS-5139:
-----------------------------------
Description:
Following changes for https://issues.redhat.com/browse/DROOLS-5137 it became evident that the Decision Navigator does not show updated Diagram names.
This pre-exists DROOLS-5137 and DROOLS-5060 (i.e. it is not a regression), so this new JIRA has been created.
* Create a new DMN Diagram
* Expand Decision Navigator
* Expand Properties Panel
* Select _background_ i.e. _diagram_
* Change name in Properties Panel
* Decision Navigator does not update
* Saving, closing and re-opening diagram shows updated name
was:Following changes for https://issues.redhat.com/browse/DROOLS-5060 use of a simple property for {{Name}} changed to use {{NameHolder}} and {{Name}}. Most uses were corrected however the Decision Navigator continues to use Stunner's {{DefinitionAdapter.getTitle(..)}} that looks up the property annotated with {{@Property(meta = PropertyMetaTypes.NAME)}} and returns its {{String}} value.
> [DMN Designer] Decision Navigator does not update Diagram name
> --------------------------------------------------------------
>
> Key: DROOLS-5139
> URL: https://issues.redhat.com/browse/DROOLS-5139
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Affects Versions: 7.34.0.Final
> Reporter: Michael Anstis
> Assignee: Michael Anstis
> Priority: Major
> Labels: drools-tools
>
> Following changes for https://issues.redhat.com/browse/DROOLS-5137 it became evident that the Decision Navigator does not show updated Diagram names.
> This pre-exists DROOLS-5137 and DROOLS-5060 (i.e. it is not a regression), so this new JIRA has been created.
> * Create a new DMN Diagram
> * Expand Decision Navigator
> * Expand Properties Panel
> * Select _background_ i.e. _diagram_
> * Change name in Properties Panel
> * Decision Navigator does not update
> * Saving, closing and re-opening diagram shows updated name
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (DROOLS-5139) [DMN Designer] Decision Navigator does not update Diagram name
by Michael Anstis (Jira)
Michael Anstis created DROOLS-5139:
--------------------------------------
Summary: [DMN Designer] Decision Navigator does not update Diagram name
Key: DROOLS-5139
URL: https://issues.redhat.com/browse/DROOLS-5139
Project: Drools
Issue Type: Bug
Components: DMN Editor
Affects Versions: 7.34.0.Final
Reporter: Michael Anstis
Assignee: Michael Anstis
Following changes for https://issues.redhat.com/browse/DROOLS-5060 use of a simple property for {{Name}} changed to use {{NameHolder}} and {{Name}}. Most uses were corrected however the Decision Navigator continues to use Stunner's {{DefinitionAdapter.getTitle(..)}} that looks up the property annotated with {{@Property(meta = PropertyMetaTypes.NAME)}} and returns its {{String}} value.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months