[
https://issues.apache.org/jira/browse/SOLR-4143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shawn Heisey updated SOLR-4143:
-------------------------------
Attachment: SOLR-4143-alternate-testsfailing.patch
Alternate patch as discussed (against branch_4x) with a test. This one no
longer does extensive code reformatting. The changes turned up a problem in
BasicDistributedZkTest, where qt was being used for additional parameters:
params.set("qt", "/admin/mbeans?key=updateHandler&stats=true");
I fixed that in the patch by assigning the parameters separately.
There is still one test failing for sure (actually failing to fail) with this
alternate patch, and I'm not sure how to fix it. I am doing a run where I
force this test to pass, to see if there are any other failures.
Test that's failing:
-Dtestcase=TestRemoteStreaming -Dtests.method=testQtUpdateFails
Is there a way to examine the response to determine that it did not update any
documents? If the qt=/update were to successfully override the /select, would
numFound be in the response? I had the test add echoParams=all and print out
the response as a string:
{noformat}
{responseHeader={status=0,QTime=5,handler=org.apache.solr.handler.StandardRequestHandler,params={stream.body=<delete><query>*:*</query></delete>,echoParams=all,q=*:*,echoHandler=true,wt=javabin,version=2}},response={numFound=1,start=0,docs=[SolrDocument{id=1234,
range_facet_si=1234, range_facet_l=[1234], range_facet_sl=[1234],
timestamp=Tue Dec 18 06:01:24 KOST 2012, multiDefault=[muLti-Default],
intDefault=42}]}}
{noformat}
> setRequestHandler - option to not set qt parameter
> --------------------------------------------------
>
> Key: SOLR-4143
> URL: https://issues.apache.org/jira/browse/SOLR-4143
> Project: Solr
> Issue Type: Improvement
> Components: clients - java
> Affects Versions: 4.0
> Environment: solr-impl 4.1-SNAPSHOT 1416639M - ncindex -
> 2012-12-03 12:54:38
> Reporter: Shawn Heisey
> Fix For: 4.1, 5.0
>
> Attachments: SOLR-4143-alternate-testsfailing.patch, SOLR-4143.patch,
> SOLR-4143.patch, SOLR-4143.patch, SOLR-4143.patch, SOLR-4143.patch
>
>
> The setRequestHandler method does what I expect in one way - it changes the
> URL path from /select to the String argument. It is however doing something
> that I did not expect, which is setting the qt parameter on the query as
> well. Here is the code:
> private static final String PING_HANDLER = "/admin/ping";
> query.setRequestHandler(PING_HANDLER);
> This is resulting in the following exception being logged in my Solr 3.5.0
> servers. I am not including the whole exception, because this issue is for
> SolrJ 4, not Solr 3.5, and the 3.5 version is working as it was designed.
> {code}
> Dec 3, 2012 4:04:01 PM org.apache.solr.common.SolrException log
> SEVERE: org.apache.solr.common.SolrException: Cannot execute the
> PingRequestHandler recursively
> at
> org.apache.solr.handler.PingRequestHandler.handleRequestBody(PingRequestHandler.java:60)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:208)
> {code}
> I believe it would be useful to include an alternate setRequestHandler method
> that includes a boolean option deciding whether or not to also set the qt
> parameter.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
