2 Replies Latest reply on Aug 1, 2007 5:52 PM by konkimalla

    Clustering and load balancing EJB 2.x

    itchy75

      Hi,

      I launch 2 Jboss servers (4.0.5) in cluster and I want to load balance the ejb calls between the two servers. I read the documentation and I created a cluster-service.xml and I modified my ejb configuration as follow :

      Part of cluster-service.xml

      <mbean code="org.jboss.ha.jndi.HANamingService"
       name="jboss:service=HAJNDI">
       <!-- We now inject the partition into the HAJNDI service instead
       of requiring that the partition name be passed -->
       <depends optional-attribute-name="ClusterPartition"
       proxy-type="attribute">jboss:service=${jboss.partition.name:DefaultPartition}</depends>
       <!-- Bind address of bootstrap and HA-JNDI RMI endpoints -->
       <attribute name="BindAddress">${jboss.bind.address}</attribute>
       <!-- RmiPort to be used by the HA-JNDI service
       once bound. 0 => auto. -->
       <attribute name="RmiPort">0</attribute>
       <!-- Port on which the HA-JNDI stub is made available -->
       <attribute name="Port">1100</attribute>
       <!-- Backlog to be used for client-server RMI
       invocations during JNDI queries -->
       <attribute name="Backlog">50</attribute>
       <!-- The thread pool service used to control the bootstrap and
       auto discovery lookups -->
       <depends optional-attribute-name="LookupPool"
       proxy-type="attribute">jboss.system:service=ThreadPool</depends>
       <!-- A flag to disable the auto discovery via multicast -->
       <attribute name="DiscoveryDisabled">false</attribute>
       <!-- Set the auto-discovery bootstrap multicast bind address. If not
       specified and a BindAddress is specified, the BindAddress will be used. -->
       <attribute name="AutoDiscoveryBindAddress">${jboss.bind.address}</attribute>
       <!-- Multicast Address and group port used for auto-discovery -->
       <attribute name="AutoDiscoveryAddress">${jboss.partition.udpGroup:230.0.0.4}</attribute>
       <attribute name="AutoDiscoveryGroup">1102</attribute>
       <!-- The TTL (time-to-live) for autodiscovery IP multicast packets -->
       <attribute name="AutoDiscoveryTTL">16</attribute>
       <!-- The load balancing policy for HA-JNDI -->
       <attribute name="LoadBalancePolicy">org.jboss.ha.framework.interfaces.RoundRobin</attribute>
      
       <!-- IP Address to which should be bound: the Port, the RmiPort and
       the AutoDiscovery multicast socket. -->
       <!-- Client socket factory to be used for client-server
       RMI invocations during JNDI queries -->
       <!--attribute name="ClientSocketFactory">custom</attribute-->
       <!-- Server socket factory to be used for client-server
       RMI invocations during JNDI queries -->
       <!--attribute name="ServerSocketFactory">custom</attribute-->
      </mbean>


      EJB configuration :

      <jboss>
       <enterprise-beans>
       <!-- Session -->
       <session>
       <ejb-name>myBean</ejb-name>
       <jndi-name>myBean</jndi-name>
       <clustered>True</clustered>
       <cluster-config>
       <partition-name>
       ${jboss.partition.name:DefaultPartition}
       </partition-name>
       <home-load-balance-policy>
       org.jboss.ha.framework.interfaces.RoundRobin
       </home-load-balance-policy>
       <bean-load-balance-policy>
       org.jboss.ha.framework.interfaces.RoundRobin
       </bean-load-balance-policy>
       </cluster-config>
       </session>
       </enterprise-beans>
      </jboss>


      Everything is good in the JMX console, the EJB is deployed in the two servers and available on both (check with DistributedReplicantManager->listContent()).

      The client application (another jboss server) is configured to lookup into the HAJNDI service of the first server.

      The problem is that the ejb calls are never balanced. Each time I call it, it runs on the first server. When I undeploy the ejb from the first server, it calls the ejb on the second server (so cluster HAJNDI works). Then I deploy again the ejb on the first server and it will always call the ejb on the first server.

      I have understood that HA JNDI algorithm is something like that :
      1. look for name in HAJNDI tree
      2. if not found, look in local jndi tree
      3. if not found, look in all cluster nodes

      Is that right ?

      So, where does load balancing on ejb is done ? In the EJB itself ?

      I have followed all the instructions in the guide, what's wrong ?

      Thanks for help.







        • 1. Re: Clustering and load balancing EJB 2.x
          konkimalla

          I am also doing the similar test but unable to make HAJNDI cluster work. I configured two nodes in the cluster and made sure the EJB has been deployed on two nodes using DistributedReplicantManager -> listContent(). I used the same configuration you have used; for ejb's I have not modified any deployment descriptor as I used @Clustered annotation as per the documentation. I am trying EJB3.0 in 4.2.0.GA

          I configured the standalone client application, separately running away from A/S but with in one of the nodes in cluster, using the following properties:

          props.put("java.naming.factory.initial", "org.jnp.interfaces.NamingContextFactory");
          props.put("java.naming.provider.url", "localhost:1100");
          props.put("java.naming.factory.url.pkgs", "org.jboss.naming:org.jnp.interfaces");

          As part of the test, when I shutdown the server, one servicing the client, the client also dead. So, as per the document I changed url at client to

          props.put("java.naming.provider.url", "<currentnodeip1>:1100,<another nodeip2>:1100"); Even then the same problem is appearing.

          The client could not even connect to the A/S when I changed the url to
          props.put("java.naming.provider.url", "<currentnodeip1>:1100");

          Can you please let me know where I am doing wrong? I can't really go further with out this one.

          Following is the exception when I shutdown the A/S in node1
          ---------------------------------------------------------------------------------
          java.lang.RuntimeException: cluster invocation failed, last exception was:
          at org.jboss.aspects.remoting.ClusterChooserInterceptor.invoke(ClusterCh
          ooserInterceptor.java:166)
          at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.
          java:101)
          at org.jboss.aspects.tx.ClientTxPropagationInterceptor.invoke(ClientTxPr
          opagationInterceptor.java:61)
          at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.
          java:101)
          at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityC
          lientInterceptor.java:53)
          at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.
          java:101)
          at org.jboss.ejb3.remoting.ClusteredIsLocalInterceptor.invoke(ClusteredI
          sLocalInterceptor.java:55)
          at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.
          java:101)
          at org.jboss.ejb3.stateful.StatefulClusteredProxy.invoke(StatefulCluster
          edProxy.java:108)
          at $Proxy2.add(Unknown Source)
          at com.clique.cmg.client.Main.main(Main.java:93)
          Caused by: org.jboss.aop.NotFoundInDispatcherException: Object with oid: jboss.j
          2ee:ear=TestJmxBean.ear,jar=TestJmxBean.jar,name=SfAddBean,service=EJB3 was not
          found in the Dispatcher
          at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:85)
          at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRem
          otingInvocationHandler.java:82)
          at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:734)
          at org.jboss.remoting.transport.socket.ServerThread.processInvocation(Se
          rverThread.java:560)
          at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.j
          ava:369)
          at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.jav
          a:165)
          at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientI
          nvoker.java:163)
          at org.jboss.remoting.Client.invoke(Client.java:1550)
          at org.jboss.remoting.Client.invoke(Client.java:530)
          at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemot
          eInterceptor.java:62)
          at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.
          java:101)
          at org.jboss.aspects.remoting.ClusterChooserInterceptor.invoke(ClusterCh
          ooserInterceptor.java:77)
          at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.
          java:101)
          at org.jboss.aspects.tx.ClientTxPropagationInterceptor.invoke(ClientTxPr
          opagationInterceptor.java:61)
          at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.
          java:101)
          at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityC
          lientInterceptor.java:53)
          at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.
          java:101)
          at org.jboss.ejb3.remoting.ClusteredIsLocalInterceptor.invoke(ClusteredI
          sLocalInterceptor.java:55)
          at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.
          java:101)
          at org.jboss.ejb3.stateful.StatefulClusteredProxy.invoke(StatefulCluster
          edProxy.java:108)
          at $Proxy2.add(Unknown Source)
          at com.clique.cmg.client.Main.main(Main.java:93)
          at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemot
          eInterceptor.java:74)
          at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.
          java:101)
          at org.jboss.aspects.remoting.ClusterChooserInterceptor.invoke(ClusterCh
          ooserInterceptor.java:77)
          ... 10 more

          • 2. Re: Clustering and load balancing EJB 2.x
            konkimalla

            Well, I solved my problem by starting the server using "run -c all -b ". At the client, I just configured to localhost:1100. I am not sure whether there is an xml entry to "Bind address for all JBoss services" with the node ip address.

            I successfully tested both fail over and loadbalancing, which can be easily tested by running several client applications that continuously access the ejb in a loop.