maybe the unclear point is that "checking for new tasks and assigning" are
on a totally separate "channel" from executing them...
if you have multiple workers that are totally free, as soon as tasks are
reassigned by the ticker they will be picked up.
If you are on a single worker, that is a ticker itself, and maybe is even
busy processing a task, assigning will happen, but the task won't be picked
up in a single loop.
Avoiding the scenario with a single worker that is already busy processing
tasks or sleeping or disabled (which no code will ever solve) basically you
have two threads working.
Upon further inspection and consideration, the main loop is
while True:
try_fetching_a_task
if successful:
process
else:
sleep heartbeat
the other loop (ipc) is
while True:
update/insert worker status
if loop is 5th, 10th, etc OR status is PICK:
check_and_assign
sleep heartbeat
soooo.....let's assume they are not in sync, and the main loop runs on
00:00:01 and 00:00:04 while the ipc loop runs on 00:00:03 and 00:00:06
00:00:00 no tasks, single worker
00:00:01 (main) no tasks yet
00:00:01 task gets queued, immediate is passed, worker status is PICK
00:00:03 (ipc) whoa, PICK is in, let's ASSIGN task --> task is ready to be
fetched
00:00:04 (main) task is here, let's process it
00:00:04 worker pops the task and starts processing it
So i really don't think there can be "several heartbeats before new tasks
are actually assigned"...
On Tuesday, June 7, 2016 at 3:54:41 AM UTC+2, Anthony wrote:
>
> On Monday, June 6, 2016 at 5:30:50 PM UTC-4, Niphlod wrote:
>>
>> okay but .....
>> """
>> Withimmediate=True you can force the check for new tasks: it will happen
>> at most as heartbeat seconds are passed
>> """
>> clearly states that "it" is "check for new tasks".
>>
>
> Yes, but earlier it says:
>
> immediate=True it will force the main worker to reassign tasks.
>
> So, you would assume that a "check for new tasks" results in the immediate
> assignment of such tasks. However, it sounds like even after a check for
> new tasks, there can still be a lag of several heartbeats before new tasks
> are actually assigned.
>
> In the task lifecycle diagram, it might be helpful to show what kinds of
> lags to expect at each of the arrows (and what causes the lag, such as
> waiting for a set number of heartbeats or simply waiting for a worker to
> complete previously assigned tasks before it can get to the next one).
>
> Anthony
>
--
Resources:
- http://web2py.com
- http://web2py.com/book (Documentation)
- http://github.com/web2py/web2py (Source code)
- https://code.google.com/p/web2py/issues/list (Report Issues)
---
You received this message because you are subscribed to the Google Groups
"web2py-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
