Isn't that OK as long as there is the option of allowing partial results if you
really want?
Keeping the logic simple has its benefits. Let client be responsible for query
resubmit strategy, and let load balancer (or shard manager) be responsible for
marking a node/shard as dead/inresponsive
The SolrCloud branch now has load balancing and fail-over amongst
shard replicas.
Partial results aren't available yet (if there are no up replicas for
a shard), but that is planned.
-Yonik
http://www.lucidimagination.com
On Tue, Feb 9, 2010 at 8:21 AM, Jan Høydahl / Cominvent
Katta has a very flexible and usable option for this even in the absence of
replicas.
The idea is that shards may report results, may report failure, may report
late, may never report or may have a transport layer issue. All kinds of
behavior should be handled.
What is done with katta is that
At this point, Distributed Search does not support any recovery if
when one or more shards fail. If any fail or time out, the whole query
fails.
On Sat, Feb 6, 2010 at 9:34 AM, mike anderson saidthero...@gmail.com wrote:
so if we received the response from shard2 before shard1, we would just
I have a need to favor documents from one shard over another when duplicates
occur. I found this code in the query component:
String prevShard = uniqueDoc.put(id, srsp.getShard());
if (prevShard != null) {
// duplicate detected
numFound--;
It seems like changing an element in a priority queue breaks the
invariants, and hence it's not doable with a priority queue and with
the current strategy of adding sub-responses as they are received.
One way to continue using a priority queue would be to add
sub-responses to the queue in the
It also seems like it should be possible to include the shard number in the
ordering of responses.
On Sat, Feb 6, 2010 at 8:33 AM, Yonik Seeley yo...@lucidimagination.comwrote:
It seems like changing an element in a priority queue breaks the
invariants, and hence it's not doable with a
so if we received the response from shard2 before shard1, we would just
queue it up and wait for the response to shard1.
This crossed my mind, but my concern was how to handle the case when shard1
never responds. Is this something I need to worry about?
-mike
On Sat, Feb 6, 2010 at 11:33 AM,
