subject:"\[jira\] \[Commented\] \(SOLR\-6625\) HttpClient callback in HttpSolrServer"

[jira] [Commented] (SOLR-6625) HttpClient callback in HttpSolrServer

2015-08-01 Thread Yonik Seeley (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-6625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14650283#comment-14650283
 ] 

Yonik Seeley commented on SOLR-6625:


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 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] [Commented] (SOLR-6625) HttpClient callback in HttpSolrServer

2015-08-01 Thread Shalin Shekhar Mangar (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-6625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14650375#comment-14650375
 ] 

Shalin Shekhar Mangar commented on SOLR-6625:
-

bq. Here's a patch that should fix this. With no tests catching it, I 
overlooked; apologies.

Can we add a test to catch this stuff?

 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-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] [Commented] (SOLR-6625) HttpClient callback in HttpSolrServer

2015-07-30 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-6625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14647678#comment-14647678
 ] 

ASF subversion and git services commented on SOLR-6625:
---

Commit 1693432 from [~noble.paul] in branch 'dev/trunk'
[ https://svn.apache.org/r1693432 ]

SOLR-6625: Enable registering interceptors for the calls made using HttpClient 
and make the
  request object available at the interceptor 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: Noble Paul
Priority: Minor
 Attachments: 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] [Commented] (SOLR-6625) HttpClient callback in HttpSolrServer

2015-07-30 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-6625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14647704#comment-14647704
 ] 

ASF subversion and git services commented on SOLR-6625:
---

Commit 1693434 from [~noble.paul] in branch 'dev/trunk'
[ https://svn.apache.org/r1693434 ]

SOLR-6625: formatting fixed

 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.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] [Commented] (SOLR-6625) HttpClient callback in HttpSolrServer

2015-07-30 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-6625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14647819#comment-14647819
 ] 

ASF subversion and git services commented on SOLR-6625:
---

Commit 1693442 from [~noble.paul] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1693442 ]

SOLR-6625: Enable registering interceptors for the calls made using HttpClient 
and make the request object available at the interceptor 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: Noble Paul
Priority: Minor
 Attachments: 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] [Commented] (SOLR-6625) HttpClient callback in HttpSolrServer

2015-07-30 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-6625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14648171#comment-14648171
 ] 

ASF subversion and git services commented on SOLR-6625:
---

Commit 1693484 from [~anshumg] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1693484 ]

SOLR-6625: Set HttpClientImpl in SolrTestCaseJ4 for tests(merge from trunk)

 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.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] [Commented] (SOLR-6625) HttpClient callback in HttpSolrServer

2015-07-30 Thread Steve Rowe (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-6625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14648332#comment-14648332
 ] 

Steve Rowe commented on SOLR-6625:
--

I tried all of the seeds my Jenkins found today and none of them reproduce for 
me on OS X after Anshum's r1693498 commit.

Here are the ones for trunk:

{noformat}
ant test  -Dtestcase=TestCloudSolrClientConnections 
-Dtests.method=testCloudClientCanConnectAfterClusterComesUp 
-Dtests.seed=F852018ABA4ECDFF -Dtests.slow=true -Dtests.locale=nl 
-Dtests.timezone=Asia/Gaza -Dtests.asserts=true -Dtests.file.encoding=UTF-8
ant test  -Dtestcase=TestCloudSolrClientConnections 
-Dtests.method=testCloudClientCanConnectAfterClusterComesUp 
-Dtests.seed=36C935176479F04C -Dtests.slow=true -Dtests.locale=ar_YE 
-Dtests.timezone=Australia/Adelaide -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8
ant test  -Dtestcase=TestCloudSolrClientConnections 
-Dtests.method=testCloudClientCanConnectAfterClusterComesUp 
-Dtests.seed=D555CA223513ED3F -Dtests.slow=true -Dtests.locale=tr 
-Dtests.timezone=Antarctica/Syowa -Dtests.asserts=true 
-Dtests.file.encoding=US-ASCII
ant test  -Dtestcase=TestCloudSolrClientConnections 
-Dtests.method=testCloudClientCanConnectAfterClusterComesUp 
-Dtests.seed=C37B717A18417443 -Dtests.slow=true -Dtests.locale=bg_BG 
-Dtests.timezone=SystemV/HST10 -Dtests.asserts=true -Dtests.file.encoding=UTF-8
{noformat}

For branch_5x/Java8:

