These are chat archives for akkadotnet/akka.net

1st
Nov 2017
Saepul Ramdani
@blackclavus
Nov 01 2017 08:58
Is it possible for actor children is alive when their parent stopped?
Alexey Kushnikov
@akushnikov
Nov 01 2017 12:20
Hi everyone, could someone help me. I'm using Akka.Remote and calling actor using ActorSelection.Ask<T>(), but actor throws and exception. I've already tried to catch it and tell back Failure with exception but nothing happens in my caller code that causes my app freeze
Bart de Boer
@boekabart
Nov 01 2017 12:23
Because Ask<T> only continues when it gets a <T> , not when it gets a 'failure'
In case the Ask target can 'fail', the T type should allow for both the OK and the ERROR response
Alexey Kushnikov
@akushnikov
Nov 01 2017 12:24
i also tried untyped ask
Bart de Boer
@boekabart
Nov 01 2017 12:25
If you response a 'failure' class, you should receive that in an untypes ask
Alexey Kushnikov
@akushnikov
Nov 01 2017 12:25
var id = await ActorSelection.Ask(message);
Bart de Boer
@boekabart
Nov 01 2017 12:25
Are you sure ActorSelection Resolves? You can try first Resolve it, validate you got an IActorRef, then ask the actorRef
... just to make sure ...
Alexey Kushnikov
@akushnikov
Nov 01 2017 12:26
yep, I'm debugging
and I'm catching this exception on my service side
Bart de Boer
@boekabart
Nov 01 2017 12:28
In the actor Receive<>?
maybe paste the message handle code (abstract) here?
Alexey Kushnikov
@akushnikov
Nov 01 2017 12:28
I'm using ReceiveAsync, is it matter?
public async Task HandleAsync(AddMessage<TViewModel> message)
        {
            try
            {
                var viewModel = message.ViewModel;
                var entity = Mapper.Map<TEntity>(viewModel);
                DbSet.Add(entity);
                await PortalDbContext.SaveChangesAsync();
                Sender.Tell(entity.Id);
            }
            catch (Exception ex)
            {
                Sender.Tell(new Failure { Exception = ex });
            }            
        }
Bart de Boer
@boekabart
Nov 01 2017 12:30
Yes - Sender isn't valid in a continuation
capture it in line 1, in var sender=Sender;
Alexey Kushnikov
@akushnikov
Nov 01 2017 12:30
Sender is an Actor property
Bart de Boer
@boekabart
Nov 01 2017 12:31
no, it's not
Alexey Kushnikov
@akushnikov
Nov 01 2017 12:31
Bart de Boer
@boekabart
Nov 01 2017 12:32
... on the inside. Sender, Self are from Context, in fact - they are valid during the 'sync' part of a handler only
Alexey Kushnikov
@akushnikov
Nov 01 2017 12:32
i forgot to pass Self as a parameter
Bart de Boer
@boekabart
Nov 01 2017 12:32
so if you need them in a continuation (after await), you need to close over them
Well Self is invalid there too :)
just capture Sender and Self before the await into vars, and you'll be OK. ALSO for the catch clause!
(since the exception can be (and likely is) thrown in the continuation as well)
(btw, you can actually just Tell the Exception ex too, no need to wrap it)
Alexey Kushnikov
@akushnikov
Nov 01 2017 12:34
public GenericEntityActor()
        {
            ReceiveAsync<GetByIdMessage>(HandleAsync);
            ReceiveAsync<GetListMessage>(HandleAsync);
            ReceiveAsync<AddMessage<TViewModel>>(HandleAsync);
            ReceiveAsync<UpdateMessage<TViewModel>>(HandleAsync);
            ReceiveAsync<DeleteMessage>(HandleAsync);
        }
