[ 
https://issues.apache.org/jira/browse/SOLR-5092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13724376#comment-13724376
 ] 

Isaac Hebsh edited comment on SOLR-5092 at 7/30/13 8:51 PM:
------------------------------------------------------------

Submitting initial patch.
As [~erickoerickson] suggested on mailing list, changes are only in solrj, so 
nothing should be changed in core.

This change should be very easy. Just move the single HTTP request into 
CompletionService :)

But, the most complicated thing in this patch, is to preserve the original 
exception handling. There are some exceptions which are considered as 
temporary, while other exceptions are fatal. Moreover, we want to preserve the 
zombie list maintenance as is.
                
      was (Author: isaachebsh):
    Submitting initial patch.
As Erick suggested on mailing list, changes are only in solrj, so nothing 
should be changed in core.

This change should be very easy. Just move the single HTTP request into 
CompletionService :)

But, the most complicated thing in this patch, is to preserve the original 
exception handling. There are some exceptions which are considered as 
temporary, while other exceptions are fatal. Moreover, we want to preserve the 
zombie list maintenance as is.
                  
> Send shard request to multiple replicas
> ---------------------------------------
>
>                 Key: SOLR-5092
>                 URL: https://issues.apache.org/jira/browse/SOLR-5092
>             Project: Solr
>          Issue Type: Improvement
>          Components: clients - java, SolrCloud
>    Affects Versions: 4.4
>            Reporter: Isaac Hebsh
>            Priority: Minor
>              Labels: distributed, performance, shard, solrcloud
>         Attachments: SOLR-5092.patch
>
>
> We have a case on a SolrCloud cluster. Queries takes too much QTime, due to a 
> randomly slow shard request. In a noticeable part of queries, the slowest 
> shard consumes more than 4 times qtime than the average.
> Of course, deep inspection of the performance factor should be made on the 
> specific environment.
> But, there is one more idea:
> If shard request will be sent to all of the replicas of each shard, the 
> probability of all the replicas of the same shard to be the slowest is very 
> small. Obviously cluster works harder, but on a (very) low qps, it might be 
> OK.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to