Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 13:23
    Aaronontheweb commented #4096
  • 13:22
    Aaronontheweb commented #4093
  • 13:16
    ismaelhamed commented #4093
  • 13:04
    ismaelhamed edited #4097
  • 13:04
    ismaelhamed opened #4097
  • 12:50
    ismaelhamed commented #4096
  • 12:48
    ismaelhamed commented #4096
  • 12:05
    Aaronontheweb commented #4096
  • 11:43
    ismaelhamed commented #4096
  • Dec 14 19:13
    hwanders commented #4096
  • Dec 14 13:05
    IgorFedchenko commented #4085
  • Dec 14 03:08
    hhko commented #4094
  • Dec 13 21:37
    Aaronontheweb commented #4085
  • Dec 13 20:28
    IgorFedchenko commented #4085
  • Dec 13 20:27
    IgorFedchenko commented #4085
  • Dec 13 15:38
    Aaronontheweb labeled #4096
  • Dec 13 15:38
    Aaronontheweb milestoned #4096
  • Dec 13 15:38
    Aaronontheweb labeled #4096
  • Dec 13 15:38
    Aaronontheweb opened #4096
  • Dec 13 10:41
    peirens-bart opened #4095
James Conway
@jwconway
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
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
cc @Aaronontheweb
btw. calling all async await people .. critical bug in testkit async tests akkadotnet/akka.net#907
Natan Vivo
@nvivo
@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
@chanan I think mostly because of eventual consistency problems - which is not what you expect when using SQL database.
Natan Vivo
@nvivo
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
... 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
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
@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
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
@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
ye, the implicit context is the root of all async evil in akka.net
Natan Vivo
@nvivo
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
but how can we use synccontext when we dont own the threads?
Arjen Smits
@Danthar
@rogeralsing I agree. The fact that we need to carry state around is the cause of most of our TPL issues
Natan Vivo
@nvivo
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
Akka is the same @Nvivo
Roger Johansson
@rogeralsing
we have our dispatchers, they could dispatch onto whatever, thread pool, new threads, existing threads, someone elses threads.
Natan Vivo
@nvivo
@Danthar sorry, didn't get it
what is the same?
Roger Johansson
@rogeralsing
so we cannot assume we have the right to change the synccontext on an existing thread
Natan Vivo
@nvivo
i know
Arjen Smits
@Danthar
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
I get what you're saying, I don't know why =)
what did I say?
Arjen Smits
@Danthar
winforms/wpf/asp.net require synccontext but only for some special cases where you want to run in that ui thread
Natan Vivo
@nvivo
maybe I expressed myself wrong
Arjen Smits
@Danthar
and the bit about maybe running in environments without context
Natan Vivo
@nvivo
let me try again
Arjen Smits
@Danthar
akka will always have its own local actor context it needs to carry around
Natan Vivo
@nvivo
the reason akka cannot assume it can change sync context is because of these environments? or are there more reasons?
Roger Johansson
@rogeralsing
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
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