{noformat}
ant test  -Dtestcase=TestCloudSolrClientConnections 
-Dtests.method=testCloudClientCanConnectAfterClusterComesUp 
-Dtests.seed=FC64970124605306 -Dtests.slow=true -Dtests.locale=ar_LY 
-Dtests.timezone=Asia/Vientiane -Dtests.asserts=true -Dtests.file.encoding=UTF-8
ant test  -Dtestcase=TestCloudSolrClientConnections 
-Dtests.method=testCloudClientCanConnectAfterClusterComesUp 
-Dtests.seed=4A4BDF1F10B61D9 -Dtests.slow=true -Dtests.locale=hu_HU 
-Dtests.timezone=Pacific/Fiji -Dtests.asserts=true 
-Dtests.file.encoding=US-ASCII
ant test  -Dtestcase=TestCloudSolrClientConnections 
-Dtests.method=testCloudClientCanConnectAfterClusterComesUp 
-Dtests.seed=E4714ED097B4D0A7 -Dtests.slow=true -Dtests.locale= 
-Dtests.timezone=Etc/GMT-5 -Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1
ant test  -Dtestcase=TestCloudSolrClientConnections 
-Dtests.method=testCloudClientCanConnectAfterClusterComesUp 
-Dtests.seed=E0C2EF677FA5EC03 -Dtests.slow=true -Dtests.locale=it_CH 
-Dtests.timezone=America/New_York -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8
ant test  -Dtestcase=TestCloudSolrClientConnections 
-Dtests.method=testCloudClientCanConnectAfterClusterComesUp 
-Dtests.seed=7F8305E670B947FE -Dtests.slow=true -Dtests.locale=fr_CH 
-Dtests.timezone=Europe/Skopje -Dtests.asserts=true 
-Dtests.file.encoding=ISO-8859-1
ant test  -Dtestcase=TestCloudSolrClientConnections 
-Dtests.method=testCloudClientCanConnectAfterClusterComesUp 
-Dtests.seed=30D63D1BAD373514 -Dtests.slow=true -Dtests.locale=it 
-Dtests.timezone=America/Iqaluit -Dtests.asserts=true 
-Dtests.file.encoding=US-ASCII
{noformat}

And for branch_5x/Java7:

{noformat}
ant test  -Dtestcase=TestCloudSolrClientConnections 
-Dtests.method=testCloudClientCanConnectAfterClusterComesUp 
-Dtests.seed=98C4B653C6DE38C9 -Dtests.slow=true -Dtests.locale=it 
-Dtests.timezone=America/Havana -Dtests.asserts=true 
-Dtests.file.encoding=US-ASCII
ant test  -Dtestcase=TestCloudSolrClientConnections 
-Dtests.method=testCloudClientCanConnectAfterClusterComesUp 
-Dtests.seed=27A47BFC57FF783D -Dtests.slow=true -Dtests.locale=en_SG 
-Dtests.timezone=Pacific/Chatham -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8
{noformat} 

 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.

[jira] [Commented] (SOLR-6625) HttpClient callback in HttpSolrServer

2015-07-30 Thread Anshum Gupta (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-6625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14648172#comment-14648172
 ] 

Anshum Gupta commented on SOLR-6625:


I've committed the patch as that would be required anyways. It doesn't fix the 
NPE issue though.

 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.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] [Commented] (SOLR-6625) HttpClient callback in HttpSolrServer

2015-07-30 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-6625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14648168#comment-14648168
 ] 

ASF subversion and git services commented on SOLR-6625:
---

Commit 1693483 from [~anshumg] in branch 'dev/trunk'
[ https://svn.apache.org/r1693483 ]

SOLR-6625: Set HttpClientImpl in SolrTestCaseJ4 for tests

 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.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] [Commented] (SOLR-6625) HttpClient callback in HttpSolrServer

2015-07-30 Thread Anshum Gupta (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-6625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14648280#comment-14648280
 ] 

Anshum Gupta commented on SOLR-6625:


That looks like it should have been interfering and would solve the problem. 
I'll commit this.

 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 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] [Commented] (SOLR-6625) HttpClient callback in HttpSolrServer

2015-07-30 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-6625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14648288#comment-14648288
 ] 

ASF subversion and git services commented on SOLR-6625:
---

Commit 1693497 from [~anshumg] in branch 'dev/trunk'
[ https://svn.apache.org/r1693497 ]

SOLR-6625: Remove RequestInterceptor at the end of the test in 
BasicHttpSolrClientTest. It was interfering with other tests running the same 
JVM.

 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 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] [Commented] (SOLR-6625) HttpClient callback in HttpSolrServer

2015-07-30 Thread Anshum Gupta (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-6625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14648345#comment-14648345
 ] 

Anshum Gupta commented on SOLR-6625:


Thanks for confirming that Steve.

 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 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] [Commented] (SOLR-6625) HttpClient callback in HttpSolrServer

2015-07-30 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-6625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14648289#comment-14648289
 ] 

ASF subversion and git services commented on SOLR-6625:
---

Commit 1693498 from [~anshumg] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1693498 ]

SOLR-6625: Remove RequestInterceptor at the end of the test in 
BasicHttpSolrClientTest. It was interfering with other tests running the same 
JVM.(merge from trunk)

 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 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] [Commented] (SOLR-6625) HttpClient callback in HttpSolrServer

2015-07-30 Thread Anshum Gupta (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-6625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14648129#comment-14648129
 ] 

Anshum Gupta commented on SOLR-6625:


I think in LBHttpSolrClient.java (L326)
{code}
HttpSolrClient client = makeSolrClient(serverStr);
{code}

for some reason fails to instantiate and return the SolrClient. Could be 
because of systemDefaultHttpClientClass being not set for 
HttpClientUtil.createHttpClient to construct the client.

Noble/Ishan: can you take a look? If there are a lot more test failures @ 
Jenkins, I suggest it'd be better to Ignore the test while actively working on 
a fix.

 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.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] [Commented] (SOLR-6625) HttpClient callback in HttpSolrServer

2015-07-30 Thread Steve Rowe (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-6625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14647874#comment-14647874
 ] 

