[
https://issues.apache.org/jira/browse/SOLR-1237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12735947#action_12735947
]
Hoss Man commented on SOLR-1237:
--------------------------------
1. i don't know if these params are really common enough to belong in common ..
the need to pay attention to them actually seems fairly uncommon, so i would
suggest putting them in their own namespace.
1. skimming the patch it wasn't clear why you needed to write
MockQuerySenderListener ... can't you just have a request handler that records
whether it got newSearcher & firstSearcher flagged requests and then ask it
(ask it once after startup, then send a commit and ask it again)?
> firstSearcher and newSearcher should identify themselves via the parameter
> set passed in
> ----------------------------------------------------------------------------------------
>
> Key: SOLR-1237
> URL: https://issues.apache.org/jira/browse/SOLR-1237
> Project: Solr
> Issue Type: Improvement
> Reporter: Grant Ingersoll
> Assignee: Grant Ingersoll
> Priority: Minor
> Fix For: 1.4
>
> Attachments: SOLR-1237.patch
>
>
> The firstSearcher and newSearcher events call the regular search component
> chain, but are special cases. They should identify themselves by passing in
> a parameter indicating their type. This way, for instance, the sharding
> component could know to ignore the &shards parameter, which currently causes
> Solr to hang if it is present in the firstSearcher query string.
> See
> http://www.lucidimagination.com/search/document/b2b9c39a8eb4e563/firstsearcher_and_newsearcher_events
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
