[
https://issues.apache.org/jira/browse/SOLR-4194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13532771#comment-13532771
]
Shawn Heisey commented on SOLR-4194:
------------------------------------
It has occurred to me that this new behavior of inheriting search handler
parameter is considered correct operation and the 3.5.0 behavior was actually
the bug.
If that's the case, then we can change this issue to making PRH properly
support shards and shards.qt and fix the bug where an error response from one
of the shards doesn't result in an error response returned to the client.
> PingRequestHandler - shards parameter inherited from search handler definition
> ------------------------------------------------------------------------------
>
> Key: SOLR-4194
> URL: https://issues.apache.org/jira/browse/SOLR-4194
> Project: Solr
> Issue Type: Bug
> Affects Versions: 4.1
> Environment: solr-impl 4.1-SNAPSHOT 1421496 - ncindex - 2012-12-13
> 14:56:25
> Reporter: Shawn Heisey
> Fix For: 4.1, 5.0
>
>
> Included in all my cores is a PingRequestHandler named /admin/ping, which I
> use to enable/disable the server from the perspective of a load balancer
> running haproxy. The handler includes a qt parameter set to /lbcheck.
> I have a special core defined (I call it a broker) that includes the shards
> parameter in most of its search handler definitions. This includes /select,
> /lbcheck, and others.
> When the /admin/ping handler is called, the query is sent to the /lbcheck
> parameter as expected, which gets distributed because it includes shards. If
> one of those shards happens to be down, the handler will give an error
> response to the load balancer.
> The problem is that the PingRequestHandler seems to inherit the shards
> parameter from the search handler it is using, which causes the /admin/ping
> request itself to be distributed, which is not what I want. The individual
> shards are not used by the load balancer, so they always remain disabled.
> This works perfectly in 3.5.0. The official 4.0.0 release has not been
> tested.
> Config and log data will follow in the comments.
--
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]