Details
-
Bug
-
Status: Open
-
Major
-
Resolution: Unresolved
-
None
-
None
-
None
-
None
Description
Because of SOLR-13471 it's possible that a client that is unmarshalling a javabin response may not "see" the `error metadat block in the response , and teh resulting RemoteSolrException won't have the correct exception message populated.
Original bug report...
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...
Attachments
Attachments
Issue Links
- is caused by
-
-
- Open
-
-
-
- Closed
-