1 2 Previous Next 16 Replies Latest reply on Nov 11, 2015 9:43 AM by wdfink

    ClusterNodeSelector not being called

    cstillwell

      We are running wildfly-8.0.0.Final and have 2 servers that are supposed to be clustered and a 3rd server that makes remote calls to an ejb deployed on the cluster.  We also have our own implementation of the org.jboss.ejb.client.ClusterNodeSelector interface and is specified in the jboss-ejb-client.xml.  Our ClusterNodeSelector gets initialized, but it is never called nor is the default RandomClusterNodeSelector.  I do see a log message from the LocalEJBReceiverPreferringDeploymentNodeSelector but it always selects the same node in the cluster.  This all worked under JBoss 7, but it looks like I must be missing something in our WildFly configuration.  We are using a slightly modified standalone-ha.xml which I have attached. 

       

      One thing I have noticed is that on JBoss 7 I used to see log messages like this:

      2014-01-14 16:24:30,180 INFO  [org.jboss.as.clustering] (Incoming-1,shared=udp) JBAS010225: New cluster view for partition ejb-atp-matching (id: 1, delta: 1, merge: false) : [ape-atpmatcher01/ejb-atp-matching, ape-atpmatcher02/ejb-atp-matching]

      2014-01-14 16:24:30,182 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-1,shared=udp) ISPN000094: Received new cluster view: [ape-atpmatcher01/ejb-atp-matching|1] [ape-atpmatcher01/ejb-atp-matching, ape-atpmatcher02/ejb-atp-matching]

       

      I don't see any "cluster view" type log messages now when we start wildfly, but I am seeing warning messages like this:

      2014-04-21 14:43:22,753 WARN  [org.jboss.as.ejb3] (MSC service thread 1-6) JBAS014267: The <clustering xmlns="urn:clustering:1.0"/> element will be ignored.

       

      I'm assuming this is coming from the jboss-ejb3.xml deployment descriptor which has not changed since JBoss 7 and just looks like this:

      <jboss xmlns="http://www.jboss.com/xml/ns/javaee"

             xmlns:jee="http://java.sun.com/xml/ns/javaee"

             xmlns:c="urn:clustering:1.0">

         <jee:assembly-descriptor>

            <c:clustering>

                <jee:ejb-name>*</jee:ejb-name>

                <c:clustered>true</c:clustered>

            </c:clustering>

         </jee:assembly-descriptor>

      </jboss>

       

      It looks like the cluster is not getting initialized correctly, but I'm haven't been able to spot what is wrong.

       

      Chris

        • 1. Re: ClusterNodeSelector not being called
          jaikiran

          What do your beans and jboss-ejb-client.xml look like?

          • 2. Re: Re: ClusterNodeSelector not being called
            cstillwell

            I've attached the full files, but essentially they are of the form:

            <jboss-ejb-client xmlns="urn:jboss:ejb-client:1.2">

                <client-context>

                    <ejb-receivers>

                        <remoting-ejb-receiver outbound-connection-ref="matching1-connection"/>

                    </ejb-receivers>

                    <clusters>

                        <cluster name="ejb-bttb-matching" max-allowed-connected-nodes="20" cluster-node-selector="com.xxi.framework.jbossaux.cluster.RoundRobinClusterNodeSelector"

                                 connect-timeout="5000" security-realm="PasswordRealm">

                            <connection-creation-options>

                                <property name="org.xnio.Options.SSL_ENABLED" value="false"/>

                                <property name="org.xnio.Options.SASL_POLICY_NOANONYMOUS" value="false"/>

                            </connection-creation-options>

                        </cluster>

                    </clusters>

                </client-context>

            </jboss-ejb-client>

             

            @Stateless

            @Remote(FareMixerModuleAPI.class)

            @TransactionManagement( TransactionManagementType.BEAN)

            public class DomesticFareMixerModuleSessionBean implements FareMixerModuleAPI {

             

                private static final long SLEEP_TIME_WAITING_FOR_DELEGATE = 1000L;

                private static final long MAXIMUM_WAIT_FOR_DELEGATE = 2L * 60L * 1000L; //two minutes

             

                @Resource(name="module.name")

                private String _moduleName;

             

                private FareMixerModuleAPI _delegate;

             

                protected Log getLog() {

                    return LogFactory.getLog( getClass() );

                }

             

                @PostConstruct

                public void init() {

                    try {

                        getLog().info( "init lookup " + _moduleName );

                        _delegate = (FareMixerModuleAPI) ModuleLookupService.getInstance().lookupModule( _moduleName );

                    } catch ( ModuleLookupException e ) {

                        e.printStackTrace();

                    }

                }

             

                private void checkDelegate() {

                    // when new cluster member comes up, requests try to get to interface methods before the jndi

                    // lookup completes causing a NullPointerException on the delegate.  Lets not let that happen

                    // by calling this method before attempting to do anything with the delegate.

                    // And lets make sure that it eventually times out!!!!!

                    if ( _delegate == null ) {

                        long timeout = System.currentTimeMillis() + MAXIMUM_WAIT_FOR_DELEGATE;

                        while ( _delegate == null ) {

                            if ( timeout > System.currentTimeMillis() ) {

                                try {

                                    Thread.sleep( SLEEP_TIME_WAITING_FOR_DELEGATE );

                                    init();

                                }

                                catch ( InterruptedException ignore ) {

                                    // something interrupted this thread and we are going to assume it was for a good reason!

                                    if ( _delegate == null ) {

                                        throw new RuntimeException( "Delegate does not exist yet!" );

                                    }

                                }

                            }

                            else {

                                init();

                                if ( _delegate == null ) {

                                    throw new RuntimeException( "Delegate does not exist yet!" );

                                }

                            }

                        }

                    }

                }

             

                public FareMixerModuleAPI getDelegate() {

                    checkDelegate();

                    return _delegate;

                }

             

                public List<MergedFare> getMergedFaresForRoutingValidation(SecurityCredential securityCredential, String originCityCode, String destinationCityCode, String carrierCode, AtpQueryContext atpQueryContext, RuleCategories ruleCategories) throws RuleMergeModuleException {

                    return getDelegate().getMergedFaresForRoutingValidation(securityCredential, originCityCode, destinationCityCode, carrierCode, atpQueryContext, ruleCategories);

                }

                // Other delegated methods

            }

             

             

            The beans and deployment descriptors have not changed since deploying to JBoss7.  Is there anything that should change?  Should I not be able to see some cluster initialization log messages regardless of what beans are being deployed?  That's the part that has me puzzled.

             

            Thanks,

            Chris

            • 3. Re: ClusterNodeSelector not being called
              wdfink

              Did you see that the cluster is build correct if you deploy the target EJB on both server?

              If you enable org.jboss.ejb.client TRACE on the client-server side you should see that after the first invocation the cluster view is send back and the ejb-client-view try to open the connections to both members.

              • 4. Re: Re: ClusterNodeSelector not being called
                cstillwell

                No, I don't see anything that indicates the cluster is getting built.  What I do see is the log message:

                2014-04-23 14:27:42,608 WARN  [org.jboss.as.ejb3] (MSC service thread 1-13) JBAS014267: The <clustering xmlns="urn:clustering:1.0"/> element will be ignored.

                 

                I am testing with 3 servers.  The clustered ejb is deployed on bttb206 and bttb207, and then a 3rd server has a client deployed that invokes the clustered ejb.  When the client server is coming up I see these log messages:

                2014-04-23 14:30:42,208 DEBUG [org.jboss.ejb.client.remoting.RemotingConnectionEJBReceiver] (default task-3) Channel Channel ID a19ddf65 (outbound) of Remoting connection 200ef2a3 to bttb206.alpha.farecompare.com/192.168.12.190:8080 opened for context EJBReceiverContext{clientContext=org.jboss.ejb.client.EJBClientContext@3f20834d, receiver=Remoting connection EJB receiver [connection=Remoting connection <e186387>,channel=jboss.ejb,nodename=bttb206]} Waiting for version handshake message from server

                2014-04-23 14:30:42,214 INFO  [org.jboss.ejb.client.remoting] (default task-4) EJBCLIENT000017: Received server version 2 and marshalling strategies [river]

                2014-04-23 14:30:42,226 INFO  [org.jboss.ejb.client.remoting] (MSC service thread 1-7) EJBCLIENT000013: Successful version handshake completed for receiver context EJBReceiverContext{clientContext=org.jboss.ejb.client.EJBClientContext@3f20834d, receiver=Remoting connection EJB receiver [connection=Remoting connection <e186387>,channel=jboss.ejb,nodename=bttb206]} on channel Channel ID a19ddf65 (outbound) of Remoting connection 200ef2a3 to bttb206.alpha.farecompare.com/192.168.12.190:8080

                2014-04-23 14:30:42,228 TRACE [org.jboss.ejb.client.remoting.ChannelAssociation] (default task-5) Received message with header 0x8

                2014-04-23 14:30:42,232 DEBUG [org.jboss.ejb.client.remoting.RemotingConnectionEJBReceiver] (default task-5) Received module availability report for 4 modules

                2014-04-23 14:30:42,233 DEBUG [org.jboss.ejb.client.remoting.RemotingConnectionEJBReceiver] (default task-5) Registering module EJBModuleIdentifier{appName='sandbox-helloworld-ear', moduleName='sandbox-helloworld-ear-1.0.0-SNAPSHOT', distinctName=''} availability for receiver context EJBReceiverContext{clientContext=org.jboss.ejb.client.EJBClientContext@3f20834d, receiver=Remoting connection EJB receiver [connection=Remoting connection <e186387>,channel=jboss.ejb,nodename=bttb206]}

                2014-04-23 14:30:42,233 DEBUG [org.jboss.ejb.client.remoting.RemotingConnectionEJBReceiver] (default task-5) Registering module EJBModuleIdentifier{appName='sandbox-helloworld-ear', moduleName='sandbox-helloworld-ejb', distinctName=''} availability for receiver context EJBReceiverContext{clientContext=org.jboss.ejb.client.EJBClientContext@3f20834d, receiver=Remoting connection EJB receiver [connection=Remoting connection <e186387>,channel=jboss.ejb,nodename=bttb206]}

                2014-04-23 14:30:42,234 DEBUG [org.jboss.ejb.client.remoting.RemotingConnectionEJBReceiver] (default task-5) Registering module EJBModuleIdentifier{appName='sandbox-helloworld-ear', moduleName='xxi-framework-module-service-jboss-ejb', distinctName=''} availability for receiver context EJBReceiverContext{clientContext=org.jboss.ejb.client.EJBClientContext@3f20834d, receiver=Remoting connection EJB receiver [connection=Remoting connection <e186387>,channel=jboss.ejb,nodename=bttb206]}

                2014-04-23 14:30:42,234 DEBUG [org.jboss.ejb.client.remoting.RemotingConnectionEJBReceiver] (default task-5) Registering module EJBModuleIdentifier{appName='', moduleName='jmx-console', distinctName=''} availability for receiver context EJBReceiverContext{clientContext=org.jboss.ejb.client.EJBClientContext@3f20834d, receiver=Remoting connection EJB receiver [connection=Remoting connection <e186387>,channel=jboss.ejb,nodename=bttb206]}

                2014-04-23 14:30:42,236 TRACE [org.jboss.ejb.client.remoting.ChannelAssociation] (default task-6) Received message with header 0xffffffff

                2014-04-23 14:30:42,237 DEBUG [org.jboss.ejb.client.remoting.ChannelAssociation] (default task-6) Unsupported message received with header 0xffffffff

                 

                So it is able to make the remote connection to the first server in the cluster.

                 

                When the client server invokes a method on the clustered ejb I see the following log messages:

                2014-04-23 14:53:56,823 INFO  [com.farecompare.sandbox.helloworldclient.impl.HelloWorldClientModule] (default task-47) HelloWorldAPI bean = Proxy for remote EJB StatelessEJBLocator{appName='sandbox-helloworld-ear', moduleName='sandbox-helloworld-ejb', distinctName='', beanName='HelloWorldModuleSessionBean', view='interface com.farecompare.sandbox.helloworld.api.HelloWorldAPI'}

                2014-04-23 14:53:56,824 DEBUG [org.jboss.ejb.client.EJBClientContext] (default task-47) org.jboss.as.ejb3.remote.LocalEJBReceiverPreferringDeploymentNodeSelector@17dae45e deployment node selector selected bttb206 node for appname=sandbox-helloworld-ear,modulename=sandbox-helloworld-ejb,distinctname=

                2014-04-23 14:53:56,825 TRACE [org.jboss.ejb.client.remoting.RemotingConnectionEJBReceiver] (default task-47) Hints are disabled. Ignoring any CompressionHint on methods being invoked on view interface com.farecompare.sandbox.helloworld.api.HelloWorldAPI

                2014-04-23 14:53:56,830 TRACE [org.jboss.ejb.client.remoting.ChannelAssociation] (default task-48) Received message with header 0x5

                2014-04-23 14:53:56,830 INFO  [com.farecompare.sandbox.helloworldclient.impl.HelloWorldClientModule] (default task-47) received: bttb206.alpha.farecompare.com: Hello there jb7

                 

                Subsequent invocations always pick the same server node. And  as I mentioned in the original post our implementation of the the ClusterNodeSelector interface is never called even though it is loaded when the ear is deployed.

                 

                Chris

                • 5. Re: ClusterNodeSelector not being called
                  wdfink

                  First you should check whether the server-side cluster is build. You should see a message if you deploy the application or start the server "No of cluster members X".

                   

                  The ClusterNodeSelector come only into play if a cluster is detected

                  • 6. Re: Re: ClusterNodeSelector not being called
                    cstillwell

                    Correct, as I mentioned in the first two posts I don't see anything that indicates that the cluster is getting built when I start the servers or deploy the application.  Are there any suggestions on how to determine why it is not getting built? As I mentioned I'm using standalone-ha.xml configurations.

                     

                    I see that the WARN message "The <clustering xmlns="urn:clustering:1.0"/> element will be ignored." is coming from org.jboss.as.ejb3.clustering.EJBBoundClusteringMetaDataParser and was part of the WFLY-2419 changes and I see references to Stateful EJBs.  We are using Staless EJBs.  Could that be part of the issue?

                     

                    Chris

                    • 7. Re: ClusterNodeSelector not being called
                      wdfink

                      Don't see a problem with the jboss-ejb3.xml.

                       

                      But you might try this one jboss-ejb3.xml from the quickstarts to check it, this QS works correct

                      • 8. Re: Re: ClusterNodeSelector not being called
                        cstillwell

                        I tried the jboss-ejb3.xml from the quickstarts with no different results.  I can run the same deployment on JBoss 7 and I see log messages that indicate the cluster is formed, but when I deploy on wildfly there are no log messages that indicate the cluster is formed.  I have attached a file where I grepped the log messages from all 3 servers for the word cluster.  You can see the cluster is created in JBoss 7, but not in wildfly.

                        • 9. Re: Re: Re: ClusterNodeSelector not being called
                          cstillwell

                          So I have figured out why the cluster was not getting created.  I appears that the cluster is only created if the cluster name is "ejb".  Since we use multiple clusters we change the names to something unique by modifying the standalone-ha.xml.  As an example:

                          <passivation-store name="infinispan" cache-container="ejb" max-size="10000"/>  changes to: <passivation-store name="infinispan" cache-container="ejb-helloworld" max-size="10000"/>

                          <cache-container name="ejb" aliases="sfsb" default-cache="dist" module="org.wildfly.clustering.ejb.infinispan"> changes to: <cache-container name="ejb-helloworld" aliases="sfsb" default-cache="dist" module="org.wildfly.clustering.ejb.infinispan">

                           

                          So when I changed back to just "ejb" I do see the cluster initialization messages:

                          2014-04-24 16:35:53,887 INFO  [stdout] (ServerService Thread Pool -- 58)

                          2014-04-24 16:35:53,887 INFO  [stdout] (ServerService Thread Pool -- 58) -------------------------------------------------------------------

                          2014-04-24 16:35:53,887 INFO  [stdout] (ServerService Thread Pool -- 58) GMS: address=bttb207/ejb, cluster=ejb, physical address=192.168.12.191:55200

                          2014-04-24 16:35:53,888 INFO  [stdout] (ServerService Thread Pool -- 58) -------------------------------------------------------------------

                          2014-04-24 16:35:54,075 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ServerService Thread Pool -- 58) ISPN000094: Received new cluster view: [bttb206/ejb|1] (2) [bttb206/ejb, bttb207/ejb]

                          2014-04-24 16:35:54,078 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ServerService Thread Pool -- 58) ISPN000079: Cache local address is bttb207/ejb, physical addresses are [192.168.12.191:55200]

                           

                          And from the client I see:

                          2014-04-24 16:46:40,649 DEBUG [org.jboss.ejb.client.ClusterContext] (ejb-client-cluster-node-connection-creation-4-thread-2) org.jboss.ejb.client.ClusterContext@1c8289d7 Added a new EJB receiver in cluster context ejb for node bttb207. Total nodes in cluster context = 2

                          2014-04-24 16:46:40,651 DEBUG [org.jboss.ejb.client.remoting.ClusterTopologyMessageHandler] (default task-14) Received a cluster node(s) addition message, for cluster named ejb with 2 nodes [ClusterNode{clusterName='ejb', nodeName='bttb206', clientMappings=[ClientMapping{sourceNetworkAddress=/0:0:0:0:0:0:0:0, sourceNetworkMaskBits=0, destinationAddress='192.168.12.190', destinationPort=8080}], resolvedDestination=[Destination address=192.168.12.190, destination port=8080]}, ClusterNode{clusterName='ejb', nodeName='bttb207', clientMappings=[ClientMapping{sourceNetworkAddress=/0:0:0:0:0:0:0:0, sourceNetworkMaskBits=0, destinationAddress='192.168.12.191', destinationPort=8080}], resolvedDestination=[Destination address=192.168.12.191, destination port=8080]}]

                           

                           

                          So the question is how do I change the cluster name to something other than just "ejb"?    Changing the name as I outlined above did work in JBoss 7.

                           

                          Chris

                          • 10. Re: ClusterNodeSelector not being called
                            jaikiran

                            I believe you have run into a bug. You should be allowed to change the name at the relevant places (like you did) and be able to use the clustering facility. Could you file a JIRA here Browse Projects - JBoss Issue Tracker with relevant details and if possible an application to reproduce this?

                            • 11. Re: ClusterNodeSelector not being called
                              cstillwell

                              Thanks, I created the issue [WFLY-3290] Cannot use a cluster name other than "ejb" - JBoss Issue Tracker and uploaded a zip file that contains the ear, source, and config files I used to test.  Let me know if there is anything I can do to help.

                               

                              Chris

                              • 12. Re: ClusterNodeSelector not being called
                                wdfink

                                Hi Chris,

                                 

                                jaikiran.jai_forums2005.yahoo.co.in is right, I've done a quick test with WF 8.0.0.Beta2.SNAPSHOT of 11-2013 it works correct (as former AS versions also). The 8.0.0.Final is not working.

                                A simple way to reproduce is the quickstart ejb-multi-server, app-one contains a clustered EAR file which can be dropped to standalone/deployments.

                                You see the warnign WARN  [org.jboss.as.ejb3] (MSC service thread 1-6) JBAS014267: The <clustering xmlns="urn:clustering:1.0"/> element will be ignored. at startup or deployment and the cluster will not start correct.

                                Please file the JIRA issue, let me know if I should attach the app-one.ear if needed. You don't need two instances, the first instance will fail if you change the cache-container name.

                                 

                                See that you create the JIRA at the same time

                                Thanks Chris for raise this issue!

                                • 13. Re: ClusterNodeSelector not being called
                                  bogdand

                                  Hi,

                                   

                                  I encountered a similar issue on JBoss 7.1.3. I'm running a clustered SLSB EJB on 2 local AS environments.The "ejb" cluster is created, but the configured cluster node selector is not invoked.Instead, the EJB client uses the deployment selector (the LocalEJBReceiverPreferringDeploymentNodeSelector). Tested also with a standalone client, with the same behaviour (deployment selector invoked instead of the cluster one).Below are the relevant listing for the server's log, and the configuration for the ejb-client.

                                  The bean is a simple @Clustered SLSB:

                                   

                                  @Clustered

                                  @Stateless(name = "HATestInvokerEJB")

                                  @Remote(HATestInvoker.class)

                                  public class HATestInvokerEJB implements HATestInvoker {

                                    private static final Logger LOG = Logger.getLogger(HATestInvokerEJB.class);

                                   

                                  @Override

                                    public void testInvocation(String source) {

                                    LOG.info(String.format("[HATestInvokerEJB invocation] SOURCE[%s] HOST[%s]" , source, ClusterTools.NODE_NAME));

                                    }

                                  }

                                   

                                  Am I missing something in the configuration?

                                   

                                   

                                  10/28-13:16:19,766 INFO  [org.jboss.as.clustering] (Incoming-4,null) JBAS010225: New cluster view for partition ejb (id: 1, delta: 1, merge: false) : [nodeA/ejb, nodeB/ejb]

                                  10/28-13:16:19,768 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-4,null) ISPN000094: Received new cluster view: [nodeA/ejb|1] [nodeA/ejb, nodeB/ejb]

                                  10/28-13:16:22,230 DEBUG [org.jboss.ejb.client.remoting.RemotingConnectionEJBReceiver] (Remoting "nodeA" task-10) Received module availability report for 6 modules

                                  10/28-13:16:22,256 DEBUG [org.jboss.ejb.client.remoting.RemotingConnectionEJBReceiver] (Remoting "nodeA" task-10) Registering module EJBModuleIdentifier{appName='', moduleName='ROOT', distinctName=''} availability for receiver context EJBReceiverContext{clientContext=org.jboss.ejb.client.EJBClientContext@1dbd4351, receiver=Remoting connection EJB receiver [connection=Remoting connection <58923439>,channel=jboss.ejb,nodename=nodeB]}

                                  10/28-13:16:22,281 DEBUG [org.jboss.ejb.client.remoting.RemotingConnectionEJBReceiver] (Remoting "nodeA" task-10) Registering module EJBModuleIdentifier{appName='luc-core-ear', moduleName='luc-oauth-server', distinctName=''} availability for receiver context EJBReceiverContext{clientContext=org.jboss.ejb.client.EJBClientContext@1dbd4351, receiver=Remoting connection EJB receiver [connection=Remoting connection <58923439>,channel=jboss.ejb,nodename=nodeB]}

                                  10/28-13:16:22,285 DEBUG [org.jboss.ejb.client.remoting.RemotingConnectionEJBReceiver] (Remoting "nodeA" task-10) Registering module EJBModuleIdentifier{appName='luc-core-ear', moduleName='luc-core-web', distinctName=''} availability for receiver context EJBReceiverContext{clientContext=org.jboss.ejb.client.EJBClientContext@1dbd4351, receiver=Remoting connection EJB receiver [connection=Remoting connection <58923439>,channel=jboss.ejb,nodename=nodeB]}

                                  10/28-13:16:22,286 DEBUG [org.jboss.ejb.client.remoting.RemotingConnectionEJBReceiver] (Remoting "nodeA" task-10) Registering module EJBModuleIdentifier{appName='luc-core-ear', moduleName='luc-connectivity-ejb', distinctName=''} availability for receiver context EJBReceiverContext{clientContext=org.jboss.ejb.client.EJBClientContext@1dbd4351, receiver=Remoting connection EJB receiver [connection=Remoting connection <58923439>,channel=jboss.ejb,nodename=nodeB]}

                                  10/28-13:16:22,297 DEBUG [org.jboss.ejb.client.remoting.RemotingConnectionEJBReceiver] (Remoting "nodeA" task-10) Registering module EJBModuleIdentifier{appName='luc-core-ear', moduleName='luc-core-ear', distinctName=''} availability for receiver context EJBReceiverContext{clientContext=org.jboss.ejb.client.EJBClientContext@1dbd4351, receiver=Remoting connection EJB receiver [connection=Remoting connection <58923439>,channel=jboss.ejb,nodename=nodeB]}

                                  10/28-13:16:22,346 DEBUG [org.jboss.ejb.client.remoting.RemotingConnectionEJBReceiver] (Remoting "nodeA" task-10) Registering module EJBModuleIdentifier{appName='luc-core-ear', moduleName='luc-webui', distinctName=''} availability for receiver context EJBReceiverContext{clientContext=org.jboss.ejb.client.EJBClientContext@1dbd4351, receiver=Remoting connection EJB receiver [connection=Remoting connection <58923439>,channel=jboss.ejb,nodename=nodeB]}

                                  10/28-13:16:22,348 DEBUG [org.jboss.ejb.client.ClusterContext] (ejb-client-cluster-node-connection-creation-4-thread-1) org.jboss.ejb.client.ClusterContext@7386ec69 Added a new EJB receiver in cluster context ejb for node nodeB. Total nodes in cluster context = 2

                                  10/28-13:16:22,396 TRACE [org.jboss.ejb.client.remoting.ChannelAssociation] (Remoting "nodeA" task-11) Received message with header 0x15

                                  10/28-13:16:22,524 DEBUG [org.jboss.ejb.client.remoting.ClusterNode] (Remoting "nodeA" task-11) Checking for a match of client address /127.0.0.1 with client mapping ClientMapping{sourceNetworkAddress=/0:0:0:0:0:0:0:0, sourceNetworkMaskBits=0, destinationAddress='192.168.5.83', destinationPort=4647}

                                  10/28-13:16:22,528 DEBUG [org.jboss.ejb.client.remoting.ClusterNode] (Remoting "nodeA" task-11) Client mapping ClientMapping{sourceNetworkAddress=/0:0:0:0:0:0:0:0, sourceNetworkMaskBits=0, destinationAddress='192.168.5.83', destinationPort=4647} matches client address /127.0.0.1

                                  10/28-13:16:22,531 DEBUG [org.jboss.ejb.client.remoting.ClusterNode] (Remoting "nodeA" task-11) Checking for a match of client address /127.0.0.1 with client mapping ClientMapping{sourceNetworkAddress=/0:0:0:0:0:0:0:0, sourceNetworkMaskBits=0, destinationAddress='192.168.5.83', destinationPort=4547}

                                  10/28-13:16:22,537 DEBUG [org.jboss.ejb.client.remoting.ClusterNode] (Remoting "nodeA" task-11) Client mapping ClientMapping{sourceNetworkAddress=/0:0:0:0:0:0:0:0, sourceNetworkMaskBits=0, destinationAddress='192.168.5.83', destinationPort=4547} matches client address /127.0.0.1

                                  10/28-13:16:22,538 DEBUG [org.jboss.ejb.client.remoting.ClusterTopologyMessageHandler] (Remoting "nodeA" task-11) Received a cluster node(s) addition message, for cluster named ejb with 2 nodes [ClusterNode{clusterName='ejb', nodeName='nodeB', clientMappings=[ClientMapping{sourceNetworkAddress=/0:0:0:0:0:0:0:0, sourceNetworkMaskBits=0, destinationAddress='192.168.5.83', destinationPort=4647}], resolvedDestination=[Destination address=192.168.5.83, destination port=4647]}, ClusterNode{clusterName='ejb', nodeName='nodeA', clientMappings=[ClientMapping{sourceNetworkAddress=/0:0:0:0:0:0:0:0, sourceNetworkMaskBits=0, destinationAddress='192.168.5.83', destinationPort=4547}], resolvedDestination=[Destination address=192.168.5.83, destination port=4547]}]

                                   

                                   

                                  <jboss-ejb-client xmlns="urn:jboss:ejb-client:1.2">

                                    <client-context>

                                    <clusters>

                                    <cluster name="ejb" security-realm="ejb-security-realm" username="cluster" cluster-node-selector="test.core.ha.TESTClusterNodeSelector">

                                    <connection-creation-options>

                                    <property name="org.xnio.Options.SSL_ENABLED" value="false" />

                                    <property name="org.xnio.Options.SASL_POLICY_NOANONYMOUS" value="false" />

                                    <property name="org.xnio.Options.SASL_POLICY_NOPLAINTEXT" value="false" />

                                    <property name="org.xnio.Options.SASL_DISALLOWED_MECHANISMS" value="JBOSS-LOCAL-USER" />

                                    </connection-creation-options>

                                    </cluster>

                                    </clusters>

                                    </client-context>

                                  </jboss-ejb-client>

                                   

                                  The jboss-ejb-client does not have a specific ejb-receiver as I'm using the cluster nodes both as "client(s)" and "server(s)".

                                   

                                  Thanks,

                                   

                                  Bogdan

                                  • 14. Re: ClusterNodeSelector not being called
                                    wdfink

                                    How do you lookup and invoke the EJB?

                                    The cluster node selector will take effect from the second invocation on.

                                     

                                    So this will not work as expected

                                    context.lookup("ejb:...../HATestInvokerEJB").invokeSomething()

                                    1 2 Previous Next