Steve Rowe commented on SOLR-6625:
--

I'm seeing reproducible {{TestCloudSolrClientConnections}} failures on trunk 
and branch_5x on my Jenkins after commits on this issue.  Here's the trunk one 
([http://jenkins.sarowe.net/job/Lucene-Solr-tests-trunk/1152/]):

{noformat}
   [junit4]   2 NOTE: reproduce with: ant test  
-Dtestcase=TestCloudSolrClientConnections 
-Dtests.method=testCloudClientCanConnectAfterClusterComesUp 
-Dtests.seed=C37B717A18417443 -Dtests.slow=true -Dtests.locale=bg_BG 
-Dtests.timezone=SystemV/HST10 -Dtests.asserts=true -Dtests.file.encoding=UTF-8
   [junit4] ERROR   7.12s J1 | 
TestCloudSolrClientConnections.testCloudClientCanConnectAfterClusterComesUp 
   [junit4] Throwable #1: org.apache.solr.common.SolrException: A 
SolrHttpContext object must be passed in as context. Context: 
{http.request=org.apache.http.impl.client.RequestWrapper@eddf10a, 
http.request-config=[expectContinueEnabled=false, proxy=null, 
localAddress=null, cookieSpec=null, redirectsEnabled=true, 
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@4861e7d6, 
http.cookie-spec=best-match, http.cookie-store=[], 
http.connection=org.apache.http.impl.conn.ManagedClientConnectionImpl@771b321c, 
http.auth.target-scope=state:UNCHALLENGED;, 
http.cookiespec-registry=org.apache.http.cookie.CookieSpecRegistry@1b78f4d2, 
http.target_host=https://127.0.0.1:51727, 
http.route={s}-https://127.0.0.1:51727, 
http.cookie-origin=[(secure)127.0.0.1:51727/solr/admin/collections], 
http.authscheme-registry=org.apache.http.auth.AuthSchemeRegistry@7acc1316}
   [junit4]at 
__randomizedtesting.SeedInfo.seed([C37B717A18417443:D897F2DA4A5D5186]:0)
   [junit4]at 
org.apache.solr.client.solrj.impl.HttpClientConfigurer$1.process(HttpClientConfigurer.java:92)
   [junit4]at 
org.apache.http.protocol.ImmutableHttpProcessor.process(ImmutableHttpProcessor.java:132)
   [junit4]at 
org.apache.http.protocol.HttpRequestExecutor.preProcess(HttpRequestExecutor.java:166)
   [junit4]at 
org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:485)
   [junit4]at 
org.apache.http.impl.client.AbstractHttpClient.doExecute(AbstractHttpClient.java:882)
   [junit4]at 
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82)
   [junit4]at 
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:107)
   [junit4]at 
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:55)
   [junit4]at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:465)
   [junit4]at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:234)
   [junit4]at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:226)
   [junit4]at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:376)
   [junit4]at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:328)
   [junit4]at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1086)
   [junit4]at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:856)
   [junit4]at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:799)
   [junit4]at 
org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1220)
   [junit4]at 
org.apache.solr.client.solrj.impl.TestCloudSolrClientConnections.testCloudClientCanConnectAfterClusterComesUp(TestCloudSolrClientConnections.java:57)
   [junit4]at java.lang.Thread.run(Thread.java:745)
{noformat}

and the branch_5x one 
([http://jenkins.sarowe.net/job/Lucene-Solr-tests-5.x-Java8/892/]):

{noformat}
   [junit4]   2 NOTE: reproduce with: ant test  
-Dtestcase=TestCloudSolrClientConnections 
-Dtests.method=testCloudClientCanConnectAfterClusterComesUp 
-Dtests.seed=FC64970124605306 -Dtests.slow=true -Dtests.locale=ar_LY 
-Dtests.timezone=Asia/Vientiane -Dtests.asserts=true -Dtests.file.encoding=UTF-8
   [junit4] ERROR   1.84s J1 | 
TestCloudSolrClientConnections.testCloudClientCanConnectAfterClusterComesUp 
   [junit4] Throwable #1:

[jira] [Commented] (SOLR-6625) HttpClient callback in HttpSolrServer

2015-07-30 Thread Noble Paul (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-6625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14647876#comment-14647876
 ] 

Noble Paul commented on SOLR-6625:
--

It was all passing when I tested it. Ishan can you please take a look?



 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.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] [Commented] (SOLR-6625) HttpClient callback in HttpSolrServer

2015-07-30 Thread Ishan Chattopadhyaya (JIRA)

[
https://issues.apache.org/jira/browse/SOLR-6625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14647878#comment-14647878
]

Ishan Chattopadhyaya commented on SOLR-6625:

Thanks for pointing it out, Steve.
Sure Noble. I'll take a look. Tests were passing for me at trunk. Will have
a look at the 5x branch.

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.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] [Commented] (SOLR-6625) HttpClient callback in HttpSolrServer

2015-07-30 Thread Anshum Gupta (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-6625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14648015#comment-14648015
 ] 

Anshum Gupta commented on SOLR-6625:


Thanks Ishan. I just reviewed the old commit to understand the new approach.
I'll commit this.

 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-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] [Commented] (SOLR-6625) HttpClient callback in HttpSolrServer

