> > What impact would there be if ThreadPriority.Lowest was set for all of
> > the other executor threads?
> >
> > I'm guessing that based upon the current design, the Manager would see
> > the Executor disappearing as non-Alchemi processing on that machine
> > increased.
> >
> > I think it would make sense to have a heartbeat thread operate at
> > ThreadPriority.Normal or AboveNormal, but to decrease the priority of
> > all other threads to Lowest or BelowNormal.  I don't think there
> > should be a GUI for this, but it should be editable in the Executor's
> > config file.
> >
> > That way, the Executor has less impact on the machine, but never
> > actually drops off the grid.
>
> This makes sense :).
>
> This feature would fit in better if the Manager would be more tolerant to
> disappearing/reappearing Executors. OTOH do we really need the heartbeat
> thread? It surely generates a lot of chatter on the network. Why not make
> the Manager take an optimistic view of life and assume that all Executors
> are alive until proven otherwise by a failed communication?

There are a couple situations where we need to know if an Executor is alive.
1) Before we send a new thread to it
2) While an Executor has been sent a thread, and is processing it, but
before it has finished

As for 1, the approach of determining if an Executor is alive via
failed or successful communication per your suggestion makes sense. 
This would also allow Executors to leave and return to the grid
transparently to the Manager.

However, for 2, it's important for the Manager to know if an Executor
is actually alive and just busy processing a task, or whether it has
dropped off the grid.  The Manager can then react appropriately and
resend the thread as necessary.

To do this, we could have a heartbeat mechanism that is activated upon
receipt of a thread, and deactivated upon completion of it.  If the
heartbeat stops, we lost the Executor.  Otherwise, it's just busy.

Any other solutions?

Jonathan


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642
_______________________________________________
Alchemi-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/alchemi-developers

Reply via email to