dependabot-preview[bot] on nuget
dependabot-preview[bot] on dev
Bump Microsoft.NET.Test.Sdk fro… (compare)
Tell
ed. IIRC Monitoring does something like it - but is there a generic way to hook in somewhere in order to get the data I'm looking for?
AroundReceive
base method
Hi, I have a question related to Stash. I don't understand this piece of docs:
The IWithUnboundedStash interface implementation of PreRestart will call UnstashAll(), which is usually the desired behavior.
(http://getakka.net/articles/actors/receive-actor-api.html#stash) Does this happen automagically when I implementIWithUnboundedStash
on my actor? Where is this logic defined? I can't find it...
yeah, seems like it, since BeforeIncarnated
is a
Plugin behavior applied to underlying <paramref name="actor"/> instance before the actor is being recycled.
ReceiveActor
mostly myself
ReceiveActor
can do things switch
cannot, such as matching on generics
OnReceive
in one and pattern match in the other one 4) notice the info on top of UntypedActor API page about C# 7, confirming it is mostly about the switch (?)
akka.net receive actor vs untyped actor
does not return anything about the why
Is there anyone out there that can help me get my head around the implications that leveraging persistence in an existing actor. I've changed the base class and am moving some "commands" over to the construct events, persist, process event pattern but am getting what "feels" like asynchronous processing of the event processing. Is it true to say that:
1) A message is received
2) Message is treated as a command and an event is created from the command
3) Persist is called supplying the event to persist and a handler to be invoked after successful persistence
4) Next message is pulled from the mailbox and processed
5) Persistence completes
6) Handler supplied in 3 is invoked with persisted event
That's how it feels, so I wonder if that is accurate, and is the fix to complete the moving over from messages to Commands/Events and it'll be okay.
async
methods which return data (to an Ask
) and PipeTo
: would using ContinueWith
on faulted tasks be a reasonable way to 'catch' and handle exceptions thrown. Example: Receive<SomeRequest>(request =>
{
GetSomethingAsync(request)
.ContinueWith(t => new FailedResponse(t.Exception), TaskContinuationOptions.OnlyOnFaulted)
.PipeTo(Sender);
});