These are chat archives for akkadotnet/akka.net

26th
Apr 2015
James Conway
@jwconway
Apr 26 2015 09:14
Hi guys
i could really do with some pointers on this jwconway/akka.net#3
its an attempt at UDP transport
ive set it up on a personal branch so you can see how I've approached it
James Conway
@jwconway
Apr 26 2015 09:19
Basically the end points seem to set up fine and I can send data to them manually but when I use UDP in a cluster the nodes don't seem to chatter
I must be missing something but can't see what
Roger Johansson
@rogeralsing
Apr 26 2015 11:43
cc @Aaronontheweb
btw. calling all async await people .. critical bug in testkit async tests akkadotnet/akka.net#907
Natan Vivo
@nvivo
Apr 26 2015 12:00
@rogeralsing just brainstorming here... one of the issues with async here is that there are too many things that need to be done to keep the state when continuations happen
you said before that you can't use sync context because it cannot override the context in asp.net/winforms environments
but at the same time, it's hard to keep the state safe using other means
Bartosz Sypytkowski
@Horusiath
Apr 26 2015 12:02
@chanan I think mostly because of eventual consistency problems - which is not what you expect when using SQL database.
Natan Vivo
@nvivo
Apr 26 2015 12:03
so, I was wondering... why does akka sets InternalCurrentActorCellKeeper from a different place instead of saving everything in the CallContext?
can't every possible state required be kept and restored from the same place at the same time?
Bartosz Sypytkowski
@Horusiath
Apr 26 2015 12:17
... but mostly because of looking up for canonical akka LevelDB code. If it'll turn out that implementation should change (and probably should) anyone could easily change it without any risk of breaking changes in the API itself
Bartosz Sypytkowski
@Horusiath
Apr 26 2015 15:05
I'm working on typed actor refs for F# and this looks very promising, but still there are some F# quirks that make me go gray
Roger Johansson
@rogeralsing
Apr 26 2015 15:17
@nvivo we used the thread static container from the start as there were no plans for async await, nor did we know about call context. then we discivered callcontext along the way. in theory we should be able to use call context all the way.. but xUnit blows up when using call context. the test runner explodes when the test finishes
@nvivo but you are correct that this is the ideal way to solve it, if everything else behaves as it should
@nvivo and then the TestKit should work. but at least in xUnit 1.9.2, we are out of luck
Arjen Smits
@Danthar
Apr 26 2015 16:47
CallContext has some stuff you need to be aware off.
Started digging and found a blog which explains it pretty well. Commented on the issue. I wont go into detail here, Because I would like to keep this discussion over at github as much as possible.
Natan Vivo
@nvivo
Apr 26 2015 17:32
@Danthar just read the blog post about CallContext, thanks
Just out of curiosity, I went to see how Orleans did it, it appears they don't have synchronizationcontext. but then, I think they don't have any implicit state the same way akka does
Roger Johansson
@rogeralsing
Apr 26 2015 17:34
ye, the implicit context is the root of all async evil in akka.net
Natan Vivo
@nvivo
Apr 26 2015 17:34
so... thinking about the future here and akka typed and these issues
what if...
what if we checked if synccontext solves the problem first
and had a way to disable it
Roger Johansson
@rogeralsing
Apr 26 2015 17:35
but how can we use synccontext when we dont own the threads?
Arjen Smits
@Danthar
Apr 26 2015 17:35
@rogeralsing I agree. The fact that we need to carry state around is the cause of most of our TPL issues
Natan Vivo
@nvivo
Apr 26 2015 17:35
just thinking out loud here
winforms/wpf/asp.net require synccontext but only for some special cases where you want to run in that ui thread
those are minor cases. maybe if synccontext worked, akka.net could still run in those environments without context
Arjen Smits
@Danthar
Apr 26 2015 17:36
Akka is the same @Nvivo
Roger Johansson
@rogeralsing
Apr 26 2015 17:36
we have our dispatchers, they could dispatch onto whatever, thread pool, new threads, existing threads, someone elses threads.
Natan Vivo
@nvivo
Apr 26 2015 17:36
@Danthar sorry, didn't get it
what is the same?
Roger Johansson
@rogeralsing
Apr 26 2015 17:36
so we cannot assume we have the right to change the synccontext on an existing thread
Natan Vivo
@nvivo
Apr 26 2015 17:36
i know
Arjen Smits
@Danthar
Apr 26 2015 17:36
look at it like this: Akka has its own gui context. Only then its not the GUI but the actor context it needs to marshall back on
Natan Vivo
@nvivo
Apr 26 2015 17:37
I get what you're saying, I don't know why =)
what did I say?
Arjen Smits
@Danthar
Apr 26 2015 17:37
winforms/wpf/asp.net require synccontext but only for some special cases where you want to run in that ui thread
Natan Vivo
@nvivo
Apr 26 2015 17:38
maybe I expressed myself wrong
Arjen Smits
@Danthar
Apr 26 2015 17:38
and the bit about maybe running in environments without context
Natan Vivo
@nvivo
Apr 26 2015 17:38
let me try again
Arjen Smits
@Danthar
Apr 26 2015 17:38
akka will always have its own local actor context it needs to carry around
Natan Vivo
@nvivo
Apr 26 2015 17:38
the reason akka cannot assume it can change sync context is because of these environments? or are there more reasons?
Roger Johansson
@rogeralsing
Apr 26 2015 17:39
Steven Cleary who wrote that blogpost wrote somewhere else that if you do own the thread: synccontext, if you dont own the thread, TaskScheduler
Natan Vivo
@nvivo
Apr 26 2015 17:39
because at least from my perspective, even in asp.net or winforms, I'd usually run the actor system in the default thread pool for almost everything
this is the part where I get confused
Arjen Smits
@Danthar
Apr 26 2015 17:40
:nods: But what will happen when you switch to another dispatcher implementation. like one that does not use the threadpool ? How will the TPL react to that? I really have no idea
Natan Vivo
@nvivo
Apr 26 2015 17:41
too many subjects. that's the part where talking is easier to follow up =)
Roger Johansson
@rogeralsing
Apr 26 2015 17:41
Orleans have its own mini threadpool afaik, so they can do whatever they want
Natan Vivo
@nvivo
Apr 26 2015 17:42
right
and dedicatedthreadpool is nowhere near what threadpool is currently
Still, what I get confused is that stephen cleary also has some examples of creating your own sync context and I don't remember reading about requiring your own thread pool
i need to read more about this
I think this idea of "owning the thread" is not exactly creating the thread yourself
but i may be wrong
Roger Johansson
@rogeralsing
Apr 26 2015 17:45
Ill see if I can find the post
Natan Vivo
@nvivo
Apr 26 2015 17:47
I'm thinking about posting a question on stackoverflow and see if he answers
I think you sent me the post link once in a discussion
what I'd like to know is: if syncrhonizationcontext seems to be the only safe way to keep context between async calls, is it possible for us to implement one safely using the thread pool?
and note that at this point I'm not worried about how to run akka in ui threads, I'd just like to know if that is possible or not
Arjen Smits
@Danthar
Apr 26 2015 17:49
Its should be possible
Roger Johansson
@rogeralsing
Apr 26 2015 17:49
I cc'ed Stephen in our issue now
but if we use CallContext, and only store single values and not mutating any structure, that should be safe, no?
Natan Vivo
@nvivo
Apr 26 2015 17:51
I guess it would, but I still think setting the call context is not the best performance. in theory, sync context should be faster because we don't need to guess when it needs to be set
Arjen Smits
@Danthar
Apr 26 2015 17:51
Its at least worth a try. but its really hard to test
Natan Vivo
@nvivo
Apr 26 2015 17:51
although in theory, the same solution should be possible with callcontext if we control the schedulers
maybe I'm talking 2 different things
Roger Johansson
@rogeralsing
Apr 26 2015 17:54
the good think now, is that everyone involved seem to understand what the problem is :) that was a bit of a pain initially to try to communicate
Natan Vivo
@nvivo
Apr 26 2015 17:55
roger, one thing that puzzles me is this
when using the synccontext, it seems the way it works is that context is captured when the task is scheduled, and brought back when the task will run
but akka seems to set the callcontext in other places outside of the scheduler
is this right? I may have to look at the code again
Roger Johansson
@rogeralsing
Apr 26 2015 17:58
this is because of reentrancy.. if we only had the "suspend" behavior, that would be easy to solve the way you describe, but as we can multiplex many messages on the same actor, we need to re-set the context
as continuations are piped back as messages
Natan Vivo
@nvivo
Apr 26 2015 17:59
found here... it's set in the actortaskscheduler only
Arjen Smits
@Danthar
Apr 26 2015 17:59
to be honest. More and more im thinking that reentrancy mode should go away.
Roger Johansson
@rogeralsing
Apr 26 2015 17:59
agree
its just too confusing
Natan Vivo
@nvivo
Apr 26 2015 17:59
the thing with reentrancy is that it's already supported with self.tell/pipeto
it doesn't need anything else
Arjen Smits
@Danthar
Apr 26 2015 18:00
I mean, I cannot think of any scenario where you should not / could not simply refactor the work into an actor
and communicatie using messages
Natan Vivo
@nvivo
Apr 26 2015 18:00
exactly
Arjen Smits
@Danthar
Apr 26 2015 18:00
in my mind, if you want to use reentrancy, then you dont understand the actor framework
Natan Vivo
@nvivo
Apr 26 2015 18:00
@Danthar it's not exactly that
Arjen Smits
@Danthar
Apr 26 2015 18:01
and you need to re-evaluate what your are trying to achieve
why not?
Natan Vivo
@nvivo
Apr 26 2015 18:01
I think we just need to agree on what the terms mean
in my view
Reentrancy means "processing other things while a logical process didn't finish"
that means, if a message uses "PipeTo(Self)" for example, the logical process didn't finish
you are using reentrancy
Bartosz Sypytkowski
@Horusiath
Apr 26 2015 18:03
depends on the definition of logical process
Natan Vivo
@nvivo
Apr 26 2015 18:03
a single message was broken into multiple steps, but still a single message from 'outside' was received, and the processing is still just one (even if the actor breaks that into 10)
right. in my sentense, if I say "actor, save these records to the database" - that is a logical process
the amount of messages generated by the actor inside of it to do that thing doesn't matter
the words may be wrong, but my line of thought is correct =)
so, what I mean is that reentrancy using async is unecessary if you look from this perspective. Just PipeTo(Self) and you get the exact same behavior
Bartosz Sypytkowski
@Horusiath
Apr 26 2015 18:05
this kind of logical process is easy to define in RPC systems, but Akka isn't necessarily such
Natan Vivo
@nvivo
Apr 26 2015 18:06
This is a very abstract description. I think it fits akka just fine
as I said, the behavior is correct. maybe my words are wrong
maybe it's not a logical process.. but it's a single "business request" let's say
Bartosz Sypytkowski
@Horusiath
Apr 26 2015 18:07
i.e. "actor, save these records to the database" has no notion of reply behavior, so no PipeTo or even Sender.Tell is necessary ;)
Natan Vivo
@nvivo
Apr 26 2015 18:07
ok, now we are probably discussing different things
=)
Roger Johansson
@rogeralsing
Apr 26 2015 18:07
we are lacking a description of semantics, that is one reason there is a lot of confusion among ourselves
Natan Vivo
@nvivo
Apr 26 2015 18:07
yes. as you said Roger, maybe in a call we can work these things out easily
but as @Danthar said, the current mechanism to support reentrancy with async/await in my opinion is unnecessary. all the stuff that works with syncrhonous code works with asyncrhonous code too.
Arjen Smits
@Danthar
Apr 26 2015 18:08
One think I do know.. I need more coffee for this discussion :P
Natan Vivo
@nvivo
Apr 26 2015 18:09
@Danthar - just to be clear - I'm agreeing with your point
Arjen Smits
@Danthar
Apr 26 2015 18:09
I realised that
Natan Vivo
@nvivo
Apr 26 2015 18:09
It's just the way I talk. I'm an architect, my view is very abstract sometimes
Arjen Smits
@Danthar
Apr 26 2015 18:09
Noticed that as well.
Roger Johansson
@rogeralsing
Apr 26 2015 18:09
I also think the reentrancy was a mistake in retrospect, Orleans have it, but it is just too confusion in the form of async await, new users dont get what it does..
Arjen Smits
@Danthar
Apr 26 2015 18:10
it also goes against the actor model imho @Aaronontheweb made a few comments on it last night as well I think
Natan Vivo
@nvivo
Apr 26 2015 18:11
I know I'll get burned by this.. but I don't agree with everything @Aaronontheweb said there
Arjen Smits
@Danthar
Apr 26 2015 18:11
cant remember what it exactly was he said, but it suddenly made a few things clear for me
Natan Vivo
@nvivo
Apr 26 2015 18:11
(async/await) they really make it a lot harder to write clean actor code that complies with the basic concurrency restriction imposed by Akka actors
I don't think that's necessarily the case
Roger Johansson
@rogeralsing
Apr 26 2015 18:11
I dont agree with that statement, becuase, it works exactly the same as PipeTo,,, so it is a DSL ontop of PipeTo... however still confusing
Natan Vivo
@nvivo
Apr 26 2015 18:12
what happens is that there should be separation between "asyncrhonous akka" and "asyncrhonous method execution"
akka supports asyncrhnous execution by processing individual messages... async/await is another form of asyncrhnous that only refers to how a specific method runs
it's a layer akka shouldn't care
akka should care about messages it receives only. that level of abstraction would make it much easier to reason about
"I'm an actor - I received a message and I won't do anything until I'm done processing it - if that means running async code, so be it.. that doesn't bother me. just let me know when it's done, so I can get the next message"
Arjen Smits
@Danthar
Apr 26 2015 18:14
I agree, But I don't think we have that luxery
Natan Vivo
@nvivo
Apr 26 2015 18:15
Yes, after looking at the dispatchers, I think it's not that simple to achieve that. but it's possible
I wonder what the akka guys would say about that
Roger Johansson
@rogeralsing
Apr 26 2015 18:15
they didnt build async support because they thought it was confusing.
Had a talk with them early on
Natan Vivo
@nvivo
Apr 26 2015 18:16
Do you still think that's confusing?
Natan Vivo
@nvivo
Apr 26 2015 18:17
it seems he was talking about reentrant behavior
I think we concluded that it was inherently unsafe because if the continuation is "never" resumed, the actor is effectively dead and its mailbox will continue to pile up. Pausing processing is anti-responsive.
This is an error in the assumption that anything is being paused
Arjen Smits
@Danthar
Apr 26 2015 18:18
@rogeralsing Concerning that link; Im all for option 1
Natan Vivo
@nvivo
Apr 26 2015 18:18
The behavior is exactly the same as if you were burning cpu cycles doing something. it's just a message being processed
Roger Johansson
@rogeralsing
Apr 26 2015 18:19
@Danthar that is what we do in the suspend behavior now
Natan Vivo
@nvivo
Apr 26 2015 18:19

