[ 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org