Open Stack

So on review of a few code paths I see that the default search depth
(request_node_count) is `2 x <num_replicas>` which is smallish on single
replica systems.  There are some error limiting situations that might have
allowed the write to go deeper than the expected 2 nodes (primary, and one
handoff) which may not have been reflected in the proxy worker later
servicing the read (or the error limits may have aged out).

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.

If you're able to reliably reproduce the failure you might try increasing
your [app:proxy_server] request_node_count setting to a fixed value of
perhaps 3, and see if that works better for you.

-Clay

On Tue, May 24, 2016 at 5:14 PM, Clay Gerrard <clay.gerrard at gmail.com>
wrote:

>
>
> On Tue, May 24, 2016 at 4:56 PM, Shrinand Javadekar <
> shrinand at maginatics.com> wrote:
>
>> Sorry... I missed the first question
>>
>>
> no worries
>
>
>>
>> Yes, I was running on a single replica system.
>
>
> Ah!  That's great information.  I have *zero* experience with single
> replica systems.  The logs should be even *more* interesting.  FWIW I have
> no idea what your expectations should be for a single replica Swift
> cluster.  But if you can produce scenarios which reliably fail to meet your
> expectations quality bug reports are greatly appreciated!
>
> GL!
>
> -Clay
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20160524/2512422c/attachment.html>