Thanks for your explanation. Right out of your head, are there any other options which prevent getting a cursorMark?
Yes, that was also my idea to set up a separate request handler for harvesting without timeAllowed. As Shawn suggested, a short note about this should go into the documentation. Regards, Bernd Am 29.06.2015 um 18:57 schrieb Chris Hostetter: > > : > Have nothing found in the ref guides, docs, wiki, examples about this > mutually > : > exclusive parameters. > : > > : > Is this a bug or a feature and if it is a feature, where is the sense of > this? > > The problem is that if a timeAllowed exceeded situation pops up, you won't > get a nextCursorMark to use -- or the one you get might be wrong, and > could trigger infinit looping. > > > code doesn't really know about hte cursorMark code, so if a timeAllowed > "exceeded" siutation pops up, you might not get a nextCursorMark in your > response, which i considered unacceptible. if you ask for a cursorMark, > you get a cursor mark. if you ask for a cursor mark and include other > options that make it possible we can't do that, it's an error. > > With a bit of work, both could probably be supported in combination -- but > for now it's untested, and thus unsupported, so we put in that error > message to make it clear and to guard end users against the risk of > nonsensical results. > >>> Yes, I'm using timeAllowed which is set in my requestHandler as >>> invariant to 60000 (60 seconds) as a limit to "killer searches". > > Your best is porbably to confine your cursorMark searches to an alternate > request handler, not used by your normal arbitrary queries, that doesn't > have the timeAllowed invariant. > > > > -Hoss > http://www.lucidworks.com/ >
