On 11/8/2012 3:25 PM, Dyer, James wrote:
Could this be a side-effect from SOLR-4019, in branch_4.0 this was commit r1405894 ? Prior to this commit, PingRequestHandler would throw a SolrException for 503/Bad Request. The change is that the exception isn't actually thrown but rather sent in place of the response. This prevents the container from logging huge stack traces just because PingrequestHandler is in a "disabled" state. Prior to this, SolrException had logging disabled for 503's with hardcoding, but this broke other uses of 503 SE's.
While working on another issue (SOLR-4143), I figured out why this isn't working. Initially I did not connect the exceptions in the Solr 3.5 log to my problems getting ping responses, but the light eventually turned on.
My requests to the 3.5 ping handler from SolrJ 4.1-SNAPSHOT use the setRequestHandler method to talk to /admin/ping. In addition to using /admin/ping as the URL path, this also sets the qt parameter to /admin/ping. The PingRequestHandler in Solr 3.x looks at the qt parameter that it receives, and if that handler is an instance of PingRequestHandler, throws an exception saying that you can't call PRH recursively. This is why I get an exception and no response, but it works perfectly in a browser -- I wasn't setting qt in my browser. Once I did that, I get the bad response in the browser too.
There is no way in SolrJ 4.x or trunk to set the request handler without also setting qt. When I looked at SolrJ code trying to make a patch for SOLR-4143, I discovered that it's not a trivial change, and it may not be possible to even do in branch_4x.
Is there possibly a workaround I can use in SolrJ? Other thoughts? Thanks, Shawn
