Shawn Heisey created SOLR-4820:
----------------------------------
Summary: SolrJ - autodetect xml/javabin transport requirements
Key: SOLR-4820
URL: https://issues.apache.org/jira/browse/SOLR-4820
Project: Solr
Issue Type: New Feature
Components: clients - java
Affects Versions: 4.3
Reporter: Shawn Heisey
Assignee: Shawn Heisey
Priority: Minor
Fix For: 5.0, 4.4
The idea here is to support automatically detecting whether a target Solr
server will work with the binary request writer and/or response parser, then
use that information to pick the most efficient combination. See discussion on
SOLR-3038.
This issue concerns itself with 4.x clients, which as of 4.3.1, send XML
requests and ask for a binary response. SOLR-3038 aims to change the default
for requests to binary. That change would break default compatibility with 3.x
servers, requiring an explicit change to the XML request writer.
This issue is designed to fill the gap if/when the default request writer is
changed, to allow the server object to detect when it needs to change request
writers and response parsers.
I see four possible approaches:
1) Run detection when the object is created. IMHO, this is a bad idea.
2) Require an explicit call to an autodetect method.
3) Run the detection mechanism the first time a request is processed. If
adjustment is deemed necessary, adjust the transports and log a warning, and
possibly even include that warning in the response object.
4) Don't actually autodetect. The FIRST time a request fails, try downgrading
the transport. If the request writer isn't already XML, change it, log a
warning, and try the request again. Repeat for the response parser. If the
change works, keep going with the new settings. If not, undo the changes and
throw the usual exception, including a note saying that downgrading to XML was
attempted.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
