Hi Chris, another question pops up, is cursorMark cloud aware?
And if so, who is handling the cursorMark and what if a shard goes down and comes up again? Regards Bernd Am 30.06.2015 um 08:43 schrieb Bernd Fehling: > 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/ >> >
