Local Activity vs Activity

Community Support
,
21

Dear Maxim

follow up some question

Regarding this
1 > It is not efficient for long retries.
does this mean for unlimited retries? or retries that has big interval we can config this via retry policy MaximumInterval
2> Local activity extends workflow task execution. While the task is running it cannot react to signals. So it increases the latency for signal handling.
what kind of signal does this implicate to ? or what kind of scenario example for this statement ?
will we get latency while using queryworkflow for viewing query handler, or all kind of signal include in the workflow execution
for example
there are workflow with steps:

  1. ExecuteActivity(A)
  2. ExecuteLocalActivity(B)
  3. ExecuteLocalActivity(C)
  4. Waiting for action : signal1.Receive()
  5. ExecuteLocalActivity(D)
  6. using selector with addFuture and addReceive
  7. 6a. ExecuteLocalActivity when timer trigger in addFuture
  8. 6b continue flow
  9. ExecuteActivity

Does the statement regarding usage of signal latency is pointing to step on number 4 and step number 6?

if there are some other flow like this:

  1. ExecuteActivity
  2. ExecuteLocalActivity
  3. ExecuteLocalActivity
  4. ExecuteActivity
  5. ExecuteLocalActivity
  6. ExecuteActivity

if the worker of workflow crash on step 5, does the workflow retry from step 2 or does it only executed from 5?

Thank You for your help

1 Like
22

1 > It is not efficient for long retries.
does this mean for unlimited retries? or retries that has big interval we can config this via retry policy MaximumInterval

Retries that exceed workflow task timeout are modeled through a timer. So each retry adds events to the history. So it is not about the period of retries, but how many retries total can lead to the history size exhaustion.

for example
there are workflow with steps:

  1. ExecuteActivity(A)
  2. ExecuteLocalActivity(B)
  3. ExecuteLocalActivity(C)
  4. Waiting for action : signal1.Receive()
  5. ExecuteLocalActivity(D)
  6. using selector with addFuture and addReceive
  7. 6a. ExecuteLocalActivity when timer trigger in addFuture
  8. 6b continue flow
  9. ExecuteActivity

Does the statement regarding usage of signal latency is pointing to step on number 4 and step number 6?

At step 4 the workflow is going to complete the workflow task. So signal will be received without delay.

Step 6 behavior depends on what it listens on. If it listens on both LA D and a timer the timer is not going to be started until LA D is completed (or workflow task heartbeat). This happens because the timer will be sent to the service only on workflow task completion.

2 Likes
23

Hi Maxim,

  1. Can you please refer me to a local activity example in Java?
  2. in your documentation (Activities | Temporal Documentation) it’s written that:
no longer than a few seconds, inclusive of retries (shorter than the Workflow Task Timeout, which is 10 seconds by default).

does it mean that every WF must finish by 10 seconds? is this WF_executionTimeout? can’t it be longer?

Thanks,
Shai

1 Like
24

  1. HelloLocalActivity

  2. Workflow task timeout is unrelated to workflow execution and run timeouts. It is the maximum time a workflow worker can take to calculate all new commands for new events. The comment you mentioned is outdated. Local activities that take longer than workflow task timeout are still supported, but still not recommended.