To debug, you could wrap the contents of your reducer in a try/catch, then
have it emit an error as output. Your re-reducer would then ignore errors
(re-emit them).
The error object you output could have the original arguments as one if its
properties, so you could inspect and reproduce the issue.
I haven't had this particular problem, these are just some ideas off the
top of my head. Good luck!
-- Jim R. Wilson (seven databases in seven weeks)
On Fri, Dec 16, 2011 at 3:26 PM, Mark Hahn <mark@hahnca.com> wrote:
> What is the algorithm for determining whether a reduce is happening fast
> enough? I went to a lot of trouble to develop a map/reduce that
> intermittently gives this error. I don't like programming where I can't
> predict whether something will work or not. It reminds me of developing an
> app for ios and then being told it can't go in the app store.
>
|