<div dir="ltr"><div class="gmail_extra">At the risk of repeating myself:</div><div class="gmail_extra"><br></div><div class="gmail_extra">On Tue, May 24, 2016 at 5:30 PM, Clay Gerrard <span dir="ltr"><<a href="mailto:clay.gerrard@gmail.com" target="_blank">clay.gerrard@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>This inconsistency in search depth based on the per-worker error limiting may be something worth looking into generally - but it's probably mostly hidden on clusters that are going 3 or more nodes deep into handoffs in the default case.</div><div><br></div></div></blockquote><div><br></div><div>I just don't know how much of an issue it is for clusters where each device in the nodes iter is going to be on a separate node, probably in independent failure domais - and you've got to not only wiff multiple primaries but multiple handoffs too.  More over - you'd have to have *all* the replicas get past request_node_count or else one of the earlier replicas is going to service the read anyway without ever noticing the write that landed further out.  Or even if my theory about error limiting maybe allowing a PUT to go deeper than the request_node_count holds...</div><div><br></div><div>Obviously the data got on second handoff device somehow - it be interesting to see the transaction logs for the write that did that - but there's a lot of ifs in there and I'm not sure it's an issue except in the single replica single node case.  Still sorta interesting I guess...</div><div><br></div><div>-Clay</div><div><br></div></div></div>