-
1. Re: hotrod failover not load balance requirement
manik Nov 15, 2010 8:43 AM (in response to warjort)1 of 1 people found this helpfulInteresting thought. Exactly which scheme proves to scale better would depend on the nature of the data, and the access patterns involved in addition to volume and client count. One of the benefits of being able to have each client talk to each and every server endpoint is smart routing, since the consistent hash scheme in use can be shared with the client. This prevents an additional hop on the server cluster to retrieve data.
But I do see your concerns as well. Mircea will probably correct me, but I'm pretty sure configuring the client's intelligence level would do the trick.
-
2. Re: hotrod failover not load balance requirement
galder.zamarreno Dec 20, 2010 10:27 AM (in response to manik)1 of 1 people found this helpfulHmm, the problem is that intelligence level is not configurable by the Java clients, see http://docs.jboss.org/infinispan/4.1/apidocs/org/infinispan/client/hotrod/RemoteCacheManager.html
I think a FirstAvailable like load balance policy makes sense, particularly for the replication case. In the distributed one, as mentioned by Manik, it would need to be weight whether it's better to incur in potential hops, or maintain socket and file descriptors counts better: