Roundroubin loadbalancing

[mallsub]

Hi
I'm loadbalancing across two nodes with HAJNDI using JBOSS3.2.0. According to JBoss document each call is dispatched to a new node. But it is not working. Every call is going to first node. I'm attaching my JBoss.xml file.


<enterprise-beans>

<ejb-name>com.register.rci.api.RCIRequestFacade</ejb-name>
<jndi-name>com.register.rci.api.RCIRequestFacade</jndi-name>
True
<cluster-config>
<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>



</enterprise-beans>

[darranl]

Are you sure that both of your nodes have actually seen each other and formed a cluster?

[mallsub]

yes. They are in the farm and communicating to each other using javagroups.

[darranl]

Are you caching the reference to the home interface once you have perfomed the lookup?

Also how many times is a method on the bean called after you have called create but before you have called remove?

It might be easier to see what is happening if you could provide us with the client code you are using to access the beans.

Another posibility is that you might be connecting to the wrong port for JNDI, hopefully I have got this the right way round but for HA-JNDI you should be connecting to port 1100 and for normal JNDI you should be connecting to port 1099.

Alternatively you could not provide the address to connect to and let the client automatically find the cluster.

[buckman1]

Keep in mind that even with 3.2.2RC1 there are still some outstanding issues with clustering. Killing a node then restarting it doesn't seem to quite work right. We tested 3 nodes where by node 2 was disconnected, and the round robin would start only going to node 1, and not to node 3. When we started node 2 back up, the round robin then only went to node 1 and 3, and ignored node 2. It was very strange.

HOWEVER, we were testing on an app that was only spitting output in some cases, so as we lated found out, but have yet to verify due to not "standard" test app to watch/test clustering with, we might have just been not seeing any output on the various nodes that seemed to have random problems, due to our own code not spitting out any output to the console. I will indeed be testing this very soon and update the forum here and the mailing list with my findings. Hopefully it will help bill/sacha if there is indeed a problem, to fix it.

[slaboure]

yes, I am interested if you have a simple test case that exhibit this odd behaviour

[aillarramendi]

Hello I'm having the same problems as the ones mentioned.

I'm using 3.2.1 JBoss release.

I will attach the files for the EJB and client I use.

Thanks in advance for any help you could provide.

[aillarramendi]

I will have to split my message in several post or I could not send it all.

(First part)

I have defined a Partition named SMCOA.
Two JBoss instances in two distinct machines.
Cluster is launched correctly, both servers see each other, farm is running just ok (there are some odd

behaviours too concerning to this issue, but i could explain the later).
I deploy one Stateless SessionBean, using farming, in both servers.
The Session bean has it's own jboss.xml description as attached.

[aillarramendi]

(second part)

The EJB is deployed correctly and I don't see anything strange.

EJB's Home and proxy interfaces are as simple as they can be done (create method in home, provided method in

proxy).

The EJB has the next code (next step make all the EJB with eclipse/xdoclet) EJBSaludo.java as attached.

[aillarramendi]

(third part)

The only thing done is that when pedirSaludo method is invoked the EJB return a message saying where (in which

machine) is it running showing the ip address.

The client code I use for invoking EJB services is ClienteCluster.java as attached.

I give in execution the next properties to the client:

-Djava.naming.factory.initial=org.jnp.interfaces.NamingContextFactory

-Djava.naming.factory.url.pkgs=org.jboss.naming:org.jnp.interfaces

-Djnp.partitionName=SMCOA

I have tested giving URL providers or not giving them, and allways for 1100 port for each machine (I have

verified that HA-JNDI is running there, if I request a lookup for /HAPartition/SMCOA I receive a HAPartition

Implementation so I supose it's ok).

[aillarramendi]

(third part)

The only thing done is that when pedirSaludo method is invoked the EJB return a message saying where (in which

machine) is it running showing the ip address.

The client code I use for invoking EJB services is ClienteCluster.java as attached.

I give in execution the next properties to the client:

-Djava.naming.factory.initial=org.jnp.interfaces.NamingContextFactory

-Djava.naming.factory.url.pkgs=org.jboss.naming:org.jnp.interfaces

-Djnp.partitionName=SMCOA

I have tested giving URL providers or not giving them, and allways for 1100 port for each machine (I have

verified that HA-JNDI is running there, if I request a lookup for /HAPartition/SMCOA I receive a HAPartition

Implementation so I supose it's ok).

[aillarramendi]

(fourth part)

When I run it n number of times, the method is allways invoked in the same EJB in the same machine. The container does never invoke ejbRemove() neither, so perhaps some kind of caching is giving me allways the same reference? I tried to remove references (proxy and home), I know that it wont force the container to invoke ejbRemove (just trying).
If i shutdown one of the servers then, HA-JNDI (or whatever) resolves the new server's IP address and continues serving me, but if I restart again the server my client still continues being served by the last server attached.

[rob_dickinson42]

If you have autodiscovery disabled, you might see this bug:

http://sourceforge.net/tracker/index.php?func=detail&aid=779351&group_id=22866&atid=376685