Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Dec 12 15:42
    Aaronontheweb synchronize #4086
  • Dec 12 15:42
    Aaronontheweb closed #4083
  • Dec 12 15:42

    Aaronontheweb on dev

    Fix #4083 - Endpoint receive bu… (compare)

  • Dec 12 15:42
    Aaronontheweb closed #4089
  • Dec 12 15:42
    Aaronontheweb labeled #4093
  • Dec 12 15:42
    Aaronontheweb labeled #4093
  • Dec 12 15:42
    Aaronontheweb labeled #4093
  • Dec 12 15:42
    Aaronontheweb opened #4093
  • Dec 12 14:20
    Aaronontheweb commented #4092
  • Dec 12 14:14
    Aaronontheweb labeled #4089
  • Dec 12 14:14
    Aaronontheweb labeled #4089
  • Dec 12 14:11
    Aaronontheweb synchronize #4089
  • Dec 12 14:10
    Aaronontheweb synchronize #4086
  • Dec 12 14:09

    Aaronontheweb on dev

    Convert to ImmutableHashSet for… (compare)

  • Dec 12 14:09
    Aaronontheweb closed #4090
  • Dec 12 12:04
    nagytech synchronize #4092
  • Dec 12 11:53
    nagytech synchronize #4092
  • Dec 12 11:49
    nagytech edited #4092
  • Dec 12 11:40
    nagytech opened #4092
  • Dec 12 11:32
    nagytech edited #4091
joowon
@HIPERCUBE
I tried both of them
Bartosz Sypytkowski
@Horusiath

if I create a persistent actor from scratch, does it go to database on its recovery phase ?

@OnurGumus by default, yes.

Onur Gumus
@OnurGumus
@Horusiath This is actually causing an issue for me. My Event Journal table contains millions of records. It is inefficient to go to database whenever I create a brand new persistent actor.
What can I do about it ?
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:

  1. Players have inventory with items
  2. Shops have the same items
  3. 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. ;)