Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Oct 18 19:12
    IgorFedchenko commented #3998
  • Oct 18 18:29
    Aaronontheweb commented #3998
  • Oct 18 18:24
    Aaronontheweb opened #3998
  • Oct 18 18:19

    Aaronontheweb on fix-readme-logo

    (compare)

  • Oct 18 17:30
    Aaronontheweb milestoned #3973
  • Oct 18 16:38
    jaydeboer opened #3997
  • Oct 18 15:53
    Aaronontheweb synchronize #3973
  • Oct 18 15:52

    dependabot-preview[bot] on dev

    Bump Microsoft.NET.Test.Sdk fro… (compare)

  • Oct 18 15:52

    dependabot-preview[bot] on nuget

    (compare)

  • Oct 18 15:52
    dependabot-preview[bot] closed #3996
  • Oct 18 15:52
    Aaronontheweb commented #3996
  • Oct 18 14:53
    Aaronontheweb commented #3973
  • Oct 18 12:20
    IgorFedchenko commented #3973
  • Oct 18 12:17
    IgorFedchenko commented #3973
  • Oct 18 11:58
    IgorFedchenko synchronize #3973
  • Oct 18 11:33
    IgorFedchenko commented #3973
  • Oct 18 11:25
    IgorFedchenko synchronize #3973
  • Oct 18 07:04
    dependabot-preview[bot] labeled #3996
  • Oct 18 07:04
    dependabot-preview[bot] opened #3996
  • Oct 18 07:04

    dependabot-preview[bot] on nuget

    Bump Microsoft.NET.Test.Sdk fro… (compare)

Aaron Stannard
@Aaronontheweb
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
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
Aaron Stannard
@Aaronontheweb
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"
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
anyway, like I said - I don't really like making black and white recommendations because everyone's domain and situation are different
Siarhei Filipau
@sfilippov
Hi, guys. I have 30min interval between sending and recieving message between two actors. They use default mailboxes and default dispatchers and they are Singletons. Which way do I need to look?
maybe too large mailboxes?
to11mtm
@to11mtm

@sfilippov could you possibly elaborate?

And are these messages sent at said interval fixed or variable?

Siarhei Filipau
@sfilippov
no, message was sent without interval. But another actor can receive immeidately, after 10 sec, after 5-30 minutes. It depends on loading on the actorsystem
Siarhei Filipau
@sfilippov
How can I get infro from actor's mailbox?
e.g. about messages queue?
Sean Farrow
@SeanFarrow
Is there a reason you need this information?
Siarhei Filipau
@sfilippov
I guess mailbox is crowded, messages do not have time to be processed
Sean Farrow
@SeanFarrow
Okay, the first question is are you doing anything specific in your configuration? If not, what do your actors do?
Siarhei Filipau
@sfilippov
no, I use default mailboxes. First actor (ActorA) sends message to second actor (ActorB), and ActorB every 10 sec sends message to itself. Message ActorB -> ActorB is received in time, but message ActorA->ActorB can be received after long time
Sean Farrow
@SeanFarrow
That makes sense. What are the purposes of these actors? what determines whether ActorB sends messages to itself? Also, are you running this in a docker container? What other processes are running on the machine that run this actor?
Siarhei Filipau
@sfilippov
No, I didn't use Docker. ActorB sends message to itself to check current status of fixture every 10 sec. Nothing any processes except antivirus
ActorB is "check-alive" actor. ActorA notifies ActorB about states of fixture. ActorB checks how long fixture in disconnect/errored state every 10 sec. If fixture in errored/disconnected state after 3 times actorB notifies about it
Every successfull update to ActorA notifies ActorB to reset counter of error
Sean Farrow
@SeanFarrow
Ok, isz this a commercial or pensource project? Is code available as I wonder whether this is the best way of doing things? I'm happy to take this off-line if that helps.Ok, ping me and let's have a chat in the new year. I'm a freelance .net developer with a lot of experience with actor systems.
Siarhei Filipau
@sfilippov
no, it's commercial project
Sean Farrow
@SeanFarrow
has the company had any akka.net training/got any support?
Siarhei Filipau
@sfilippov
I don't know:) I'll ask my manager
Sean Farrow
@SeanFarrow
Ok, If not I would seriously recomend this. Where are you located/would it be useful to have my Email address?c
Siarhei Filipau
@sfilippov
Ok, London
Sean Farrow
@SeanFarrow
@sfilippov I'm in trhe same area, so feel free to contact me at: sean.farrow@seanfarrow.co.uk. What is the company name?
Siarhei Filipau
@sfilippov
Sporting Solutions
Sean Farrow
@SeanFarrow
Ok, Your based in Kennington, if I'm right?
Siarhei Filipau
@sfilippov
yes
Sean Farrow
@SeanFarrow
Ok, ping me, let's have a chat inthe new year. I'm a freelance .net developer with a lot of experience in actor programming and Akka.net specifically.
Siarhei Filipau
@sfilippov
OK, happy new year :)
Bartosz Sypytkowski
@Horusiath
@sfilippov this sounds like your actor actor is not able to keep up with the pace of incoming messages (it's processing requests slower than the new requests are arriving).
Greg Shackles
@gshackles
wouldn't mind some opinions on this, to see if I'm just totally missing something here :) akkadotnet/akka.net#3690
Zetanova
@Zetanova
@angrybug i had the same issue but to store the events for different boundary context a single akka system acting as a platform. I could handle it with the properties of Eventsourced.SnapshotPluginId, and Eventsourced.JournalPluginId. But of course it would be still a problem when u split the storage by tenants and have hundreds of them. Maybe there is a easy why to add/remove PersistentPlugins at runtime. One good extension would be to use persistent proxies that relay the events to a tenant-persistent-store actor system, so software versions would be decoupled by tenants.
I have a conflict of approach where i need some help. I have one pull-feed of transactions from an external source. That need to by queried every 5sec.
Zetanova
@Zetanova
Normaly the timestamp of the last query is stored as a key/value pair somewhere (redis). But that would be near only thing that is stored there, rest would be all realized over eventsourcing
My question would be how to save the last-query-stamp over eventsourcing without boiling it over with events/data?