On Fri, Jun 13, 2014 at 12:11 PM, shikhar <[email protected]> wrote:
> I take this back, I understand the ES model better now. So although the > write-consistency-level check is only applied before the write is about > to be issued, with sync replication the client can only get an ack if it > succeded on the primary shard as well as all replicas (as per the same > cluster state as the check is performed on). In case it fails on some > replica(s), the operation would be retried (together with the write- > consistency-level check using a possibly-updated cluster state). > FWIW I'm really not sure anymore. TransportShardReplicationOperationAction where this stuff is happening has a bunch of logic in performReplicas(..) <https://github.com/elasticsearch/elasticsearch/blob/a06fd46a72193a387024b00e226241511a3851d0/src/main/java/org/elasticsearch/action/support/replication/TransportShardReplicationOperationAction.java#L557-L676> where it decides to take into account updated cluster state, and there seem to be exceptions for certain kinds of failures being tolerated. Seems like this would be so much more straightforward if a write were to be fanned-out and then block uptil max of timeout for checking that the requried number of replicas succeeded (with success on primary being required). -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/CAHWG4DMM_-0ySs3iCFkVKxL3DrNW2vT9daUAT9eWfXHpUrN2wQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
