Hoss Man commented on LUCENE-997: > I'm not entirely convinced it makes sense to modify these classes to > include timeouts > as core functionality ... would it make more sense to deal with this in > subclasses of > IndexSearcher/TopDocs/Hits ?
I like the idea of timeouts as core functionality, as it makes it much easier to deal with things like partial results. I do have some thoughts on the patch though: (1) You only added timeouts to: public TopDocs search(Weight weight, Filter filter, final int nDocs) It's confusing if timeout functionality is not also added to: public TopFieldDocs search(Weight weight, Filter filter, final int nDocs, Sort sort) (2) Estimating the the number of results is a good idea, however it breaks some of the code in Hits.java when the Vector of results is not as long as expected. This either needs more work or just returning the number or results actually found. Perhaps a separate method for getting the estimate in the case of partial results would be the way to go. (3) The timer, consisting of a whole lot of millisecond pauses (if the resolution is 1) is not accurate (certainly under load). There needs to be at least an occasional call to an accurate timer. It would also be better to replace getCounter() by something like getMilliseconds() so the caller does not need to know the resolution of the timer. -- View this message in context: http://www.nabble.com/-jira--Created%3A-%28LUCENE-997%29-Add-search-timeout-support-to-Lucene-tf4438431.html#a13247616 Sent from the Lucene - Java Developer mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
