The queues are configured on both nodes. If one node goes down, the other will
pick them up and deploy the queues. I can only see the queues in the
jmx-console on one node at a time.
Is there a way to see what is bound to HAJNDI without doing the failover to
local jndi? I'd really just like
Still no success with this.
The wiki indicates that in jboss 4.x, that replication is handled via explicit
RPC calls. I can only assume that the replication is not happening correctly,
but I don't know when to start in attempting to determine what is at fault, any
thoughts?
View the origina
All nodes and they were configured the same.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3896083#3896083
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3896083
---
I have a 4.0.2 cluster with 2 nodes running on java 1.4.2_05 on solaris 5.7.
Things are working very well expect for this issue. I've written an external
client that attempts to list the queue's deployed on a server (just testing the
problem here). The problem is that I get inconsistent resul
Final update: the config was wrong on my second post. All is well with the
world now.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3893658#3893658
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3893658
It appears that the problem was that I didn't understand that my destinations
would only be deployed on one server in the cluster (I guess deploy-hasingleton
should have tipped me off). However, now that I understand that, it doesn't
explain why when one server goes down, the other doesn't pick
I discovered the problem on a fully configured pair of nodes, so I worked back
to a basic installation and see the same problem. Perhaps I've forgotten
something basic, but investigation throughout the day has lead no where.
Here's the current dilemma.
1. Download jboss-4.0.2
2. Install on
Our environment currently consists of 3 servers. 2 are clustered under the
Partition named MyPartitiation. The 3rd server is not clustered and is run as
default. A client attempts to get an InitialContext provided by the 3rd
server. If it is not there, for some reason it is connecting to th
