[ 
https://issues.apache.org/jira/browse/SOLR-14160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Noble Paul updated SOLR-14160:
------------------------------
    Description: 
The list of replicas to which requests are sent are identified in a static 
fashion. There is no way to cleanly plugin alternate logic of identifying the 
replica list .

two major interfaces abstracted out are

{code:java}

import java.util.List;

public interface HeaderInterceptor {
 /**Names of headers to be read from the resposne
 */
 List<String> responseHeaders();

 /**The callback received after a response. This must be called with a 'null' 
if there was no such header
 *
 */
 void responseHeaderVal(String key, String val);

}
{code}

{code:java}

/**This interface gives urls one by one instead of giving a full list.
 * This also lets the implementation provide extra details as HTTP headers
 *
 */
public interface UrlProvider extends HeaderInterceptor {

 /**Give the base url for the next request to be fired. This is invoked the 
first time
 * a request needs to be fired, or subsequent after \{@link 
UrlProvider#toRetry()} returns true
 * @return null if no more nodes/cores are available
 */
 String nextBaseurl();

 /**The headers that must be added to the request.
 * @return return null or an empty map if nothing needs to added
 */
 Map<String, String > requestHeaders();

 /**Verify header value. This callback WILL be given if responseHeaderName is 
supplied, even if it is null
 * @return true if the request should be retried
 * Return the error message if there is something wrong with the response
 */
 boolean toRetry() throws SolrException;

}
{code}

  was:The list of replicas to which requests are sent are identified in a 
static fashion. There is no way to cleanly plugin alternate logic of 
identifying the replica list .


> Abstract out the replica identification interface for internode requests
> ------------------------------------------------------------------------
>
>                 Key: SOLR-14160
>                 URL: https://issues.apache.org/jira/browse/SOLR-14160
>             Project: Solr
>          Issue Type: Improvement
>      Security Level: Public(Default Security Level. Issues are Public) 
>            Reporter: Noble Paul
>            Priority: Major
>
> The list of replicas to which requests are sent are identified in a static 
> fashion. There is no way to cleanly plugin alternate logic of identifying the 
> replica list .
> two major interfaces abstracted out are
> {code:java}
> import java.util.List;
> public interface HeaderInterceptor {
>  /**Names of headers to be read from the resposne
>  */
>  List<String> responseHeaders();
>  /**The callback received after a response. This must be called with a 'null' 
> if there was no such header
>  *
>  */
>  void responseHeaderVal(String key, String val);
> }
> {code}
> {code:java}
> /**This interface gives urls one by one instead of giving a full list.
>  * This also lets the implementation provide extra details as HTTP headers
>  *
>  */
> public interface UrlProvider extends HeaderInterceptor {
>  /**Give the base url for the next request to be fired. This is invoked the 
> first time
>  * a request needs to be fired, or subsequent after \{@link 
> UrlProvider#toRetry()} returns true
>  * @return null if no more nodes/cores are available
>  */
>  String nextBaseurl();
>  /**The headers that must be added to the request.
>  * @return return null or an empty map if nothing needs to added
>  */
>  Map<String, String > requestHeaders();
>  /**Verify header value. This callback WILL be given if responseHeaderName is 
> supplied, even if it is null
>  * @return true if the request should be retried
>  * Return the error message if there is something wrong with the response
>  */
>  boolean toRetry() throws SolrException;
> }
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

Reply via email to