These are chat archives for akkadotnet/

Dec 2016
Andrey Leskov
Dec 09 2016 10:48
)) welcome to Azure, great cloud but sometimes weird
Maciek Misztal
Dec 09 2016 12:22
Aaron Stannard
Dec 09 2016 18:03
@andreyleskov agreed
I'm still deleting hundreds of resource groups TeamCity created on-demand by accident a couple of months back when we were working on the CI system
cloud equivalent of toxic waste removal
@Silv3rcircl3 so it looks like that TeamCity formatting for NBench has found the worst offender already for the Akka.Streams.Tests.Performance specs
looks like some issue where the minimum throughput can vary a lot (yay concurrency on preemptive operating systems)
Failed at least one assertion or threw exception.

------- Stdout: -------
[Counter] Bracket: Max: 7,973.00 operations, Average: 7,973.00 operations, Min: 7,973.00 operations, StdDev: 0.00 operations
[Counter] Bracket: Max / s: 16,441.10 operations, Average / s: 15,850.27 operations, Min / s: 13,593.64 operations, StdDev / s: 879.99 operations
------- Stderr: -------
[FAIL] Expected [Counter] Bracket to must be greater than 20,000.00 operations; actual value was 15,850.27 operations.
Aaron Stannard
Dec 09 2016 18:10
I haven't looked at the spec itself yet, but given that the number of operations is identical I'm assuming this is written as a RunMode = ThroughPut spec, right?
what can end up happening there.... interesting... this is actually probably a design issue with NBench!
if the first warmup we use, for estimating roughly how many iterations it takes to execute in whatever the duration is you specify, is really slow
which it usually is given that that's when all of the code gets JITed
then the maximum number of iterations the system executes is always going to be fairly low
for each of the benchmark runs
hence why the maximum value, let alone the average value, didn't make it above your threshold here
we should probably not blindly rely on the very first run to estimate how many iterations it takes to fill a second
rather run a few of them and discard the first value, knowing that JIT plays a factor there
essentially this bug means we never generate a sample size that's sufficiently large
if the "estimator" round for a throughput spec has a ton of overhead
does that make sense?
Dec 09 2016 18:31
Forgive me if this has been asked a lot before - I didn't find an answer by googling. It seems like a curious omission in ActorCell.ReceiveMessage not to include the name of the message sender in the logged string. It would be very useful to know this information, but by the time the published message is received by the logger, the sender information is not available, at least as far as I could determine, so I cannot even inject the sender name at that point. Is there a reason the sender name isn't included, and if not could it be added? Second question, is there a way to get a hold of the sender name in the logger with the existing version of Akka.Net that I am not seeing? Thanks.
Aaron Stannard
Dec 09 2016 18:32
that's an interesting point
currently, unless a logging statement specifically tries to log the sender
that information is not captured
I can't think of a good reason why not aside from performance reasons, but honestly if you're writing something to the log and doing string formatting anyway that's kind of a moot point
Dec 09 2016 18:34
I'm using ILogReceive on my actors so I can easily turn on/off the Receive logging, rather than specifically have a log in every receive (which would be kind of a PITA since there's a built-in facility).
Aaron Stannard
Dec 09 2016 18:35
makes sense
yeah, I see your point
would you consider opening up a Github issue and link to the specific logging statement where it'd be useful to capture that information when ILogReceive is on, since you've already been stepping into the code?
Dec 09 2016 18:35
It's already building a string in ReceiveMessage, so I can't imagine there'd be a detectible performance hit.
Aaron Stannard
Dec 09 2016 18:35
yeah, I'm in agreement with you
if you're logging every receive on an actor
you're probably not worried about performance when that setting is on
Dec 09 2016 18:36
Right, it's more of a very useful debugging facility that can easily be disabled.
Yes, I can open a Github issue.
Aaron Stannard
Dec 09 2016 18:37
sounds good
I can't think of a reason not to do that
but some of the other folks who've worked on the low-level stuff might know things that I don't :p
Dec 09 2016 18:38
Thanks! And thanks for making the source accessible. That is super helpful when learning about the dark corners of Akka.Net
Aaron Stannard
Dec 09 2016 18:53
no better way to learn than by diving into those corners
Dec 09 2016 18:58
Issue added: akkadotnet/
Arjen Smits
Dec 09 2016 19:32
I think this PR possibly already addresses this issue ? akkadotnet/
It started off as a bit more then what it is now, which is an extension in the logmessage and an attempt to fix some recursive logging problem
Dec 09 2016 21:09
It looks like 2379 includes a change similar to mine (which is just one line), but it also covers a larger unrelated change as well.
Dec 09 2016 22:11
Hi guys. I've been away (busy) for a while. Just wanted to check on the status of Akka 1.5 with the new remoting model. I'd like to restart my attempt for a WebSockets implementation
Chris Ochs
Dec 09 2016 23:06
I have a game where I have a top level actor that spawns a number of children, so when the client disconnects I stop the top level actor which stops all of the others. But I have one child actor that I need to gracefully shut down, as it interacts with the distributed pubusb extension. Is there a way to do this while still keeping this actor as a child?
also ran into probably not a great behavior with pubsub. If an actor subs to a topic and dies, if I create another actor with the same name sub and publish, the publish just goes into a black hole. No dead letter generated, just nothing
Chris Ochs
Dec 09 2016 23:18
there is also a strange timing component to it also. It works for some amount of time, like under a minute, the stops