that how I register my handlers
so why do you think Self and Sender are not captured after await?
Bart de Boer
@boekabart
Nov 01 2017 12:36
Could you just give me the benefit of the doubt and try it?
I used the source, Luke.
Alexey Kushnikov
@akushnikov
Nov 01 2017 12:36
they are successfully captured if no exception thrown
Bart de Boer
@boekabart
Nov 01 2017 12:36
You might be lucky. Maybe the DB call was actually done synchronously, for example
depends on the implementation there
Alexey Kushnikov
@akushnikov
Nov 01 2017 12:37
nope, srsly, i'm using EF and async/await
I suppose that is smth went wrong with ActorSelection
Bart de Boer
@boekabart
Nov 01 2017 12:38
not every 'Task Async' function actually always executes asynchronously
RoBiK75
@RoBiK75
Nov 01 2017 12:38
so what? async/await is no guarantee that the execution will actually be asynchronous
implementation can decide to return result sychronousely
Bart de Boer
@boekabart
Nov 01 2017 12:38
Dude, did you TRY closing over them and see if your problem is fixed? Otherwise I'm going to stop helping you now.
Alexey Kushnikov
@akushnikov
Nov 01 2017 12:38
it's a db call, it's async
RoBiK75
@RoBiK75
Nov 01 2017 12:38
smh
Alexey Kushnikov
@akushnikov
Nov 01 2017 12:39
and i tried your way with var sender = Sender
not working anyway
Bart de Boer
@boekabart
Nov 01 2017 12:43
from Petabridges blog post about async:
So for instance, the Sender property of your actor will almost definitely change between messages. You’ll need to use a C# closure for this property in order to guarantee that any asynchronous methods that depend on this property get the right value.
you use the captured sender in both Tells?
Alexey Kushnikov
@akushnikov
Nov 01 2017 12:44
yes
in both of them
Bart de Boer
@boekabart
Nov 01 2017 12:45
Ok, and you do get to the 'catch' close, the Tell happens and your Ask is typeless?
(If that happens, also the ActorSelection isn't the problem, without it working you wouldn't get to the message handler in the first place)
Alexey Kushnikov
@akushnikov
Nov 01 2017 12:58
Ok, I found out that it's a problem with exception serialization using JSON serializer
akkadotnet/akka.net#1841
Bart de Boer
@boekabart
Nov 01 2017 13:15
Ah, you were going over remote?
Also smth I've run in to in the past ... we basically learned to send meaningfull error messages back, not wrapping Exceptions.. like an enum with possible errors for example
Alexey Kushnikov
@akushnikov
Nov 01 2017 13:17
yes, I'm using remote.
Ok, I'll try to handle it
Bart de Boer
@boekabart
Nov 01 2017 13:18
I feel it's best not to have your actor users have to deal with Exception details, just get back useful info like: This won't ever work , or Can't do it now, retry later, or, Done
the actor itself can analyse the exception to determine whether it's smth that'll never work, or is a temporary situation (network etc)
RoBiK75
@RoBiK75
Nov 01 2017 13:18
you can't always avoid it tho
Bart de Boer
@boekabart
Nov 01 2017 13:20
I think, by the way and on topic, that Sender and Self may work in a continuation, depending on how the Task continues (as in, other thread maybe). Also, it will almost Never work if you await in a non "ReceiveAsync" handler.... which you may have to do sometimes, for example if you want to offer concurrent DB reads (which you implementation currently doesn't)
RoBiK75
@RoBiK75
Nov 01 2017 13:22
if an actor has a remote child and the child fails, there parent should receive a failure message that can contain the exception that caused the failure... or am i mistaken?
Bart de Boer
@boekabart
Nov 01 2017 13:49
That's very different
supervising an actor vs. using an actor, where your 'request' can fail and you need a response for that failure
the latter doesn't have to (shouldn't, IMO) be an exception
Aaron Stannard
@Aaronontheweb
Nov 01 2017 13:50

Is it possible for actor children is alive when their parent stopped?

if the parent dies, the children die

Bart de Boer
@boekabart
Nov 01 2017 13:51
whether this issue with serializing exceptions affects supervision... dunno
Aaron Stannard
@Aaronontheweb
Nov 01 2017 13:51
if an actor has a remote child and the child fails, there parent should receive a failure message that can contain the exception that caused the failure... or am i mistaken?
that's correct
we serialize and transmit that information
can't guarantee the stacktrace et al are going to make sense
since we have to stringify that
but remotely deployed actors who fault and need to be restarted have the ability to report those failures back to the parent just like a local actor
RoBiK75
@RoBiK75
Nov 01 2017 14:45
hey Aaron, welcome back :)
Arsene Tochemey GANDOTE
@Tochemey
Nov 01 2017 19:20
Hello Geeks, please what is the advantage of using Akka.NET IO over DotNetty
Bartosz Sypytkowski
@Horusiath
Nov 01 2017 22:04
@Tochemey if you're already using akka actors or streams, integrating them with sockets using akka i/o is easier. Also you have full power of streams composition at your side. DotNetty however is more mature and got few features (like TLS) which Akka IO still misses