I'll take a look at that
I've had a spec written down on paper, quite literally - in my notebook, for Helios 2.0 and I'm desperate to work on it because I think it'll finally be easy to work directly with Helios once I've made those changes :p
Helios' current API is simple but not the most intuitive
had to rewrite our Murmur3 implementation in order to support it
(followed the Scala implementation - it wasn't so different from mine, just optimized for being able to construct a hash in discrete steps)
(rather than treating it like a black-box all-or-nothing operation)
@/all Unit2 for Akka.NET bootcamp is now available ;) https://github.com/petabridge/akka-bootcamp/tree/master/src/Unit-2
group routers don't manage their routees
however, for turning on a resizer with consistent hashing pools
let me see if I can find a config example for that - about to head out but I'm in the middle of updating all of the consistent hashing routers now
brought them up to code with JVM akka, includes fun stuff like virtual nodes
Once I get that done I may see if I have any Azure time left at work and try a stress test. My small Asus Ultra slim with an i5 is not the best for that sort of thing. Thanks again. I am will talk to you soon. Signing off here on the east coast.
One last thing I am blogging all about this experience so I may ping you with some research questions. Cheers and have a good one.
I'm seeing PR:s (like #689 and #691) with no explanation to why they are submitted. I think A PR should at least have a sentence or two explaining why the changes are being made and what the changes are, even if it's only white space changes. In the case of #689 several bugs were introduced. An explanation to why the changes were made could have saved me some time, instead I had to decipher what was done, and trying to figure out why it had been changed. Thoughts?
Håkan, to get the community onboard, the more interest the better, and even if a PR is just ws, if it makes the code cleaner, why not? And regarding the child stats bug, thats on us if we dont have test coverage for it, the intended behavior cant just be in someones head. We do need more tests, and now we found a place where we could improve it.
since tests are failing randomly for any reason
I picked that size for the build server because that's the sort of VM I'd expect a basic Akka.NET application to run on on Azure
on my build machine the entire test suite passes pretty reliably most of the time, although some of the same tests that fail on the build server occasionally fail here too but way less often
err, development machine :p - giant Asus gaming laptop with 4 intel core i7s
I think the stuff that fails is either inherently racy or we're running into some system resource issue that causes tests with realtime constraints (i.e. expect message within 3 seconds) to timeout
so I've tried doing stuff like adding explicit garbage collection during the shutdown or every TestKit run
to help eliminate GC pauses as a potential issue
and others
but still, these few tests are a pain in the ass ;p - I will work with you to help fix them and would love everyone else's help too
getting that green check mark at the end of each commit
makes everyone feel good :shipit:
btw. I occasionally find that JSON.NET is failing while trying to serialize messages with an error inside
maybe we should enable
Exception(SerializationInfo info, StreamingContext context) to be reached from AkkaException and inheriting classes?
var config = ConfigurationFactory.ParseString(@"""akka://MySystem/user/Worker1"" #testing full path
user/Worker2
user/Worker3
user/Worker4
]");
using (var system = ActorSystem.Create("MySystem"))
{
var resizer = new DefaultResizer(3, 5, pressureThreshold: 1, rampupRate: 0.1d, backoffRate: 0.0d,
messagesPerResize: 1, backoffThreshold: 0.0d);
var pool = new ConsistentHashingPool(config);
pool.Resizer = resizer;
var router = system.ActorOf(Props.Create<TypedWorker>().WithRouter(pool));