JBossDeveloper

Check each beans jboss.xml file. Each bean can specify true but more so they can specify where by you can specify for each bean the home and remote load balancing policy, or your roll your own. That would be my first place to look. I think session is round robin and entity is first available, although you are accessing session bean.

We also experienced the same problems with redeployment. Undeployment and deployment works. Here is another one for you to try. Add a new clean node. You'll see that it wont get a copy of the jar file and thus will sit their useless. Just yesterday I tried another thing. I started up one node, ran my client, it connected fine. I then started up nodes 2 and 3. All 3 showed that they were talking, but the client would not start round-robin to the other two nodes. I am assuming that round-robin SHOULD work when you add a new node, even if a client already connected to one node. Each connection to the ejb layer brings back a new view of the clustered nodes... the smart proxy stuff that JBoss sends back so a client can load balance between nodes. So I am not sure if this is a bug, or expected behavior. For me, if you bring a new node on, and you are using round robin, it should immediately start working round robin with newly added nodes.

Also, keep in mind that the jndi.properties setting you use is only for "fail-over" upon connection. Each and every time you make any remote call, your client gets a new view of the clustered nodes. Here is another test. Bring up 3 or 4 nodes. Change your jndi.properties to only use one of the ip:1100 nodes. You'll see that it will still load balance even though you didn't specify all the nodes. The jndi.properties is merely for that first connection (or reconnection should the network go down in between). It ensures that if your client can't connect to the first jndi node, it will try the second, and so on. It is a good thing to have at least two there, but if you add new nodes to the cluster, you don't need to add those ip's to every client.

So as I see it, redeployment needs to be fixed, as well as deployment on new nodes, and if a node fails and comes up, or a node comes up while a client is already connected, the next request should present the new list of nodes to the client and the client should be able to round robin to all nodes. Not sure about fail-over at this point, such as http session state or ejb session state. Also not sure if their JMS is load balanced/failed over (if it even needs to be), I see JNDI is.

We have the same thing. Odd, I am not sure why but re-deployment across the farm doesn't seem to work, nor does bringing up a new empty node (or node with old app on it). Undeploying (deleting) the file from one node makes the rest delete and undeploy the app, then dropping it back in updates all of them again. But just dropping in a new version doesn't seem to hot redeploy across the cluster.

Hi,
I'm using JBoss 3.2.3 and also noticed a bug with hot redeployment.
It goes like this:
Working with a two-node cluster, deploy jar on ./farm of node1, it gets deployed on ./farm of node2.
If updating the jar on node1, redeployment occurs on both node1 and node2.
Buf if updating the jar on node2, redeployment is successfull only on node2, while on node1, it is only deleted.

I also have the same issue with hot-deployment. Works fine when the server is started but after bringing a node down and then back up , the deployment happens only on the node where it is touched.

Whats the sourceforge issue number in case something is already filed?

Thanks