akkadotnet/akka.net

Port of Akka actors for .NET

Onur Gumus

@OnurGumus

by checking ToSequenceNr == 0

Onur Gumus

@OnurGumus

@Horusiath and regarding that do you think extending FunPersistentActor as below is ok?

type FunPersistentActor2<'Message>(actor : Eventsourced<'Message> -> Effect<'Message>, recovery)  =
    inherit  FunPersistentActor<'Message>(actor)
    override __.Recovery  = recovery

let propsPersist2 (receive: Eventsourced<'Message> -> Effect<'Message>, recovery) : Props<'Message> =

        Props<'Message>.ArgsCreate<FunPersistentActor2<'Message>, Eventsourced<'Message>, 'Message>([|receive,recovery|])

joowon

@HIPERCUBE

@angrybug Here is my configuration

I tried both of them

Bartosz Sypytkowski

@Horusiath

@OnurGumus it was originally created so that you don't need to think if actor is new or not (how would you know it, if a machine can crash)

Peter Huang

@ptjhuang

@HIPERCUBE had another look at your first snippet, have you try adding await/Wait()

Ilya Komendantov

@IlyaKomendantov_twitter

Hey guys,
The situation:

Players have inventory with items
Shops have the same items
Items have different parameters
The parameters of the item can change.

How to store this data correctly?

I'm going to store only Guid and amount of the item
Also I'm going to have a Resolver that keeps the description of each item (by Guid)
But everytime when player is asked about item, it needs to resolve it first (the same for shops). This will probably create a huge load for Resolver..
I can create a PersistentActor for each item with the PersistentId = Guid. Then I can get this actor by Context.ActorSelection("../Guid") , how about performance here?
The projections can be used, but the parameters of the item I need in a lot of different places, will this work?

Can you suggest the best practice for such scenario?

Peter Huang

@ptjhuang

@HIPERCUBE the using block kills the materializer before it has a chance to run.

Onur Gumus

@OnurGumus

@Horusiath just in case will my above code work for akkling?

Aaron Stannard

@Aaronontheweb

@/all Akka.NET v1.3.11 is now live on NuGet https://twitter.com/AkkaDotNET/status/1075064280804925442

@HIPERCUBE having some trouble following all of the threads in Gitter chat here - I'd be happy to help though. Would you mind opening a Github issue with all of this in a single thread?

that'd be really helpful for me!

joowon

@HIPERCUBE

@angrybug Thanks so much!
Now it works :)

atresnjo

@atresnjo

When using Become, for some reason one of my Receive never gets triggered and the message ends up Unhandled. Anyone an idea what I could be doing wrong? Checked the type, and it's 100% correct. It feels like my last Receive doesn't replace the previous one or something.

Chris G. Stevens

@cgstevens

After my demo at work I was ask how Akka.Net comes to service mesh. The implementation to compare is Istio.
Can you even compare the two? I have some reading to do but figure I would ask if anyone know about what concepts overlap and why use one over the other.
Besides the fact it doesn't do anything with Actors.. more of the managing of the microservices I guess... Will need to read up on it.
Any info would be great! I am trying to sell Akka.Net here at my new place of work. Had the first part of my demo today which I felt like it went really well.
Will finish tomorrow but this was one of the questions.

Peter Huang

@ptjhuang

What's a good design for Akka Persistence using different event stores? i.e. in a multi-tenancy setting where each tenant needs a separate event store database (read connection string)? Looks like someone tried to do this: https://stackoverflow.com/questions/49776339/akka-net-config-multi-tenant, but what if you have a large number of tenants (does Hcon scale to 50k lines)? Another alternative I'm considering is using custom AsyncWriteJournal/SnapshotStore that changes write location based on PersistenceId - is that a good idea?

to11mtm

@to11mtm

@cgstevens I almost feel like the two are on slightly different layers... Akka.NET with clustering can act as sort of a service mesh, but it looks like Istio is a higher level of abstraction.

IMHO, from an architectural standpoint Istio looks like it does a lot.... possibly too much. That's an opinionated statement, but concepts like Authentication should be handled at the API Gateway level and not at a service mesh level.

Also, looks like if you're not using Kubernetes... good luck?

