[jira] [Comment Edited] (SOLR-6625) HttpClient callback in HttpSolrServer

["Gregory Chanan (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/SOLR-6625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14238589#comment-14238589 ] 

Gregory Chanan edited comment on SOLR-6625 at 12/8/14 10:41 PM:
----------------------------------------------------------------

Put up a review request: https://reviews.apache.org/r/28826

New patch allows the callback to throw an IOException; this allows the calling code to do something reasonable in error cases, i.e. if the callback makes an HttpRequest, the code in SolrDispatchFilter will print a good error message about it failing when trying to forward requests if it actually fails.

The only part I'm hesitant about here is the code to generate a SolrRequest if one doesn't exist (in SolrCLI, SolrDipsatchFilter).  This seems like a decent amount of complexity for little gain compared to just passing null.  For my case, in the SolrDispatchFilter, I need to get some information from the SolrQueryRequest or HttpServletRequest (basically, the authenticated user that's available in the HttpServletRequest.getAttribute or SolrQueryRequest.getContext() or SolrQueryRequest.getParams()).  But passing in either the SolrQueryRequest or HttpServletRequest doesn't seem like a good idea, because those are both really server-side data structures and the HttpClientRequestCallback is client side.  We could have a different interface for the server-side stuff, but that doesn't seem less complex than generating a new SolrRequest.  One alternative would be to pass a SolrParams or Map (i.e. SolrQueryRequest.getContext()) as another parameter, call it context, and make it clear from the documentation it is only useful on forwarded requests and can be ignored for clients.  That would allow us to remove the code for HttpHead/HttpDelete support in SolrRequests.

Anyway, that's my thinking right now, any feedback would be appreciated.


was (Author: gchanan):
Put up a review request: https://reviews.apache.org/r/28826

Need patch allows the callback to throw an IOException; this allows the calling code to do something reasonable in error cases, i.e. if the callback makes an HttpRequest, the code in SolrDispatchFilter will print a good error message about it failing when trying to forward requests if it actually fails.

The only part I'm hesitant about here is the code to generate a SolrRequest if one doesn't exist (in SolrCLI, SolrDipsatchFilter).  This seems like a decent amount of complexity for little gain compared to just passing null.  For my case, in the SolrDispatchFilter, I need to get some information from the SolrQueryRequest or HttpServletRequest (basically, the authenticated user).  But passing in either of those classes doesn't seem like a good idea, because those are both really server-side data structures and the HttpClientRequestCallback is client side.  We could have a different interface for the server-side stuff, but that doesn't seem less complex than generating a new SolrRequest.  One alternative would be to pass a SolrParams or Map (i.e. SolrQueryRequest.getContext()) as another parameter, call it context, and make it clear from the documentation it is only useful on forwarded requests and can be ignored for clients.  That would allow us to remove the code for HttpHead/HttpDelete support in SolrRequests.

Anyway, that's my thinking right now, any feedback would be appreciated.

> HttpClient callback in HttpSolrServer
> -------------------------------------
>
>                 Key: SOLR-6625
>                 URL: https://issues.apache.org/jira/browse/SOLR-6625
>             Project: Solr
>          Issue Type: Improvement
>          Components: SolrJ
>            Reporter: Gregory Chanan
>            Assignee: Gregory Chanan
>            Priority: Minor
>         Attachments: SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch
>
>
> Some of our setups use Solr in a SPNego/kerberos setup (we've done this by adding our own filters to the web.xml).  We have an issue in that SPNego requires a negotiation step, but some HttpSolrServer requests are not repeatable, notably the PUT/POST requests.  So, what happens is, HttpSolrServer sends the requests, the server responds with a negotiation request, and the request fails because the request is not repeatable.  We've modified our code to send a repeatable request beforehand in these cases.
> It would be nicer if HttpSolrServer provided a pre/post callback when it was making an httpclient request.  This would allow administrators to make changes to the request for authentication purposes, and would allow users to make per-request changes to the httpclient calls (i.e. modify httpclient requestconfig to modify the timeout on a per-request basis).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org