2015-07-30 Thread Ishan Chattopadhyaya (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-6625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14648128#comment-14648128
 ] 

Ishan Chattopadhyaya commented on SOLR-6625:


I've tried that seed and the test (after the last test fix patch) many times, 
and its passing for me always; i.e. I can't reproduce the NPE after applying 
the last patch. 

Anyway, looking into it a bit more.

 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.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] [Commented] (SOLR-6625) HttpClient callback in HttpSolrServer

2015-07-28 Thread Anshum Gupta (JIRA)

[
https://issues.apache.org/jira/browse/SOLR-6625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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

--
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] [Commented] (SOLR-6625) HttpClient callback in HttpSolrServer

2015-04-28 Thread Noble Paul (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-6625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14517326#comment-14517326
 ] 

Noble Paul commented on SOLR-6625:
--

Use a ThreadLocal to pass on the Context around and ensure that no one creates 
HttpClient directly

 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] [Commented] (SOLR-6625) HttpClient callback in HttpSolrServer

2015-04-27 Thread Ishan Chattopadhyaya (JIRA)

[
https://issues.apache.org/jira/browse/SOLR-6625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14514839#comment-14514839
]

Ishan Chattopadhyaya commented on SOLR-6625:

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
-

--
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] [Commented] (SOLR-6625) HttpClient callback in HttpSolrServer

2015-04-22 Thread Noble Paul (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-6625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14506964#comment-14506964
 ] 

Noble Paul commented on SOLR-6625:
--

I think there are simpler ways to achieve this than banning the execute() 
method altogether.
We can ban the creating of new HttpClient object and mandate the use of 
UpdateShardHandler.getHttpClient() . That can be arapped to set the right 
context. That way you don't have to make changes to the entire codebase

 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] [Commented] (SOLR-6625) HttpClient callback in HttpSolrServer

2015-04-17 Thread Anshum Gupta (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-6625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14499977#comment-14499977
 ] 

Anshum Gupta commented on SOLR-6625:


Thanks for the patch Ishan. I like the simplified approach but among other 
things that Greg pointed out, I'm most concerned about enforcing that every 
call to httpclient has the complete and correct information.

 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_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] [Commented] (SOLR-6625) HttpClient callback in HttpSolrServer

2015-04-14 Thread Ishan Chattopadhyaya (JIRA)

[
https://issues.apache.org/jira/browse/SOLR-6625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14493839#comment-14493839
]

Ishan Chattopadhyaya commented on SOLR-6625:

If I'm not missing something, I think we don't need to create our own callback
framework in Solr and instead leverage the HttpRequestInterceptor /
HttpResponseInterceptor. Please excuse my ignorance if this has been discussed
above and I've missed it.

bq. The reason I didn't take that approach is that in some cases there's not
enough context to figure out what you need to do.
The SolrRequest / SolrQueryRequest object (and whatever else we want) can be
passed into the interceptor's context. And hence, any authentication info that
needs to be propagated from original request to sub-requests (internode
requests) can be part of the interceptor. Please see the attached patch
(SOLR-6625_interceptor.patch). It contains a test method in the
MiniSolrClusterTest which uses an request interceptor to capture the
SolrRequest object.

HttpClient callback in HttpSolrServer
-

--
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] [Commented] (SOLR-6625) HttpClient callback in HttpSolrServer

2015-04-14 Thread Gregory Chanan (JIRA)

[
https://issues.apache.org/jira/browse/SOLR-6625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14495132#comment-14495132
]

Gregory Chanan commented on SOLR-6625:
--

[~ichattopadhyaya] thanks for posting the patch. As far as I can tell, this
replaces our own interface/abstract class for callbacks with an
HttpRequestInterceptor. That seems reasonable, but there are a few issues
discussed on this JIRA that don't seem addressed. A somewhat comprehensive
list:

1. How is configuration handled? Is it the responsibility of the
authentication layer to specify the HttpRequestInterceptor to use for all
requests?
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?
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
4. How do you check that we actually pass the correct information to the
interceptor? [~steff1193] 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.

HttpClient callback in HttpSolrServer
-

--
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] [Commented] (SOLR-6625) HttpClient callback in HttpSolrServer

2014-12-12 Thread Per Steffensen (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-6625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14244185#comment-14244185
 ] 

Per Steffensen commented on SOLR-6625:
--

Had a few hours for a look at the latest patch. Not a lot of time so I might 
very well have overlooked something, so please bear with me. But from what I 
got out of it I have the following comments

