[Product-Developers] Relaunch a job after a failure with plone.app.async

[Yiorgis Gozadinos]

On May 25, 2011, at 3:03 PM, Encolpe Degoute wrote:

> Hello,
> 
> We are transferring data on a FTP from Plone.
> Every transfer is starting by acquiring a lock put the file then
> releasing the lock.
> If the FTP server is unreachable or the lock cannot be acquired we want
> to launch again the transfer later.
> Nothing is write in the ZODB.
> 
> We want to use async to not block the user on such job.
> 
> The first thing that was not clear for me was that le retry policy is
> only transaction (ZODB) centric. Our process doesn't write in the ZODB,
> then the NeverRetry policy seems to be the better to use.
> 

The API does not provide access to the retry policy. You would have to use zc.async directly to do that unfortunately.

> How can I use the success and the failure callback ?
> 
> In the success callback the 'context' is the value returned by job
> function. From there almost everything is not available:
> ipdb> getToolByName(getSite(), 'MailHost')
> *** AttributeError: MailHost
> ipdb> getUtility(IURLTool)
> *** ComponentLookupError: (<InterfaceClass Products...IURLTool>, '')
> ipdb> getUtility(IMailHost)
> *** ComponentLookupError: (<InterfaceClass Products...IMailHost>, '')
> 
> In the failure callback the 'context' is build with several data from
> the error context. But it's still unusable like the success callback.
> 
> We can also register handlers but we cannot filter jobs:
> 
>>>> from zope.component import provideHandler
>>>> from plone.app.async.interfaces import IJobSuccess, IJobFailure
>>>> provideHandler(successHandler, [IJobSuccess])
>>>> provideHandler(failureHandler, [IJobFailure])
> 
> Success case:
> ipdb> event.object
> Out[0]: True
> ipdb> event.__dict__
> Out[0]: {'object': True}
> 
> Failure case:
> ipdb> event
> Out[0]: <plone.app.async.interfaces.JobFailure object at 0xe193210>
> ipdb> event.__dict__
> ipdb> Out[0]: {'object': <zc.twist.Failure failure test>}
> 
> The problem is the same than above.
> How can I relaunch the job after it fails ?
> 

In a typical scenario you provide the callback together with the job. That allows you to know what kind of job this is and act accordingly. If you need to pass info around you could do so in the exception for example. One idea would be to  then reconstruct the job and submit again. The generic failure/success handlers are generic :) They are meant to do stuff like sending an email. You could again use the exception info to filter but it's probably a better idea to register specific callbacks on the job rather than filter. 

-- 
Yiorgis Gozadinos
www.jarn.com/ggozad