[
https://issues.apache.org/jira/browse/SOLR-13470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man updated SOLR-13470:
----------------------------
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...
{panel}
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...
{panel}
was:
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...
Summary: SolrException msg not always propogated to HttpClient if
exception occurs during response writting (was: SolrException msg not always
propogated to HttpClient (may be specific to SOLR-12999 ?))
> SolrException msg not always propogated to HttpClient if exception occurs
> during response writting
> --------------------------------------------------------------------------------------------------
>
> Key: SOLR-13470
> URL: https://issues.apache.org/jira/browse/SOLR-13470
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Hoss Man
> Priority: Major
> Attachments: SOLR-13470.patch
>
>
> 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...
> {panel}
> 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...
> {panel}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
