Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Oct 25 19:19
    SeanKilleen edited #5312
  • Oct 25 19:16
    Aaronontheweb commented #5312
  • Oct 25 19:16
    Aaronontheweb milestoned #5312
  • Oct 25 19:16

    Aaronontheweb on dev

    Markdown linting: build steps a… (compare)

  • Oct 25 19:16
    Aaronontheweb closed #5345
  • Oct 25 19:16
    Aaronontheweb closed #5312
  • Oct 25 19:16
    Aaronontheweb labeled #5345
  • Oct 25 16:31
    Aaronontheweb commented #4530
  • Oct 25 16:14

    dependabot[bot] on nuget

    (compare)

  • Oct 25 16:14
    dependabot[bot] closed #5219
  • Oct 25 16:14
    dependabot[bot] commented #5219
  • Oct 25 16:14
    dependabot[bot] labeled #5346
  • Oct 25 16:14
    dependabot[bot] opened #5346
  • Oct 25 16:14

    dependabot[bot] on nuget

    Bump FluentAssertions from 5.10… (compare)

  • Oct 25 15:39
    SeanKilleen edited #5312
  • Oct 25 15:39
    SeanKilleen commented #5312
  • Oct 25 15:22
    jonnydee commented #4530
  • Oct 25 15:20
    SeanKilleen edited #5312
  • Oct 25 14:51
    SeanKilleen opened #5345
  • Oct 25 13:57
    jonnydee commented #4530
David Smith
@smalldave
the jvm version is
  // start periodic publish of current stats
  val publishStatsTask: Option[Cancellable] = PublishStatsInterval match {
    case Duration.Zero | _: Duration.InfiniteNone
    case d: FiniteDurationSome(scheduler.schedule(PeriodicTasksInitialDelay.max(d), d, self, PublishStatsTick))
  }
Aaron Stannard
@Aaronontheweb
yeah, if we set a task for 0
then I don't think the scheduler actually uses the TPL at all
I think it just executes it line
inline*
but the thing is, that would technically put the actor into an infinite loop, wouldn't it?
if the interval is 0?
yeah, that would spam up the mailbox
David Smith
@smalldave
yep
Aaron Stannard
@Aaronontheweb
first time the scheduler runs it has a real delay
but from that point onward the thread would write an infinite number of messages to itself
so yeah, that's got to be it
If I change my >= to > that should do it
David Smith
@smalldave
hope so. sorry about that. pretty nasty bug
would explain why I turned it off!
Aaron Stannard
@Aaronontheweb
actually I think that's a two-part bug
the scheduler should absolutely not allow a value of zero for the interval
for this very reason
should have a Guard.Assert in there
this was helpful Dave - mystery solved
hopefully
now I just need to figure out how I broke programmatically configured cluster routers, and then I'm all set :sparkles:
David Smith
@smalldave
excellent
Aaron Stannard
@Aaronontheweb
been porting the routing multi-node specs
so far so good - favorite test is the one where I kill off a node and watch the consistent hash router automatically adjust its hash ring
David Smith
@smalldave
i need to get back on to this. i've got some stuff to get finished up at work and then I should have some time to look at this again
Aaron Stannard
@Aaronontheweb
sounds good - I've been really impressed at how well Akka.Cluster has performed in all of the multinode tests
with the exception of that bug
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)