On Thu, Jan 03, 2013 at 05:30:37PM -0600, Iuri Gagnidze wrote: > > Let me try to explain my problem in a different way. > > Right now I have participant A that takes couple hours to run and I have > participant B that takes only couple seconds and is scheduled to run every > minute. > > When I run participant A, participant B get blocked, since the worker > instance is busy doing work for participant A, and participant B misses its > schedule.
Hello again, is your participant using do_not_thread --> true ? By default it's false, so participant work happens in its own thread, thus that should not block. Ah, I guess you're overriding StorageParticipant... Wouldn't you be better served by a "normal" participant? One that doesn't extend StorageParticipant? StorageParticipant is meant for human task lists. An automated task is better served by something else that a storage participant. At least, let your #do_not_thread respond false. > What I'm trying to do is to have two worker instances, were one worker will > only consume participant A, and another worker only consumes participant B. > That way I am guaranteed that long tasks won't block my short tasks. > > Also, I have couple long running tasks queued up and I don't want to run > them in parallel, but if I bring up two instances of worker, then both of > them start running long running tasks that are queued up. Maybe you could override the #reserve(msg) method in your storage and return false if the msg is a "dispatch" for the wrong participant_name. The worker places a reference to itself in Thread.current['ruote_worker'], the storage could use that to determine if the reserve should fail or be successful. (in the reserve case, true means success, ie the worker can go on processing the msg). If the root issue is task a blocking task b, please use something else than a storage participant. I remember vaguely discussing with people on this list about storage participant and automated tasks and I came up with explanations on how to combine both... Try setting #do_not_thread to responding false... Do you use a StorageParticipant because you need to list the workitems currently being processed by this participant? -- John Mettraux - http://lambda.io/jmettraux -- you received this message because you are subscribed to the "ruote users" group. to post : send email to [email protected] to unsubscribe : send email to [email protected] more options : http://groups.google.com/group/openwferu-users?hl=en
