[
https://issues.apache.org/jira/browse/SOLR-6625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ishan Chattopadhyaya updated SOLR-6625:
---------------------------------------
Attachment: SOLR-6625_interceptor.patch
Updated the patch, using the SolrRequestInfo from previous patch (thanks
[~noble.paul]). Now, instead of enforcing httpclient.execute(req, context),
added a SolrHttpClient (and within it SolrDefaultHttpClient and
SolrSystemDefaultHttpClient) that adds the request object from the
SolrRequestInfo into an overridden execute() method transparently.
[~noble.paul], in your previous patch (the SolrRequestInfo part), there are a
few exceptions/assertions logged:
{noformat}
6564 ERROR (searcherExecutor-17-thread-1-processing-x:collection1
snapshot.20150730163745674
//tmp//solr.handler.TestRestoreCore_21A69B2D533EDA15-001//tempDir-002
collection1) [ x:collection1] o.a.s.c.SolrCore Previous SolrRequestInfo was
not closed!
req=location=/tmp/solr.handler.TestRestoreCore_21A69B2D533EDA15-001/tempDir-002&command=restore
6564 ERROR (searcherExecutor-17-thread-1-processing-x:collection1
snapshot.20150730163745674
//tmp//solr.handler.TestRestoreCore_21A69B2D533EDA15-001//tempDir-002
collection1) [ x:collection1] o.a.s.c.SolrCore java.lang.AssertionError
at
org.apache.solr.request.SolrRequestInfo.setRequestInfo(SolrRequestInfo.java:58)
at
org.apache.solr.search.SolrIndexSearcher.warm(SolrIndexSearcher.java:2206)
at org.apache.solr.core.SolrCore$4.call(SolrCore.java:1817)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor$1.run(ExecutorUtil.java:198)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
{noformat}
Can you please have look at it? I've included it as is in this current patch,
and haven't looked into why this is happening, since the tests are passing
anyway.
> 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_SolrReqPropogate.patch, SOLR-6625_interceptor.patch,
> SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch,
> SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch,
> SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch,
> SOLR-6625_interceptor.patch, SOLR-6625_interceptor.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: [email protected]
For additional commands, e-mail: [email protected]