It seems you can control the used callbacks in two ways
* 1) Through {{solr.xml}}. 
** Request that {{SolrDispatchFilter}} forwards (using {{remoteQuery}})
** Update requests sent through {{UpdateShardHandler}} - 
{{DistributedUpdateProcessor}}, {{SnapPuller}}, {{PeerSync}}, {{SyncStrategy}} 
...
** {{Overseer}} requests (through {{UpdateShardHandler}} via {{ZkController}})
* 2) Through VM parameter. Used for every request sent - from Solr nodes and 
clients or whatever is running in the JVM sending request using 
{{HttpSolrServer}} (or {{ConcurrentUpdateSolrServer}}). Believe, for the 
requests mentioned under 1) above, both callbacks (the one from {{solr.xml}} 
AND the one from VM parameter) will be triggered - is that intentional? (it is 
fine for me)
I think, that if you want to support setting the callback through {{solr.xml}} 
it should be used for all requests sent out of a Solr node - including e.g. 
search requests to shards issued from {{SearchHandler}} (by code inspection it 
seems to me that it will not currently be included here). Regarding this 
principle of using the {{solr.xml}}-callback for ALL requests going out of a 
Solr node, I would really like to see some testing that makes sure this 
principle is fulfilled now and that it is not broken in the future (the day 
after SOLR-6625 is committed and forgotten about, someone adds a new place in 
the code sending requests going out of Solr nodes and forgets to call the 
callbacks). I wanted to do the same in SOLR-4470 (making sure that no requests 
going out of Solr nodes do not have credentials added - not it the code as it 
is today nor in the code as it changes in the future). I achieved it by adding 
a protecting layer around every Solr node ever started during testing, and 
assuming that the test-suite triggers every type of requests going out of Solr 
nodes, that will basically ensure that no one forgets to propagate credentials 
when extending the code in the future (those requests will fail and the test 
will likely fail). I would really like to see something similar here, verifying 
that {{solr.xml}}-callback is triggered for every request going out of a Solr 
node.

Maybe you should consider the naming of {{distribCount}} and {{forwardCount}} 
in {{BasicDistributedZk2Test.HttpClientRequestCallbackCounter}}. They are very 
confusing to me. {{distribCount}} seem to count update-requests (they are kinda 
forwarded) and {{forwardCount}} seem to count everything else including request 
from e.g. {{Overseer}} (they are among those that can not be characterized as 
forwarded)

I know you are not keen on cleaning up while adding a new feature (I was told 
that we have to do cleanup in different JIRAs). Personally I am very much 
against that, because no one will ever make a JIRA just to clean up (at least, 
looking at the code-base I see that it does not happen enough). Assuming we 
want to do a little cleanup (in that code that is touched anyway in this JIRA) 
I have the following suggestions
* Change {{ConcurrentUpdateSolrServer}} to use {{HttpSolrServer}} or at least 
make them share common code. Then we do not have remember to add 
callback-support in both when we solve this SOLR-6625
* In general we should do some Separation of Concerns here and create a 
single component X (e.g. {{SolrNodeOutgoingRequestSender}}) concerned with 
sending requests out of Solr nodes. Make X use callback from {{solr.xml}}.
** Let {{SolrDispatchFilter}}, {{UpdateShardHandler}} and whatever sends 
requests out of Solr nodes use that component X, or something based on or using 
it
** It is strange that {{Overseer}} uses {{UpdateShardHandler}} - {{Overseer}} 
is not doing updates. Either rename {{UpdateShardHandler}} to something that 
does not signal that it is only used for update-requests, or let {{Overseer}} 
use something else based on component X

Instead of adding callback-calls numerous places in the code not knowing if 
some place was forgotten, polluting the code even more and leaving the same 
kind of problems for others doing similar things in the future, IMHO SOLR-6625 
should be solved by refactoring the code so that the actual feature of 
SOLR-6625 is ridiculously easy to add
* Separating the general concern of sending request from solr-code (server or 
client) to one single component Y. ({{HttpSolrServer}} or a class containing 
the code shared between it and {{ConcurrentUpdateSolrServer}} is fine for now). 
It is easy to make a test that ensures that {{HttpClient.execute}} only occurs 
one single

[jira] [Commented] (SOLR-6625) HttpClient callback in HttpSolrServer

2014-12-10 Thread Per Steffensen (JIRA)

[
https://issues.apache.org/jira/browse/SOLR-6625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14241254#comment-14241254
]

Per Steffensen commented on SOLR-6625:
--

bq. Maybe Per Steffensen can chime in with the motivation there rather than
always using the static credentials – I'm guessing it is because there is some
organization-specific authorization checking expecting the actual user who made
the original request.

* Every paranoid customers. In general we/they just do not want a user to be
able to indirectly (through distributed sub-requests) get a response to a query
he is not allowed to fire directly. There is a lot of details to it that I will
spare you, but overall we are also 1) using authorization to prevent specific
groups of users to do queries (directly or indirectly) that takes certain
amounts of resources from the system or 2) to fetch certain fields or any
information that can be derived from those fields. Ad 1) By a lot of testing we
know which types of queries really takes a lot of resources out of our system,
but it is hard to be sure that a query that does not seem to be such a query,
does not indirectly fire such queries in distributed sub-requests. Ad 2) Just
because an outer request does not specifically ask for a certain field, it is
hard to know that the indirect sub-request also does not, even though in
practice it is so (except for id an score)
* Distributed audit logging
* Etc.

I realize that the reasons we want the credentials from the outer request
forwarded in sub-requests are very thin. I understand if this is not something
that you feel is necessary to support in Apache Solr. But if it does not make
the solution much more complicated you might just support it. I do not think
SOLR-4470 is a complicated solution - most of it, really, is testing.

bq. Likewise you can see all of the various other authentication schemes
HttpClient supports (SPNego included)

SOLR-4470 does not try to do itself what HttpClient can already do. The
HttpClient capabilities can just be used outside or through the
authentication-framework introduced in SOLR-4470. SOLR-4470 is mostly about
joggling the credentials inside Solr-nodes. When they have to be added to
requests, of course use HttpClient capabilities.

