These are chat archives for akkadotnet/akka.net

19th
Feb 2015
Aaron Stannard
@Aaronontheweb
Feb 19 2015 01:59
@rogeralsing I figured out what's going on with routers - it affects all routers. There's a design flaw in the RoutedActorCell
going to write some notes down on it, but it involves some of the changes we're making to dispatchers and the core ActorCell itself
TL;DR; routers are not supposed to be using mailboxes for certain operations, but they currently are.
some of these tests are hitting an edge case where the mailbox has been swapped to deadletters, but that message should have bypassed the mailbox entirely
Aaron Stannard
@Aaronontheweb
Feb 19 2015 04:26
@rogeralsing dang! I was wrong about that. Issue is still something else then
Aaron Stannard
@Aaronontheweb
Feb 19 2015 06:43
in order to run SandCastle in our build process, do I really have to install this .MSI on our build agents?
Natan Vivo
@nvivo
Feb 19 2015 13:33
Hi @all, are there any plans to provide an "async" UntypedActor in Akka?
I just implemented one for my personal use: https://gist.github.com/nvivo/432f55caa959afcb93a1
Sorry, didn't know gist expands like this here
Natan Vivo
@nvivo
Feb 19 2015 14:28
I can do a PR if you find it useful.
Roger Johansson
@rogeralsing
Feb 19 2015 15:02
That is pretty genious how you deal with re-entrant messages there, please do a PR, I'd like to take a peek at it :)
Roger Johansson
@rogeralsing
Feb 19 2015 16:01
@nvivo the ExceptionDispatchInfo I should use that in the ReceiveActor.Receive too, right? currently I re-throw the exception on the task.
never seen that one tbh
Natan Vivo
@nvivo
Feb 19 2015 16:03
Yeah, I just found that too here: http://stackoverflow.com/a/20170583/1902354
it keeps the stack trace from the previous exception. I was getting the stack trace from my code before this
Roger Johansson
@rogeralsing
Feb 19 2015 16:04
hehe I was bitten by the same async void problem, thought I was going crazy untill I understood what was happening :)
Natan Vivo
@nvivo
Feb 19 2015 16:05
the only "problem" with this code currently is that I need to keep a reference to self/sender if I want to tell messages after await
but I saw you are working on a taskdispatcher that would keep the context. would it work for this too?
Bartosz Sypytkowski
@Horusiath
Feb 19 2015 16:13
hi all, sorry if I was unresponsive, but I was on a holiday for last weekend
Roger Johansson
@rogeralsing
Feb 19 2015 16:13
yepp, that works great, it does allowasync state to flow between the continuations
Hi @Horusiath. I think @Aaronontheweb had some issues with the persistence stuff in the new build server :)
Natan Vivo
@nvivo
Feb 19 2015 16:20
I also built an "AsyncFSM" actor using the same logic, I'm still testing but seems doable
I'll try to replace my old code with that, and if it works fine I'll do a PR as well for analysis
Roger Johansson
@rogeralsing
Feb 19 2015 16:21
:+1:
See the AsyncAwaitSpec, those tests should probably be replicated for UntypedActor in that case
Bartosz Sypytkowski
@Horusiath
Feb 19 2015 16:22
Do you think that making an Async... actor versions for everything is a good idea?
Natan Vivo
@nvivo
Feb 19 2015 16:22
I'll take a look. need to understand this testkit stuff
Roger Johansson
@rogeralsing
Feb 19 2015 16:23
We should probably look into what can be done there, but a PR for UntypedActor atleast shows if it will work as intended. so we know if its worth investigating
Natan Vivo
@nvivo
Feb 19 2015 16:23
For reference, I tried to make this as extension methods for FSM
but didn't work as expected
I think the problem is that async requires a state machine to replicate the behavior of normal actors. If you could block, everything could be done with extension methods
One idea that could work is that you could think of tasks as first class citizens on current base actors, and have synchronous code as an optimization. There is not a lot much overhead from returning a completed task... if that was the case, it could even use a different stash that didn't interfere with the one the user uses for other stuff.
Natan Vivo
@nvivo
Feb 19 2015 16:28
But that changes a lot of things..
Roger Johansson
@rogeralsing
Feb 19 2015 17:15
@Aaronontheweb that ParsingSpec, didn't you fix that? it still fails on the node log formats
Aaron Stannard
@Aaronontheweb
Feb 19 2015 17:25
@rogeralsing I did fix that, but that's when I started having those mailbox issues with the MultiNodeTestKit
haven't checked the code in yet
Roger Johansson
@rogeralsing
Feb 19 2015 17:25
oki
Aaron Stannard
@Aaronontheweb
Feb 19 2015 19:28
turns out that the ResizablePoolActor didn't inherit from RouterPoolActor this entire time
that explains a lot
awfully hard to downsize a router if you can't handle Terminated messages
Roger Johansson
@rogeralsing
Feb 19 2015 19:29
woot!?
Aaron Stannard
@Aaronontheweb
Feb 19 2015 19:30
btw, to get SandCastle support on the build server
looks like I'm going to have to install this and add it to the path
so I'll try to take care of that this weekend - will need to update the build agent image
otherwise I'd have to bundle a lot of binaries into the repo
Roger Johansson
@rogeralsing
Feb 19 2015 19:33
ok ok
btw. sandcastle is slow as f## so the builds will probably take a while
Aaron Stannard
@Aaronontheweb
Feb 19 2015 19:33
I'm only going to have it run on release builds
or on dev builds (for latest unstable)
won't run it on pull requests
takes about 10 minutes to do the entire test suite + MSBuild right now
Aaron Stannard
@Aaronontheweb
Feb 19 2015 19:39
once we start running the MultiNodeTestKit regularly that will tack on another 10-15 minutes easily
so yeah, long build time :p
Aaron Stannard
@Aaronontheweb
Feb 19 2015 20:24
@rogeralsing is there any reason why MessageQueueMailbox isn't the Mailbox base class?
one of the reasons why these router and receivetimeout specs are going nuts is they depend on checking the HasMessages property of the mailbox
it'd be easier to implement this feature consistently across all mailbox implementations if we could make that a feature of the MessageQueue
I'm noticing that this is coming up as a race condition in the Resizer tests as well as ReceiveTimeout
Mailbox.HasMessages and such
the ReceiveTimeout spec started failing more often when I started having the mailbox count system messages
towards the MessageCount
Roger Johansson
@rogeralsing
Feb 19 2015 20:27
The concurrentqueue mailbox is optimized for throughput, it doesnt support the same stuff as the other mailboxes. might still be a good idea to do this, but we'd lose some of our nice throghput
Aaron Stannard
@Aaronontheweb
Feb 19 2015 20:28
that would show up in our PingPong benchmark, right?
because if that's the case, I'd be willing to benchmark it - the issue is now that the default mailbox doesn't do what everything else that depends on the Mailbox API expects
doesn't really impact live applications
at least on the surface
but all of these unit tests expose it as an issue
Roger Johansson
@rogeralsing
Feb 19 2015 20:32
Why cant we use HasMessages on the Mailbox baseclass?
Aaron Stannard
@Aaronontheweb
Feb 19 2015 20:33
that's what we are using currently
Roger Johansson
@rogeralsing
Feb 19 2015 20:33
ok, but what would the difference be? we call a method "somewhere" that reports the current message count, right?
Aaron Stannard
@Aaronontheweb
Feb 19 2015 20:33
but the issue is that the NumberOfMessages property (which HasMessages depends on) is supposed to derived from the Counts of the MessageQueu
Queue*
looking at Akka's mailbox implementation, it looks like you can configure based on the type of queue whether or not system messages count against that total
do you know what the default configuration is offhand?
because maybe I screwed up by making it count system messages
just trying to get TeamCity to show that :white_check_mark:
Roger Johansson
@rogeralsing
Feb 19 2015 20:36
hmm nope, I dont think it does include sys messages by default, that would be weird if a pool router scaled up because there was a lot of sys messages or so
Aaron Stannard
@Aaronontheweb
Feb 19 2015 20:37
I'll rerun the test suite again with it disabled
that might be what's aggravating the ReceiveTimeout and ResizerSpecs
I turned the polling time on the ReceiveTimeout way down and was able to get it to fail consistently - realized it was an issue with the HasMessages property on the mailbox more than the Scheduler.
@smalldave had a good name for this type of issue "Heisenbug"
Roger Johansson
@rogeralsing
Feb 19 2015 20:40
that is also something that both me and @HCanber had some problems with, how do we know if the HasMessages / Count report the latest value when reading across threads? maybe we need some sort of volatile read for that?
Aaron Stannard
@Aaronontheweb
Feb 19 2015 20:41
yeah I think that's definitely an issue
Roger Johansson
@rogeralsing
Feb 19 2015 20:41
because we have to use volatile / interlocked ops to get correct values everywhere else, but when it comes to message count, we just happily read the values as normal
Aaron Stannard
@Aaronontheweb
Feb 19 2015 20:42
that's definitely an issue then
especially with routers
since they're reading that from multiple threads concurrently
Bartosz Sypytkowski
@Horusiath
Feb 19 2015 20:52
@rogeralsing what are rules applying to direct actor creation? When and what exception should be thrown?
Roger Johansson
@rogeralsing
Feb 19 2015 21:24
Depends, you can get invalid name, the name can be reserved, the actor could throw actorinitializationexception and you could get an exception if there is no actor context. Those are the ones of the top of my head