JNDI Lookup in JBoss Cluster| JBoss.org Content Archive (Read Only)

15. Re: JNDI Lookup in JBoss Cluster

wdfink Jun 30, 2011 1:58 AM (in response to nitin_jain)

AFAIK it dosn't matter whether you use JNDI od HA-JNDI if you get a valid proxy, the difference between HA- and normal JNDI is only that the InitialContext will be cluster aware in case of HA, that mean if the node goes down from which the InitialContext is the HA context know the other nodes and the next lookup reach a still existing server.

But if you already have a Remote-IF this is the proxy but the loadbalancing-failover is only available if the implemented bean was annotated with @Clustered. If not a proxy is created with a glue to exact the providing server.

16. Re: JNDI Lookup in JBoss Cluster

ronsen Jun 30, 2011 4:11 AM (in response to wdfink)

One thing I discevered with caching the object (correct me if im wrong), was that the application wasn't aware of new cluster nodes because theres no new lookup. Therefore I just catched the exception and forced to do a new lookup and recache the object. Even though in cases of a failover, if the "masternode" got killed/crashed/whatever, the application couldnt failover without the new lookup.

17. Re: JNDI Lookup in JBoss Cluster

wdfink Jun 30, 2011 8:16 AM (in response to ronsen)

The behaviour I observe is that every change (new or died node) is propagated to all clients.

One exception is if the last node goes down, e.g. complete shutdown of cluster, in this case it depends on the configuration of the client-invoker stack. AFAIK since 5.1 the stack is by default configured with the self-healing invoker.

Other exception occour seldom, it is because the client call hit a timeframe where the clusterview is not up-to-date and the node is not reachable.

In this case a manual retry (or the retry interceptor within the stack) might help.

18. Re: JNDI Lookup in JBoss Cluster

ronsen Jun 30, 2011 9:56 AM (in response to wdfink)

But from where if it doesnt do a new lookup? My cluster was aware of it, but my application not.

Lets say for example i have a cluster of 5 nodes wheres node 1 is the master node. I do the initial lookup in my application and cache the object.

When I now kill node 2-5, its no problem, but if I then add a new node6 to it and kill node 1 (Masternode), the application throws exceptions that the bean is missing. So I have to relookup the topology. Is that an error in my application or a typical behavior?

19. Re: JNDI Lookup in JBoss Cluster

nitin_jain Jul 3, 2011 11:34 PM (in response to wdfink)

I am sorry for not replying earlier. As you have suggested, I will update the beans with @Clustered annotation and verify the loadbalancing mechanism in a node failover scenario. Thank you for your support.

Regards,

Nitin

20. Re: JNDI Lookup in JBoss Cluster

nitin_jain Jul 5, 2011 7:56 AM (in response to wdfink)

Is there a possibility to avoid annotating every stateless EJB with @Clustered annotation and just making a single entry in a configuration file for all stateless session beans to be part of a cluster?

Regards,

Nitin

21. Re: JNDI Lookup in JBoss Cluster

wdfink Jul 5, 2011 9:45 AM (in response to nitin_jain)

You might add a deployment descriptor jboss.xml to the ejb.jar file with the elements for all beans.

This override the annotations.

22. Re: JNDI Lookup in JBoss Cluster

ronsen Jul 5, 2011 11:01 AM (in response to wdfink)

I read somewhere here about a solution with an interceptor if im not totally mistaken...? Should be found via the forum search.

23. Re: JNDI Lookup in JBoss Cluster

nitin_jain Jul 7, 2011 4:10 AM (in response to wdfink)

I used jboss.xml for the beans and have been successful. In case one AS node is down and the cached lookup references refer to it, by marking the bean Clustered, any successive lookups for the same bean are successful via second AS node.

Just for reference.

jboss.xml

<?xml version="1.0" encoding="UTF-8"?>
<jboss xmlns:xs="http://www.jboss.org/j2ee/schema"
 xs:schemaLocation="http://www.jboss.org/j2ee/schema jboss_5_0.xsd"
 version="5.0">
 <enterprise-beans>
  <session>
   <ejb-name>SampleEJBBean</ejb-name>
   <clustered>true</clustered>
   <cluster-config>
    <partition-name>MyCluster</partition-name>
    <load-balance-policy>org.jboss.ha.framework.interfaces.RandomRobin</load-balance-policy>
    </cluster-config>       
  </session>   
 </enterprise-beans>
</jboss>

Server log

2011-07-07 10:06:18,251 INFO  [org.jboss.ejb3.deployers.JBossASKernel] (main) Added bean(jboss.j2ee:ear=myapp.ear,jar=platform-services-ejbs.jar,name=NotificationProcessorBean,service=EJB3) to KernelDeployment of: platform-services-ejbs.jar
2011-07-07 10:06:18,251 INFO  [org.jboss.ejb3.deployers.JBossASKernel] (main) installing bean: jboss.j2ee:ear=myapp.ear,jar=platform-services-ejbs.jar,name=RequestDispatcherBean,service=EJB3
2011-07-07 10:06:18,251 INFO  [org.jboss.ejb3.deployers.JBossASKernel] (main)   with dependencies:
2011-07-07 10:06:18,251 INFO  [org.jboss.ejb3.deployers.JBossASKernel] (main)   and demands:
2011-07-07 10:06:18,251 INFO  [org.jboss.ejb3.deployers.JBossASKernel] (main)  jboss.ejb:service=EJBTimerService
2011-07-07 10:06:18,251 INFO  [org.jboss.ejb3.deployers.JBossASKernel] (main)  partition:partitionName=MyCluster
2011-07-07 10:06:18,251 INFO  [org.jboss.ejb3.deployers.JBossASKernel] (main)   and supplies:
2011-07-07 10:06:18,251 INFO  [org.jboss.ejb3.deployers.JBossASKernel] (main)  Class:com.myapp.platform.bs.SampleEJB
2011-07-07 10:06:18,251 INFO  [org.jboss.ejb3.deployers.JBossASKernel] (main)  jndi:myapp/SampleEJBBean/remote-com.myapp.platform.bs.SampleEJB
2011-07-07 10:06:18,251 INFO  [org.jboss.ejb3.deployers.JBossASKernel] (main)  jndi:myapp/SampleEJBBean/remote

As Ron has advised I have tried my luck using "ejb3-interceptors-aop.xml"; however I have not been successful. I have raised a query with JBoss AOP forum.

http://community.jboss.org/message/613833

Thank you for all the support.

Regards,

Nitin

24. Re: JNDI Lookup in JBoss Cluster

ronsen Jul 7, 2011 3:19 AM (in response to nitin_jain)

Thanks for sharing, perfect post.