Glad you enjoy it!

🙏

We plan to support F# users as first-class citizens on the new serialization tooling

PipeTo is more like an integration between the TPL (Task) APIs and actors - it takes the results of a Task and lets it get piped back into the actor's mailbox like a normal IActorRef.Tell would. If you have a really long-running Task or if you want to run several of them all concurrently from the same actor, this pattern in combination with something like behavior switching allows the actor to still be responsive to additional messages while those tasks are running

We had it in the description but I'll post it here too! github.com/petabridge/DrawTogether.NET

Is the question on how to do the async / await portion of this or just how data access should look, generally, when using actors to facilitate this?

@@Stannardian Hi! This is more of a general question (although I'm not very familiar with the async / await or .PipeTo() part either). Should I just send messages that will be converted by the "database-handler" actor into plain asynchronous database queries? Is this the right way to do it?

@@zkWarrior I'd keep the db queries async and maybe put an actor in front of the query handler if you want to do things like limit the number of parallel database requests / open connections at any given time. The other reason for maybe having an actor responsible for this is so you can avoid having to spread DbContexts et al around to lots and lots of actors who might need database access. My $0.02

@@Petabridge Thanks for the reply! I'll try to experiment with that and maybe will check out some vids on the channel just to know more of the technical stuff.

A couple of things: 1. Props is meant to be serializable, so we actually take a NewExpression in the Props.Create so we can extract the individual CTOR arguments - this is necessary to support remote deployment of actors. That's kind of an edge case though - remote deployments are cool but not really super necessary. 2. Props can include some additional details needed to configure an actor - for instance, if you want to run an actor as a round-robin router pool of 5, use a custom mailbox (like a priority queue), or customize the dispatcher (i.e. have the actor run on the UI thread so it can manipulate a live chart) - those are all things you can specify on Props. It's also a convenient abstraction that allows us to swap out how actors are created internally - for instance, Akka.DependencyInjection uses the ActivatorUtilities inside MSFT.EXT.DI to instantiate actors so you can blend DI'd and non-DI'd arguments. That being said, we're probably going to be using a Func-based input for Props in the future in order to make Akka.NET more AOT-friendly in v1.6.

Thought I wrote a reply here but maybe I missed it - the big difference is that Props is serializable, so it can be used for remote deployments. It's also able to deal with other configuration issues like customizing the actor's mailbox (i.e. use a priority queue), dispatcher, using a router, and more.

Oh, the resolution of the source code size? yes sorry about that, we probably should ask for users to increase the font size significantly going forward

It's a bug in a popular .NET distributed programming framework? How on earth would that title be clickbait?

Thanks!

That's a great question - so you'd need at least a 3-node cluster in order to even run into this problem (something I probably should have mentioned in the video) and the issue would be that at least two of the surviving nodes would have duplicates. The most robust solution would be to SLOWLY restart both of them - waiting at least 20 seconds between each. That'd remedy the current situation and prevent it from happening again. Detecting the duplicate would be the hardest part, probably, unless you had good OpenTelemetry support that could prove that more than 1 instance of the same entity actor was alive concurrently.

Glad to hear that!

Ah I got the reference to the `IServiceProvider _serviceProvider` by just making that one of my CTOR arguments on that actor

An example of how to do this: github.com/petabridge/akkadotnet-code-samples/blob/master/src/cqrs/cqrs-sqlserver/CqrsSqlServer.Backend/Actors/ProductProjectorActor.cs edit: we wrote and published this sample AFTER the video was made

Unsure - never tried to use it myself

Use Context.System.Materializer when you want to host the Akka.Streams actors as children of the current actor, Context.Materializer if you want them to be top-level actors underneath the ActorSystem. The difference with the former is that you have much more implicit control over the lifecycle of those Akka.Streams graphs - i.e. the graph will always terminate when the parent actor is terminated.

<3

Glad you liked it!

ah, for doing restore or something else?

@@Petabridge correct. You can’t use the “dotnet restore” task. Instead you have to NuGetAuthenticate and then do a restore from a Powershell task.

@@robadobdob is this using the built-in AzDo task or just running the dotnet cli? We implicitly do restores but we just call the CLI commands directly for this

Sure thing - just added a link to the description with it too. You can find the source here: github.com/petabridge/akkadotnet-code-samples/tree/master/src/cqrs/cqrs-sqlserver

“Implement Event Sourcing and CQRS Using Akka.Persistence” - seems pretty clear to me

I had a lot of trouble keeping track of the different measures that were getting used throughout the various projects, so in our benchmarks we use a range of size parameters from 10b all the way up to 8kb github.com/petabridge/TurboMqtt/blob/dev/docs/Performance.md

Performance takes a noticeable dip between 2kb and 8kb and I suspect that's because we're significantly over the TCP max segment size (1140ish bytes IIRC), so each "packet" now requires more work to transmit at the syscall level

In this case, we're going for "better than nothing" without compromising on performance by using a value type, which yes - is fully zero'd by by default(T). Perfect isn't achievable - developers can find a way to still abuse and break things. You'd need a Roslyn Analyzer to catch that, since there's no guarantee with structs that the CTOR will be called.

@@Petabridge wait couldn't you just default it to 1? Value = 1

@@FilipCordasbet you’re right!

@@Stannardian no my bad constructors don't run on default init it just sets the field.

You'll need to use an MQTT broker - before you can use TurboMQTT. EMQX is a simple, high performance one you can get started with

I'll see what I can do - that might merit doing a separate video

Yes, we're working on that!

Our recent video on Spectre.Console demonstrates how to use StreamRefs for this

@@Petabridge thanks for the reply

answer: add something like this to your csproj: <PackageReference Include="Akka.Hosting" Version="1.5.19" /> <PackageReference Include="Akka.Hosting.TestKit" Version="1.5.19" /> write something like this code - using Akka.Hosting.TestKit; var dependencyResolver = DependencyResolver.For(Sys); var props = dependencyResolver.Props<MyLogActor>(); var myLogActor = ActorOf(props, nameof(MyLogActor)); myLogActor.Tell(new MyLogActor.Messages.Create(logFileName)); you can leave your override void ConfigureAkka method empty.

I just used the sample actors from our dotnet new templates here: github.com/akkadotnet/akkadotnet-templates

@@Petabridge great. going to take a look now.

Yes it's weird - I can see it on the cards I added to the video but it's not popping up. Wonder if there's an issue with the YT editor.

Whoops, my bad kzbin.info/www/bejne/boHIn4Wles-NgcU&