bq. To get around this, we use secure impersonation

Interesting!

HttpClient callback in HttpSolrServer
-

--
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] [Commented] (SOLR-6625) HttpClient callback in HttpSolrServer

2014-12-09 Thread Steve Davids (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-6625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14239541#comment-14239541
 ] 

Steve Davids commented on SOLR-6625:


bq. See SOLR-4470. That makes use of SolrRequest.getPreemptiveAuthentication, 
so you'd need the actual SolrRequest

I took a look at the patch but not quite sure any of that is actually 
necessary. Looking at the what detailed in SOLR-4470 they need to be able to 
lock down Solr Cloud via BasicAuth, you can easily do this via HttpClient's 
[BasicScheme| 
http://hc.apache.org/httpcomponents-client-ga/httpclient/apidocs/org/apache/http/impl/auth/BasicScheme.html]
 authentication scheme. Likewise you can see all of the various other 
[authentication schemes| 
http://hc.apache.org/httpcomponents-client-ga/httpclient/apidocs/org/apache/http/auth/AuthScheme.html]
 HttpClient supports (SPNego included). This would seem to do the trick, except 
for perhaps propagating the authentication from the original request though 
this shouldn't really be a requirement since the challenge will be static in 
the web container that you can live with having static credentials in the solr 
distrib - if it changes deploy new config changes.

For further information on authentication via HttpClient check out their help 
page here: 
http://hc.apache.org/httpcomponents-client-ga/tutorial/html/authentication.html

bq. See the discussion above about SolrDispatchFilter. In that case, the client 
needs to get the context of the SolrQueryRequest... 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())

Are you using these credentials to execute distributed requests? Or would it 
make sense to have a certain user hit the frontend shard, then that shard will 
perform the distributed request on behalf of the system's authentication 
credentials?

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

[jira] [Commented] (SOLR-6625) HttpClient callback in HttpSolrServer

2014-12-09 Thread Gregory Chanan (JIRA)

[
https://issues.apache.org/jira/browse/SOLR-6625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14239957#comment-14239957
]

Gregory Chanan commented on SOLR-6625:
--

bq. This would seem to do the trick, except for perhaps propagating the
authentication from the original request though this shouldn't really be a
requirement since the challenge will be static in the web container that you
can live with having static credentials in the solr distrib - if it changes
deploy new config changes.

Right, as far as I understand it, that part is there to propagate the
authentication from the original request. Maybe [~steff1193] can chime in with
the motivation there rather than always using the static credentials -- I'm
guessing it is because there is some organization-specific authorization
checking expecting the actual user who made the original request.

This patch is based on what we do with Apache Sentry and is a little different
than the SOLR-4470 approach, I'll explain that below. I put the SolrRequest
param in the callback because it was easy, we have evidence that other people
who implemented authentication find it useful to have access to the
SolrRequest, and it is compatible with SOLR-4470.

bq. Likewise you can see all of the various other authentication schemes
HttpClient supports (SPNego included)

Yep, we are actually using HttpClient's SPNego support -- I plan on
contributing that in separate patch. One difference is Solr doesn't use
repeatable requests, so we need to address that in some way (e.g. use
BufferedEntity like SOLR-4470). That part seems like it could be implemented
either via this HttpClientRequestCallback or an HttpRequestInterceptor.

bq. Are you using these credentials to execute distributed requests? Or would
it make sense to have a certain user hit the frontend shard, then that shard
will perform the distributed request on behalf of the system's authentication
credentials?

The later is close to correct. In Sentry we have some request handlers that do
the checking based on the authenticated user, so if you make a request to a
shard and the request is not forwarded, everything works as expected. All
solr-to-solr requests are done via internal (solr) credentials; we may have
used SOLR-4470 if it were available in the version we were developing against
and it was tested with SPNego, but it wasn't and this approach is simpler. So
this means in the forwarded case, the request looks like it came from solr and
thus you can't do proper authorization. To get around this, we use secure
impersonation (http://hadoop.apache.org/docs/r1.2.1/Secure_Impersonation.html)
to make the forwarded request look like it came from the original authenticated
user. That's what the part about including the context from the
SolrQueryRequest is about above.

Now, you could argue that these concerns should be separated -- i.e. there
should be some sort of forwarded request callback for handling the
authenticated user for that specific case and the HttpRequestInterceptor should
handle the http concerns around BufferedEntities and such. I'm not totally
against that, but I'd say that the HttpClientRequestCallback is compatible with
two independently developed authentication/authorization implementations
(Sentry and SOLR-4470), and the separated
ForwardedCallback/HttpRequestInterceptor approach doesn't seem simpler. And
you can still use HttpRequestInterceptors if you want to write your own
HttpClientConfigurer.

Hopefully that addresses your questions [~sdavids], any feedback is appreciated.

HttpClient callback in HttpSolrServer
-

[jira] [Commented] (SOLR-6625) HttpClient callback in HttpSolrServer

2014-12-08 Thread Mark Miller (JIRA)

[
https://issues.apache.org/jira/browse/SOLR-6625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14238644#comment-14238644
]

Mark Miller commented on SOLR-6625:
---

I think the last option is best.

Perhaps we could add this info to the current context info map on the
SolrRequest, and pass that context to the call back.

HttpClient callback in HttpSolrServer
-

--
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] [Commented] (SOLR-6625) HttpClient callback in HttpSolrServer

2014-12-08 Thread Steve Davids (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-6625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14238865#comment-14238865
 ] 

Steve Davids commented on SOLR-6625:


Is there any reason why we wouldn't just utilize HttpClient's 
[HttpRequestInterceptor| 
http://hc.apache.org/httpcomponents-core-4.3.x/httpcore/apidocs/org/apache/http/HttpRequestInterceptor.html]
 and [HttpResponseInterceptor| 
http://hc.apache.org/httpcomponents-core-4.3.x/httpcore/apidocs/org/apache/http/HttpResponseInterceptor.html]?
 It seems as though if we could just provide an HttpClientFactory that clients 
can implement/override it should provide enough hooks to have everyone 
customize HttpClient to their hearts delight.

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

[jira] [Commented] (SOLR-6625) HttpClient callback in HttpSolrServer

2014-12-08 Thread Gregory Chanan (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-6625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14238876#comment-14238876
 ] 

Gregory Chanan commented on SOLR-6625:
--

The reason I didn't take that approach is that in some cases there's not enough 
context to figure out what you need to do.  It's essentially equivalent to just 
passing the HttpRequest to the callback (and would thus be superior if that's 
all we needed), but consider the following cases:
1) See SOLR-4470.  That makes use of SolrRequest.getPreemptiveAuthentication, 
so you'd need the actual SolrRequest
2) See the discussion above about SolrDispatchFilter.  In that case, the client 
needs to get the context of the SolrQueryRequest

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

[jira] [Commented] (SOLR-6625) HttpClient callback in HttpSolrServer

2014-11-19 Thread Per Steffensen (JIRA)

[
https://issues.apache.org/jira/browse/SOLR-6625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14217591#comment-14217591
]

Per Steffensen commented on SOLR-6625:
--

Sorry I do not have the time to go into details. But from quick reading, and as
I remember the SOLR-4470 implementation, most/all of what you say sounds
reasonable.

Please note that SOLR-4470 hasnt been committed to the Apache Solr code-base. I
provided it long time ago, and just recently [~janhoy] and I updated it to fit
tip of trunk, and I know Jan intended to try to push it to the code-base. Do
not know what happened after that.

Please also note that in SOLR-4470 I tried to prepare for additional
authentication types, but it is hard to make it 100% right when you do not know
the nature of the actual types being implemented in the future. Essence is that
{{AuthCredentials}} should carry [information about] the authentications to be
used for the request(s). How to use them is an implementation-detail of the
specific authentication type (implementing {{AbstractAuthMethod}}), and it may
require a little rearranging of code to implement authentication type #2.
Basing it on a general callback feature sound like good idea. I believe in
never design for the future, but if I didnt at least try to sketch the idea
in a framework, there is a big risk than the next authentication type would
be implemented in a completely different way. I also believe in separation of
concerns, so I would really like the authentication concern to be handled in
one single place - {{AuthCredentials}} was my attempt to make such a place.

HttpClient callback in HttpSolrServer
-

--
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] [Commented] (SOLR-6625) HttpClient callback in HttpSolrServer

