[
https://issues.apache.org/jira/browse/SOLR-6625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14644732#comment-14644732
]
Anshum Gupta commented on SOLR-6625:
------------------------------------
Thanks for updating this Ishan but I wonder how this would work in case of a
custom component/handler where the restrictions imposed by checking for context
== null and forbidden APIs. It still wouldn't guarantee that the context is
used in all cases.
Also, I'm assuming you didn't run precommit as there was a use of .execute()
without the context in the code (mentioned below). If you did, we might be
missing something even more.
I just did a quick review and here's a bit of feedback:
* SolrQueryRequestContext.java can you remove all the Solr prefixes?
* HttpClientUtil.interceptors should be made final. Also it's not threadsafe.
* AbstractFullDistribZkTestBase.createNewSolrClient(int port) have
client.setSoTimeout instead of using the HttpClientUtil. Same for
TestReplicationHandlerBackup, and TestRestoreCore.
* BasicHttpSolrClientTest.changeRequestInterceptor has redundant declaration
for cookieName and cookieValue.
* HttpSolrCall.remoteQuery declares a context but doesn't use it in the
.execute() call.
* In SolrJettyTestBase.SolrContextHttpClient.execute methods you don't need to
throw ClientProtocolException as it has IOException in the throws spec already.
It also has a few unused imports.
* Unused imports have been introduced in SolrSchemalessExampleTest.
> 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_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]