he said then

There is a compromise that is possible, though: enqueue incoming messages locally until the continuation has been resumed and completed (so that users are not surprised) until the local queue is full, at which point the actor fails. This places a limit on the non-responsiveness while not breaking semantics.

this seems to be your option 1
that is exactly what async/await should do in fact
Bartosz Sypytkowski
@Horusiath
Apr 26 2015 18:19
@nvivo not only, while message is being processed, state changes
(I'm talking about reentrancy right now)
Natan Vivo
@nvivo
Apr 26 2015 18:21
yes, that's why reentrancy should be handled by message passing, not a custom mechanism on top of async/await
the reason async/await exists is just to make syncrhnous code non-blocking, it was never intended to create a notion of parallelism
IMO, there is no need to change that because Akka already supports PipeTo very well
Bartosz Sypytkowski
@Horusiath
Apr 26 2015 18:23
while about your quote - persistent actors in fact stash incoming messages while in recovery phase, but this is destructive when used in some routing strategies
Natan Vivo
@nvivo
Apr 26 2015 18:24
the quote is from Roland Kuhn, just to be clear
Bartosz Sypytkowski
@Horusiath
Apr 26 2015 18:24
yep, I've read the thread ;)
I think our "Feasiblity" bouble is quite small here due to the implicit context. so that limits our options

Roger Just unlocked Pointy Haired Boss acheivement - posting nonsense venn diagrams

:)
Arjen Smits
@Danthar
Apr 26 2015 18:32
lol
Maybe some UML diagrams would be better
:P
Roger Johansson
@rogeralsing
Apr 26 2015 18:34
dude you have no idea how much UML I have done in my days :) spent a few years drawing sequence diagrams at my last job...
Arjen Smits
@Danthar
Apr 26 2015 18:34
hehe
So should be no problem then!
^^
Roger Johansson
@rogeralsing
Apr 26 2015 18:43
read the thread
Natan Vivo
@nvivo
Apr 26 2015 18:46
Haha
Natan Vivo
@nvivo
Apr 26 2015 19:02
was thinking about all of this ... one problem with "tasks" in c# is that it mixes the idea of a promise with the execution of code asyncrhonously
I heard a typesafe guy saying the same thing about java futures, so there is probably a performance reason there
if the future value was to be separated in an IPromise<T> for example, I guess async/await wouldn't be so mysterious
Stefan Sedich
@stefansedich
Apr 26 2015 23:01
@rogeralsing decided to clean up the whole Event namespace.
I assume we have the R# rule for comment all protected/public? it really gets annoying for obvious methods. I have found myself hating myself :)
also there are one or two Obsolete still in Logging, is it safe for me to kill them now?
Natan Vivo
@nvivo
Apr 26 2015 23:33
This message was deleted
Stefan Sedich
@stefansedich
Apr 26 2015 23:35
I don't like seeing deleted messages :D
too curios
I wish they just removed it totally.
Natan Vivo
@nvivo
Apr 26 2015 23:36
haha
it was the secret of the universe, life and everything
Stefan Sedich
@stefansedich
Apr 26 2015 23:37
I knew it!