Ah, I see the problem now. The timeout exception is not caught, so the document never enters the error state, nor does it advance to the next state (because it is not successful).
This is a tricky situation. I can think of a few things to counteract it. * One possibility is to raise the time limit on the task server. Of course this might just move the issue, but if you are close to the limit, it might solve your problem. The default timeout is relatively low if you are doing really heavy-duty processing. * Another idea is to look at the ErrorLog.txt file. By default, uncaught errors from the task server are logged, so you can periodically look for them and then figure out something clever to do. * If you get in this state, doing a forest restart will fire the restart trigger, which should re-spawn the unfinished document. Of course it may well time out again.... * This is a hack, but you can add some sort of check in your code to give up and throw an exception after a certain amount of time. Depending on why you are getting timeouts, this may or may not make sense. I hope that might give you some ideas. -Danny -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Florent Georges Sent: Wednesday, March 24, 2010 10:32 AM To: General Mark Logic Developer Discussion Subject: Re: [MarkLogic Dev General] Timeout in a CPF pipeline? Danny Sokolsky wrote: > If the spawned module processing takes longer then the time > limit, then that module will throw an exception (and it will > not complete). Yes, that's what I understood. The question is: can we do anything to detect that? Let's take the example of a pipeline launched by the insertion of a document (yes, I know the pipeline itself is not "executed", but that's a good abstraction though). From what I understand, the installation of the pipeline creates a trigger on document insertion (which is pre-commit), and a trigger on property change (which is post-commit). The first trigger sets a property on the newly inserted document (setting its status to created), and that fires the second trigger, but only after the transaction has been committed (as a task if I am right). This second trigger in turn sets the state to "initial" and executes the module associated with that state. If this module does times out, then this transaction is rolled back, and the net effect is that even the state is not recorded on the document. If that is correct, I do not see any way to detect whether the state has succeeded or not (at least in case of a timeout). But maybe my understanding is simply not correct... > the API documentation for xdmp:spawn That's maybe the missing piece. Thanks for the link! Regards, -- Florent Georges http://www.fgeorges.org/ _______________________________________________ General mailing list [email protected] http://xqzone.com/mailman/listinfo/general
_______________________________________________ General mailing list [email protected] http://xqzone.com/mailman/listinfo/general
