Workers will specify the queues they listen to. For now, queues will always include a _system_ queue.
System activities (and soon workflows) will go to the _system_ queues.
Activities can be scheduled to specific queues
Workflows can be scheduled to specific queues
Sub-Workflows can be scheduled to specific queues
/diag UI will allow you to filter by queue
Stats backend call will break out pending activity/workflow tasks by queue
Stats backend call will break out active workflow instances by queue
This will allow you to scale differently, set different number of max parallel workflows/activities per queue for example. This will also help with back-compat scenarios when rolling out new changes (e.g., worker N listens to queue A, worker N+1 with a new incompatible workflow change will listen to queue A and B with new workflows only going to B). Other systems have moved away from this model for dealing with back-compat but I think it's "good enough" for the level of complexity this library targets.
cschleiden
commented
4 months ago
_system_queue._system_queues./diagUI will allow you to filter by queueStatsbackend call will break out pending activity/workflow tasks by queueStatsbackend call will break out active workflow instances by queueThis will allow you to scale differently, set different number of max parallel workflows/activities per queue for example. This will also help with back-compat scenarios when rolling out new changes (e.g., worker N listens to queue A, worker N+1 with a new incompatible workflow change will listen to queue A and B with new workflows only going to B). Other systems have moved away from this model for dealing with back-compat but I think it's "good enough" for the level of complexity this library targets.