[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 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}
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!
{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
[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 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!
{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
[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:
-------------------------------------------
Some background on how these topology updates from cluster members are generated:
{noformat}
- use of RegistryCollector and Registry is to keep track of which clusters a node belongs to and membership changes of the clusters
- RegistryCollector
- the RegistryCollector holds a set of Registry objects and represents the *set* of clusters that a node belongs to
- implemented by a service on the node, which holds the collection
- the RegistryCollector has listeners:
registryAdded
registryRemoved
- Registry
- each Registry represents a cluster that the node is a member of and holds a Map<String,List<ClientMapping>>
- each Map.Entry represents a node in that cluster and its local set of ClientMapping elements (outgoing connections)
- implemented by a distributed cache which holds a Map of node names to List<ClientMapping>
- CacheRegistry (the implementation) has three listeners:
@ToplologyChanged -> only processed on coordinator; calculate the set of old addresses; perform an invocation to remove them from all nodes; notify remove listeners on this node only
@CacheEntryModified -> addedEntries(Collections.singletonMap(entry.getKey(), entry.getValue())) / updatedEntries(Collections.singletonMap(entry.getKey(), entry.getValue()))
@CacheEntryRemoved -> removedEntries(Collections.singletonMap(entry.getKey(), entry.getValue()))
- cluster-related update events originate on the server side, due to changes to the caches underlying RegistryCollector and Registry
- these events are interpreted and propagated to the client side where they are used to update the ClientContexts
{noformat}
The operation of these callbacks can be seen from the logs:
{no format}
[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
15:11:18,705 INFO [stdout] (MSC service thread 1-8) Registry collector service started on node node-0
15:11:25,895 INFO [stdout] (MSC service thread 1-9) Registry collector service started on node node-1
15:11:36,017 INFO [stdout] (MSC service thread 1-2) Registry for cluster ejb added on node node-0
15:11:39,950 INFO [stdout] (MSC service thread 1-10) Registry for cluster ejb added on node node-1
// node-0 undeploys clustered app
15:11:42,320 INFO [stdout] (MSC service thread 1-2) Registry for cluster ejb removed on node node-0
15:11:42,320 INFO [stdout] (MSC service thread 1-2) Registry removed on node node-0 with (key) entries: [node-0, node-1] (same callback as previous message)
15:11:42,326 INFO [stdout] (remote-thread-0) Registry entries removed on node node-1 for nodes: [node-0]
// node-0 deploys clustered app
15:11:43,180 INFO [stdout] (remote-thread-0) Registry entries added on node node-1 for nodes: [node-0]
15:11:43,182 INFO [stdout] (MSC service thread 1-12) Registry for cluster ejb added on node node-0
15:11:43,183 INFO [stdout] (MSC service thread 1-12) Registry added on node node-0 with (key) entries: [node-0, node-1] (same callback as previous message)
// node-1 shuts down
15:11:48,644 INFO [stdout] (MSC service thread 1-9) Registry for cluster ejb removed on node node-1
15:11:48,645 INFO [stdout] (MSC service thread 1-9) Registry removed on node node-1 with (key) entries: [node-0, node-1] (same callback as previous message)
15:11:48,645 INFO [stdout] (MSC service thread 1-11) Registry collector service stopped on node node-1
15:11:48,648 INFO [stdout] (remote-thread-0) Registry entries removed on node node-0 for nodes: [node-1]
// node-1 starts up
15:11:55,788 INFO [stdout] (MSC service thread 1-12) Registry collector service started on node node-1
15:11:57,365 INFO [stdout] (remote-thread-0) Registry entries added on node node-0 for nodes: [node-1]
15:11:57,369 INFO [stdout] (MSC service thread 1-16) Registry for cluster ejb added on node node-1
// node-0, node-1 shut down
15:12:12,374 INFO [stdout] (MSC service thread 1-16) Registry for cluster ejb removed on node node-0
15:12:12,375 INFO [stdout] (MSC service thread 1-16) Registry removed on node node-0 with (key) entries: [node-0, node-1] (same callback as previous message)
15:12:12,829 INFO [stdout] (MSC service thread 1-12) Registry for cluster ejb removed on node node-1
15:12:12,829 INFO [stdout] (MSC service thread 1-12) Registry removed on node node-1 with (key) entries: [node-1]
15:12:12,829 INFO [stdout] (MSC service thread 1-12) Registry removed on node node-1 with (key) entries: [node-1]
15:12:12,830 INFO [stdout] (MSC service thread 1-12) Registry removed on node node-1 with (key) entries: [node-1]
15:12:12,830 INFO [stdout] (MSC service thread 1-12) Registry removed on node node-1 with (key) entries: [node-1]
{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
[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 1:56 PM:
-------------------------------------------------------------------
Some background on how these topology updates from cluster members are generated:
{noformat}
- use of RegistryCollector and Registry is to keep track of which clusters a node belongs to and membership changes of the clusters
- RegistryCollector
- the RegistryCollector holds a set of Registry objects and represents the *set* of clusters that a node belongs to
- implemented by a service on the node, which holds the collection
- the RegistryCollector has listeners:
registryAdded
registryRemoved
- Registry
- each Registry represents a cluster that the node is a member of and holds a Map<String,List<ClientMapping>>
- each Map.Entry represents a node in that cluster and its local set of ClientMapping elements (outgoing connections)
- implemented by a distributed cache which holds a Map of node names to List<ClientMapping>
- CacheRegistry (the implementation) has three listeners:
@ToplologyChanged -> only processed on coordinator; calculate the set of old addresses; perform an invocation to remove them from all nodes; notify remove listeners on this node only
@CacheEntryModified -> addedEntries(Collections.singletonMap(entry.getKey(), entry.getValue())) / updatedEntries(Collections.singletonMap(entry.getKey(), entry.getValue()))
@CacheEntryRemoved -> removedEntries(Collections.singletonMap(entry.getKey(), entry.getValue()))
- cluster-related update events originate on the server side, due to changes to the caches underlying RegistryCollector and Registry
- these events are interpreted and propagated to the client side where they are used to update the ClientContexts
{noformat}
The operation of these callbacks can be seen from the logs:
{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
15:11:18,705 INFO [stdout] (MSC service thread 1-8) Registry collector service started on node node-0
15:11:25,895 INFO [stdout] (MSC service thread 1-9) Registry collector service started on node node-1
15:11:36,017 INFO [stdout] (MSC service thread 1-2) Registry for cluster ejb added on node node-0
15:11:39,950 INFO [stdout] (MSC service thread 1-10) Registry for cluster ejb added on node node-1
// node-0 undeploys clustered app
15:11:42,320 INFO [stdout] (MSC service thread 1-2) Registry for cluster ejb removed on node node-0
15:11:42,320 INFO [stdout] (MSC service thread 1-2) Registry removed on node node-0 with (key) entries: [node-0, node-1] (same callback as previous message)
15:11:42,326 INFO [stdout] (remote-thread-0) Registry entries removed on node node-1 for nodes: [node-0]
// node-0 deploys clustered app
15:11:43,180 INFO [stdout] (remote-thread-0) Registry entries added on node node-1 for nodes: [node-0]
15:11:43,182 INFO [stdout] (MSC service thread 1-12) Registry for cluster ejb added on node node-0
15:11:43,183 INFO [stdout] (MSC service thread 1-12) Registry added on node node-0 with (key) entries: [node-0, node-1] (same callback as previous message)
// node-1 shuts down
15:11:48,644 INFO [stdout] (MSC service thread 1-9) Registry for cluster ejb removed on node node-1
15:11:48,645 INFO [stdout] (MSC service thread 1-9) Registry removed on node node-1 with (key) entries: [node-0, node-1] (same callback as previous message)
15:11:48,645 INFO [stdout] (MSC service thread 1-11) Registry collector service stopped on node node-1
15:11:48,648 INFO [stdout] (remote-thread-0) Registry entries removed on node node-0 for nodes: [node-1]
// node-1 starts up
15:11:55,788 INFO [stdout] (MSC service thread 1-12) Registry collector service started on node node-1
15:11:57,365 INFO [stdout] (remote-thread-0) Registry entries added on node node-0 for nodes: [node-1]
15:11:57,369 INFO [stdout] (MSC service thread 1-16) Registry for cluster ejb added on node node-1
// node-0, node-1 shut down
15:12:12,374 INFO [stdout] (MSC service thread 1-16) Registry for cluster ejb removed on node node-0
15:12:12,375 INFO [stdout] (MSC service thread 1-16) Registry removed on node node-0 with (key) entries: [node-0, node-1] (same callback as previous message)
15:12:12,829 INFO [stdout] (MSC service thread 1-12) Registry for cluster ejb removed on node node-1
15:12:12,829 INFO [stdout] (MSC service thread 1-12) Registry removed on node node-1 with (key) entries: [node-1]
15:12:12,829 INFO [stdout] (MSC service thread 1-12) Registry removed on node node-1 with (key) entries: [node-1]
15:12:12,830 INFO [stdout] (MSC service thread 1-12) Registry removed on node node-1 with (key) entries: [node-1]
15:12:12,830 INFO [stdout] (MSC service thread 1-12) Registry removed on node node-1 with (key) entries: [node-1]
{noformat}
was (Author: rachmato):
Some background on how these topology updates from cluster members are generated:
{noformat}
- use of RegistryCollector and Registry is to keep track of which clusters a node belongs to and membership changes of the clusters
- RegistryCollector
- the RegistryCollector holds a set of Registry objects and represents the *set* of clusters that a node belongs to
- implemented by a service on the node, which holds the collection
- the RegistryCollector has listeners:
registryAdded
registryRemoved
- Registry
- each Registry represents a cluster that the node is a member of and holds a Map<String,List<ClientMapping>>
- each Map.Entry represents a node in that cluster and its local set of ClientMapping elements (outgoing connections)
- implemented by a distributed cache which holds a Map of node names to List<ClientMapping>
- CacheRegistry (the implementation) has three listeners:
@ToplologyChanged -> only processed on coordinator; calculate the set of old addresses; perform an invocation to remove them from all nodes; notify remove listeners on this node only
@CacheEntryModified -> addedEntries(Collections.singletonMap(entry.getKey(), entry.getValue())) / updatedEntries(Collections.singletonMap(entry.getKey(), entry.getValue()))
@CacheEntryRemoved -> removedEntries(Collections.singletonMap(entry.getKey(), entry.getValue()))
- cluster-related update events originate on the server side, due to changes to the caches underlying RegistryCollector and Registry
- these events are interpreted and propagated to the client side where they are used to update the ClientContexts
{noformat}
The operation of these callbacks can be seen from the logs:
{no format}
[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
15:11:18,705 INFO [stdout] (MSC service thread 1-8) Registry collector service started on node node-0
15:11:25,895 INFO [stdout] (MSC service thread 1-9) Registry collector service started on node node-1
15:11:36,017 INFO [stdout] (MSC service thread 1-2) Registry for cluster ejb added on node node-0
15:11:39,950 INFO [stdout] (MSC service thread 1-10) Registry for cluster ejb added on node node-1
// node-0 undeploys clustered app
15:11:42,320 INFO [stdout] (MSC service thread 1-2) Registry for cluster ejb removed on node node-0
15:11:42,320 INFO [stdout] (MSC service thread 1-2) Registry removed on node node-0 with (key) entries: [node-0, node-1] (same callback as previous message)
15:11:42,326 INFO [stdout] (remote-thread-0) Registry entries removed on node node-1 for nodes: [node-0]
// node-0 deploys clustered app
15:11:43,180 INFO [stdout] (remote-thread-0) Registry entries added on node node-1 for nodes: [node-0]
15:11:43,182 INFO [stdout] (MSC service thread 1-12) Registry for cluster ejb added on node node-0
15:11:43,183 INFO [stdout] (MSC service thread 1-12) Registry added on node node-0 with (key) entries: [node-0, node-1] (same callback as previous message)
// node-1 shuts down
15:11:48,644 INFO [stdout] (MSC service thread 1-9) Registry for cluster ejb removed on node node-1
15:11:48,645 INFO [stdout] (MSC service thread 1-9) Registry removed on node node-1 with (key) entries: [node-0, node-1] (same callback as previous message)
15:11:48,645 INFO [stdout] (MSC service thread 1-11) Registry collector service stopped on node node-1
15:11:48,648 INFO [stdout] (remote-thread-0) Registry entries removed on node node-0 for nodes: [node-1]
// node-1 starts up
15:11:55,788 INFO [stdout] (MSC service thread 1-12) Registry collector service started on node node-1
15:11:57,365 INFO [stdout] (remote-thread-0) Registry entries added on node node-0 for nodes: [node-1]
15:11:57,369 INFO [stdout] (MSC service thread 1-16) Registry for cluster ejb added on node node-1
// node-0, node-1 shut down
15:12:12,374 INFO [stdout] (MSC service thread 1-16) Registry for cluster ejb removed on node node-0
15:12:12,375 INFO [stdout] (MSC service thread 1-16) Registry removed on node node-0 with (key) entries: [node-0, node-1] (same callback as previous message)
15:12:12,829 INFO [stdout] (MSC service thread 1-12) Registry for cluster ejb removed on node node-1
15:12:12,829 INFO [stdout] (MSC service thread 1-12) Registry removed on node node-1 with (key) entries: [node-1]
15:12:12,829 INFO [stdout] (MSC service thread 1-12) Registry removed on node node-1 with (key) entries: [node-1]
15:12:12,830 INFO [stdout] (MSC service thread 1-12) Registry removed on node node-1 with (key) entries: [node-1]
15:12:12,830 INFO [stdout] (MSC service thread 1-12) Registry removed on node node-1 with (key) entries: [node-1]
{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
[JBoss JIRA] (WFLY-3696) Security domain configuration doesn't allow empty or missing login-module-stack
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-3696?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-3696:
-----------------------------------------------
Kabir Khan <kkhan(a)redhat.com> changed the Status of [bug 901075|https://bugzilla.redhat.com/show_bug.cgi?id=901075] from POST to MODIFIED
> Security domain configuration doesn't allow empty or missing login-module-stack
> -------------------------------------------------------------------------------
>
> Key: WFLY-3696
> URL: https://issues.jboss.org/browse/WFLY-3696
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Security
> Affects Versions: 8.1.0.Final
> Reporter: Chao Wang
> Assignee: Chao Wang
>
> https://bugzilla.redhat.com/show_bug.cgi?id=901075 description:
> project_key: JBPAPP6
> Adding a security domain with JASPI authentication fails if there is no (or is empty) login-module-stack. It should be possible to add custom ServerAuthModule, which doesn't use JAAS login modules.
> {code:xml}
> <security-domain name="jmx-console" cache-type="default">
> <authentication-jaspi>
> <!-- FIXME: the not empty login-module-stack must be provided even it's not used -->
> <login-module-stack name="lm-stack">
> <login-module code="UsersRoles" flag="required"/>
> </login-module-stack>
> <auth-module code="org.jboss.example.CustomServerAuthModule" flag="required">
> <module-option name="option1" value="value1" />
> </auth-module>
> </authentication-jaspi>
> </security-domain>
> {code}
> It should be possible to remove here the login-module-stack element.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 11 months
[JBoss JIRA] (WFLY-2205) Undeployment prints null
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-2205?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-2205:
-----------------------------------------------
Kabir Khan <kkhan(a)redhat.com> changed the Status of [bug 1112433|https://bugzilla.redhat.com/show_bug.cgi?id=1112433] from POST to MODIFIED
> Undeployment prints null
> ------------------------
>
> Key: WFLY-2205
> URL: https://issues.jboss.org/browse/WFLY-2205
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Server
> Affects Versions: 8.0.0.Beta1
> Reporter: Jesper Pedersen
> Assignee: David Salter
> Fix For: 8.1.0.CR1, 8.1.0.Final
>
>
> The following is printed during a shutdown of an .ear
> {noformat}
> 11:21:52,260 INFO [org.jboss.as.server.deployment] (MSC service thread 1-8) JBAS015877: Stopped deployment null (runtime-name: msginflow1_mdb_msginflow_ejb.jar) in 16ms
> 11:21:52,260 INFO [org.jboss.as.server.deployment] (MSC service thread 1-11) JBAS015877: Stopped deployment null (runtime-name: msginflow_mdb_msginflow_ejb.jar) in 16ms
> 11:21:52,262 INFO [org.jboss.as.server.deployment] (MSC service thread 1-11) JBAS015877: Stopped deployment msginflow_mdb.ear (runtime-name: msginflow_mdb.ear) in 18ms
> 11:21:52,387 INFO [org.jboss.as.server] (DeploymentScanner-threads - 2) JBAS018558: Undeployed "msginflow_mdb.ear" (runtime-name: "msginflow_mdb.ear")
> {noformat}
> The 'null' part of the .jar undeployment doesn't look nice.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 11 months
[JBoss JIRA] (WFLY-3248) Removing ViewChangeListener* broke the extended clustering testsuite
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-3248?page=com.atlassian.jira.plugin.... ]
Paul Ferraro closed WFLY-3248.
------------------------------
Resolution: Out of Date
I've replaced the ViewChangeListener logic with TopologyChangeListener logic.
> Removing ViewChangeListener* broke the extended clustering testsuite
> --------------------------------------------------------------------
>
> Key: WFLY-3248
> URL: https://issues.jboss.org/browse/WFLY-3248
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Clustering, Test Suite
> Affects Versions: 8.0.0.Final
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
> Fix For: 9.0.0.Beta1
>
>
> What we did a while back, we made the sync-tcp the default configuration for running the clustering tests. However, we kept a extended testsuite with other combinations and other unimportant clustering tests.
> The async combinations partly relied on the ViewChangeListener* mechanisms. This was not detected earlier because this part of TS is not run by default on the CI.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 11 months
[JBoss JIRA] (WFLY-3248) Removing ViewChangeListener* broke the extended clustering testsuite
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-3248?page=com.atlassian.jira.plugin.... ]
Radoslav Husar commented on WFLY-3248:
--------------------------------------
The logic is back, needs to be reteested.
> Removing ViewChangeListener* broke the extended clustering testsuite
> --------------------------------------------------------------------
>
> Key: WFLY-3248
> URL: https://issues.jboss.org/browse/WFLY-3248
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Clustering, Test Suite
> Affects Versions: 8.0.0.Final
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
> Fix For: 9.0.0.Beta1
>
>
> What we did a while back, we made the sync-tcp the default configuration for running the clustering tests. However, we kept a extended testsuite with other combinations and other unimportant clustering tests.
> The async combinations partly relied on the ViewChangeListener* mechanisms. This was not detected earlier because this part of TS is not run by default on the CI.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 11 months
[JBoss JIRA] (WFLY-3248) Removing ViewChangeListener* broke the extended clustering testsuite
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-3248?page=com.atlassian.jira.plugin.... ]
Radoslav Husar updated WFLY-3248:
---------------------------------
Fix Version/s: 9.0.0.Beta1
> Removing ViewChangeListener* broke the extended clustering testsuite
> --------------------------------------------------------------------
>
> Key: WFLY-3248
> URL: https://issues.jboss.org/browse/WFLY-3248
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Clustering, Test Suite
> Affects Versions: 8.0.0.Final
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
> Fix For: 9.0.0.Beta1
>
>
> What we did a while back, we made the sync-tcp the default configuration for running the clustering tests. However, we kept a extended testsuite with other combinations and other unimportant clustering tests.
> The async combinations partly relied on the ViewChangeListener* mechanisms. This was not detected earlier because this part of TS is not run by default on the CI.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 11 months