John,
With the clarification I still think 24h is ok. I could make an
argument for 72h. The Agent dies over the course of a weekend and you
cant collect the data for some reason, but this argument feels pretty
weak. What ever the limit there could be a reason to extend it. We
intend to use the worker_info like a heart beat or a ping. I think the
time frame should be tied to the longest period that an non-human
participant could take to complete before the worker could beat again.
If the worker does not beat for 24hours, in my book its dead.

I assume that  "put_at"=>"2011-09-19 12:32:33.881352 UTC" is the last
time the worker checked in?

Thanks
Eric Smith

On Oct 4, 6:42 pm, John Mettraux <[email protected]> wrote:
> On Wed, Oct 05, 2011 at 01:15:37AM +0200, Mario Camou wrote:
>
> > I would make it configurable, say in config.ru (perhaps per participant
> > type? That would probably make things too complex). I can think of at least
> > one case where you might want more than 24 hours: interactive participants.
> > So you call the participant, it notifies a user of some action that needs to
> > take place, and doesn't reply until the user performs the action. In some
> > use cases the user might take several days from the moment they receive the
> > notification to the moment they perform the aciton.
>
> Hello Mario,
>
> Engine/Dashboard#worker_info is giving you information about ruote workers, 
> which are alive (ip, pid, workload, memory, last time seen).
>
> Are you suggesting ruote should collect such information from remote 
> participants as well ?
>
> Let me reformulate my question to Eric: we have multiple ruote workers (!= 
> participant) and they each update worker_info like every minute. At some 
> point worker dies and are not replaced. How long should we keep worker_info 
> (about dead workers) 1 month, 1 day, 5 minutes ?
>
> 24h seems OK.
>
> Thanks for clarifying your idea.
>
> Kind regards,
>
> John

-- 
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

Reply via email to