[ 
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

Hi Anshum, thanks a lot for your review!

bq. 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.

I think even if there is custom code (within Solr in the form of plugins, or 
outside Solr which uses SolrJ/HttpSolrClient), it would be asserted that an 
httpclient, created using HttpClientUtil, should always use a context. Do you 
suggest we do something more for the case of custom code?

bq. 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.
Right, I hadn't even run the full tests, but caught (in my previous patch) the 
execute() thing in HttpSolrCall during the full tests. Now, I have run the 
precommit and it runs fine after fixing the execute() at a few places. :-)

bq.    SolrQueryRequestContext.java can you remove all the Solr prefixes?
Renamed to QueryRequestContext.

bq.    HttpClientUtil.interceptors should be made final. Also it's not 
threadsafe.
Made it final. Made it a synchronized list.

bq.    AbstractFullDistribZkTestBase.createNewSolrClient(int port) have 
client.setSoTimeout instead of using the HttpClientUtil. Same for 
TestReplicationHandlerBackup, and TestRestoreCore.
This is done because HttpSolrClient's httpClient was created outside of HSC, 
and hence the `client.setDefaultMaxConnectionsPerHost()` call would throw 
UnsupportedOperationException.
{noformat}
  public void setDefaultMaxConnectionsPerHost(int max) {
    if (internalClient) {
      HttpClientUtil.setMaxConnectionsPerHost(httpClient, max);
    } else {
      throw new UnsupportedOperationException(
          "Client was created outside of HttpSolrServer");
    }
  }
{noformat}

bq.    BasicHttpSolrClientTest.changeRequestInterceptor has redundant 
declaration for cookieName and cookieValue.
Removed now.

bq.    HttpSolrCall.remoteQuery declares a context but doesn't use it in the 
.execute() call.
This was the "minor fix" in the above comment/updated patch :-) Fixed already.

bq.    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.
Removed the ClientProtocolException.

bq.    Unused imports have been introduced in SolrSchemalessExampleTest.
Removed.


> 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_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

Reply via email to