7 Replies Latest reply on Mar 26, 2014 1:23 PM by Wolf-Dieter Fink

    Undertanding <cluster> in jboss-ejb-client.xml

    Juanjo Alvarez Newbie

      Hi all.

       

      I'd like to check the philosophy of the jboss-ejb-client.xml regarding cluster tag. (EAP 6.2)

       

       

      In this example:

       

      <jboss:jboss-ejb-client xmlns:jboss="urn:jboss:ejb-client:1.2" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

          <client-context>

              <ejb-receivers>

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

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

              </ejb-receivers>

              <clusters>

                  <cluster name="ejbCluster" />

              </clusters>

          </client-context>

      </jboss:jboss-ejb-client>

       

      My understanding is that It will handle the two receivers as a cluster, relying in the definition written in the server config files. Is this ok?

       

      Also I understand that the references to the outbound connections can change between environments and the same file could be shared in desa/preprod (same numbers of nodes).

       

      But what if the topology change (i.e. 2 nodes vs 4)?. Is it possible to have something like "cluster-ref". I mean the possibility of share this xml file in several environments?.

       

      thanks in advance

        • 1. Re: Undertanding <cluster> in jboss-ejb-client.xml
          Wolf-Dieter Fink Master

          Your understanding is not exactly correct.

           

          Each ejb-receiver will connect to a remote server. If this server is started as cluster it will send a cluster-view back after the first invocation which contains all the members.

          The cluster name must match the server configuration (it is the SFSB replication cache of infinispan  == "ejb").

          But consider you need to add more configuration to <cluster>

           

          If both receiver are of the same cluster you are save if one fails that all.

          If you add more servers to the cluster it will loadbalance and failover.

           

          If the nodes are not clustered you will be able to call EJB's on both, if you deploy the same application it will be some LB and failover but no cluster (i.e. no replication for SFSB's)

           

          You can find an example in the ejb-multi-server quickstart

           

          The configuration is subject to change as there is a request [EJBCLIENT-47] Simplify client configuration in case of clustered server

          • 2. Re: Undertanding <cluster> in jboss-ejb-client.xml
            Juanjo Alvarez Newbie

            Thanks. I really had no idea where the cluster name was pointing to. So refers to the infinispan cache of the target cluster, right?. So correcting and updating my config file finally looks like the others that i see around and in the multi server example .

             

             

            <jboss:jboss-ejb-client xmlns:jboss="urn:jboss:ejb-client:1.2" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

                <client-context>

                    <ejb-receivers>

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

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

                    </ejb-receivers>

                    <clusters>

                        <cluster name="ejb" username="ejbclient" security-realm="ejb-security-realm">

                            <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:jboss-ejb-client>

             

             

            But now I'm wondering why is a must to define the connection-creation-options and security-realm, etc. because EAP already know how to connect to the individuals.

            I suppose that this is what the request that you link is about, isn't it?

             

            The last thing is:

            Working with stateless EJB (SLSB); at this time is not possible to refer to a "cluster embebed definition", but we have to define a initial list of nodes, which probably will be the real composition, I'm not sure that if in this case the cluster section is really needed for us. There will be not dynamic nodes.

             

            Thanks in advance

            • 3. Re: Undertanding <cluster> in jboss-ejb-client.xml
              Wolf-Dieter Fink Master
              But now I'm wondering why is a must to define the connection-creation-options and security-realm, etc. because EAP already know how to connect to the individuals.

              I suppose that this is what the request that you link is about, isn't it?

               

              Yes, the intention is to get rid of 'any' cluster knowledge at the client side.

              The last thing is:

              Working with stateless EJB (SLSB); at this time is not possible to refer to a "cluster embebed definition", but we have to define a initial list of nodes, which probably will be the real composition, I'm not sure that if in this case the cluster section is really needed for us. There will be not dynamic nodes.

              I don't understand what you mean exact, if you have a clustered application you need to have the <clustered> element, otherwise you might see errors/warnigs in your log

              1 of 1 people found this helpful
              • 4. Re: Undertanding <cluster> in jboss-ejb-client.xml
                Juanjo Alvarez Newbie

                Wolf-Dieter Fink escribió:

                 

                But now I'm wondering why is a must to define the connection-creation-options and security-realm, etc. because EAP already know how to connect to the individuals.

                I suppose that this is what the request that you link is about, isn't it?

                 

                Yes, the intention is to get rid of 'any' cluster knowledge at the client side.

                 

                Ok, that would be nice.

                 

                 

                Wolf-Dieter Fink escribió:

                The last thing is:

                Working with stateless EJB (SLSB); at this time is not possible to refer to a "cluster embebed definition", but we have to define a initial list of nodes, which probably will be the real composition, I'm not sure that if in this case the cluster section is really needed for us. There will be not dynamic nodes.

                I don't understand what you mean exact, if you have a clustered application you need to have the <clustered> element, otherwise you might see errors/warnigs in your log

                 

                I mean something like:

                 

                Static Cluster SLSB (stateless) well known at deploy time = multiple node selector (no cluster section in the xml file)

                 

                in the EJB client side because there is no no replication needed. As yo point up here "it will be some LB and failover but no cluster". So may be we can skip the <cluster> section as LB and failover is enough at this stateless application. Sounds good?

                 

                Thanks in advance

                • 5. Re: Undertanding <cluster> in jboss-ejb-client.xml
                  Wolf-Dieter Fink Master

                  As I mentioned before if you have a cluster and did not add the <cluster> section you might have warnings in your logfile. The behaviour will be the same as you have a non-cluster application.

                  • 6. Re: Undertanding <cluster> in jboss-ejb-client.xml
                    Juanjo Alvarez Newbie

                    Thanks, Wolf-Dieter! My fault ...