lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hoss Man (JIRA)" <>
Subject [jira] [Created] (SOLR-13470) SolrException msg not always propogated to HttpClient (may be specific to SOLR-12999 ?)
Date Tue, 14 May 2019 21:23:00 GMT
Hoss Man created SOLR-13470:

             Summary: SolrException msg not always propogated to HttpClient (may be specific
to SOLR-12999 ?)
                 Key: SOLR-13470
             Project: Solr
          Issue Type: Bug
      Security Level: Public (Default Security Level. Issues are Public)
            Reporter: Hoss Man

While working on some test hardening for SOLR-12999, I discovered a strange bug related to
how SolrExceptions are propogated to HttpClients -- sometimes the message set by the server
side code when throwing the SolrException is set in the remote exception recieved by the HttpSolrClient,
other times it is not.

it's not clear to me if this is specific to the IndexFetcher related code (added in SOLR-12999)
that throw SolrExceptions when the index is in the middle of a full copy, or if it's a general
problem that can happen with any SolrException->HTTP->RemoteSolrException via HttpSolrClient
that only happens to manifests because of some quirk in the threading of TestReplicationHandlerDiskOverFlow.

(perhaps because we don't have a lot of HTTP level tests checking the exception message?)

At the moment, TestReplicationHandlerDiskOverFlow works around this issue by only comparing
the HTTP Staus code to ensure it's what's expected, w/o checking the getMessage() ... I'll
attach a patch that demonstrates how including a getMessage() assertion can (sporadically)
fail, and includes some nocommit debugging code i added to HttpSolrClient to try and make
sense of what's happening...

This message was sent by Atlassian JIRA

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message