lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hoss Man (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (SOLR-13470) SolrException msg not always propogated to HttpClient if exception occurs during response writting
Date Mon, 20 May 2019 18:00:00 GMT

     [ 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message