[JBoss JIRA] (WFCORE-4875) Provide common capability for Remoting connectors
by Richard Achmatowicz (Jira)
[ https://issues.redhat.com/browse/WFCORE-4875?page=com.atlassian.jira.plug... ]
Richard Achmatowicz reassigned WFCORE-4875:
-------------------------------------------
Assignee: Richard Achmatowicz (was: Flavia Rainone)
> Provide common capability for Remoting connectors
> -------------------------------------------------
>
> Key: WFCORE-4875
> URL: https://issues.redhat.com/browse/WFCORE-4875
> Project: WildFly Core
> Issue Type: Bug
> Components: Remoting
> Affects Versions: 11.0.0.Final
> Reporter: Richard Achmatowicz
> Assignee: Richard Achmatowicz
> Priority: Major
> Fix For: 11.0.1.Final
>
>
> The EJB3 subsystem has an element <remote/> which performs a few different functions relating to external clients accessing EJBs on the server:
> * sets up a Remoting connector service so that external clients may connect to the server using EJB / Remoting or EJB / HTTP Upgrade / Remoting
> * sets up client mappings entries for those remote clients which are used in topology updates to allow the client to find the server's connectors
> The Remoting subsystem has two connector types which may be supplied to the <remote connector-ref/> attribute. <connector name="remoting-connector"/> represents a Remoting endpoint and <http-connector name="http-connector"/> represents an Undertow listener which may be used with HTTP Upgrade.
> At present, in the Remoting subsystem, these connectors have two separately defined capabilities:
> // for <connector/>
> private static final String CONNECTOR_CAPABILITY_NAME ="org.wildfly.remoting.connector";
> static final RuntimeCapability<Void> CONNECTOR_CAPABILITY = RuntimeCapability.Builder.of(CONNECTOR_CAPABILITY_NAME, true).build();
> // for <http-connector/>
> private static final String HTTP_CONNECTOR_CAPABILITY_NAME = "org.wildfly.remoting.http-connector";
> static final RuntimeCapability<Void> HTTP_CONNECTOR_CAPABILITY = RuntimeCapability.Builder.of(HTTP_CONNECTOR_CAPABILITY_NAME, true).build();
> The proposal here is to allow referencing both connectors using a single capability base name, "org.wildfly.remoting.connector" to simplify specification of the capabilities which the <remote/> element needs (i.e. it may depend on one or the other).
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (WFCORE-4875) Provide common capability for Remoting connectors
by Richard Achmatowicz (Jira)
Richard Achmatowicz created WFCORE-4875:
-------------------------------------------
Summary: Provide common capability for Remoting connectors
Key: WFCORE-4875
URL: https://issues.redhat.com/browse/WFCORE-4875
Project: WildFly Core
Issue Type: Bug
Components: Remoting
Affects Versions: 11.0.0.Final
Reporter: Richard Achmatowicz
Assignee: Flavia Rainone
Fix For: 11.0.1.Final
The EJB3 subsystem has an element <remote/> which performs a few different functions relating to external clients accessing EJBs on the server:
* sets up a Remoting connector service so that external clients may connect to the server using EJB / Remoting or EJB / HTTP Upgrade / Remoting
* sets up client mappings entries for those remote clients which are used in topology updates to allow the client to find the server's connectors
The Remoting subsystem has two connector types which may be supplied to the <remote connector-ref/> attribute. <connector name="remoting-connector"/> represents a Remoting endpoint and <http-connector name="http-connector"/> represents an Undertow listener which may be used with HTTP Upgrade.
At present, in the Remoting subsystem, these connectors have two separately defined capabilities:
// for <connector/>
private static final String CONNECTOR_CAPABILITY_NAME ="org.wildfly.remoting.connector";
static final RuntimeCapability<Void> CONNECTOR_CAPABILITY = RuntimeCapability.Builder.of(CONNECTOR_CAPABILITY_NAME, true).build();
// for <http-connector/>
private static final String HTTP_CONNECTOR_CAPABILITY_NAME = "org.wildfly.remoting.http-connector";
static final RuntimeCapability<Void> HTTP_CONNECTOR_CAPABILITY = RuntimeCapability.Builder.of(HTTP_CONNECTOR_CAPABILITY_NAME, true).build();
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (WFCORE-4875) Provide common capability for Remoting connectors
by Richard Achmatowicz (Jira)
[ https://issues.redhat.com/browse/WFCORE-4875?page=com.atlassian.jira.plug... ]
Richard Achmatowicz updated WFCORE-4875:
----------------------------------------
Description:
The EJB3 subsystem has an element <remote/> which performs a few different functions relating to external clients accessing EJBs on the server:
* sets up a Remoting connector service so that external clients may connect to the server using EJB / Remoting or EJB / HTTP Upgrade / Remoting
* sets up client mappings entries for those remote clients which are used in topology updates to allow the client to find the server's connectors
The Remoting subsystem has two connector types which may be supplied to the <remote connector-ref/> attribute. <connector name="remoting-connector"/> represents a Remoting endpoint and <http-connector name="http-connector"/> represents an Undertow listener which may be used with HTTP Upgrade.
At present, in the Remoting subsystem, these connectors have two separately defined capabilities:
// for <connector/>
private static final String CONNECTOR_CAPABILITY_NAME ="org.wildfly.remoting.connector";
static final RuntimeCapability<Void> CONNECTOR_CAPABILITY = RuntimeCapability.Builder.of(CONNECTOR_CAPABILITY_NAME, true).build();
// for <http-connector/>
private static final String HTTP_CONNECTOR_CAPABILITY_NAME = "org.wildfly.remoting.http-connector";
static final RuntimeCapability<Void> HTTP_CONNECTOR_CAPABILITY = RuntimeCapability.Builder.of(HTTP_CONNECTOR_CAPABILITY_NAME, true).build();
The proposal here is to allow referencing both connectors using a single capability base name, "org.wildfly.remoting.connector" to simplify specification of the capabilities which the <remote/> element needs (i.e. it may depend on one or the other).
was:
The EJB3 subsystem has an element <remote/> which performs a few different functions relating to external clients accessing EJBs on the server:
* sets up a Remoting connector service so that external clients may connect to the server using EJB / Remoting or EJB / HTTP Upgrade / Remoting
* sets up client mappings entries for those remote clients which are used in topology updates to allow the client to find the server's connectors
The Remoting subsystem has two connector types which may be supplied to the <remote connector-ref/> attribute. <connector name="remoting-connector"/> represents a Remoting endpoint and <http-connector name="http-connector"/> represents an Undertow listener which may be used with HTTP Upgrade.
At present, in the Remoting subsystem, these connectors have two separately defined capabilities:
// for <connector/>
private static final String CONNECTOR_CAPABILITY_NAME ="org.wildfly.remoting.connector";
static final RuntimeCapability<Void> CONNECTOR_CAPABILITY = RuntimeCapability.Builder.of(CONNECTOR_CAPABILITY_NAME, true).build();
// for <http-connector/>
private static final String HTTP_CONNECTOR_CAPABILITY_NAME = "org.wildfly.remoting.http-connector";
static final RuntimeCapability<Void> HTTP_CONNECTOR_CAPABILITY = RuntimeCapability.Builder.of(HTTP_CONNECTOR_CAPABILITY_NAME, true).build();
> Provide common capability for Remoting connectors
> -------------------------------------------------
>
> Key: WFCORE-4875
> URL: https://issues.redhat.com/browse/WFCORE-4875
> Project: WildFly Core
> Issue Type: Bug
> Components: Remoting
> Affects Versions: 11.0.0.Final
> Reporter: Richard Achmatowicz
> Assignee: Flavia Rainone
> Priority: Major
> Fix For: 11.0.1.Final
>
>
> The EJB3 subsystem has an element <remote/> which performs a few different functions relating to external clients accessing EJBs on the server:
> * sets up a Remoting connector service so that external clients may connect to the server using EJB / Remoting or EJB / HTTP Upgrade / Remoting
> * sets up client mappings entries for those remote clients which are used in topology updates to allow the client to find the server's connectors
> The Remoting subsystem has two connector types which may be supplied to the <remote connector-ref/> attribute. <connector name="remoting-connector"/> represents a Remoting endpoint and <http-connector name="http-connector"/> represents an Undertow listener which may be used with HTTP Upgrade.
> At present, in the Remoting subsystem, these connectors have two separately defined capabilities:
> // for <connector/>
> private static final String CONNECTOR_CAPABILITY_NAME ="org.wildfly.remoting.connector";
> static final RuntimeCapability<Void> CONNECTOR_CAPABILITY = RuntimeCapability.Builder.of(CONNECTOR_CAPABILITY_NAME, true).build();
> // for <http-connector/>
> private static final String HTTP_CONNECTOR_CAPABILITY_NAME = "org.wildfly.remoting.http-connector";
> static final RuntimeCapability<Void> HTTP_CONNECTOR_CAPABILITY = RuntimeCapability.Builder.of(HTTP_CONNECTOR_CAPABILITY_NAME, true).build();
> The proposal here is to allow referencing both connectors using a single capability base name, "org.wildfly.remoting.connector" to simplify specification of the capabilities which the <remote/> element needs (i.e. it may depend on one or the other).
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (JGRP-2461) Clustering can fail when re-adding an existing node using TCP_NIO2
by Robert Mitchell (Jira)
[ https://issues.redhat.com/browse/JGRP-2461?page=com.atlassian.jira.plugin... ]
Robert Mitchell commented on JGRP-2461:
---------------------------------------
We have chose the following workarounds to deal with this:
# Placing all of our possible nodes into the initial hosts for TCPPING and setting the max_dynamic_hosts value to 0. Note that this works for us because we manage the possible nodes for our cluster outside of JGroups.
# Reduce the {conn_close_timeout} timeout setting on UNICAST3 to 30 seconds. The default 4 minutes was just a little long in some edge cases (and especially when testing the clustering). This allows even very quick outages to be unlikely to see this issue (our node restart time is almost always over 30 seconds).
> Clustering can fail when re-adding an existing node using TCP_NIO2
> ------------------------------------------------------------------
>
> Key: JGRP-2461
> URL: https://issues.redhat.com/browse/JGRP-2461
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.1.8
> Reporter: Robert Mitchell
> Assignee: Bela Ban
> Priority: Major
>
> When a node leaves a cluster and then later attempts to re-enter, a race condition can occur where the clustering fails to occur. Here is the sequence of events that seems to allow this to occur:
> # The rejoining node must have a "higher" IP address than the current cluster coordinator.
> # On the rejoin attempt, the coordinator sends a message to the rejoining node before the rejoining node sends to the coordinator using its prior address. I have seen this happen for two reasons:
> ## UNICAST3 is resending messages (which often happens with the final LEAVE_RSP from the prior cluster membership because it apparently does not get acked before the connection closes)
> ## TCPPING is sending a ping request to the cached prior address.
> # The connection gets established. It will then be used by the rejoining node whenever communicating with the cluster coordinator.
> # However, the cluster coordinator has this as the connection for the prior address. So the following happens whenever it wants to send a message to the rejoining node:
> ## It will attempt to create a new connection.
> ## The rejoining node will reject the connection as a redundant connection with its current connection taking precedence since it is coming from the same logical address as the "bad" connection.
> Since the messages needed to find and join the cluster or merge the two clusters are all unicast messages, the rejoining node will never get them and not be able to join until something happens that causes the initial connection to get closed.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (JGRP-2461) Clustering can fail when re-adding an existing node using TCP_NIO2
by Robert Mitchell (Jira)
[ https://issues.redhat.com/browse/JGRP-2461?page=com.atlassian.jira.plugin... ]
Robert Mitchell edited comment on JGRP-2461 at 3/16/20 5:17 PM:
----------------------------------------------------------------
We have chosen the following workarounds to deal with this:
# Placing all of our possible nodes into the initial hosts for TCPPING and setting the max_dynamic_hosts value to 0. Note that this works for us because we manage the possible nodes for our cluster outside of JGroups.
# Reduce the {conn_close_timeout} timeout setting on UNICAST3 to 30 seconds. The default 4 minutes was just a little long in some edge cases (and especially when testing the clustering). This allows even very quick outages to be unlikely to see this issue (our node restart time is almost always over 30 seconds).
was (Author: bjetal2003):
We have chose the following workarounds to deal with this:
# Placing all of our possible nodes into the initial hosts for TCPPING and setting the max_dynamic_hosts value to 0. Note that this works for us because we manage the possible nodes for our cluster outside of JGroups.
# Reduce the {conn_close_timeout} timeout setting on UNICAST3 to 30 seconds. The default 4 minutes was just a little long in some edge cases (and especially when testing the clustering). This allows even very quick outages to be unlikely to see this issue (our node restart time is almost always over 30 seconds).
> Clustering can fail when re-adding an existing node using TCP_NIO2
> ------------------------------------------------------------------
>
> Key: JGRP-2461
> URL: https://issues.redhat.com/browse/JGRP-2461
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.1.8
> Reporter: Robert Mitchell
> Assignee: Bela Ban
> Priority: Major
>
> When a node leaves a cluster and then later attempts to re-enter, a race condition can occur where the clustering fails to occur. Here is the sequence of events that seems to allow this to occur:
> # The rejoining node must have a "higher" IP address than the current cluster coordinator.
> # On the rejoin attempt, the coordinator sends a message to the rejoining node before the rejoining node sends to the coordinator using its prior address. I have seen this happen for two reasons:
> ## UNICAST3 is resending messages (which often happens with the final LEAVE_RSP from the prior cluster membership because it apparently does not get acked before the connection closes)
> ## TCPPING is sending a ping request to the cached prior address.
> # The connection gets established. It will then be used by the rejoining node whenever communicating with the cluster coordinator.
> # However, the cluster coordinator has this as the connection for the prior address. So the following happens whenever it wants to send a message to the rejoining node:
> ## It will attempt to create a new connection.
> ## The rejoining node will reject the connection as a redundant connection with its current connection taking precedence since it is coming from the same logical address as the "bad" connection.
> Since the messages needed to find and join the cluster or merge the two clusters are all unicast messages, the rejoining node will never get them and not be able to join until something happens that causes the initial connection to get closed.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (DROOLS-5169) [DMN Editor] Datatype drag and drop, drops unintentionally
by Michael Anstis (Jira)
[ https://issues.redhat.com/browse/DROOLS-5169?page=com.atlassian.jira.plug... ]
Michael Anstis updated DROOLS-5169:
-----------------------------------
Steps to Reproduce:
# Go to *Data types* of *Dmn editor *on *Business central*
# Add root node with type *structure*
# Add nested nodes (2-3) with type *structure*
# Add another root note to drag to
# Click on four points button to start dragging the structure and do not release button
Expect: list is following by mouse pointer till user release the button
Unexpected: it release unexpectedly. See: [^selfReleasingList.webm]
was:
# Go to *Data types* of *Dmn editor *on *Business centrall*
# Add root node with type *structure*
# Add nested nodes (2-3) with type *structure*
# Add another root note to drag to
# Click on four points button to start dragging the structure and do not release button
Expect: list is following by mouse pointer till user release the button
Unexpected: it release unexpectedly. See: [^selfReleasingList.webm]
> [DMN Editor] Datatype drag and drop, drops unintentionally
> ------------------------------------------------------------
>
> Key: DROOLS-5169
> URL: https://issues.redhat.com/browse/DROOLS-5169
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Affects Versions: 7.35.0.Final
> Reporter: Anna Dupliak
> Assignee: Michael Anstis
> Priority: Major
> Labels: drools-tools
> Attachments: selfReleasingList.webm
>
>
> If user creates a nested fields and drag it to another field, then it drops unexpectedly even if user do not release the mouse button.
> Reproduced on FF 72.0.2 and Chrome Version 80.0.3987.87
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (JGRP-2461) Clustering can fail when re-adding an existing node using TCP_NIO2
by Robert Mitchell (Jira)
[ https://issues.redhat.com/browse/JGRP-2461?page=com.atlassian.jira.plugin... ]
Robert Mitchell commented on JGRP-2461:
---------------------------------------
In detail, here is our channel configuration:
{code}
channel = new JChannel(
// Primary transport
new TCP_NIO2()
.setBindPort(CLUSTER_PORT) // CLUSTER_PORT=7800
.setThreadPoolMaxThreads(20)
.setPortRange(0)
.setBindAddress(InetAddress.getByName(clusterManager.getLocalIpAddress())) // primary external IP address
.level("TRACE")
.setValue("use_ip_addrs", true), // Make sure we know each other's IP address
// Cluster identification and merging
new TCPPING()
.initialHosts(initialHosts()) // Provides 2 "well known" hosts as the initial hosts
.portRange(0)
.level("TRACE")
.setValue("async_discovery", true),
new MERGE3().level("TRACE"),
// Failure detection
new FD_SOCK()
.setValue("start_port", 7825)
.setValue("port_range", 0)
.setValue("bind_addr", InetAddress.getByName(clusterManager.getLocalIpAddress())),
new FD_ALL().timeout(30000),
new VERIFY_SUSPECT(),
// Security
new SYM_ENCRYPT().keystoreName("...keystore path..."),
new SERIALIZE(), // Make sure the entire message is encrypted
// Ensure deliveries
new NAKACK2().setUseMcastXmit(false),
new UNICAST3(),
// Garbage collection
new STABLE(),
// Membership management
new GMS().joinTimeout(2000).printLocalAddress(false).level("TRACE"),
// Flow control (non-blocking)
new UFC_NB(),
new MFC_NB(),
// Large message fragmentation
new FRAG2()
);
{code}
> Clustering can fail when re-adding an existing node using TCP_NIO2
> ------------------------------------------------------------------
>
> Key: JGRP-2461
> URL: https://issues.redhat.com/browse/JGRP-2461
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.1.8
> Reporter: Robert Mitchell
> Assignee: Bela Ban
> Priority: Major
>
> When a node leaves a cluster and then later attempts to re-enter, a race condition can occur where the clustering fails to occur. Here is the sequence of events that seems to allow this to occur:
> # The rejoining node must have a "higher" IP address than the current cluster coordinator.
> # On the rejoin attempt, the coordinator sends a message to the rejoining node before the rejoining node sends to the coordinator using its prior address. I have seen this happen for two reasons:
> ## UNICAST3 is resending messages (which often happens with the final LEAVE_RSP from the prior cluster membership because it apparently does not get acked before the connection closes)
> ## TCPPING is sending a ping request to the cached prior address.
> # The connection gets established. It will then be used by the rejoining node whenever communicating with the cluster coordinator.
> # However, the cluster coordinator has this as the connection for the prior address. So the following happens whenever it wants to send a message to the rejoining node:
> ## It will attempt to create a new connection.
> ## The rejoining node will reject the connection as a redundant connection with its current connection taking precedence since it is coming from the same logical address as the "bad" connection.
> Since the messages needed to find and join the cluster or merge the two clusters are all unicast messages, the rejoining node will never get them and not be able to join until something happens that causes the initial connection to get closed.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months