Use a unique Task Queue for each Worker in order to have certain Activities run on a specific Worker.
This is useful in scenarios where multiple Activities need to run in the same process or on the same host, for example to share memory or disk. This sample has a file processing Workflow, where one Activity downloads the file to disk and other Activities process it and clean it up.
The strategy is:
- Each Worker process creates two
Worker
instances:- One instance listens on the
normal-task-queue
Task Queue. - Another instance listens on a uniquely generated Task Queue (in this case,
uuid
is used, but you can inject smart logic here to uniquely identify the Worker, as Netflix did).
- One instance listens on the
- The Workflow and the first Activity are run on
normal-task-queue
. - The first Activity returns one of the uniquely generated Task Queues (that only one Worker is listening on—i.e. the Worker-specific Task Queue).
- The rest of the Activities do the file processing and are run on the Worker-specific Task Queue.
Activities have been artificially slowed with sleep(3000)
to simulate doing more work.
temporal server start-dev
to start Temporal Server.npm install
to install dependencies.npm run start.watch
to start the Worker.- In another shell,
npm run workflow
to run the Workflow.
Example output:
Downloading https://temporal.io and saving to /tmp/b15036de-dbc7-4bc9-b2c7-7c48635c5797
Did some work on /tmp/b15036de-dbc7-4bc9-b2c7-7c48635c5797, checksum: b3fc767460efa514753a75e6f3d7af97
Removing /tmp/b15036de-dbc7-4bc9-b2c7-7c48635c5797
You can try to intentionally crash Workers while they are doing work to see what happens when work gets "stuck" in a unique queue: currently the Workflow will scheduleToCloseTimeout
without a Worker, and retry when a Worker comes back online.
After the 5th attempt, it logs Final attempt 5 failed, giving up
and exits. But you may wish to implement compensatory logic, including notifying you.