These are chat archives for akkadotnet/akka.net

27th
Feb 2015
Raymen Scholten
@raymens
Feb 27 2015 10:58
@Aaronontheweb that looks pretty good :)
Raymen Scholten
@raymens
Feb 27 2015 11:19
Natan Vivo
@nvivo
Feb 27 2015 19:32
Anyone else understood what I'm proposing on #686? I know I'm confusing sometimes, but I'm trying to explain the best I can... =)
Roger Johansson
@rogeralsing
Feb 27 2015 19:39
I do get it, totally, its more of a theoretical issue if we should promote async await inside actors, there are some side effects to it... e.g. if we use your approach, if an actor just stash everything while waiting, it could cause out of memory due to a large mailbox... or if we use re-entrancy where we do not pause the message processing, but still keep actor concurrency, the actor can get new state during the await period , this is exactly how it would be with pipeto also, but in the pipeto case, it is explicit, we see that we pass a message back. while with await, one could get the impression that no state could change..
async await sort of unfolds a series of messages that should happen in sequence, either in direct sequence using your approach , or just in a series over time with other stuff going in in between. as in reentrancy
Natan Vivo
@nvivo
Feb 27 2015 19:41
Yes. Actually, this post is based on the question from @Horusiath when I proposed the AsyncUntypedActor, where he asked if there could be a way to support this for all the actors.
without having to implement an "async" version for each one
In fact, this is solving some thread starvation problems I was facing
Aaron Stannard
@Aaronontheweb
Feb 27 2015 19:43
how many requests per second are you doing inside your app
where you could be running into thread starvation issues?
Natan Vivo
@nvivo
Feb 27 2015 19:43
in this case, I was opening 64 threads
Roger Johansson
@rogeralsing
Feb 27 2015 19:43
but you wouldnt get thread starvation if you use PipeTo, right? and you can still compose tasks and just do a single pipeto on the last task. assuming no task in between changes actor state, just task output
Natan Vivo
@nvivo
Feb 27 2015 19:43
right
but the problem is that I had to wait for the processing to finish before going to the next one
it's currently well supported in .net using async/await
the only problem is that the actor doesn't support that
Aaron Stannard
@Aaronontheweb
Feb 27 2015 19:44
@nvivo honest question... how much work have you done with the TPL directly?
Natan Vivo
@nvivo
Feb 27 2015 19:44
I'm quite good at it =)
Roger Johansson
@rogeralsing
Feb 27 2015 19:44
task1.ContinueWith(t => do more stuff).ContinueWith(...).PipeTo(self)
Aaron Stannard
@Aaronontheweb
Feb 27 2015 19:45
async / await are not magic
they just write the continuations for you
Natan Vivo
@nvivo
Feb 27 2015 19:45
I know
Aaron Stannard
@Aaronontheweb
Feb 27 2015 19:45
why not just do that?
Natan Vivo
@nvivo
Feb 27 2015 19:45
it's not what I'm doing
I understand how concurrency works, it's not the problem
Aaron Stannard
@Aaronontheweb
Feb 27 2015 19:46
BTW, read my latest reply - have to head out now
but it sounds like you've coupled state and commanding in areas where they shouldn't be
Natan Vivo
@nvivo
Feb 27 2015 19:46
ok
Aaron Stannard
@Aaronontheweb
Feb 27 2015 19:47
not every actor should be responsible for reading from the database
Natan Vivo
@nvivo
Feb 27 2015 19:47
no, it's not the case
Aaron Stannard
@Aaronontheweb
Feb 27 2015 19:47
have dedicated actors that service every other actor who needs it
Natan Vivo
@nvivo
Feb 27 2015 19:47
@rogeralsing got what i'm trying to achieve
Aaron Stannard
@Aaronontheweb
Feb 27 2015 19:47
what I clearly don't understand is why the current tools don't work for you
Natan Vivo
@nvivo
Feb 27 2015 19:48
=)
You are leaving, I don't know how to explain to you this way
I'm trying to
but it seems you are certain the since all your problems are solved by the current solution, no other problems may appear
what I'm proposing is just supporting officially the default pattern for non-blocking code in .NET
Aaron Stannard
@Aaronontheweb
Feb 27 2015 19:49
no, you just haven't offered any evidence to the contrary
the official pattern for non-blocking code in .NET is also procedural and doesn't use actors
has no power here
not a valid argument
Actor model is a different programming model than OOP
Natan Vivo
@nvivo
Feb 27 2015 19:50
I think you are getting the wrong idea of what I'm saying
maybe I need to explain better
but it seems you convinced yourself of what I'm proposing
even though I'm saying it has nothing to do with that
english is not my primary language, maybe that's the issue
Aaron Stannard
@Aaronontheweb
Feb 27 2015 19:51
no worries - I'm also respond faster than I can think sometimes
so I may not be getting it
but worth noting, we've had A LOT of history with people who wanted to do absolutely idiotic shit inside actors with async
Natan Vivo
@nvivo
Feb 27 2015 19:51
it's not the case
Aaron Stannard
@Aaronontheweb
Feb 27 2015 19:51
so I might just be traumatized from that
biased, in other words
Natan Vivo
@nvivo
Feb 27 2015 19:52
I tried to give an example in the last comment on the issue
Aaron Stannard
@Aaronontheweb
Feb 27 2015 19:52
yeah, and you should read my response - I don't think even using async is the right way to solve that problem
Natan Vivo
@nvivo
Feb 27 2015 19:52
I got what you are saying
I'm just adding that there is more to it
there are reasons to use async that have nothing to do with concurrency
Bartosz Sypytkowski
@Horusiath
Feb 27 2015 20:36
have you looked at bottom readme in https://github.com/OrleansContrib/DesignPatterns ?
Natan Vivo
@nvivo
Feb 27 2015 20:40
@Horusiath me?
Bartosz Sypytkowski
@Horusiath
Feb 27 2015 20:41
this is a general question I just cannot belive in those numbers
Natan Vivo
@nvivo
Feb 27 2015 20:42
you think it's too much or too little?
I'm not impressed by anything =)
Bartosz Sypytkowski
@Horusiath
Feb 27 2015 20:44
my comp has 8 cores, and I can spin Akka.NET up to 20-68mln msgs/sec, while Orleans is talking about 10k on 8 core VM
Roger Johansson
@rogeralsing
Feb 27 2015 20:44
Optimizing for locality in akka.net, we would do 30 mil messages per sec inside that machine...
Bartosz Sypytkowski
@Horusiath
Feb 27 2015 20:45
I'm guessing that's a metrics methodology issue
Natan Vivo
@nvivo
Feb 27 2015 20:45
that's what I thought
I'm not sure what "requests" mean there and what they are doing
Also, I'm very skeptical about VMs.... sometimes we forget how faster a bare machine can be
Roger Johansson
@rogeralsing
Feb 27 2015 21:13
Also orleans serialize all messages, because no immutable messages
Aaron Stannard
@Aaronontheweb
Feb 27 2015 23:22
man those numbers
ewwwwwwwwwww
serializing every message will do that
their benchmark is probably comparing different stuff though
I would love to do an Akka.Cluster / Akka.Remote benchmark at some point
had an idea for a load-testing tool for Akka.Remote but haven't had any time to work on it
Aaron Stannard
@Aaronontheweb
Feb 27 2015 23:43
btw, not sure who's interesting in using the Clustering module yet
but I have a patch coming in soon - hopefully this weekend, that enables full support for Pool routers
even have the multi-node tests to prove it :p
@rogeralsing for the ConsistentHashing stuff that we talked about - I'm just going to go full-bore and import virtual nodes while I'm atit
no reason for us not to have the latest stuff there
Aaron Stannard
@Aaronontheweb
Feb 27 2015 23:49
plus, although it's not a perfect solution for #673, I think it offers a better solution that what we have now