that gets periodically refreshed - like once per hour, up to some maximum number of tokens
every time the user makes an API call, you take a token out of the bucket
once the bucket is empty, the user can no longer make any API calls
does that concept make sense?
@lepinay we already have a trace logger
(although it's probably not in the docs... so my bad on that)
getting a HOCON sample...
akka {
loggers = ["Akka.Event.TraceLogger, Akka"]
loglevel = "ERROR"
}
the seed nodes are there to help automate the formation / join process
@joecojabba we cover this in detail in Petabridge's design patterns training, but the correct answer is that if your actor has a longer lifespan than the dependency it takes (like a database connection) then the actor has to be responsible for fetching / replacing that dependency
so the actor can take a factory method (
Func<Neo4JClient> generator) in its constructor or call a static factory somewhere if necessary
the other option is to make it so the actor's lifespan matches the lifespan of the dependency
but you can pay a hefty price when it comes to performance and consistency if you do that - much better to have a long-lived actor that can refresh its db connection
@schatekar it this case
replyMap is accumulated value. Since in your example immutable map is used, when your calling replyMap + (address -> (replyMap(address) + 1)) you're actually returning new map instance with updated key-value pair. This map is then moved as replyMap to the next iteration of foldLeft
(address -> (replyMap(address) + 1)) is Scala equivalent of C# new KeyValuePair<Address, int>(address, replyMap[address] + 1)
waiting on TC to give me a nice green checkmark
then I'll release it
did you know that Polish violinist made a song with familiar title :) https://www.youtube.com/watch?v=6Udold4Pj6s
what if instead of having
Sender, Self, and Parent always dynamically resolve their state using the current IActorContext
what if we just made them auto-properties and assigned those values each time they were updated?
wouldn't that eliminate the need to have to have a closure when using TPL and PipeTo?
or would we still have that issue? I was wondering if the fact that we're actually invoking a function to return the latest Sender / Self / Parent each time is part of the issue
Scala Akka is able to avoid having to do closures for a lot of this stuff because they just use fields
might have even fixed the deadlock issue on #1134
that last art was 2) :D
part
I think that's a JVM / CLR difference then
looks to me like the JVM uses the address of the object being referenced
whereas the CLR looks for the address of a pointer to an object
i.e. the field's pointer
ok well that's good to know
I found a bug in the
TestConductor in the multi-node testkit that your Roslyn analyzer also found
caused tests that use throttling to crash