On Aug 18, 2008, at 11:51 AM, Ian Connor wrote:
On Mon, Aug 18, 2008 at 9:31 AM, Ian Connor <[EMAIL PROTECTED]>
wrote:
I don't think this patch is working yet. If I take a shard out of
rotation (even just one out of four), I get an error:
org.apache.solr.client.solrj.SolrServerException:
java.net.ConnectException: Connection refused
It's my understanding that SOLR-502 is really only concerned with
queries timing out (i.e. they connect but take over N seconds to
return) If the connection gets refused then a non-solr java connection
exception is thrown. Something would have to get put in that
(optionally) catches connection errors and still builds the response
from the shards that did respond.
On Fri, Aug 15, 2008 at 1:23 PM, Brian Whitman <[EMAIL PROTECTED]
> wrote:
I was going to file a ticket like this:
"A SOLR-303 query with &shards=host1,host2,host3 when host3 is
down returns
an error. One of the advantages of a shard implementation is that
data can
be stored redundantly across different shards, either as direct
copies (e.g.
when host1 and host3 are snapshooter'd copies of each other) or
where there
is some "data RAID" that stripes indexes for redundancy."
But then I saw SOLR-502, which appears to be committed.
If I have the above scenario (host1,host2,host3 where host3 is not
up) and
set a timeAllowed, will I still get a 400 or will it come back with
"partial" results? If not, can we think of a way to get this to
work? It's
my understanding already that duplicate docIDs are merged in the
SOLR-303
response, so other than building in some "this host isn't working,
just move
on and report it" and of course the work to index redundantly, we
wouldn't
need anything to achieve a good redundant shard implementation.
B
--
Regards,
Ian Connor
--
Regards,
Ian Connor
--
http://variogr.am/
