[JBoss JIRA] (WFLY-3711) Topology updates of EJBClient ClusterContexts not being processed correctly after failover
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/WFLY-3711?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz commented on WFLY-3711:
-------------------------------------------
The other problem, as mentioned before, is that ClusterNodeManagers which represent the nodes of a cluster in the cluster context, are being created each time a topology update comes in, and there is no check that an existing ClusterNodeManager exists and is still valid.
> Topology updates of EJBClient ClusterContexts not being processed correctly after failover
> ------------------------------------------------------------------------------------------
>
> Key: WFLY-3711
> URL: https://issues.jboss.org/browse/WFLY-3711
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Clustering
> Affects Versions: 9.0.0.Beta1
> Reporter: Richard Achmatowicz
> Assignee: Richard Achmatowicz
>
> ClusterContexts are used by EJBClient to keep track of the current set of nodes in a cluster, so that if an EJBClient invocation fails on one node, it may failover to another node in the same cluster. The ClusterContext is made up of ClusterNodeManagers which are responsible for setting up the connections between the EJBClient and the nodes in the cluster.
> Cluster topology updates are sent to registered EJBClients whenever the cluster topology changes (nodes join, nodes leave a cluster). Thse topology updates are processed on the client side by ClusterTopologyUpdateHandler and are used to update the current contents of the associated ClusterContext held on the client.
> The current implementation of the handling of topology updates does not correctly handle the addition/removal of ClusterNodeManagers from the cluster context - namely, rather than check whether or not a new ClusterNodeManager really needs to be added, ClusterNodeManagers are added for every node in the received topology update, leading to many unnecessary EJBReceivers and their channels being created.
> The logs show that up to 18 cluster node manager instances may be created, have their EJBReceivers registered and channels to the remote node created, when only one node has been added to the cluster.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 11 months
[JBoss JIRA] (WFLY-3711) Topology updates of EJBClient ClusterContexts not being processed correctly after failover
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/WFLY-3711?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz commented on WFLY-3711:
-------------------------------------------
There is at least one problem here: the cluster contexts on the client are not getting closed when the last node laves the cluster. The reason for this is that at the moment, as initially designed, the closing of the cluster context on the client is only triggered by the sendClusterRemoved message on the server which is in turn triggered by the registryRemoved callback. The callback action is commented out as removing a registry from a single node equates to that node leaving the cluster - not that the cluster has no members. Also, topology updates are not issued by Infinispan when the last member of a cluster leaves It seems the only way to detect the removal of a cluster on the client side is that the set of live connections to cluster nodes has become empty with the removal of the last cluster node. This in turn depends on channel closure working properly.
So, the logic for clusterContext closure on the client needs to take this into account.
> Topology updates of EJBClient ClusterContexts not being processed correctly after failover
> ------------------------------------------------------------------------------------------
>
> Key: WFLY-3711
> URL: https://issues.jboss.org/browse/WFLY-3711
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Clustering
> Affects Versions: 9.0.0.Beta1
> Reporter: Richard Achmatowicz
> Assignee: Richard Achmatowicz
>
> ClusterContexts are used by EJBClient to keep track of the current set of nodes in a cluster, so that if an EJBClient invocation fails on one node, it may failover to another node in the same cluster. The ClusterContext is made up of ClusterNodeManagers which are responsible for setting up the connections between the EJBClient and the nodes in the cluster.
> Cluster topology updates are sent to registered EJBClients whenever the cluster topology changes (nodes join, nodes leave a cluster). Thse topology updates are processed on the client side by ClusterTopologyUpdateHandler and are used to update the current contents of the associated ClusterContext held on the client.
> The current implementation of the handling of topology updates does not correctly handle the addition/removal of ClusterNodeManagers from the cluster context - namely, rather than check whether or not a new ClusterNodeManager really needs to be added, ClusterNodeManagers are added for every node in the received topology update, leading to many unnecessary EJBReceivers and their channels being created.
> The logs show that up to 18 cluster node manager instances may be created, have their EJBReceivers registered and channels to the remote node created, when only one node has been added to the cluster.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 11 months
[JBoss JIRA] (JBMETA-363) Validation errors with "jboss-web_7_0.xsd
by Wolfgang Knauf (JIRA)
[ https://issues.jboss.org/browse/JBMETA-363?page=com.atlassian.jira.plugin... ]
Wolfgang Knauf commented on JBMETA-363:
---------------------------------------
Same applies to jboss_web_7_1.xsd and jboss_web_8_0.xsd
Using Eclipse 4.4 (WebTools 3.6), the validation error has changed, but I assume it is still the same source:
"schema_reference.4: Failed to read the schema document 'web-app_3_1.xsd', because 1) could not find the document; 2) the document could not be read; 3) the root element of the document is not 'xsd:schema'
Same happens for jboss-app.xml instances based on "jboss-app_7_0.xsd"
The issue now happens always (without me changing the schema location to a local file), because the JBoss Tools plugin brings all jboss schema files and thus Eclipse can validate them even if they are not published to the web location.
> Validation errors with "jboss-web_7_0.xsd
> -----------------------------------------
>
> Key: JBMETA-363
> URL: https://issues.jboss.org/browse/JBMETA-363
> Project: JBoss Metadata
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: web
> Affects Versions: 7.0.5.Final, 8.1.0.Beta1
> Environment: Eclipse
> Reporter: Wolfgang Knauf
> Assignee: Jean-Frederic Clere
>
> I tried to create a "jboss-web.xml" file based on the "jboss-web_7_1.xsd"
> As this is not uploaded to the web up to now, I created it with a schema location pointing to my local JBoss 7.2.0Alpha1 snapshot:
> <?xml version="1.0" encoding="UTF-8"?>
> <jboss-web xmlns="http://www.jboss.com/xml/ns/javaee"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xsi:schemaLocation="http://www.jboss.com/xml/ns/javaee file:///C:/Temp/jboss-as-7.2.0.Alpha1-SNAPSHOT/docs/schema/jboss-web_7_0.xsd"
> version="7.0">
> ...
> </jboss-web>
> Eclipse shows validation errors in the XSD file.
> The first on is:
> sch-props-correct.2: A schema cannot contain two global components with the same name; this schema contains two
> occurences of 'http://java.sun.com/xml/ns/javaee,descriptionGroup'
> (occurs in javaee_6.xsd, line 88)
> And a lot more of those.
> The file was created as part of https://issues.jboss.org/browse/AS7-1262 - and the one who created it found the same validation error.
> It seems the fix is quite simple:
> "jboss-web_7_0.xsd" contains this import:
> <xsd:import namespace="http://java.sun.com/xml/ns/javaee" schemaLocation="web-app_3_0.xsd"/>
> Change it to:
> <xsd:import namespace="http://java.sun.com/xml/ns/javaee" schemaLocation="http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"/>
> The reason seems to be: "jboss-web_7_0.xsd" imports "jboss-common_6-0.xsd", and this one imports "javaee_6.xsd" with a full schema location.
> The "web-app_3_0.xsd" in "jboss-web_7_0.xsd" has a local schema location, thus the "javaee_6.xsd" import in "web-app_3_0.xsd" points also to local.
> And this seems to cause a duplicate import of the file.
> (might also be an Eclipse valiation bug)
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 11 months
[JBoss JIRA] (ELY-39) Ensure all algorithms are on the password interfaces and not private implementations.
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-39?page=com.atlassian.jira.plugin.sys... ]
Darran Lofthouse updated ELY-39:
--------------------------------
Description:
Some algorithm names are in the password implementations, the problem with this is they are not visible to other classes in the project wanting to create instances of them.
was:
The mechanism names are currently in the password implementations, this means they can not be used by classes in other packages or outside of Elytron.
In addition to this a password provider whilst obtained by using an algorithm can decide on what password type to return based on the passwordspec so we should not assume a tight coupling of password and algorithm name.
> Ensure all algorithms are on the password interfaces and not private implementations.
> -------------------------------------------------------------------------------------
>
> Key: ELY-39
> URL: https://issues.jboss.org/browse/ELY-39
> Project: WildFly Elytron
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: API / SPI
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Fix For: 1.0.0.Beta1
>
>
> Some algorithm names are in the password implementations, the problem with this is they are not visible to other classes in the project wanting to create instances of them.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 11 months
[JBoss JIRA] (ELY-39) Ensure all algorithms are on the password interfaces and not private implementations.
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-39?page=com.atlassian.jira.plugin.sys... ]
Darran Lofthouse updated ELY-39:
--------------------------------
Summary: Ensure all algorithms are on the password interfaces and not private implementations. (was: Move the Elytron supplied algorithms names to a single class.)
> Ensure all algorithms are on the password interfaces and not private implementations.
> -------------------------------------------------------------------------------------
>
> Key: ELY-39
> URL: https://issues.jboss.org/browse/ELY-39
> Project: WildFly Elytron
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: API / SPI
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Fix For: 1.0.0.Beta1
>
>
> The mechanism names are currently in the password implementations, this means they can not be used by classes in other packages or outside of Elytron.
> In addition to this a password provider whilst obtained by using an algorithm can decide on what password type to return based on the passwordspec so we should not assume a tight coupling of password and algorithm name.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 11 months
[JBoss JIRA] (JGRP-1866) Broken Links on JBoss.org
by Daniel Coughlin (JIRA)
[ https://issues.jboss.org/browse/JGRP-1866?page=com.atlassian.jira.plugin.... ]
Daniel Coughlin commented on JGRP-1866:
---------------------------------------
[~paul.robinson] Does something need to be initiated to fix this? It is still broken on the site.
> Broken Links on JBoss.org
> -------------------------
>
> Key: JGRP-1866
> URL: https://issues.jboss.org/browse/JGRP-1866
> Project: JGroups
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Reporter: Daniel Coughlin
> Assignee: Bela Ban
> Fix For: 3.5
>
>
> The following broken link is currently listed against this project on www.jboss.org/projects.
> git@github.com:belaban/JGroups.git - Committer Git
> If you maintain a project.properties file that you have told the jboss.org team about, then you just need to fix it in there and the change will be reflected on the site. Otherwise, you need to update the data on this project's Magnolia page.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 11 months
[JBoss JIRA] (ELY-39) Move the Elytron supplied algorithms names to a single class.
by Darran Lofthouse (JIRA)
Darran Lofthouse created ELY-39:
-----------------------------------
Summary: Move the Elytron supplied algorithms names to a single class.
Key: ELY-39
URL: https://issues.jboss.org/browse/ELY-39
Project: WildFly Elytron
Issue Type: Task
Security Level: Public (Everyone can see)
Components: API / SPI
Reporter: Darran Lofthouse
Assignee: Darran Lofthouse
Fix For: 1.0.0.Beta1
The mechanism names are currently in the password implementations, this means they can not be used by classes in other packages or outside of Elytron.
In addition to this a password provider whilst obtained by using an algorithm can decide on what password type to return based on the passwordspec so we should not assume a tight coupling of password and algorithm name.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 11 months
[JBoss JIRA] (WFLY-3711) Topology updates of EJBClient ClusterContexts not being processed correctly after failover
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/WFLY-3711?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz edited comment on WFLY-3711 at 8/7/14 2:00 PM:
-------------------------------------------------------------------
The various registry callbacks then cause messages to be sent from server to client along all open EJBClient <--> EJBRemoteConnector connections:
{noformat}
[nrla@lenovo surefire-reports]$ grep Registry org.jboss.as.test.clustering.cluster.ejb.remote.RemoteFailoverTestCase-SYNC-tcp-output.txt
// node-0, node-1 start up and deploy clustered app
16:00:55,432 INFO [stdout] (MSC service thread 1-3) Registry collector service started on node node-0
16:01:02,046 INFO [stdout] (MSC service thread 1-2) Registry collector service started on node node-1
16:01:10,575 INFO [stdout] (MSC service thread 1-8) Registry for cluster ejb added on node node-0
16:01:13,624 INFO [stdout] (MSC service thread 1-5) Registry for cluster ejb added on node node-1
Registry: Received a cluster node(s) addition message, for cluster named ejb with 2 nodes [ClusterNode{clusterName='ejb', nodeName='node-0', clientMappings=[ClientMapping{sourceNetworkAddress=/0:0:0:0:0:0:0:0, sourceNetworkMaskBits=0, destinationAddress='127.0.0.1', destinationPort=8080}], resolvedDestination=[Destination address=127.0.0.1, destination port=8080]}, ClusterNode{clusterName='ejb', nodeName='node-1', clientMappings=[ClientMapping{sourceNetworkAddress=/0:0:0:0:0:0:0:0, sourceNetworkMaskBits=0, destinationAddress='127.0.0.1', destinationPort=8180}], resolvedDestination=[Destination address=127.0.0.1, destination port=8180]}]
Registry: Received a cluster node(s) addition message, for cluster named ejb with 2 nodes [ClusterNode{clusterName='ejb', nodeName='node-0', clientMappings=[ClientMapping{sourceNetworkAddress=/0:0:0:0:0:0:0:0, sourceNetworkMaskBits=0, destinationAddress='127.0.0.1', destinationPort=8080}], resolvedDestination=[Destination address=127.0.0.1, destination port=8080]}, ClusterNode{clusterName='ejb', nodeName='node-1', clientMappings=[ClientMapping{sourceNetworkAddress=/0:0:0:0:0:0:0:0, sourceNetworkMaskBits=0, destinationAddress='127.0.0.1', destinationPort=8180}], resolvedDestination=[Destination address=127.0.0.1, destination port=8180]}]
// node-0 undeploys clustered app
16:01:15,998 INFO [stdout] (MSC service thread 1-8) Registry for cluster ejb removed on node node-0
16:01:15,999 INFO [stdout] (MSC service thread 1-8) Registry removed on node node-0 with (key) entries: [node-0, node-1]
16:01:16,004 INFO [stdout] (remote-thread-0) Registry entries removed on node node-1 for nodes: [node-0]
Registry: Received a cluster node(s) removal message, for cluster named ejb with 1 removed nodes [node-0]
// node-0 deploys clustered app
16:01:16,881 INFO [stdout] (remote-thread-0) Registry entries added on node node-1 for nodes: [node-0]
Registry: Received a cluster node(s) addition message, for cluster named ejb with 1 nodes [ClusterNode{clusterName='ejb', nodeName='node-0', clientMappings=[ClientMapping{sourceNetworkAddress=/0:0:0:0:0:0:0:0, sourceNetworkMaskBits=0, destinationAddress='127.0.0.1', destinationPort=8080}], resolvedDestination=[Destination address=127.0.0.1, destination port=8080]}]
16:01:16,883 INFO [stdout] (MSC service thread 1-6) Registry for cluster ejb added on node node-0
16:01:16,884 INFO [stdout] (MSC service thread 1-6) Registry added on node node-0 with (key) entries: [node-0, node-1]
Registry: Received a cluster node(s) addition message, for cluster named ejb with 2 nodes [ClusterNode{clusterName='ejb', nodeName='node-0', clientMappings=[ClientMapping{sourceNetworkAddress=/0:0:0:0:0:0:0:0, sourceNetworkMaskBits=0, destinationAddress='127.0.0.1', destinationPort=8080}], resolvedDestination=[Destination address=127.0.0.1, destination port=8080]}, ClusterNode{clusterName='ejb', nodeName='node-1', clientMappings=[ClientMapping{sourceNetworkAddress=/0:0:0:0:0:0:0:0, sourceNetworkMaskBits=0, destinationAddress='127.0.0.1', destinationPort=8180}], resolvedDestination=[Destination address=127.0.0.1, destination port=8180]}]
// node-1 undeploys clustered app and shuts down
16:01:22,323 INFO [stdout] (MSC service thread 1-3) Registry for cluster ejb removed on node node-1
16:01:22,324 INFO [stdout] (MSC service thread 1-3) Registry removed on node node-1 with (key) entries: [node-0, node-1]
16:01:22,325 INFO [stdout] (MSC service thread 1-3) Registry collector service stopped on node node-1
16:01:22,328 INFO [stdout] (remote-thread-0) Registry entries removed on node node-0 for nodes: [node-1]
Registry: Received a cluster node(s) removal message, for cluster named ejb with 1 removed nodes [node-1]
// node-1 starts up and deploys clustered app
16:01:29,490 INFO [stdout] (MSC service thread 1-1) Registry collector service started on node node-1
16:01:31,047 INFO [stdout] (remote-thread-0) Registry entries added on node node-0 for nodes: [node-1]
Registry: Received a cluster node(s) addition message, for cluster named ejb with 1 nodes [ClusterNode{clusterName='ejb', nodeName='node-1', clientMappings=[ClientMapping{sourceNetworkAddress=/0:0:0:0:0:0:0:0, sourceNetworkMaskBits=0, destinationAddress='127.0.0.1', destinationPort=8180}], resolvedDestination=[Destination address=127.0.0.1, destination port=8180]}]
16:01:31,051 INFO [stdout] (MSC service thread 1-1) Registry for cluster ejb added on node node-1
Registry: Received a cluster node(s) addition message, for cluster named ejb with 2 nodes [ClusterNode{clusterName='ejb', nodeName='node-0', clientMappings=[ClientMapping{sourceNetworkAddress=/0:0:0:0:0:0:0:0, sourceNetworkMaskBits=0, destinationAddress='127.0.0.1', destinationPort=8080}], resolvedDestination=[Destination address=127.0.0.1, destination port=8080]}, ClusterNode{clusterName='ejb', nodeName='node-1', clientMappings=[ClientMapping{sourceNetworkAddress=/0:0:0:0:0:0:0:0, sourceNetworkMaskBits=0, destinationAddress='127.0.0.1', destinationPort=8180}], resolvedDestination=[Destination address=127.0.0.1, destination port=8180]}]
// node-0 and node-1 shut down
16:01:39,289 INFO [stdout] (MSC service thread 1-3) Registry for cluster ejb removed on node node-0
16:01:39,290 INFO [stdout] (MSC service thread 1-3) Registry removed on node node-0 with (key) entries: [node-0, node-1]
16:01:39,296 INFO [stdout] (remote-thread-0) Registry entries removed on node node-1 for nodes: [node-0]
Registry: Received a cluster node(s) removal message, for cluster named ejb with 1 removed nodes [node-0]
16:01:39,756 INFO [stdout] (MSC service thread 1-4) Registry for cluster ejb removed on node node-1
16:01:39,757 INFO [stdout] (MSC service thread 1-4) Registry removed on node node-1 with (key) entries: [node-1]
// no cluster node removal message for node-1!
// no "cluster context closed" messages appearing on client when both servers stop
{noformat}
was (Author: rachmato):
The various registry callbacks then cause messages to be send from server to client along all open EJBClient <--> EJBRemoteConnector connections:
{noformat}
[nrla@lenovo surefire-reports]$ grep Registry org.jboss.as.test.clustering.cluster.ejb.remote.RemoteFailoverTestCase-SYNC-tcp-output.txt
// node-0, node-1 start up and deploy clustered app
16:00:55,432 INFO [stdout] (MSC service thread 1-3) Registry collector service started on node node-0
16:01:02,046 INFO [stdout] (MSC service thread 1-2) Registry collector service started on node node-1
16:01:10,575 INFO [stdout] (MSC service thread 1-8) Registry for cluster ejb added on node node-0
16:01:13,624 INFO [stdout] (MSC service thread 1-5) Registry for cluster ejb added on node node-1
Registry: Received a cluster node(s) addition message, for cluster named ejb with 2 nodes [ClusterNode{clusterName='ejb', nodeName='node-0', clientMappings=[ClientMapping{sourceNetworkAddress=/0:0:0:0:0:0:0:0, sourceNetworkMaskBits=0, destinationAddress='127.0.0.1', destinationPort=8080}], resolvedDestination=[Destination address=127.0.0.1, destination port=8080]}, ClusterNode{clusterName='ejb', nodeName='node-1', clientMappings=[ClientMapping{sourceNetworkAddress=/0:0:0:0:0:0:0:0, sourceNetworkMaskBits=0, destinationAddress='127.0.0.1', destinationPort=8180}], resolvedDestination=[Destination address=127.0.0.1, destination port=8180]}]
Registry: Received a cluster node(s) addition message, for cluster named ejb with 2 nodes [ClusterNode{clusterName='ejb', nodeName='node-0', clientMappings=[ClientMapping{sourceNetworkAddress=/0:0:0:0:0:0:0:0, sourceNetworkMaskBits=0, destinationAddress='127.0.0.1', destinationPort=8080}], resolvedDestination=[Destination address=127.0.0.1, destination port=8080]}, ClusterNode{clusterName='ejb', nodeName='node-1', clientMappings=[ClientMapping{sourceNetworkAddress=/0:0:0:0:0:0:0:0, sourceNetworkMaskBits=0, destinationAddress='127.0.0.1', destinationPort=8180}], resolvedDestination=[Destination address=127.0.0.1, destination port=8180]}]
// node-0 undeploys clustered app
16:01:15,998 INFO [stdout] (MSC service thread 1-8) Registry for cluster ejb removed on node node-0
16:01:15,999 INFO [stdout] (MSC service thread 1-8) Registry removed on node node-0 with (key) entries: [node-0, node-1]
16:01:16,004 INFO [stdout] (remote-thread-0) Registry entries removed on node node-1 for nodes: [node-0]
Registry: Received a cluster node(s) removal message, for cluster named ejb with 1 removed nodes [node-0]
// node-0 deploys clustered app
16:01:16,881 INFO [stdout] (remote-thread-0) Registry entries added on node node-1 for nodes: [node-0]
Registry: Received a cluster node(s) addition message, for cluster named ejb with 1 nodes [ClusterNode{clusterName='ejb', nodeName='node-0', clientMappings=[ClientMapping{sourceNetworkAddress=/0:0:0:0:0:0:0:0, sourceNetworkMaskBits=0, destinationAddress='127.0.0.1', destinationPort=8080}], resolvedDestination=[Destination address=127.0.0.1, destination port=8080]}]
16:01:16,883 INFO [stdout] (MSC service thread 1-6) Registry for cluster ejb added on node node-0
16:01:16,884 INFO [stdout] (MSC service thread 1-6) Registry added on node node-0 with (key) entries: [node-0, node-1]
Registry: Received a cluster node(s) addition message, for cluster named ejb with 2 nodes [ClusterNode{clusterName='ejb', nodeName='node-0', clientMappings=[ClientMapping{sourceNetworkAddress=/0:0:0:0:0:0:0:0, sourceNetworkMaskBits=0, destinationAddress='127.0.0.1', destinationPort=8080}], resolvedDestination=[Destination address=127.0.0.1, destination port=8080]}, ClusterNode{clusterName='ejb', nodeName='node-1', clientMappings=[ClientMapping{sourceNetworkAddress=/0:0:0:0:0:0:0:0, sourceNetworkMaskBits=0, destinationAddress='127.0.0.1', destinationPort=8180}], resolvedDestination=[Destination address=127.0.0.1, destination port=8180]}]
// node-1 undeploys clustered app and shuts down
16:01:22,323 INFO [stdout] (MSC service thread 1-3) Registry for cluster ejb removed on node node-1
16:01:22,324 INFO [stdout] (MSC service thread 1-3) Registry removed on node node-1 with (key) entries: [node-0, node-1]
16:01:22,325 INFO [stdout] (MSC service thread 1-3) Registry collector service stopped on node node-1
16:01:22,328 INFO [stdout] (remote-thread-0) Registry entries removed on node node-0 for nodes: [node-1]
Registry: Received a cluster node(s) removal message, for cluster named ejb with 1 removed nodes [node-1]
// node-1 starts up and deploys clustered app
16:01:29,490 INFO [stdout] (MSC service thread 1-1) Registry collector service started on node node-1
16:01:31,047 INFO [stdout] (remote-thread-0) Registry entries added on node node-0 for nodes: [node-1]
Registry: Received a cluster node(s) addition message, for cluster named ejb with 1 nodes [ClusterNode{clusterName='ejb', nodeName='node-1', clientMappings=[ClientMapping{sourceNetworkAddress=/0:0:0:0:0:0:0:0, sourceNetworkMaskBits=0, destinationAddress='127.0.0.1', destinationPort=8180}], resolvedDestination=[Destination address=127.0.0.1, destination port=8180]}]
16:01:31,051 INFO [stdout] (MSC service thread 1-1) Registry for cluster ejb added on node node-1
Registry: Received a cluster node(s) addition message, for cluster named ejb with 2 nodes [ClusterNode{clusterName='ejb', nodeName='node-0', clientMappings=[ClientMapping{sourceNetworkAddress=/0:0:0:0:0:0:0:0, sourceNetworkMaskBits=0, destinationAddress='127.0.0.1', destinationPort=8080}], resolvedDestination=[Destination address=127.0.0.1, destination port=8080]}, ClusterNode{clusterName='ejb', nodeName='node-1', clientMappings=[ClientMapping{sourceNetworkAddress=/0:0:0:0:0:0:0:0, sourceNetworkMaskBits=0, destinationAddress='127.0.0.1', destinationPort=8180}], resolvedDestination=[Destination address=127.0.0.1, destination port=8180]}]
// node-0 and node-1 shut down
16:01:39,289 INFO [stdout] (MSC service thread 1-3) Registry for cluster ejb removed on node node-0
16:01:39,290 INFO [stdout] (MSC service thread 1-3) Registry removed on node node-0 with (key) entries: [node-0, node-1]
16:01:39,296 INFO [stdout] (remote-thread-0) Registry entries removed on node node-1 for nodes: [node-0]
Registry: Received a cluster node(s) removal message, for cluster named ejb with 1 removed nodes [node-0]
16:01:39,756 INFO [stdout] (MSC service thread 1-4) Registry for cluster ejb removed on node node-1
16:01:39,757 INFO [stdout] (MSC service thread 1-4) Registry removed on node node-1 with (key) entries: [node-1]
// no cluster node removal message for node-1!
// no "cluster context closed" messages appearing on client when both servers stop
{noformat}
> Topology updates of EJBClient ClusterContexts not being processed correctly after failover
> ------------------------------------------------------------------------------------------
>
> Key: WFLY-3711
> URL: https://issues.jboss.org/browse/WFLY-3711
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Clustering
> Affects Versions: 9.0.0.Beta1
> Reporter: Richard Achmatowicz
> Assignee: Richard Achmatowicz
>
> ClusterContexts are used by EJBClient to keep track of the current set of nodes in a cluster, so that if an EJBClient invocation fails on one node, it may failover to another node in the same cluster. The ClusterContext is made up of ClusterNodeManagers which are responsible for setting up the connections between the EJBClient and the nodes in the cluster.
> Cluster topology updates are sent to registered EJBClients whenever the cluster topology changes (nodes join, nodes leave a cluster). Thse topology updates are processed on the client side by ClusterTopologyUpdateHandler and are used to update the current contents of the associated ClusterContext held on the client.
> The current implementation of the handling of topology updates does not correctly handle the addition/removal of ClusterNodeManagers from the cluster context - namely, rather than check whether or not a new ClusterNodeManager really needs to be added, ClusterNodeManagers are added for every node in the received topology update, leading to many unnecessary EJBReceivers and their channels being created.
> The logs show that up to 18 cluster node manager instances may be created, have their EJBReceivers registered and channels to the remote node created, when only one node has been added to the cluster.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 11 months