1 of 1 people found this helpful
Our app also use not sharing internal objects (JBoss cache, persistence ...). Only a few JMS messages to signal configuration change.
Also we separate in different clusters because of load behaviour.
But all use the same database or backend systems.
- JVM (only if it is alive)
- GC logs of each instance
- JBoss logfile for application and other ERROR messages
So in my point of view more than one cluster is not a problem (if you know why and what you doing ;-) )
thanks. the reason why I am using clusters is because the code needed is minimal. I thought about using directly a jgroups channel. i.e, develop a bean to deploy in JBoss microcontainer. This bean would hava channel member. Maybe it could be good solution?
sounds not bad to me.
The reason for us is mostly the EJB-RMI loadbalancing and failover.
What do you want to share via the channel, it will help to make the picture clear.
I found that it is not a good idea to transport lots of information accross the nodes.
For our configuration only a signal is send and other members reload if it is received.
We use ATM a JMS topic for this.
It's simple to implement.
The first implementation via MBean was not transactional and produce some race-conditions ...
I dont want to share nothing. I only want to detect when the node's groups enters or leaves their groups....
is separating with a cluster.log not enough?
[org.jboss.ha.framework.server.DistributedReplicantManagerImpl.CLUSTERNAME] All Members : 1 ([192.168.200.16:5099])
org.jgroups and org.jboss.ha with a separate appender.
Well, not really. I need to perform actions bases on the group's changes so I need a component (channel or whatever) that detects theses changes. Then I need to register a callback from my application components to that monitor component. In this way my application can execute rules based on the node's status