Im not sure I understand the difference in the worker options :
MaxConcurrentWorkflowTaskPollers and MaxConcurrentWorkflowTaskExecutionSize
I see Pollers need to be atleast 2, and I wasnt able to disable stick execution, so there are two pollers each polling a sticky and non-sticky queue? But then if set concurrent execution to 1, the worker processed no workflows. I had to set it to 2 as well for it to process any workflow.
Does it mean, I cannot ensure I get serial processing of workflows in a given task queue?
I was wondering for a use-case that requires serial processing of updates, e.g. imagine a banking application, where someone tries to send money to X first and then to Y. And for some reason they may not have sufficient balance and maybe sending money to X was important that Y, so it would be odd for the user to see that sending money to Y succeeded and sending money to X resulted in insufficient funds because they got executed out of order. I understand global order with multiple producers can be difficult, but atleast with a single producers, if there can be ordering or serial processing? Seems like no, but just wanted to get your thoughts.
Such use case can be solved by relying on uniqueness of workflows by WorkflowID.
WorkflowID can be the ID of the sender. In this case each transfer request can be a signal (or signalWithStart) to the workflow with that ID. Then workflow can process these signals according to your business requirements. For example, one by one.
Can I get more details on this? For instance, is the workflow running for every in a loop waiting for signals and can signals carry some meta-data in terms of parameters necessary for the workflow business logic? E.g. transfer N to X or Y.
When a signal is received, workflow waits for signals and executes business logic (either inline or through a child workflow). This StackOverflow post has a very simplified example.
Thanks for the example, Im wondering is this pattern still possible if the workflow has something to return as a result of a signal processing. E.g. Can a client query if the workflow has handled a signal and what the result of that is? Seems like with a regular workflow execution I get a WorkflowRun which gives me the result. So is there something similar to that?
We are working on the synchronous update feature right now. It will be similar to a signal but would support waiting for its result. In the meantime, you can use the synchronous proxy pattern.
I looked at the synchronous proxy pattern, itseems to me that it works when request and response alternate each other like in the example. But if there are multiple requests at the same time, Im not sure the corresponding responses will be read, itseems since the channel is a fifo, whoever reads the channel first may read the first response as opposed to the response related to their request. Am I understanding this correctly?
hi @maxim , i have similar business requirements:
i am developing stress test platform and stress test executors. The platform and all the executors are separate containers deployed by k8s. The platform acting as a starter is used for sending workflows which includes some test details to temporal. Then the executors serving as workers get the workflow to run the stress test. However, each worker could not execute multiple stress tests simultaneously which would affect the results. In other words, one specific test could correspond to one or more workers to run. But one worker could not conduct multiple tests at the same time. Each worker should run the stress tests in serial order. Is there any way to solve this scenario, i would appreciate your advice, thank you.
best regards
I would create a workflow that represents a worker. Then, the test workflows could communicate with the worker workflows, which would give them permission to run the test. This assumes that you don’t run too many tests per second.