8 Replies Latest reply on Jan 24, 2014 12:27 AM by jmsjr

    @Asynchronous and @Remote and JNDI lookup in a cluster.... Does JBossAS7 have a preference for returning a proxy that is "local" to the node vs another node in the cluster ?

    jmsjr

      I have an un-managed POJO inside the container, that needs to do an @Asyncrhonous invocation on a @Remote SLSB obtained via programmatic JNDI lookup.

      Now assuming that I have 2 JBoss nodes in a cluster ... if I do a programmatic lookup, does JBossAS7 have a preference when returning a proxy ?

       

      e.g. Does it always return a proxy that is "local" to the node ? .... or does it round-robin from one-node to the next-node in the cluster ?

      Is there a way of controlling this behaviour ?

        • 1. Re: @Asynchronous and @Remote and JNDI lookup in a cluster.... Does JBossAS7 have a preference for returning a proxy that is "local" to the node vs another node in the cluster ?
          jaikiran

          Yes, the locally available EJB is given preference if it can handle the call. More details in this post https://community.jboss.org/message/793940#793940

          • 2. Re: @Asynchronous and @Remote and JNDI lookup in a cluster.... Does JBossAS7 have a preference for returning a proxy that is "local" to the node vs another node in the cluster ?
            jmsjr

            jaikiran pai wrote:

             

            Yes, the locally available EJB is given preference if it can handle the call. More details in this post https://community.jboss.org/message/793940#793940

             

            Thanks for pointing in the right direction. So it all boils down to an implementation of org.jboss.ejb.client.DeploymentNodeSelector

            I was also reading this:

             

            http://blog.akquinet.de/2012/11/09/load-balancing-and-failover-of-remote-ejb-clients-in-eap6-and-jboss-as7/

             

            Can I summarise my understanding here:


            1) When calling an EJB from a remote app ( e.g. running a Java thick client started via Java webstart, for example ), the ejb-client library uses jboss-ejb-client.properties

            2) When calling an EJB from a container BUT from non-managed POJO and via manual JNDI lookup, the ejb-client library uses META-INF/jboss-ejb-client.xml

            3) Does [2] also apply for EJB injected via the @EJB annotation ?

            4) When is the org.jboss.ejb.client.RandomNodeSelector used ( Hey, you wrote it ) ? The link I posted above suggests that it is automatically used in a clustered environment ( assuming also that the SLSB is annotated with @Clustered ):

             

            "By default, the EJB client library uses the RandomClusterNodeSelector implementation"

             

            ... but in your answer to my initial question in this thread, you mentioned that a "locally available EJB is given preference".

             

            To clarify, I am evaluating migrating to EAP 6.2.

            • 3. Re: @Asynchronous and @Remote and JNDI lookup in a cluster.... Does JBossAS7 have a preference for returning a proxy that is "local" to the node vs another node in the cluster ?
              wdfink

              Yes for 1. and 2. if the container is aware of the context it will prefer the local deployed EJB instances if found. In that case no DeploymentNodeSelector come into view.

              This is to prevent from remote access which is burden with network traffic and (maybe) additional serialization.

              This happen also for 3. but you need to have a jboss-ejb-client.xml with your application.

               

              The RandomNodeSelector implements DeploymentNodeSelector and this take only effect if there is no cluster available.

              You need to set a selector which implements ClusterNodeSelector, this take account if a cluster is available and the bean is marked as Clustered. After the first invocation (with DeploymentNodeSelector) a cluster-view is returned from the server and the client creates a ClusterContext with all cluster-members and the ClusterNodeSelector. From now on this context is used.

               

              You might have a look to jboss-as-quickstart at ejb-clients

              1 of 1 people found this helpful
              • 4. Re: @Asynchronous and @Remote and JNDI lookup in a cluster.... Does JBossAS7 have a preference for returning a proxy that is "local" to the node vs another node in the cluster ?
                jmsjr

                Wolf-Dieter Fink wrote:

                 

                Yes for 1. and 2. if the container is aware of the context it will prefer the local deployed EJB instances if found. In that case no DeploymentNodeSelector come into view.

                This is to prevent from remote access which is burden with network traffic and (maybe) additional serialization.

                This happen also for 3. but you need to have a jboss-ejb-client.xml with your application.

                 

                 

                Thanks for the clarification.

                 

                The RandomNodeSelector implements DeploymentNodeSelector and this take only effect if there is no cluster available.

                You need to set a selector which implements ClusterNodeSelector, this take account if a cluster is available and the bean is marked as Clustered. After the first invocation (with DeploymentNodeSelector) a cluster-view is returned from the server and the client creates a ClusterContext with all cluster-members and the ClusterNodeSelector. From now on this context is used.

                 

                You might have a look to jboss-as-quickstart at ejb-clients

                Sorry ... I mistyped my question [4]. I should have said RandomClusterNodeSelector instead of RandomNodeSelector

                 

                https://github.com/jbossas/jboss-ejb-client/blob/master/src/main/java/org/jboss/ejb/client/RandomClusterNodeSelector.java

                 

                4) When is the org.jboss.ejb.client.RandomClusterNodeSelector used ( Hey, you wrote it ) ? The link I posted above suggests that it is automatically used in a clustered environment ( assuming also that the SLSB is annotated with @Clustered ):

                 

                "By default, the EJB client library uses the RandomClusterNodeSelector implementation"

                 

                ... but in your answer to my initial question in this thread, you mentioned that a "locally available EJB is given preference".

                 

                 

                My question was if RandomClusterNodeSelector is used by automatically default.

                From what you said above, RandomClusterNodeSelector is used automatically, but only after the first invocation, if the EJB is marked as @Clustered

                In other words, I do not have to configure RandomClusterNodeSelector in jboss-ejb-client.properties or in META-INF/jboss-ejb-client.xml.

                • 5. Re: @Asynchronous and @Remote and JNDI lookup in a cluster.... Does JBossAS7 have a preference for returning a proxy that is "local" to the node vs another node in the cluster ?
                  wdfink

                  No, if you don't set any config for Selector (nevertheless whether cluster or not) the default one is use in both cases.

                  This is a Random implementation, but this should be good enough to have a fair balance. No need to override.

                  1 of 1 people found this helpful
                  • 6. Re: @Asynchronous and @Remote and JNDI lookup in a cluster.... Does JBossAS7 have a preference for returning a proxy that is "local" to the node vs another node in the cluster ?
                    jmsjr

                    Wolf-Dieter Fink wrote:

                     

                    No, if you don't set any config for Selector (nevertheless whether cluster or not) the default one is use in both cases.

                    This is a Random implementation, but this should be good enough to have a fair balance. No need to override.

                     

                    Thanks again ... although I find the answer confusing .. or maybe it's just the grammar or they way I read it ( Is it just me ??? ).

                     

                    In short, random implementation is used by default and there is no need to override.

                     

                    ... which contradicts what jaikiran said earlier when he said "locally available EJB is given preference" ??? .. meaning random selector is not used (?)

                    I guess I'll just have to experiment more and try to prove that it is indeed random.

                    What I am hoping for is an even distribution of EJB invocations across the cluster.

                    • 7. Re: @Asynchronous and @Remote and JNDI lookup in a cluster.... Does JBossAS7 have a preference for returning a proxy that is "local" to the node vs another node in the cluster ?
                      jaikiran

                      When I replied to your first post in this thread, I didn't pay attention to the "clustering" part of it. I thought you were talking of 2 non-clustered nodes and the same bean deployed on them. Consider my first answer in this thread, for that scenario. Now here's how clustering works:

                       

                      1) Please read Clustered EJBs - JBoss AS 7.1 - Project Documentation Editor for a quick overview of clustered EJBs in AS7

                      2) Now consider an example where you have the same Stateful clustered bean Foo deployed on 2 nodes which are part of a cluster. Let's call those nodes A and B.

                      3) Some client (for example, servlet) which resides on node A now looks up the Foo clustered SFSB. Now, since this is a Stateful bean, a lookup triggers a session creation which ultimately means that the EJB client API internally goes looking for a suitable node which can handle this EJB. Since by default on the server side a "local node prefering" DeploymentNodeSelector is setup (remember, the clustering semantics haven't yet come in picture since that information about the bean is only available after a successful lookup) and since node A has the Foo bean, the EJB client API selects the local node A as the target receiver for that bean.

                      4) At this point, the session has been created on node A and since all of this is in a clustering context, the session is "available" throughout the cluster (i.e. even on node B). The EJB client API, associates a hard affinity to that session to point to the cluster and a weak affinity to that specific node A (please read the link I referred earlier for details). To put in simple terms, the EJB client API associates certain information to the returned proxy so that subsequent requests on that proxy will give priority to node A for handling the invocation. If node A isn't available, then the priority is given to any other node in the cluster (to which the affinity was set). Now this is where the ClusterNodeSelector comes into picture (i.e. only if the original node on which the session was created isn't able to handle the request).

                       

                      If you look at the whole flow that's explained above, you'll realize that almost always the local node is preferred by default. Of course, that's the default and can be overridden using a different implementation of DeploymentNodeSelector (so that the initial selected node is something other than the local one).

                      • 8. Re: @Asynchronous and @Remote and JNDI lookup in a cluster.... Does JBossAS7 have a preference for returning a proxy that is "local" to the node vs another node in the cluster ?
                        jmsjr

                        jaikiran pai wrote:

                         

                        When I replied to your first post in this thread, I didn't pay attention to the "clustering" part of it. I thought you were talking of 2 non-clustered nodes and the same bean deployed on them. Consider my first answer in this thread, for that scenario. Now here's how clustering works:

                         

                        1) Please read Clustered EJBs - JBoss AS 7.1 - Project Documentation Editor for a quick overview of clustered EJBs in AS7

                        2) Now consider an example where you have the same Stateful clustered bean Foo deployed on 2 nodes which are part of a cluster. Let's call those nodes A and B.

                        3) Some client (for example, servlet) which resides on node A now looks up the Foo clustered SFSB. Now, since this is a Stateful bean, a lookup triggers a session creation which ultimately means that the EJB client API internally goes looking for a suitable node which can handle this EJB. Since by default on the server side a "local node prefering" DeploymentNodeSelector is setup (remember, the clustering semantics haven't yet come in picture since that information about the bean is only available after a successful lookup) and since node A has the Foo bean, the EJB client API selects the local node A as the target receiver for that bean.

                        4) At this point, the session has been created on node A and since all of this is in a clustering context, the session is "available" throughout the cluster (i.e. even on node B). The EJB client API, associates a hard affinity to that session to point to the cluster and a weak affinity to that specific node A (please read the link I referred earlier for details). To put in simple terms, the EJB client API associates certain information to the returned proxy so that subsequent requests on that proxy will give priority to node A for handling the invocation. If node A isn't available, then the priority is given to any other node in the cluster (to which the affinity was set). Now this is where the ClusterNodeSelector comes into picture (i.e. only if the original node on which the session was created isn't able to handle the request).

                         

                        If you look at the whole flow that's explained above, you'll realize that almost always the local node is preferred by default. Of course, that's the default and can be overridden using a different implementation of DeploymentNodeSelector (so that the initial selected node is something other than the local one).

                         

                        Thanks .. that makes perfect sense now.