[MTOS-dev] Background Task Change

[Byrne Reese]

I see your point. But before we seek to make it more complicated, I wonder
if we can just re-think the business logic. Perhaps:

1) a developer instantiates a Schwarts Job Queue A
   - TS assigns A an ID
2) a developer adds tasks to A
   - these tasks get added to the DB, but have a status of claimed with an
     owner of A
3) at the end of the process the developer can call A->do_work()
4) if the developer chooses not to, or if the process dies before it has a
chance, TS will at some point release the jobs in the queue from the
ownership of A by ID and allow others to do the work

This seems like it will actually make TS more reliable yes? While allowing a
web process to use the job queuing and worker API of TS to manage specific
tasks. And of course, the flexibility and option to offload any of those web
tasks to a daemon should they choose.


On 2/9/08 3:07 PM, "Reed A. Cartwright" <reed at scit.us> wrote:

> Byrne Reese wrote:
>> But would this would run all tasks in the queue, or just the tasks that have
>> accumulated for this specific request lifecycle?
> 
> This runs all tasks in the queue.  It's how I'm able to use the external
> and periodic publishing queue abilities of MTOS, without using a cron
> job or daemon.  I simply have my dispatch daemon do it post-request.
> The page is sent to the user before the queue is executed so they don't
> see any delay.
> 
> So assuming that under the new framework, that one wants to distinguish
> between background tasks and deferred tasks, then the schwartz will need
>   several different queues, classifying tasks: rebuilding queue, email
> queue, periodic publishing, etc.  It will also need three (or four)
> different queue types.  The assignment between queues and queue types
> should be user controlled.  The types:
> 
> 1. Execute before returning, issue 'working...' page.
> 2. Execute after returning, but in the same process.
> 3. Execute externally, via cron or sleeping daemon.
> 4. Execute immediately via fork.  (This one should be dropped, but there
> may be some reason to keep it.)
>