- Activity retries are driven from the service. So they are retried not only on failures but on crashes or downtimes of the activity worker processes.
- Activities support cancellation.
- There is a visibility API/UI to see the current state of an activity retries. It shows how many times it attempted execution, the identity of the process that executed the last attempt, the last failure information, and the next attempt’s time. The arguments of the activity are also shown.
- Any duration of activity retries is supported. Yes, you can retry for a year if needed.
- They don’t consume resources (threads and memory) on the worker process while waiting for the next attempt.
- Activity tasks are delivered through task queues. This way their invocations are flow and rate controlled. The worker doesn’t pick a task from a queue if it doesn’t have the capacity to execute it.
- Temporal supports global (across multiple workers) rate limit per task queue. It is useful to ensure that calls don’t overload a downstream service an activity calls.
- Long running activities are supported. Activity heartbeating can be used to save the current progress of activity execution.
- No need to have an end point and load balancer to invoke activities as their worker calls into the Temporal service. This is good for security as the host that executes activities doesn’t need to listen on any open ports.
- Activities can be routed to specific hosts and processes. For example, it is possible to ensure that a sequence of activities is executed by the same process.
8 Likes