Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Allow RaiseEventAsync to create an orchestration instance if one doesn't already exist #21
I have the following scenario (simplified):
I want 1 instance of Function B per metric type. My question is - how does the first function know/manage the instance ID and instance lifecycle. Should it instantiate new instances of Function B? I did something like this for now in Function A:
Is that a proper way? Should it also check if that status is not faulty, and restart otherwise? Isn't it a waste to
Missing some guidance on that part of function lifecycle management.
One part that's missing from the "actor" capability is the ability to have one instance create other instances and send messages to them. I need to open an issue to make this more clear, but we're working on a design for this pattern.
Your example above looks like the right way to go. There are some known timing issues, however, so you may want to add an
Thanks for the answer.
Ideally, for my kind of scenario I would expect something like
Another use case I was thinking of was stateful stream processing. So, I got an event hub, and each event belongs to an aggregate ID. It could be natural, if I had an eventhub-triggered "normal" function, then sending event to an actor for specific aggregate ID, who would carry state in it. Calling
Or is there another (not actor based) pattern for such stream processing scenario?
This is great feedback, thanks!
Yes, sorry about my suggestion about
Your stream processing scenario is a good one and will require a bit more thought on my part. I agree that keeping track of which instances have been created is possible (even using a simple, static in-memory cache) but not ideal. Regular Azure Functions does not support stateful stream processing so there aren't any good alternatives at this point (in the realm of Functions, anyways - so folks look to Service Fabric to help with this).
FYI, I'm tracking improving support for actors here: #22. I'll add some notes about stateful stream processing so we can make sure we enable that scenario.
referenced this issue
Mar 19, 2018
Updating the title and changing the labels. I think this is closely related to the Aggregator Pattern, which we plan to document and provide samples for: #166.
But I think allowing
I have the exact same scenario in place, currently I am forced to calls StartNew in advance to make sure everything is ready prior starting to receive events. When doing the StartNew and raising the event just after, I sometime get an error that the StartNew is not active yet (GetStatus would be returning null).