Where communities thrive


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

    Aaronontheweb on dev

    Provide static GetRoutees.Insta… (compare)

  • Oct 14 17:16
    Aaronontheweb closed #3974
  • Oct 14 17:16
    Aaronontheweb milestoned #3974
  • Oct 14 16:05
    jackowild opened #90
  • Oct 14 15:08
    Aaronontheweb commented #3974
  • Oct 14 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
David Smith
@smalldave
it is nice to watch that kind of functionality working in the multi-node tests. hopefully it will happen a bit more often now
the majority of the issues actually seem to be in the test framework :)
jcwrequests
@jcwrequests
@rogeralsing Thanks it's nice to know that at least someone reads my blog. :smile:
jcwrequests
@jcwrequests
@Horusiath @rogeralsing @Aaronontheweb So it's not a good idea for using resizers with the hashpools For the reason that while a sizing action occurs I risk a message that should have went to Actor B goes to say Actor C. Do I have that right? The main reason I want to use this combination is to safely allow for multiple writers to my EventStore and ensure that always the same writer used for a particular aggregate. I wonder if there is a way to to stop all message processing, resize the rebalance all the messages. Much like what happens in a Cassandra cluster when a new node is added. To mitigate the costly rebalancing I would have to have a larger amount of actors pre allocated on start up. Is that something that could theoretically be done? Even if it's not I might be able to mitigate the risk on the data store end. What are you thoughts?
Aaron Stannard
@Aaronontheweb
@jcwrequests yes, that's correct - the risk really comes from how rapidly the resizer fires
can be tuned with settings, but if you have a bursty workload it can be really unpredictable
the amount of time it takes the hashrange to change in the new release is pretty close to instant - it's an atomic CAS operation
but under really large workloads, it's possible that some messages will be mis-routed
the real problem comes from having state fragments spread across the routees
whenever the routee pool changes
without using Akka.Persistence to merge state
it's going to be an issue
so my recommendation is to avoid the Resizer there - I should have mentioned to this you earlier; my fault
are you using Akka.Cluster at all?
jcwrequests
@jcwrequests
@Aaronontheweb I am just in the proof of concept phase right now. But I still I wonder if there is a way around this issue. Currently I use a single writer pattern in which I have to look up all the events load them into the aggregate run an invariant check then commit the results as versioned events. What I liked about the resizer and hash pool combo was the elasticity. When an actor being the aggregate is no longer needed it would just shutdown but if it was used constantly being used there was no need to reload it just to the invariant check then move on. Still the hash pool is still a good idea I just need to determine the a good number of actors in the pool at startup. That value could be a configurable value and a system restart would solve the resizing. It just to bad you can't send a message to all the actors to stop processing and then once the are done processing pump all their messages back through the system hasher to rebalance.
jcwrequests
@jcwrequests
@Aaronontheweb I was trying to find the config info for NrOfInstances in the cluster config link https://github.com/akkadotnet/akka.net/blob/dev/src/core/Akka.Cluster/Configuration/Cluster.conf you sent yesterday but it's not there. I will keep looking. I will be fine with the pool for now. Maybe as the framework matures that will be addressed :>. Cheers!!!
Bartosz Sypytkowski
@Horusiath
@HCanber did you started to work with CircuitBreaker yet - I've created some general purpose CircuitBreaker with support for async code, non-locking state switching and test suite
maybe it could be usefull
Bartosz Sypytkowski
@Horusiath
it's available here - maybe I'll write a blog post about it
jcwrequests
@jcwrequests
@Horusiath Writing a post would be a good idea. The code looks really interesting and it would cool to see how you came up with your implementation. If I where in the Poland I would buy you a cold beer 🍺 and we could discuss it but a post will do.😊
Aaron Stannard
@Aaronontheweb
@jcwrequests here's an example of NrOfInstances:
common-router-settings = {
                        router = consistent-hashing-pool
                        nr-of-instances = 10
                        cluster {
                            enabled = on
                            max-nr-of-instances-per-node = 2
                        }
                    }
(from my latest PR)
jcwrequests
@jcwrequests
Thanks @Aaronontheweb . I am getting a strange symptom with this config. If I don't specify var pool = new ConsistentHashingPool(config);
pool.NrOfInstances = 10;
pool.NrOfInstances = 10 in the code is does not function. Shouldn't just specifying in the config be enough or am I am missing something?
Aaron Stannard
@Aaronontheweb
hmmm
not sure
I changed all of that stuff in my latest PR
rewrote consistent hashing routers from scratch basically
so I can't remember how the old stuff is supposed to function :p
however, it should work
jcwrequests
@jcwrequests
Let me rephrase that if I don't add the pool.NrOfInstances = 10 in the code is does not function but it I do it works fine. Seems like something is not correct. Here is what I have
akka.actor.deployment {
        /router1 {
           router = consistent-hashing-pool
                    nr-of-instances = 10
                    cluster {
                        enabled = on
                        max-nr-of-instances-per-node = 2
                    }

            }
Aaron Stannard
@Aaronontheweb
ahhh, this is with clustered consistent hashing pools?
jcwrequests
@jcwrequests
Yup
Aaron Stannard
@Aaronontheweb
haha.... yeah, that was a fun bug to fix: akkadotnet/akka.net#707
I rewrote all of the ActorOf methods in order to make that work
because they didn't properly chain configs
in that PR they will
should have that merged in soon unless someone sees something they don't like
it's big so I'll give it a couple more days
jcwrequests
@jcwrequests
No problem. Just wanted to be sure I was not going crazy.
Aaron Stannard
@Aaronontheweb
no, you're not
I experienced the same problem
when I was working with them
jcwrequests
@jcwrequests
Otherwise they have been really simple to setup and test.
Aaron Stannard
@Aaronontheweb
glad to hear it!
jcwrequests
@jcwrequests
They work perfectly with the IOC extensions.
Aaron Stannard
@Aaronontheweb
that reminds me, btw - did you get a chance to see this issue about IOC? akkadotnet/akka.net#706
err, DI
jcwrequests
@jcwrequests
Nope. I will take a look.