(I don't trust google.)

to11mtm

@to11mtm

(Broader opinionated statement) I'm always careful of libraries/frameworks that are backed by massive corps like Google/IBM (and even MS; see: EF). They have a lot of organizational/process strength to enforce rules that go with making large frameworks work well. Smaller shops, it's often a very difficult battle.

OTOH, This has been re-hammered into me because I'm on a team with only 4 devs in the entire company right now. ;_;

Bartosz Sypytkowski

@Horusiath

@angrybug you can use different stores per actor type, but not per persistenceId, if this is what you are asking for

Peter Huang

@ptjhuang

@Horusiath that's a shame - what would you suggest for multi-tenancy requirement like that, where the event store needs to be separate for each tenant? i was hoping there's some way for each actor instance to signal which store it should live in, but the design doesn't seem to allow that naturally. Would you say a better approach be to use the persistence store as a "temporary" event store, then replay it to separate the entries into the tenant-specific stores? (duplicated data etc)

On another note, how often do AkkaContrib pull requests get processed? I noticed the last one was in March for MongoDb persistence repo. Was hoping to not have to make our own nuget packages in private repo in the mean time.

Bartosz Sypytkowski

@Horusiath

@angrybug it really depends on the people's occupation. I can review your PR eventually, but it's 2k lines of code and I'm pretty tight on time myself ;)

regarding multi-tenant event stores, you'd probably need something customized

Aaron Stannard

@Aaronontheweb

After my demo at work I was ask how Akka.Net comes to service mesh. The implementation to compare is Istio

Honestly, Akka.NET eliminates the need for a lot of infrastructure like Istio

Istio and service mesh technologies in general are designed for making it easy to connect stateless microservices together, because these types of technologies inherently have no concept of "topology" built into them

(because they are stateless)

Akka.Cluster pushes topology awareness into every node inside the system, because fundamentally all of those services are peers in a peer-to-peer network

not stateless client-server services

therefore, I don't need a central point for looking up the address of services

knowing which nodes are up or down

or routing messages to them

this is all decentralized in Akka.Cluster - all of the data and infrastructure needed to do that is available locally on each node

the stuff Istio provides that you don't get out of the box with Akka.NET would be stuff like the access control policies and built-in tracing

Aaron Stannard

@Aaronontheweb

in terms of what a large company needs, infrastructure-wise

if your company is thinking in terms of making it easy to form large networks of HTTP services that need to work together, Istio might be worth investing in - maybe. Depends on the number of services and developers working on it

Akka.Cluster is more for building fast, real-time services that work cooperatively together

you probably don't want a gigantic Akka.Cluster that every single possible service in your company is a part of

designs I've supported for large-scale adoption of Akka.NET look like having multiple clusters, one for each "product" within the company - that product usually consists of 4-10 services, and these clusters communicate with each other when necessary by either passing messages through something like Kafka or calling HTTP APIs on top of each other. This gives those products the ability to be maintained and managed by totally separate teams

this design also allows products that don't intrinsically need Akka.NET themselves to still benefit from having those clusters around - i.e. a CRUD service that needs to read some output from the cluster and serve it up to a reporting tool or an HTTP API

maybe integrating those clusters inside a service mesh would make sense for scenarios like that

I don't want to be too prescriptive and give any recommendations that sound like "always do X" or "never do Y"

Aaron Stannard

@Aaronontheweb

so those are my thoughts on the subject

does that make sense @cgstevens ?

to11mtm

@to11mtm

@Aaronontheweb Thanks for this, as we've been having discussions about Service meshes as well and Akka has come up but people worry about a distributed monolith. I wasn't able to put what you just said into words, but now I can at least use some of yours. ;)

Aaron Stannard

@Aaronontheweb

@to11mtm happy to help

I abhor complexity in my infrastructure

I want as few moving parts as I can manage

so you wouldn't see me moving towards something like a big service mesh unless I had dozens and dozens of services that all needed to be exposed to each other

because my chief concern isn't really the technical side of things - it's the human cost part of the equation. It's yet another thing we have to standardize and train people on and manage during deployments

Where communities thrive

People

Repo info

Activity