[
https://issues.apache.org/jira/browse/SOLR-6496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steve Davids updated SOLR-6496:
-------------------------------
Attachment: SOLR-6496.patch
Updated patch to use nano time. Still thinking of some potential tricks to
*not* use mocks, are there any tests out there that may screw with the jetty
server to make the socket connection arbitrarily long then somehow throw an
exception and verify that the next request isn't made?
On the mocking front I would do something like (note: redundant static
Mockito.* accessors only showed for demonstrative purposes):
{code}
@Test
public void testNoRetryOnTimeout() throws Exception {
LBHttpSolrServer testServer = Mockito.spy(new
LBHttpSolrServer("http://test1";, "http://test2";));
Mockito.doAnswer(new Answer<Exception>() {
@Override
public Exception answer(InvocationOnMock invocation) throws Throwable {
Thread.sleep(1);
return new SolrServerException("Mock error.");
}}).when(testServer).doRequest(Mockito.any(HttpSolrServer.class),
Mockito.any(Req.class), Mockito.any(Rsp.class), Mockito.anyBoolean(),
Mockito.anyBoolean(), Mockito.anyString());
testServer.query(SolrTestCaseJ4.params(CommonParams.Q, "test",
CommonParams.TIME_ALLOWED, "1"));
Mockito.verify(testServer,
Mockito.times(1)).doRequest(Mockito.any(HttpSolrServer.class),
Mockito.any(Req.class), Mockito.any(Rsp.class), Mockito.anyBoolean(),
Mockito.anyBoolean(), Mockito.anyString());
}
{code}
This test actually showed some strange behavior that there are multiple
implemented methods trying to do the same thing. See LBHttpSolrServer's:
# public Rsp request(Req req) throws SolrServerException, IOException
# public NamedList<Object> request(final SolrRequest request) throws
SolrServerException, IOException
So, depending on if you are using the CloudSolrServer or the
HttpShardHandlerFactory you are going to get different request behavior. We
should probably try to refactor this code to provide consistent behavior
perhaps in a different ticket.
> LBHttpSolrServer should stop server retries after the timeAllowed threshold
> is met
> ----------------------------------------------------------------------------------
>
> Key: SOLR-6496
> URL: https://issues.apache.org/jira/browse/SOLR-6496
> Project: Solr
> Issue Type: Bug
> Affects Versions: 4.9
> Reporter: Steve Davids
> Assignee: Anshum Gupta
> Priority: Critical
> Fix For: 5.0
>
> Attachments: SOLR-6496.patch, SOLR-6496.patch, SOLR-6496.patch
>
>
> The LBHttpSolrServer will continue to perform retries for each server it was
> given without honoring the timeAllowed request parameter. Once the threshold
> has been met, you should no longer perform retries and allow the exception to
> bubble up and allow the request to either error out or return partial results
> per the shards.tolerant request parameter.
> For a little more context on how this is can be extremely problematic please
> see the comment here:
> https://issues.apache.org/jira/browse/SOLR-5986?focusedCommentId=14100991&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14100991
> (#2)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
