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
org.apache.solr.common.SolrException:
org.apache.solr.client.solrj.SolrServerException:
java.net.ConnectException: Connection refused
at
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:256)
at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:1156)
from
http://localhost:8983/solr/select/?shards=10.0.16.181:8983,10.0.16.182:8983,10.0.16.183:8983,10.0.16.184:8983/solr&timeAllowed=1000&q=cancer%0D%0A&version=2.2&start=0&rows=10&indent=on
where .181 is down but .183->.184 are up.
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
