Uploaded image for project: 'WildFly'
  1. WildFly
  2. WFLY-13132

Wrong/Incomplete CLUSTER_TOPOLOGY update sent to EJB client

XMLWordPrintable

    • Hide

      The attached playground.zip can be used to reproduce the issue. The archive contain the project that includes a Readme.txt, explaining how to use it...

      Show
      The attached playground.zip can be used to reproduce the issue. The archive contain the project that includes a Readme.txt , explaining how to use it...
    • Hide

      If old legacy remoting is required and the backend environment has to run a cluster, the only chance it to stick with the single protocol and configure the remote in the ejb3 subsystem to point to the remoting-connector

      Show
      If old legacy remoting is required and the backend environment has to run a cluster, the only chance it to stick with the single protocol and configure the remote in the ejb3 subsystem to point to the remoting-connector

      Issue

      General Client setup:

          Properties p = new Properties();
          p.put(Context.INITIAL_CONTEXT_FACTORY, "org.wildfly.naming.client.WildFlyInitialContextFactory");
          p.put(Context.PROVIDER_URL, {see below});
          p.put(Context.SECURITY_PRINCIPAL, USER);
          p.put(Context.SECURITY_CREDENTIALS, PWD);
          Context context = new InitialContext(p);
      

      Standard server configuration:

          <subsystem xmlns="urn:jboss:domain:ejb3:5.0">
              ...
              <remote connector-ref="http-remoting-connector" thread-pool-name="default">
                  <channel-creation-options>
                      <option name="READ_TIMEOUT" value="${prop.remoting-connector.read.timeout:20}" type="xnio"/>
                      <option name="MAX_OUTBOUND_MESSAGES" value="1234" type="remoting"/>
                  </channel-creation-options>
              </remote>
              ...
          </subsystem>
          ...
          <subsystem xmlns="urn:jboss:domain:remoting:4.0">
              <connector name="remoting-connector" socket-binding="remoting" security-realm="ApplicationRealm">
                  <properties>
                      <property name="SSL_ENABLED" value="false"/>
                  </properties>
              </connector>
              <http-connector name="http-remoting-connector" connector-ref="default" security-realm="ApplicationRealm"/>
          </subsystem>
      
      invocation from remote client to server with:
      Client side topology update always:
      DEBUG (XNIO-1 task-2) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY(15) message from node master:app-cluster-node0, registering cluster ejb to node master:app-cluster-node0
      DEBUG (XNIO-1 task-2) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY(15) message block from master:app-cluster-node0, registering block ::/0 to address 127.0.0.1:8080
      DEBUG (XNIO-1 task-2) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY(15) message from node master:app-cluster-node0, registering cluster ejb to node master:app-cluster-node1
      DEBUG (XNIO-1 task-2) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY(15) message block from master:app-cluster-node0, registering block ::/0 to address 127.0.0.1:8180
      DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received MODULE_AVAILABLE(8) message from node master:app-cluster-node0 for module playground-app/playground-app-web
      DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received MODULE_AVAILABLE(8) message from node master:app-cluster-node0 for module playground-app/playground-app-ejb
      

      Legacy server configuration:

          <subsystem xmlns="urn:jboss:domain:ejb3:5.0">
              ...
              <remote connector-ref="remoting-connector" thread-pool-name="default">
                  <channel-creation-options>
                      <option name="READ_TIMEOUT" value="${prop.remoting-connector.read.timeout:20}" type="xnio"/>
                      <option name="MAX_OUTBOUND_MESSAGES" value="1234" type="remoting"/>
                  </channel-creation-options>
              </remote>
              ...
          </subsystem>
          ...
          <subsystem xmlns="urn:jboss:domain:remoting:4.0">
              <connector name="remoting-connector" socket-binding="remoting" security-realm="ApplicationRealm">
                  <properties>
                      <property name="SSL_ENABLED" value="false"/>
                  </properties>
              </connector>
              <http-connector name="http-remoting-connector" connector-ref="default" security-realm="ApplicationRealm"/>
          </subsystem>
      
      invocation from remote client to server with:
      Client side topology update always:
      DEBUG (XNIO-1 task-2) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY(15) message from node master:app-cluster-node0, registering cluster ejb to node master:app-cluster-node0
      DEBUG (XNIO-1 task-2) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY(15) message block from master:app-cluster-node0, registering block ::/0 to address 127.0.0.1:4447
      DEBUG (XNIO-1 task-2) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY(15) message from node master:app-cluster-node0, registering cluster ejb to node master:app-cluster-node1
      DEBUG (XNIO-1 task-2) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY(15) message block from master:app-cluster-node0, registering block ::/0 to address 127.0.0.1:4547
      DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received MODULE_AVAILABLE(8) message from node master:app-cluster-node0 for module playground-app/playground-app-web
      DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received MODULE_AVAILABLE(8) message from node master:app-cluster-node0 for module playground-app/playground-app-ejb
      

      Conclusion

      Depending on what is configured as connector-ref in the remote of the ejb3 subsystem the CLUSTER_TOPOLOGY update is different. From a client perspective it would be expected that either the CLUSTER_TOPOLOGY update would only contain destinations that are applicable for the connector/protocol that has been used, or maybe even ALL available destinations, as the client could potentially run a mix of protocols between invocations...

              cfang@redhat.com Cheng Fang
              rhn-support-jbaesner Joerg Baesner
              Votes:
              0 Vote for this issue
              Watchers:
              7 Start watching this issue

                Created:
                Updated:
                Resolved: