[jira] [Comment Edited] (SOLR-6625) HttpClient callback in HttpSolrServer
[
https://issues.apache.org/jira/browse/SOLR-6625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14650283#comment-14650283
]
Yonik Seeley edited comment on SOLR-6625 at 8/1/15 11:53 AM:
-
I haven't checked 5x yet, but I'm having issues on trunk:
{code}
/opt/code/lusolr_clean2/solr$ bin/solr start
Waiting to see Solr listening on port 8983 [|]
Started Solr server on port 8983 (pid=69801). Happy searching!
/opt/code/lusolr_clean2/solr$ bin/solr create -c demo
ERROR: create failed due to: A SolrHttpContext object must be passed in as
context. Context:
{http.request=org.apache.http.impl.client.RequestWrapper@4e1d422d,
http.request-config=[expectContinueEnabled=false, proxy=null,
localAddress=null, cookieSpec=null, redirectsEnabled=false,
relativeRedirectsAllowed=true, maxRedirects=50, circularRedirectsAllowed=false,
authenticationEnabled=true, targetPreferredAuthSchemes=null,
proxyPreferredAuthSchemes=null, connectionRequestTimeout=0, connectTimeout=0,
socketTimeout=0, decompressionEnabled=true],
http.auth.proxy-scope=state:UNCHALLENGED;, http.auth.credentials-provider={},
http.scheme-registry=org.apache.http.conn.scheme.SchemeRegistry@66480dd7,
http.cookie-spec=best-match, http.cookie-store=[],
http.connection=org.apache.http.impl.conn.ManagedClientConnectionImpl@52a86356,
http.auth.target-scope=state:UNCHALLENGED;,
http.cookiespec-registry=org.apache.http.cookie.CookieSpecRegistry@5ce81285,
http.target_host=http://localhost:8983, http.route={}-http://localhost:8983,
http.cookie-origin=[localhost:8983/solr/admin/info/system],
http.authscheme-registry=org.apache.http.auth.AuthSchemeRegistry@78c03f1f}
{code}
edit: now confirmed that I'm having this issue on 5x as well
was (Author: ysee...@gmail.com):
I haven't checked 5x yet, but I'm having issues on trunk:
{code}
/opt/code/lusolr_clean2/solr$ bin/solr start
Waiting to see Solr listening on port 8983 [|]
Started Solr server on port 8983 (pid=69801). Happy searching!
/opt/code/lusolr_clean2/solr$ bin/solr create -c demo
ERROR: create failed due to: A SolrHttpContext object must be passed in as
context. Context:
{http.request=org.apache.http.impl.client.RequestWrapper@4e1d422d,
http.request-config=[expectContinueEnabled=false, proxy=null,
localAddress=null, cookieSpec=null, redirectsEnabled=false,
relativeRedirectsAllowed=true, maxRedirects=50, circularRedirectsAllowed=false,
authenticationEnabled=true, targetPreferredAuthSchemes=null,
proxyPreferredAuthSchemes=null, connectionRequestTimeout=0, connectTimeout=0,
socketTimeout=0, decompressionEnabled=true],
http.auth.proxy-scope=state:UNCHALLENGED;, http.auth.credentials-provider={},
http.scheme-registry=org.apache.http.conn.scheme.SchemeRegistry@66480dd7,
http.cookie-spec=best-match, http.cookie-store=[],
http.connection=org.apache.http.impl.conn.ManagedClientConnectionImpl@52a86356,
http.auth.target-scope=state:UNCHALLENGED;,
http.cookiespec-registry=org.apache.http.cookie.CookieSpecRegistry@5ce81285,
http.target_host=http://localhost:8983, http.route={}-http://localhost:8983,
http.cookie-origin=[localhost:8983/solr/admin/info/system],
http.authscheme-registry=org.apache.http.auth.AuthSchemeRegistry@78c03f1f}
{code}
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: Noble Paul
Priority: Minor
Attachments: SOLR-6625-testfailure.log, SOLR-6625-testfix.patch,
SOLR-6625-testfix.patch, SOLR-6625-testfix.patch, SOLR-6625.patch,
SOLR-6625.patch, 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_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
[jira] [Comment Edited] (SOLR-6625) HttpClient callback in HttpSolrServer
[ https://issues.apache.org/jira/browse/SOLR-6625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14650294#comment-14650294 ] Ishan Chattopadhyaya edited comment on SOLR-6625 at 8/1/15 1:08 PM: Thanks for pointing out [~yo...@apache.org]. Here's a patch that should fix this. With no tests catching it, I overlooked; apologies. I'll run the full tests and also manual tests with the bin/solr scripts after this patch and report back if I see any issues. The httpClient for SDF was created as a class level member, before the init() was called. Edit: My setup was stuck downloading restlet; now that I've copied it from another server, I realize the issue remains. Looking into it... was (Author: ichattopadhyaya): Thanks for pointing out [~yo...@apache.org]. Here's a patch that should fix this. With no tests catching it, I overlooked; apologies. I'll run the full tests and also manual tests with the bin/solr scripts after this patch and report back if I see any issues. The httpClient for SDF was created as a class level member, before the init() was called. 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: Noble Paul Priority: Minor Attachments: SOLR-6625-testfailure.log, SOLR-6625-testfix.patch, SOLR-6625-testfix.patch, SOLR-6625-testfix.patch, SOLR-6625-testfix.patch, SOLR-6625.patch, SOLR-6625.patch, 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_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
[jira] [Comment Edited] (SOLR-6625) HttpClient callback in HttpSolrServer
[ https://issues.apache.org/jira/browse/SOLR-6625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14647887#comment-14647887 ] Ishan Chattopadhyaya edited comment on SOLR-6625 at 7/30/15 4:24 PM: - Attaching the patch to fix it. was (Author: ichattopadhyaya): [~sar...@syr.edu] Thanks for the pointer (and to the super fast sarowe jenkins). I had missed it. Attaching the patch to fix it. 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: Noble Paul Priority: Minor Attachments: SOLR-6625-testfix.patch, SOLR-6625.patch, SOLR-6625.patch, 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_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
[jira] [Comment Edited] (SOLR-6625) HttpClient callback in HttpSolrServer
[ https://issues.apache.org/jira/browse/SOLR-6625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14514839#comment-14514839 ] Ishan Chattopadhyaya edited comment on SOLR-6625 at 4/27/15 7:55 PM: - I think banning creation of HttpClients can't solve the problem of validating that each request made through them have the request object in the context. Each call via an HttpClient needs to have a different context (if any), so I don't think a wrapped up HttpClient can be used with the right context. bq. That way you don't have to make changes to the entire codebase Currently, these httpclient.execute() calls are, in the main source, in: # SolrDispatchFilter (remote query) # CUSC # HttpSolrClient # SolrCLI # JarRepository (latter two don't have a request object to send around) And then there are tons of them in the tests. I think, for the tests only, we can try what you suggest; i.e. an extended HttpClient that overrides the execute() method to pass in an empty context. was (Author: ichattopadhyaya): I think banning creation of HttpClients can't solve the problem of validating that each request made through them have the request object in the context. Each call via an HttpClient needs to have a different context (if any), so I don't think a wrapped up HttpClient can be used with the right context. bq. That way you don't have to make changes to the entire codebase Currently, these httpclient.execute() calls are, in the main source, in: SolrDispatchFilter (remote query) CUSC HttpSolrClient SolrCLI JarRepository (latter two don't have a request object to send around) And then there are tons of them in the tests. I think, for the tests only, we can try what you suggest; i.e. an extended HttpClient that overrides the execute() method to pass in an empty context. 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_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
[jira] [Comment Edited] (SOLR-6625) HttpClient callback in HttpSolrServer
[ https://issues.apache.org/jira/browse/SOLR-6625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14514847#comment-14514847 ] Ishan Chattopadhyaya edited comment on SOLR-6625 at 4/27/15 7:59 PM: - Here's an updated patch that does what I described above. [~gchanan], [~anshumg], [~noble.paul], Can you please review? was (Author: ichattopadhyaya): Here's an updated patch that does what I described above. [~gchanan], [~noble.paul], Can you please review? 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_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
[jira] [Comment Edited] (SOLR-6625) HttpClient callback in HttpSolrServer
[ https://issues.apache.org/jira/browse/SOLR-6625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14514839#comment-14514839 ] Ishan Chattopadhyaya edited comment on SOLR-6625 at 4/27/15 8:04 PM: - I think banning creation of HttpClients can't solve the problem of validating that each request made through them have the request object in the context (or something that explicitly means that there was no context available to be passed in, e.g. SolrHttpContext.EMPTY_CONTEXT in the patch). Each call via an HttpClient may need to have a different context (if any), so I don't think a wrapped up HttpClient can be used with the right context. bq. That way you don't have to make changes to the entire codebase Currently, these httpclient.execute() calls are, in the main source, in: # SolrDispatchFilter (remote query) # CUSC # HttpSolrClient # SolrCLI # JarRepository (latter two don't have a request object to send around) And then there are tons of them in the tests. I think, for the tests only, we can try what you suggest; i.e. an extended HttpClient that overrides the execute() method to pass in an empty context. was (Author: ichattopadhyaya): I think banning creation of HttpClients can't solve the problem of validating that each request made through them have the request object in the context. Each call via an HttpClient needs to have a different context (if any), so I don't think a wrapped up HttpClient can be used with the right context. bq. That way you don't have to make changes to the entire codebase Currently, these httpclient.execute() calls are, in the main source, in: # SolrDispatchFilter (remote query) # CUSC # HttpSolrClient # SolrCLI # JarRepository (latter two don't have a request object to send around) And then there are tons of them in the tests. I think, for the tests only, we can try what you suggest; i.e. an extended HttpClient that overrides the execute() method to pass in an empty context. 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_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
[jira] [Comment Edited] (SOLR-6625) HttpClient callback in HttpSolrServer
[ https://issues.apache.org/jira/browse/SOLR-6625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14505251#comment-14505251 ] Ishan Chattopadhyaya edited comment on SOLR-6625 at 4/21/15 4:51 PM: - Thanks for your review, [~gchanan] and [~anshumg]. I've added another patch, for your review. bq. 1. How is configuration handled? Is it the responsibility of the authentication layer to specify the HttpRequestInterceptor to use for all requests? My thought was that the authentication (SOLR-7274) and authorization (SOLR-7275) plugins would add their own interceptors, e.g. to pass in original request's user principal or ACL to a subrequest. The work of taking these things, i.e. user principal, ACL or whatever else is generated from authc/authz plugins, from original user request and adding it to SolrRequest/SolrQueryRequest could be dealt in another issue. bq. 2. There is some question about passing in SolrRequests (client) vs SolrQueryRequests (server). Presumably the authentication layer needs to operate on the client side (often the authentication requirements will be the same), but what are you supposed to do with the SolrQueryRequest? You've sort of hidden it by putting it in the context, but that seems fragile; we should have our own Context that makes clear what is available, but if you pull in SolrQueryRequest, then clients need access to server data structures, which isn't ideal. Perhaps the right thing to do is split up client vs server interceptors? In this new patch, I've created two context objects, SolrHttpContext (client, encapsulates SolrRequest) and SolrQueryRequestContext (server, encapsulates SolrQueryRequest). Based on which of the contexts is received, an interceptor can do its thing with these request objects. bq. 3. Can the request interceptor do everything our own callback can do? There are sample tests in the patch which add cookies, modify the URL, etc. It would be good to see those tests with the new implementation I've added similar tests to HttpSolrClient that were in the previous patches by you and [~steff1193]. bq. 4. How do you check that we actually pass the correct information to the interceptor? Per Steffensen described this above; what if someone adds another httpclient.execute call tomorrow and doesn't pass the SolrRequest object? We'll never know, so relying on the HttpRequestInterceptor didn't really help us (it automatically dispatches but doesn't check that it has all the info it needs to dispatch). It just limits us to an interface we don't control. We need some way of enforcing the property that every call to httpclient has the information we need. That's a good point, thanks for bringing it up, since I had missed it. One of the ways I could think of enforcing this was to add an interceptor that always checks if an httpclient.execute() call puts in a SolrHttpContext object, and throws an exception if not. Another way, we can forbid calls to httpclient.execute() without a SolrHttpContext context. In this patch, I've added done of these. was (Author: ichattopadhyaya): Thanks for your review, [~gchanan] and [~anshumg]. bq. 1. How is configuration handled? Is it the responsibility of the authentication layer to specify the HttpRequestInterceptor to use for all requests? My thought was that the authentication (SOLR-7274) and authorization (SOLR-7275) plugins would add their own interceptors, e.g. to pass in original request's user principal or ACL to a subrequest. The work of taking these things, i.e. user principal, ACL or whatever else is generated from authc/authz plugins, from original user request and adding it to SolrRequest/SolrQueryRequest could be dealt in another issue. bq. 2. There is some question about passing in SolrRequests (client) vs SolrQueryRequests (server). Presumably the authentication layer needs to operate on the client side (often the authentication requirements will be the same), but what are you supposed to do with the SolrQueryRequest? You've sort of hidden it by putting it in the context, but that seems fragile; we should have our own Context that makes clear what is available, but if you pull in SolrQueryRequest, then clients need access to server data structures, which isn't ideal. Perhaps the right thing to do is split up client vs server interceptors? In this new patch, I've created two context objects, SolrHttpContext (client, encapsulates SolrRequest) and SolrQueryRequestContext (server, encapsulates SolrQueryRequest). Based on which of the contexts is received, an interceptor can do its thing with these request objects. bq. 3. Can the request interceptor do everything our own callback can do? There are sample tests in the patch which add cookies, modify the URL, etc. It would be good to see those tests with the new implementation I've added similar
[jira] [Comment Edited] (SOLR-6625) HttpClient callback in HttpSolrServer
[ https://issues.apache.org/jira/browse/SOLR-6625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14289100#comment-14289100 ] Per Steffensen edited comment on SOLR-6625 at 1/23/15 11:38 AM: Updated patch to HEAD of branch_x5. Not a completely trivial task. Did not try to make any of the changes I suggested in previous comments. Just tried to make a 1-to-1 upgrade to HEAD of branch_5x. Please someone verify that I did not miss anything. was (Author: steff1193): Updated patch to HEAD of branch_x5. Not a completely trivial task. 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 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
[jira] [Comment Edited] (SOLR-6625) HttpClient callback in HttpSolrServer
[ https://issues.apache.org/jira/browse/SOLR-6625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14289383#comment-14289383 ] Per Steffensen edited comment on SOLR-6625 at 1/23/15 3:29 PM: --- New patch * Support for multiple callbacks (for nicer separation of concerns) - both for sys-prop-callbacks and for solr.xml-callbacks. preExecuteRequest lets callbacks build on contexts from each other - a logical consequence of introducing support for multiple callbacks * Solr-nodes now use both sol.xml-callbacks AND sys-prop-callbacks * SolrCLI.getJson attempts-variant now actually uses the callbacks given to it (via sys-prop) * Cleaning up some of the code-duplication. Separating more of the code related to this issue in HttpClientRequestCallbackUtil was (Author: steff1193): New patch * Support for multiple callbacks (for nicer separation of concerns) - both for sys-prop-callbacks and for solr.xml-callbacks. preExecuteRequest lets callbacks build on contexts from each other - a logical consequence of introducing support for multiple callbacks * Sold-nodes now use both sol.xml-callbacks AND sys-prop-callbacks * SolrCLI.getJson attempts-variant now actually uses the callbacks given to it (via system param) * Cleaning up some of the code-duplication. Separating more of the code related to this issue in HttpClientRequestCallbackUtil 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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-6625) HttpClient callback in HttpSolrServer
[ https://issues.apache.org/jira/browse/SOLR-6625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14238589#comment-14238589 ] Gregory Chanan edited comment on SOLR-6625 at 12/8/14 10:41 PM: Put up a review request: https://reviews.apache.org/r/28826 New patch allows the callback to throw an IOException; this allows the calling code to do something reasonable in error cases, i.e. if the callback makes an HttpRequest, the code in SolrDispatchFilter will print a good error message about it failing when trying to forward requests if it actually fails. The only part I'm hesitant about here is the code to generate a SolrRequest if one doesn't exist (in SolrCLI, SolrDipsatchFilter). This seems like a decent amount of complexity for little gain compared to just passing null. For my case, in the SolrDispatchFilter, I need to get some information from the SolrQueryRequest or HttpServletRequest (basically, the authenticated user that's available in the HttpServletRequest.getAttribute or SolrQueryRequest.getContext() or SolrQueryRequest.getParams()). But passing in either the SolrQueryRequest or HttpServletRequest doesn't seem like a good idea, because those are both really server-side data structures and the HttpClientRequestCallback is client side. We could have a different interface for the server-side stuff, but that doesn't seem less complex than generating a new SolrRequest. One alternative would be to pass a SolrParams or Map (i.e. SolrQueryRequest.getContext()) as another parameter, call it context, and make it clear from the documentation it is only useful on forwarded requests and can be ignored for clients. That would allow us to remove the code for HttpHead/HttpDelete support in SolrRequests. Anyway, that's my thinking right now, any feedback would be appreciated. was (Author: gchanan): Put up a review request: https://reviews.apache.org/r/28826 Need patch allows the callback to throw an IOException; this allows the calling code to do something reasonable in error cases, i.e. if the callback makes an HttpRequest, the code in SolrDispatchFilter will print a good error message about it failing when trying to forward requests if it actually fails. The only part I'm hesitant about here is the code to generate a SolrRequest if one doesn't exist (in SolrCLI, SolrDipsatchFilter). This seems like a decent amount of complexity for little gain compared to just passing null. For my case, in the SolrDispatchFilter, I need to get some information from the SolrQueryRequest or HttpServletRequest (basically, the authenticated user). But passing in either of those classes doesn't seem like a good idea, because those are both really server-side data structures and the HttpClientRequestCallback is client side. We could have a different interface for the server-side stuff, but that doesn't seem less complex than generating a new SolrRequest. One alternative would be to pass a SolrParams or Map (i.e. SolrQueryRequest.getContext()) as another parameter, call it context, and make it clear from the documentation it is only useful on forwarded requests and can be ignored for clients. That would allow us to remove the code for HttpHead/HttpDelete support in SolrRequests. Anyway, that's my thinking right now, any feedback would be appreciated. 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 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:
