Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 08:20
    Zetanova synchronize #3916
  • 08:13
    Horusiath commented #3908
  • 08:12
    Horusiath commented #3908
  • 08:11
    Horusiath commented #3908
  • 07:58
    Horusiath commented #3284
  • 07:56
    Horusiath commented #3284
  • 07:32
    ismaelhamed commented #3284
  • 07:24
    Zetanova opened #3916
  • Sep 16 15:35
    Aaronontheweb commented #3284
  • Sep 16 07:55
    ismaelhamed commented #3284
  • Sep 13 16:35
    Aaronontheweb commented #3905
  • Sep 13 16:35
    Aaronontheweb labeled #3905
  • Sep 13 16:35
    Aaronontheweb labeled #3905
  • Sep 13 16:35
    Aaronontheweb labeled #3914
  • Sep 13 16:34
    Aaronontheweb commented #3914
  • Sep 13 01:50
    Aaronontheweb synchronize #3914
  • Sep 13 01:45
    Aaronontheweb commented #3914
  • Sep 12 14:10
    Aaronontheweb synchronize #3914
  • Sep 12 14:10

    Aaronontheweb on dev

    name AzureDevops artifacts per … (compare)

  • Sep 12 14:10
    Aaronontheweb closed #3915
Onur Gumus
@OnurGumus
ActorSelection returns a selection , not an actor ref. You can get an actorRef by calling Resolve on the Selection.
Stephen Riley
@stephen-riley
Do you mean ResolveOne()?
Onur Gumus
@OnurGumus
which may fail if no such actor found.
yes that one
Stephen Riley
@stephen-riley
k, let me try
Onur Gumus
@OnurGumus
I would also move the resolution outside of your lambda.
there is no need to resolve it there. You can resolve before.
me-slove
@me-slove
I haven't looked at the code for Context but what you are seeing for sure is that it is losing itself across the task boundary. It must be that it is derived instead of a variable
Stephen Riley
@stephen-riley
It must be that it is derived instead of a variable
Yeah, @me-slove , looking that way.
@OnurGumus , interestingly, waiting 1 second on the ResolveOne() returned null. Waiting 10 seconds (totally arbitrary) resulted in a good reference.
Onur Gumus
@OnurGumus
that's odd.
Stephen Riley
@stephen-riley
however, still shows all messages as coming from deadLetters. :worried:
I verified with the Identify message that the path is fine.
I think I'm gonna just pull down source and start tracing in. Clearly I have more to understand about the inner workings of Akka.NET when using the TPL patterns. :smile:
me-slove
@me-slove
protected static IActorContext Context
{
get
{
var context = InternalCurrentActorCellKeeper.Current;
if (context == null)
throw new NotSupportedException(
"There is no active ActorContext, this is most likely due to use of async operations from within this actor.");
            return context.ActorHasBeenCleared ? null : context;
        }
    }
it got screwy on the paste but it is definitely derived. here's the code https://github.com/akkadotnet/akka.net/blob/dev/src/core/Akka/Actor/ActorBase.cs
hectorcaban
@hectorcaban
Since I am creating multiple child actors .. how do I do child actors with wildcard routes. ?
Stephen Riley
@stephen-riley
@me-slove, after tracing into the code, I can confirm that InternalCurrentActorCellKeeper.Current is null when inside the ContinueWith() lambda.
So I guess it's just safe to assume that inside ContinueWith() (for this TPL-style IO handling), you have to be explicit because you simply don't have any current actor context for the calls to work with. shrugs
so that's why I have to explicitly specify a sender in Tell(), because of how the normal Tell() is implemented:
        public static void Tell(this IActorRef receiver, object message)
        {
            var sender = ActorCell.GetCurrentSelfOrNoSender();
            receiver.Tell(message, sender);
        }
It would be nice to solve this in the library, but short of making the "current self" concept a stack instead of a singleton, I don't see how to do that nicely. Oh well.
@me-slove and @OnurGumus, thanks for all your help! :smiley:
me-slove
@me-slove
I using chaining a lot so I generally pass around the sender anyway so for me it works fine :)
Stephen Riley
@stephen-riley
The more I think about it, @me-slove, I just wasn't thinking hard enough about how TPL works vis-a-vis the different threads your Task<T> might continue on, and how Akka won't know anything about that. Completely different runtime contexts.
I'm gonna have to think a lot more about this and how I would want this to work ideally so I had something like ContinueWith() that was Akka-aware. Anyway, thanks for the thoughts.
Aaron Stannard
@Aaronontheweb
@stephen-riley we resolve Context by checking a thread-local variable
the value of Context is therefore, volatile
on top of that, the Context can change each time an actor processes a message
so it's a good practice to close over things like Sender and Self when you want to use them in continuations
Stephen Riley
@stephen-riley
heh, glad you confirmed that for me, @Aaronontheweb , as looking into the thread-local storage aspect of it was next on my list. :smiley: This is quite fun digging into this all!
Aaron Stannard
@Aaronontheweb
no problem
normally none of that stuff is an issue when you're working inside an actor
but yeah, when you want to re-use some of that state asynchronously
Stephen Riley
@stephen-riley
This really all started from "why do I need to explicitly specify a sender in Tell() while inside a continuation?" Been quite a lot of fun digging in.
Aaron Stannard
@Aaronontheweb
ah yeah
because our extension method that automatically supplies Self doesn't work outside the ActorCell
Context is basically the public API of the ActorCell
Stephen Riley
@stephen-riley
I know I could/should use PipeTo() for what I'm doing to be a little more "proper" about things, but you know how it is: once you start pulling a thread, you gotta see what unravels. :smile:
Aaron Stannard
@Aaronontheweb
I know how that feels
Stephen Riley
@stephen-riley
Ah, okay. I need to read up on ActorCell, clearly.
Aaron Stannard
@Aaronontheweb
ActorCell is what fits all of the different pieces of an actor together for user-defined actors
and most, but not all, built-in actors
connects the mailbox to the dispatcher to the actor implementation class
it's also what allows for safe restarting of actors too
there are some built-in actor types that operate without a cell, but they're special cases
router actors are one example
typically they're actors that don't need to obey the 1 message at a time guarantee
Stephen Riley
@stephen-riley
Ah, okay. So it's really the central "actor infrastructure state" thing per thread, and encapsulates the context on which my actor code is running?