> > This will cancel all current queries with a > BlurException of type BACK_PRESSURE, the controller will automatically > retry the queries that were cancelled
This is a real nice feature and most handy in production too, as a protection gainst both intentional and un-intentional bad queries Since every update to the index via thrift mutates are committed and syncedto > HDFS, it possible to have other shards follow the lead shard (the writer) I think I am back to data-locality we previously discussed with your "lead shard" remark. It is now possible to pin data-nodes to a file during writes in hadoop. https://issues.apache.org/jira/browse/HDFS-2576 We can always pin a shard to 3 shard-servers [assuming shard-server is run in datanodes] and persist this ZK. Failures can be easily handled using this info The big advantage of this method is, even in case of failures short-circuit reads are always utilized. I know you are not a big-fan of it, but still is it worthwhile to pursue it? One downside to this approach is, cluster balance might get skewed and need to be properly handled in HDFS -- Ravi
