You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Ishan Chattopadhyaya (JIRA)" <ji...@apache.org> on 2015/04/14 11:31:12 UTC
[jira] [Commented] (SOLR-6625) HttpClient callback in
HttpSolrServer
[ https://issues.apache.org/jira/browse/SOLR-6625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14493839#comment-14493839 ]
Ishan Chattopadhyaya commented on SOLR-6625:
--------------------------------------------
If I'm not missing something, I think we don't need to create our own callback framework in Solr and instead leverage the HttpRequestInterceptor / HttpResponseInterceptor. Please excuse my ignorance if this has been discussed above and I've missed it.
bq. The reason I didn't take that approach is that in some cases there's not enough context to figure out what you need to do.
The SolrRequest / SolrQueryRequest object (and whatever else we want) can be passed into the interceptor's context. And hence, any authentication info that needs to be propagated from original request to sub-requests (internode requests) can be part of the interceptor. Please see the attached patch (SOLR-6625_interceptor.patch). It contains a test method in the MiniSolrClusterTest which uses an request interceptor to capture the SolrRequest object.
> 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, SOLR-6625_r1654079.patch, SOLR-6625_r1654079.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