akkadotnet/akka.net

Port of Akka actors for .NET

Onur Gumus

@OnurGumus

I thought you were trying to access self.

Stephen Riley

@stephen-riley

var mylogger = Context.ActorSelection("/user/ConsoleLogger");

mylogger.Tell("message");            // this does not work (always from deadLetters)

mylogger.Tell("message}", self);    // this works fine

Onur Gumus

@OnurGumus

that's not normal.

Stephen Riley

@stephen-riley

lol

Good, glad it's not just me. :smile:

Onur Gumus

@OnurGumus

No it's just you.

Stephen Riley

@stephen-riley

lol

Onur Gumus

@OnurGumus

You are probably doing some thing wrong.

Stephen Riley

@stephen-riley

Agreed. :wink:

Onur Gumus

@OnurGumus

mylogger.Tell("message"); // this should just work

Stephen Riley

@stephen-riley

Was hoping someone here would say "oh yeah, do x-y-z and you're fine". Guess I'll pull down source and deep-dive.

Onur Gumus

@OnurGumus

instead try to simplify and isolate the case.

I am sure you will find.

Stephen Riley

@stephen-riley

It totally did work until I put the code inside the lambda I'm passing to ContinueWith().

me-slove

@me-slove

actorselection is probably a reference. in which case you'd be back to the closure problem

Stephen Riley

@stephen-riley

I built the code first just using await httpClient.GetAsync()...

@me-slove , I've tried closing over it, too, and it still didn't work. Which is weird to me, cuz I figured if I'd closed over it, I'd get all the context linked to it and be fine.

me-slove

@me-slove

inside the same code block it should work though. that seems a little odd

Stephen Riley

@stephen-riley

Agreed, @me-slove , it is quite odd. I just re-tested that, still doesn't work.

var self = Self;
var context = Context;

httpClient.GetAsync(req.Url).ContinueWith(responseTask =>
{
    var mylogger = context.ActorSelection("/user/ConsoleLogger");
    var response = responseTask.Result;
    var duration = stopwatch.Elapsed.TotalMilliseconds;
    var msgResponse = new AkkaBlaster.Dto.WebResponse
    {
        StatusCode = response.StatusCode,
        Duration = duration
    };

    mylogger.Tell("message");
},
TaskContinuationOptions.AttachedToParent & TaskContinuationOptions.ExecuteSynchronously);

Onur Gumus

@OnurGumus

@stephen-riley can you actually try to resolve the selection by calling Resolve ?

Stephen Riley

@stephen-riley

The actor mylogger definitely receives the message, but it is from deadLetters, instead of from this httpclient actor.

@OnurGumus , I don't know about Resolve(), but I will try that!

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.

Where communities thrive

People

Repo info

Activity