AFAIK, unless you use a hardware load balancer, you will always have a single point of failure. But the goal is to minimize the work done by this server so that failures happen on other nodes I would say. So you could use ServiceMix as a front-end HTTP and let the clustering happen using JMS (JMS is automatically load balanced). Another way would be to use Apache HTTPD (http://httpd.apache.org/docs/2.2/mod/mod_proxy_balancer.html) in front of several ServiceMix running HTTP .
On 5/22/07, ywtsang <[EMAIL PROTECTED]> wrote:
We are trying to setup a cluster of servicemix and are successful in running the example of "cluster". We want to test the other setup of cluster of servicemix to see if the servicemix can provide transparent fail-over functionalitiy, but we met difficulties in setting up this and want to seek help here. We want to simulate a simple situation that a simple client, using "webservice", to make request to a cluster of servicemix to query for something. For the client, we should specify a single ip address of servicemix server for the client to connect to. Does that mean for the cluster of servicemix, we need to have a single servicemix instance acting as the entry point of the cluster, and let that entry point service to do all the "clustering" stuff (e.g. fail-over, load-balance, etc)? Is what I am describing correct? Is it possible that we do not have that single entry point of servicemix for the cluster? i.e. the client can automatically "connect" to the cluster by some means? My main concern is that we want the "cluster of servicemix" to be "100% available" with high scalablility using "clustering". What does the appropriate setup of this cluster of servicemix look like? I may be describing the problems with many unclear parts, it would be nice to point me out for further clarification of the problems. -- View this message in context: http://www.nabble.com/cluster-setup-tf3795182s12049.html#a10734374 Sent from the ServiceMix - User mailing list archive at Nabble.com.
-- Cheers, Guillaume Nodet ------------------------ Principal Engineer, IONA Blog: http://gnodet.blogspot.com/
