Is it possible to cancel a scheduled operation in azure function durable entity ? Below is an example code.I want to cancel the call to operation "DeviceTimeout"after it is scheduled.
Entity.Current.SignalEntity(Entity.Current.EntityId, DateTime.UtcNow.Add(TimeSpan.FromSeconds(30)), nameof(DeviceTimeout));
Unfortunately not. There is an open issue requesting this ability but afaik it has not been implemented yet:
I can' think of a very straightforward API to provide this. One approach would be to include some sort of unique identifier for the signal so that a cancellation request can be precisely matched to the signal being cancelled. But there are some open questions on what exactly the implementation would have to guarantee, and whether that can lead to new issues. For example, would we need to store a cancellation request that we can't match to a signal until such a signal arrives? what if it never arrives?
I suppose the next best thing is to just exit immediately once the operation is executed.
Related
I was wondering if anyone could help me understand some behavior regarding orchestration functions and entities.
Say I have one HttpTriggered function that starts an orchestration that calls (not signal) a Durable Entity and runs a long process (30 seconds) to update some string member. I also have another HttpTriggered function that starts an orchestration to call the same Entity and get that string.
What I want to know is that if I trigger the first function "A" and then the second function "B" immediately after. When "B" calls the Entity to get the string, does it wait for "A" to finish its call to the Entity? Or will "B" get a "dirty" value from it?
Guess what I'm trying to figure out is if all calls to the Entity have to be synchronous in regards to the Control Queue.
Entities execute operations one-at-a-time in FIFO order, so if you have two orchestrations (A and B) that call some operation simultaneously, the second operation (B in your example) will be forced to wait for A's operation to finish, which could be as long as 30 seconds. Dirty reads therefore aren't possible when calling entities. This synchronization happens in memory in the Durable Functions extension itself.
This is mentioned in the documentation here:
https://learn.microsoft.com/en-us/azure/azure-functions/durable/durable-functions-entities#general-concepts
To prevent conflicts, all operations on a single entity are guaranteed to execute serially, that is, one after another.
This applies both to entity calls and signals.
I am new to Event sourcing concept so there are a couple of moments I don't understand. One of them is how to handle following scenario:
I've got 2 instances of a service. Both of them listen to a event queue. There are two messages: CreateUser and UpdateUser. First instance picks up CreateUser and second instance picks up UpdateUser. For some reason second instance will handle its command quicker but there will be no User to update, since it was not created.
What am I getting wrong here?
What am I getting wrong here?
Review: Race Conditions Don't Exist
A microsecond difference in timing shouldn’t make a difference to core business behaviors.
In other words, what you want is logic such that the order of the messages doesn't change the final result, and a first writer wins policy (aka compare-and-swap), so that when you have two processes trying to update the same resource, the loser of the data race has to start over.
As a general rule, events should be understood to support multiple observers - all subscribers get to see all events. So a queue with competing consumers isn't the usual approach unless you are trying to distribute a specific subscriber across multiple processes.
You do not have a concurrency issue you can solve. This totally runs down to either using bad tools or not reading the documentation.
Both of them listen to a event queue.
And that queue should support that. Example are azure queues, where I Can listen AND TELL THE QUEUE not to show the event to anyone else for X seconds (which is enough for me to decide whether i handled it or not). If I do not answer -> event is reinserted after that time. If I kill it first, there is no concurrency.
So, you need a backend queue that can handle this.
Ok completely new to this essentially we want to be able to time out a session after 10mins. that's pretty easy.
We also want to wait for external user input -- essentially data from a multi step form. also pretty easy.
We want to be able to Task.WaitAny (waitforexternalevent("updatedata"), timeout)
But this is causing issues in the orchestration.
Individually these concepts work, however we see the Task.WaitAny to unblock and reuse the first "updatedata" event.. other "updatedata" events never reach the orchestration.
Is this expected behavior, are we mixing concepts in an invalid way, or is this a bug?
We might need to see some more of your code, but with what you've described here I think the behavior you're seeing is what should be expected.
Your orchestration is "waiting" on the timeout or the external event. Once that external event is triggered, the orchestration is going to move forward and, even if something triggers that event again, the orchestration is not expecting/waiting on it.
Again, this is based on the sliver of code you've included in your question thus far. If you need to handle the event being broadcast into the orchestration multiple times you would need to have a loop of some kind.
I would like some pointers of best practice. I need to wait for a binding to complete before polling for data through it, and much of this happens in parallell all the way back to the client. But if there is already a binding operation in progress, issuing another one will replace the callback.
If I would like to patch node-amqp to support a separate callback for each binding operation, how would I proceed?
The short answer is that this is not possible in node-amqp. If you call bind on a queue that already has a binding operation in progress, the callback will be replaced. So only one callback will be called for concurrent bindings on the same queue, namely the last one passed.
For this reason, and others, I have switched to using amqp-coffee which handles the binding callback differently.
I've been looking at CQRS but I find it restricting when it comes to showing the result of commands in lets say a Web Application.
It seems to me that using CQRS, one is forced to refresh the whole view or parts of it to see the changes (using a second request) because the original command request will only store an event which is to be processed in future.
In a Web Application, is it possible that a Command request could carry the result of the event it creates back to the browser?
The answer to the headline of this question is quite simple: nothing, void or from a webbrower/rest point of view 200 OK with an empty body.
Commands applied to the system (if the change is successfully committed) does not yield a result. And in the case that you wish to leave the business logic on the server side, yes you do need to refresh the data by executing yet another request (query) to the server.
However most often you can get rid of the 2nd roundtrip to the server. Take a table where you modify a row and press a save button. Do you really need to update the table? Or in the case a user submits a comment on a blog post just append the comment to the other comments in the dom without the round trip.
If you find yourself wanting the modified state returned from the server you need to think hard about what you are trying to achieve. Most scenarios can be changed so that a simple 200 OK is more than enough.
Update: Regarding your question about queuing incoming commands. It's not recommended that incoming commands are queued since this can return false positives (a command was successfully received and queued but when the command tries to modify the state of the system it fails). There is one exception to the rule and that is if you are having a system with an append only model as state. Then is safe to queue the mutation of the system state till later if the command is valid.
Udi Dahans article called Clarified CQRS is always a good read on this topic http://www.udidahan.com/2009/12/09/clarified-cqrs/
Async commands are a strange thing to do in CQRS considering that commands can be accepter or rejected.
I wrote about it, mentioning the debate between Udi Dahan's vision and Greg Young's vision on my blog: https://www.sunnyatticsoftware.com/blog/asynchronous-commands-are-dangerous
Answering your question, if you strive to design the domain objects (aggregates?) in a transactional way, where every command initiates a transaction that ends in zero, one or more events (independently on whether there are some process managers later on, picking one event and initiating another transaction), then I see no reason to have an empty command result. It's extremely useful for the external actor that initates the use case, to receive a command result indicating things like whether the command was accepted or not, which events did it produce, or which specific state has now the domain (e.g: aggregate version).
When you design a system in CQRS with asynchronous commands, it's a fallacy to expect that the command will succeed and that there will be a quick state change that you'll be notified about.
Sometimes the domain needs to communicate with external services (domain services?) in an asynchronous way depending on those services api. That does not mean that the domain cannot produce meaningful domain events informing of what's going on and which changes have occured in the domain in a synchronous way. For example, the following flow makes a lot of sense:
Actor sends a sync command PurchaseBasket
Domain uses an external service to MakePayment and knows that the payment is being processed
Domain produces the events BasketPurchaseAttempted and/or PaymentRequested or similar
Still, synchronously, the command returns the result 200 Ok with a payload indicating some information about what has happened. Even if the payment hasn't completed because the payment platform is asynchronous, at least the actor has a meaningful knowledge about the result of the transaction it initiated.
Compare this design with an asynchronous one
Actor sends an async command PurchaseBasket
The system returns a 202 Accepted with a transaction Id indicating "thanks for your interest, we'll call you, this is the ticket number")
In a separate process, the domain initiates a process manager or similar with the payment platform, and when the process completes (if it completes, assuming the command is accepted and there are no business rules that forbid the purchase basket), then the system can start the notifying process to the actor.
Think about how to test both scenarios. Think about how to design UX to accommodate this. What would you show in the second scenario in the UI? Would you assume the command was accepted? Would you display the transaction Id with a thank you message and "please wait"? Would you take a big faith leap and keep the user waiting with a loading screen waiting for the async process to finish and be notified with a web socket or polling strategy for XXX seconds?
Async commands in CQRS are a dangerous thing and make us lazy domain designers.
UPDATE: the accepted answer suggest not to return anything and I fully disagree. Checkout Eventuous library and you'll see that returning a result is extremely helpful.
Also, if an async command can't be rejected it's... because it's not really a command but a fact.
UPDATE: I am surprised my answer got negative votes. Especially because Greg Young, the creator of CQRS term, says literally in his book about CQRS
One important aspect of Commands is that they are always in the imperative tense; that is they are
telling the Application Server to do something. The linguistics with Commands are important. A situation
could for with a disconnected client where something has already happened such as a sale and could
want to send up a “SaleOccurred” Command object. When analyzing this, is the domain allowed to say
no that this thing did not happen? Placing Commands in the imperative tense linguistically shows that
the Application Server is allowed to reject the Command, if it were not allowed to, it would be an Event
for more information on this see “Events”.
While I understand certain authors are biased towards the solutions they sell, I'd go to the main source of info in CQRS, regardless of how many hundred of implementations are there returning void when they can return something to inform requester asap. It's just an implementation detail, but it'll help model better the solution to think that way.
Greg Young, again, the guy who coined the CQRS term, also says
CQRS and Event Sourcing describe something inside a single system or component.
The communication between different components/bounded contexts (which ideally should be event driven and asynchronous, although that's not a requirement either) is outside the scope of CQRS.
PS: ignoring an event is not the same as rejecting a command. Rejection implies a direct answer to the command sender. Something "difficult" if you return nothing to the sender (not even a correlation ID?)
Source:
https://gregfyoung.wordpress.com/tag/cqrs/
https://cqrs.files.wordpress.com/2010/11/cqrs_documents.pdf