2014-11-18 Thread Per Steffensen (JIRA)

[
https://issues.apache.org/jira/browse/SOLR-6625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14216313#comment-14216313
]

Per Steffensen commented on SOLR-6625:
--

bq. One thing I wanted to avoid with this patch is putting authentication-type
specific details in HttpSolrServer. SOLR-4470 has a little logic there that is
basic-auth specific

Actually SOLR-4470 aims at introducing a framework for any authentication-type,
and then (for now) implement basic-auth using this framework. It is prepared
for adding new authentication types. See {{AuthCredentials}} carrying any kind
of {{AbstractAuthMethod}} - currently only
{{AbstractAuthMethod}}-implementation is {{BasicHttpAuth}}. Adding a new
authentication type should basically be about adding a new
{{AbstractAuthMethod}}-implementation. But sorry, I do not remember to many
details. But what I do know, is that we have been using SOLR-4470 solution now
in production for a long time, without any problems at all.

bq. As for the suggestion of using a BufferedHttpEntity rather than the OPTIONS
approach I describe above, that certainly may be an improvement.

I do not know if it is an improvement compared to your approach. I just
implemented in a way that worked. Supporting non-preemptive authenticating
POST-requests was not the main focus of SOLR-4470, so I just quickly did it in
the way that I found it could be done - without considering performance or
anything

HttpClient callback in HttpSolrServer
-

--
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] [Commented] (SOLR-6625) HttpClient callback in HttpSolrServer

2014-11-18 Thread Gregory Chanan (JIRA)

[
https://issues.apache.org/jira/browse/SOLR-6625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14216585#comment-14216585
]

Gregory Chanan commented on SOLR-6625:
--

bq. Actually SOLR-4470 aims at introducing a framework for any
authentication-type, and then (for now) implement basic-auth using this
framework

Ah, I see, I misinterpreted the SOLR-4470 code in HttpSolrServer -- it uses
BasicAuthCache and BasicScheme which I thought were in reference to basic auth,
but they are really just default implementations.

