I created 1 activity function and calling it from orchestrator function using powershell commandlet Invoke-DurableActivity. But when I executed the orchestrator function I'm seeing that the code running asynchronous and replay activity causing code to re-run. How can I avoid this re-run as we don't need it.
The re-run is part of the design of the framework. The good news is, once the activity finishes, The orchestrator will check internally for the state (result of the activity) and will move to the next step of your workflow.
Related
In a Node.js Function App on Azure I have an orchestration (generator*) function that calls an series of activity functions. In between each successful activity function there seems to be a period of dead time before the orchestrator is resumed and the next activity is begun. Sometimes it seems very long, like many minutes. Is there anything I can do to make the orchestrator turn over faster? I am on the Premium plan.
Something I have experienced is that, if the output of an activity function is big it creates a dead time before the orchestrator is resumed and the next activity is begun.
Durable Task Saves execution history (also the activity function's output) into table storage. If the output of the activity function becomes big (more than 64kb), it can't save the result in the table column so it saves the result in the blob storage.
Every time the orchestrator function is resumed after waiting for a task to complete, the Durable Task Framework reruns the orchestrator function from scratch and deserializes the blob, and binds to your variable every time. It creates a lot of overhead and slows down the orchestration.
I have a timer function that runs by itself once per minute.
Is it possible to invoke this function from another type of function if I want to call it at an arbitrary time (not on its cron schedule).
From:
An orchestrator function?
An activity function?
Also, it is it possible to call an orchestrator directly from a an activity function? I have heard that you can do "sub orchestrations" from an orchestrator. But what about directly from an activity function.
You cannot call the Time Trigger Function, but one thing you can do is extract the logic to a class library and share it with a Http Trigger that function that will be running in the same Azure Function App as the time trigger one.
About the Durable part, it's been a while since the last time I worked with that, but as far as I know, the orchestrator can call sub orchestrators and activities.
We have a durable function which is invoked from a Service Bus Trigger working fine with Azure
However, it appears as though the message doesn't get removed from Service Bus until the whole process has finished
Is this by design? Is there a workaround for this? Because it will cause me problems if the message gets picked up twice
Paul
Yes, that's by design. It completes it automatically when the function execution completes successfully - and that is not until the end of the orchestration, if it gets all the way through.
You could have a separate non-durable Azure Function with the ServiceBus trigger - and get that to start a new instance of the durable function. That orchestration would run asynchronously, meanwhile the trigger function itself would return immediately (and mark the message as completed). You'd just need to ensure your durable function does the right thing (for you) in event of a failure.
See https://learn.microsoft.com/en-us/azure/azure-functions/durable/durable-functions-instance-management?tabs=csharp for example
Because http-trigger azure function has a strict time limit for 230s, I created a http-trigger durable azure function. I find that when I trigger durable function multiple times and if the last run is not completed, the current run will continue the last run until it is finished. It is a little confused for me because I only want each run to do the task of the current run, not replay the last un-finished run. So my question is that:
Is it by design for durable function to make sure each run is completed (succeed or failed)?
Can durable function only focus on the current run just like the normal http-trigger azure function?
If 2) is not, is there any way to mitigate the time limit issue for normal http-trigger azure function?
Thanks a lot!
The function runs until it gets results that is Successfully completed or failed message.
According to Microsoft-Documentation it says,
Azure Functions times out after 230 seconds regardless of the functionTimeout setting you've configured in the settings.
I am new to azure durable functions. According to documents that the orchestrator functions are reliable. But I am wondering if the the starter function is reliable. Suppose that I have a http-trigger orchestrator functions. I guess when durable function framework (or something run in backend) detects that an http request matches a orchestrator function, it starts the starter function to trigger the orchestrator function. I am wondering where the starter function runs, a VM? Can the VM fail? I cannot find much doc on msdn.
Orchestrator functions reliably maintain their execution state by using the event sourcing design pattern. Instead of directly storing the current state of an orchestration, the Durable Task Framework uses an append-only store to record the full series of actions the function orchestration takes. An append-only store has many benefits compared to "dumping" the full runtime state. Benefits include increased performance, scalability, and responsiveness. You also get eventual consistency for transactional data and full audit trails and history. The audit trails support reliable compensating actions.
Durable Functions uses event sourcing transparently. Behind the scenes, the await (C#) or yield (JavaScript) operator in an orchestrator function yields control of the orchestrator thread back to the Durable Task Framework dispatcher. The dispatcher then commits any new actions that the orchestrator function scheduled (such as calling one or more child functions or scheduling a durable timer) to storage. The transparent commit action appends to the execution history of the orchestration instance. The history is stored in a storage table. The commit action then adds messages to a queue to schedule the actual work. At this point, the orchestrator function can be unloaded from memory.
When an orchestration function is given more work to do (for example, a response message is received or a durable timer expires), the orchestrator wakes up and re-executes the entire function from the start to rebuild the local state. During the replay, if the code tries to call a function (or do any other async work), the Durable Task Framework consults the execution history of the current orchestration. If it finds that the activity function has already executed and yielded a result, it replays that function's result and the orchestrator code continues to run. Replay continues until the function code is finished or until it has scheduled new async work.
Offcial doc