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 <[email protected]> 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. >
