Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 20:06
    IgorFedchenko synchronize #3973
  • 20:06
    IgorFedchenko synchronize #3973
  • 19:42
    IgorFedchenko edited #3973
  • 18:08
    Aaronontheweb commented #3937
  • 17:27
    Aaronontheweb commented #90
  • 17:26
    Aaronontheweb commented #90
  • 17:25
    Aaronontheweb assigned #90
  • 17:16

    Aaronontheweb on dev

    Provide static GetRoutees.Insta… (compare)

  • 17:16
    Aaronontheweb closed #3974
  • 17:16
    Aaronontheweb milestoned #3974
  • 16:05
    jackowild opened #90
  • 15:08
    Aaronontheweb commented #3974
  • 15:08
    Aaronontheweb commented #3974
  • Oct 13 14:40
    cptjazz synchronize #3974
  • Oct 13 14:07
    cptjazz opened #3974
  • Oct 13 08:30
    ismaelhamed commented #3937
  • Oct 12 15:50
    IrvinDominin opened #127
  • Oct 11 18:21
    Aaronontheweb commented #3973
  • Oct 11 18:20
    Aaronontheweb commented #3937
  • Oct 11 18:16
    Zetanova commented #3937
Yin Zhang
@melcloud
@aachinfiev I see. Are you treating them as routee? You want to handle each request with one actor, or just has a pool/group persistence actor to handle all the requests?
Alex Achinfiev
@aachinfiev
@melcloud I have AggregateCoordinator that spawns AggregateRoot per entity (DDD) and I am importing a lot of events. There is a separate coordinate per each type of entity. But there could be lots of entities for a given type. And events can come fast during import. E.g. 100k in a row for a security coordinator.
Yin Zhang
@melcloud
I see. I don’t see the problem of keeping them alive if they are boudned (e.g. 1000). Because relatively they are doing anything. However, I don’t think you should spin up 100k - 500k persist actor, as you may open that many connections at the same time. It is not great idea. Perhaps think about back pressure and akka stream?
Alex Achinfiev
@aachinfiev
Akka Streams is something I want to move at some point, but I am not able to get there just yet. Isn't persistence actor can only represent a single entity by design? I didn't think you can dynamically swap it's persistence Id to handle more than one unique entity.
Bartosz Sypytkowski
@Horusiath
@aachinfiev what persistent backend are you using?
Alex Achinfiev
@aachinfiev
Akka.Persistence.Cassandra (1.0.6) atm with Akka.Persistence 1.0.6 because it's not compatible with 1.2.0 yet
If I could spawn a fixed number (say M = 1000) of persistent actors to handle N (say 100k) entities and each new id dynamically replays state for new message that would work. But I don't know if it works that way.
Bartosz Sypytkowski
@Horusiath
@aachinfiev having 100k-500k actors may not be that bad (you probably relax amount of memory used by the process). If you're going to use them anyway within close time range, it's better to have them in memory than trying to kill some of them and respawn on demand -> latter is much more expensive.
Alex Achinfiev
@aachinfiev
Using sharding won't help me here, since I don't want to keep all 100k of them in memory regardless.
100k-500k is an arbitrary number. I can have other record types during import that may go into millions.
Most of the requests are for a new entity .. with sometimes updates to existing one during same import
Bartosz Sypytkowski
@Horusiath
I would measure how much memory does it take. Probably few GB
Alex Achinfiev
@aachinfiev
And after each import send a purge request to reclaim memory? I have a number of services running and box has only 8 - 16gb in total.
Bartosz Sypytkowski
@Horusiath
@Kavignon you must clearly define actors relationship. Because actors that can be either created or already active doesn't fit master-slave scenario (as slave may be already there, where master is being created or I get your case wrong)
@aachinfiev actor-based systems are stateful by default, and this also means they'll consume a lot of memory. Maybe actor-per-entity is not a good option for you, and you need something lighter indeed
Bartosz Sypytkowski
@Horusiath
(if you really need, you may fabricate a message that persistent actor sends to its journal when it's going to persist an event: see example)
Alex Achinfiev
@aachinfiev
So you directly communicate with Journal rather than making a persitentactor do one message at a time?
I.e. pool a set of messages and then batch them to journal to persist
Bartosz Sypytkowski
@Horusiath
I'm using this when I want to have compatibility with akka.persistence protocol without actually creating thousands of actors
for persisting multiple events at once you may just use PersistAll method
Alex Achinfiev
@aachinfiev
Your first point is my use case for the import case. Looks very interesting. I need to check that out. Thanks :)
Michael Chandler
@optiks
Hello. Is it possible to intercept ICanTell.Tell()? I'd like to add some logging. Or would this be better done by monitoring the mailbox or
  • or some other means.
Basically, I want to be able to visualise the messages flying around. I'd like to generate a sequence diagram or similar. AroundReceive works for the receiving side, but not the sending side.
Aaron Stannard
@Aaronontheweb
@optiks on the sending side...
unfortunately I don't think you can intercept the .Tell operation without using something like PostSharp to do IL weaving
since that's built into objects like all of the IActorRef implementations
Kevin Avignon
@Kavignon
@Horusiath Well I'd Actor A to start first and it starts 4 actors at different moments. And once they're not useful any more, I'd like to dispose of them
Michael Chandler
@optiks
@Aaronontheweb Thanks. I had a poke around and came to the same conclusion. It would be a nice extensibility point :)
Michael Chandler
@optiks
Hacky workaround is to use an extension method. i.e. Duplicate ActorRefImplicitSenderExtensions. It just needs to be defined in each project due to scoping.
Aaron Stannard
@Aaronontheweb
@to11mtm yeah, we're going to bring that back into the picture
I'd be up for releasing that now
seen a couple of interesting ideas
one is the aftorref caching
the other is lazily creating the remote actor ref
for the sender
if it's not needed
@schepersk dude, I'm so sorry - looks like I totally missed your messages over the past week
do you still need help with those cluster issues?
Bartosz Sypytkowski
@Horusiath
@Kavignon with standard akka.fsharp you can use mailbox.Context.Child(name) to try to get the child from the parent by name. If such actor didn't exist, it will return ActorsRefs.Nobody as a reference.
Aaron Stannard
@Aaronontheweb
seems weird to me that now that we have TeamCity formatting for NBench all of our performance specifications suddenly stop being racy again
the concurrent programming version of the observer effect :p
Sean Farrow
@SeanFarrow
@aaronontheweb is that just on the server or building locally as well
Aaron Stannard
@Aaronontheweb
@SeanFarrow building locally it's worked fine for the most part. We had issues on the server where the time-sensitive Akka.Streams NBench specs would fail
5ms deadlines on some of them
Aaron Stannard
@Aaronontheweb
blob
there we go
we're going to be adding this to the Multi node test runner as well
that'll allow TeamCity's "flaky tests" report to help signal to us where we need to go spend some time hardening stuff
the benchmarking stuff is a bit harder to fix mostly because benchmarking concurrent code is a dark art