What I'm really arguing -- and it's my fault I didn't make it clear with
example code -- is that the authentication type may affect how you want the
http requests to look, beyond just the credentials. For example, I'm using an
authentication filter based off of Hadoop's AuthenticationFilter
(https://github.com/apache/hadoop/blob/7250b0bf914a55d0fa4802834de7f1909f1b0d6b/hadoop-common-project/hadoop-auth/src/main/java/org/apache/hadoop/security/authentication/server/AuthenticationFilter.java).
That filter does SPNego negotiation on the first request, but sets a cookie
you can use to avoid the negotiation on subsequent requests. So, I wouldn't
want the the SOLR-4470 implementation where I buffer up every request; I only
want to do that on the first request to the server on the connection.

From seeing the SOLR-4470 code, though, it looks like I was thinking about
this incorrectly. Instead of the HttpClientCallback being a function of the
HttpSolrServer, it's really a function of the AuthCredentials implementation.
So, the default implementation would just be the
credentialsButNonPreemptive/getHttpContextForRequest code you have in
HttpSolrServer in SOLR-4470, but other AuthCredentials implementations could
override. Does that sound right to you, [~steff1193]?

bq. I do not know if it is an improvement compared to your approach. I just
implemented in a way that worked. Supporting non-preemptive authenticating
POST-requests was not the main focus of SOLR-4470, so I just quickly did it in
the way that I found it could be done - without considering performance or
anything

Cool, I'll investigate in another jira.

HttpClient callback in HttpSolrServer
-

--
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] [Commented] (SOLR-6625) HttpClient callback in HttpSolrServer

2014-11-18 Thread Gregory Chanan (JIRA)

[
https://issues.apache.org/jira/browse/SOLR-6625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14217346#comment-14217346
]

Gregory Chanan commented on SOLR-6625:
--

One other note: if we buy my argument above, that each authentication
implementation may want to implement an HttpClientCallback in order to perform
some authentication-specific work, we need it in every place where uses
HttpClient. From scanning the source code, it looks like we'd need to add
something to ConcurrentUpdateSolrServer and SolrDispatchFilter and possibly
SolrCLI.

bq. Instead of the HttpClientCallback being a function of the HttpSolrServer,
it's really a function of the AuthCredentials implementation

I should mention, perhaps AuthCredentials is not a good name here if it's
credentials + callback. Maybe AuthenticationMethod or AuthenticationType or
something.

HttpClient callback in HttpSolrServer
-

--
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] [Commented] (SOLR-6625) HttpClient callback in HttpSolrServer

2014-11-17 Thread Gregory Chanan (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-6625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14215368#comment-14215368
 ] 

Gregory Chanan commented on SOLR-6625:
--

Thanks for pointing that out [~steff1193]!

One thing I wanted to avoid with this patch is putting authentication-type 
specific details in HttpSolrServer.  SOLR-4470 has a little logic there that is 
basic-auth specific; if we support a range of authentication types this could 
get complex.  Perhaps the best thing is to combine approaches here?

i.e. it seems from my reading of SOLR-4470 that if you were to implement the 
basic-auth specific code via a callback you'd need:
1) to be passed the SolrRequest (so you could check getPreemptiveAuthentication)
2) the ability to return an HttpContext for the HttpSolrServer to use

1) certainly doesn't seem like a problem, and 2) we could do via the return 
value of preRequest or via another method in the callback, e.g 
applyContextForRequestPre.

As for the suggestion of using a BufferedHttpEntity rather than the OPTIONS 
approach I describe above, that certainly may be an improvement.  I'd have to 
look more into it, but in either case, it seems it can be implemented via the 
callback.

Thoughts?

 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


 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] [Commented] (SOLR-6625) HttpClient callback in HttpSolrServer

2014-11-16 Thread Per Steffensen (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-6625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14213955#comment-14213955
 ] 

Per Steffensen commented on SOLR-6625:
--

SOLR-4470 supports repeatable POST request by using BufferedHttpEntity. Look at 
the changes in HttpSolrServer - search for credentialsButNonPreemptive in 
latest patch 
https://issues.apache.org/jira/secure/attachment/12634740/SOLR-4470.patch

 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


 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] [Commented] (SOLR-6625) HttpClient callback in HttpSolrServer

2014-11-11 Thread Mark Miller (JIRA)

[
https://issues.apache.org/jira/browse/SOLR-6625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14207600#comment-14207600
]

Mark Miller commented on SOLR-6625:
---

+1, looks good.

Might want to consider making that interface an abstract class in case we want
to add postRequest with back compat or something, but nothing I'm stuck on.

HttpClient callback in HttpSolrServer
-

--
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] [Commented] (SOLR-6625) HttpClient callback in HttpSolrServer

2014-11-11 Thread Gregory Chanan (JIRA)

[
https://issues.apache.org/jira/browse/SOLR-6625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14207675#comment-14207675
]

Gregory Chanan commented on SOLR-6625:
--

bq. Might want to consider making that interface an abstract class in case we
want to add postRequest with back compat or something, but nothing I'm stuck on.

Good suggestion, I'll do that on commit.

HttpClient callback in HttpSolrServer
-

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

41 matches

Mail list logo