: A quick question though: how would I write the shard logic to behave similar : to Java's Zookeeper-aware client? I'm able to get the hash/hex needed for each : shard from clusterstate.json, but how do I know which field to hash on?
The logic you're asking about is encapsulated in the DocRouter (which can be customized per collection). I'm not sure how the CloudSolrServer SolrJ client current deals with knowing which DocRouter to use, but for a non-Java langauge that can't directly load the same classes a great first step would be... * be conigurable solely with a list of ZK addresses * connect to ZK and per collection be continuously aware of: - the list of all live nodes as they go up/down - the list of leaders as shard elections happen * for queries, route to a random live node * for updates, route to any live leader the most important part being the first 2 bullets. the last bullet being an optimization over just sending to a random node because you increase the odds of hitting the correct leader for the doc in question regardless of which DocRouter is in use. -Hoss http://www.lucidworks.com/
