Confused about whether Real-time Gets must be sent to leader?

[Timothy Potter <th...@gmail.com>]

I'm seeing that RTG requests get routed to any active replica of the
shard hosting the doc requested by /get ... I was thinking only the
leader should handle that request since there's a brief window of time
where the latest update may not be on the replica (albeit usually very
brief) and the latest update is definitely on the leader. Am I
overthinking this since we've always maintained that Solr is
eventually consistent or ???

Cheers,
Tim

Re: Confused about whether Real-time Gets must be sent to leader?

[Yonik Seeley <ys...@gmail.com>]

On Thu, May 21, 2015 at 3:15 PM, Timothy Potter <th...@gmail.com> wrote:
> I'm seeing that RTG requests get routed to any active replica of the
> shard hosting the doc requested by /get ... I was thinking only the
> leader should handle that request since there's a brief window of time
> where the latest update may not be on the replica (albeit usually very
> brief) and the latest update is definitely on the leader.

There are different levels of "consistency".
You are guaranteed that after an update completes, a RTG will retrieve
that version of the update (or later).
The fact that a replica gets the update after the leader is not
material to this guarantee since the update has not yet completed.

What can happen is that if you are doing multiple RTG requests, you
can see a later version of a document, then see a previous version
(because you're hitting different shards).  This will only be an issue
in certain types of use-cases.  Optimistic concurrency, for example,
will *not* be bothered by this phenomenon.

In the past, we've talked about an option to route search requests to
the leader.  But really, any type of server affinity would work to
ensure a monotonic view of a document's history.  Off the top of my
head, I'm not really sure what types of apps require it, but I'd be
interested in hearing about them.

-Yonik