These are chat archives for akkadotnet/akka.net

9th
Feb 2018
Lutando Ngqakaza
@Lutando
Feb 09 2018 07:07
@OnurGumus thanks :)
Thomas Weiss
@ThomasWeiss
Feb 09 2018 07:20
Hi guys! I'm working on a I/O heavy workload and PipeTo works perfectly (as my actor receives a message when the awaited I/O call returns) but I'm struggling a bit with error handling. I know that I can receive a Status.Failure message when the awaited function throws an exception, but unfortunately in my case the exception doesn't hold enough context. I've also tried to use the failure callback that's the last argument of PipeTo, and it gets called indeed in case of error, but then I've no ActorContext in that callback...
Onur Gumus
@OnurGumus
Feb 09 2018 07:21
@ThomasWeiss use continue with with onfault and return a meaningful message before the pipe
ContinueWith
In other words don't allow your piped tasks to fail ever
You will be surprised what happens if your task is canceled
Thomas Weiss
@ThomasWeiss
Feb 09 2018 07:24
@OnurGumus what's that onfault? is it a parameter to ContinueWith?
Onur Gumus
@OnurGumus
Feb 09 2018 07:26
t.ContinueWith(c => { var ignored = c.Exception; },
TaskContinuationOptions.OnlyOnFaulted |
Thomas Weiss
@ThomasWeiss
Feb 09 2018 07:27
great pointer, thanks a lot!
Onur Gumus
@OnurGumus
Feb 09 2018 07:28
ContinueWith is like linq's select method.
For tasks.
Thomas Weiss
@ThomasWeiss
Feb 09 2018 07:29
I see, that analogy helps indeed :)
Thomas Weiss
@ThomasWeiss
Feb 09 2018 07:47
@OnurGumus Just tried with ContinueWith but I'm afraid there's no ActorContext in the continuation either
Onur Gumus
@OnurGumus
Feb 09 2018 07:47
What do you mean?
Ah you need the context?
Thomas Weiss
@ThomasWeiss
Feb 09 2018 07:48
I can't call Self.Tell from the lambda
yep :)
Onur Gumus
@OnurGumus
Feb 09 2018 07:48
myTask.ContinueWith(....).PipeTo(Self) ?
I am actually a bit confused. Are you piping this to yourself?
Thomas Weiss
@ThomasWeiss
Feb 09 2018 07:50
yes that's what I was doing initially, and basically I need the context when an exception occurs, but using the Status.Failure message type doesn't work for me because the exception doesn't carry enough information
Onur Gumus
@OnurGumus
Feb 09 2018 07:51
But you can access the context Self.Context in your callback
I am not sure why are you trying to attach the context to the message.
Thomas Weiss
@ThomasWeiss
Feb 09 2018 07:51
you mean the callback from PipeTo?
basically I need to know which call threw an exception, and that information is not in the exception itself
Onur Gumus
@OnurGumus
Feb 09 2018 07:55
myTask.ContinueWith(t => new MyRequestFailed(SomeRequestID), TaskContinuationOptions.OnlyOnFaulted).Pipe(Self)
then you handle the message with your receive method
you can add the exception too
to your message
Thomas Weiss
@ThomasWeiss
Feb 09 2018 07:55
thanks, let me try that
Onur Gumus
@OnurGumus
Feb 09 2018 07:56
of course you will need at least 2 ContinueWith
the success case
as well
or just use continue with and check task status with ternary operator
and conditional decide on the result
a third continuewith might be necessary if cancellation happens
if this is too verbose you can encapsulate all this logic into one extension method
myTask.ContinueWithEx(new Successful(...), new Failed(...), new Cancelled(...)).PipeTo(Self)
Thomas Weiss
@ThomasWeiss
Feb 09 2018 08:29
the argument to ContinueWith is correctly piped, unless I use a TaskContinuationOptions... in that case, I receive a Failure message with no Cause
Onur Gumus
@OnurGumus
Feb 09 2018 08:29
Yes should use that option
Thomas Weiss
@ThomasWeiss
Feb 09 2018 08:31
actually it's TaskContinuationOptions.OnlyOnFaulted that seems to cause problems
Onur Gumus
@OnurGumus
Feb 09 2018 08:31
I don't see why
Thomas Weiss
@ThomasWeiss
Feb 09 2018 08:31
if I only specify a successful continuation with TaskContinuationOptions.OnlyOnRanToCompletion it seems to run fine
but when I add the faulty path, I end up with a Failure message even though the task should have completed successfully
Onur Gumus
@OnurGumus
Feb 09 2018 08:32
Hmm
So it cannot recover from the failure
hold on
Thomas Weiss
@ThomasWeiss
Feb 09 2018 08:32
well in my case there's no failure
Onur Gumus
@OnurGumus
Feb 09 2018 08:33
Thomas you should have two continuewith
one for success and one for failure
Thomas Weiss
@ThomasWeiss
Feb 09 2018 08:33
yep that's what I'm doing
let me try to paste some code here
Onur Gumus
@OnurGumus
Feb 09 2018 08:33
hmm let me check
Thomas Weiss
@ThomasWeiss
Feb 09 2018 08:35
.ContinueWith(t => t.Result, TaskContinuationOptions.OnlyOnRanToCompletion) .ContinueWith(t => new UploadFailedMessage { Document = ... }, TaskContinuationOptions.OnlyOnFaulted) .PipeTo(Self);
that leads to a Failure, but if I remove the second ContinueWith it works (even though I've no failure)
Onur Gumus
@OnurGumus
Feb 09 2018 08:37
@ThomasWeiss can you try this variant : .ContinueWith( t => t.IsFaulted ?
.ContinueWith( t => t.IsFaulted ? new UploadFailedMessage { Document} : t.Result).PipeTo(Self);
Thomas Weiss
@ThomasWeiss
Feb 09 2018 08:40
wait that doesn't even compile :)
Onur Gumus
@OnurGumus
Feb 09 2018 08:42
 class ActorDummy : UntypedActor
    {
        protected override void OnReceive(dynamic message)
        {
            Console.WriteLine(message);
            Thread.Sleep(100);
            Task.Run(() => throw new Exception()).ContinueWith(t => t.IsFaulted ? 1 : 2).PipeTo(Self);
        }
    }
Thomas Weiss
@ThomasWeiss
Feb 09 2018 08:42
it was confused by the type of the ternary
looks better, let me test a bit more
Onur Gumus
@OnurGumus
Feb 09 2018 08:43
This just works fine for me prints 1 with exception and 2 with non exception
Thomas Weiss
@ThomasWeiss
Feb 09 2018 08:44
yay! seems that I got it all working now
thanks a lot Onur
Onur Gumus
@OnurGumus
Feb 09 2018 08:45
yw, btw this also works for me :
    class ActorDummy : UntypedActor
    {
        protected override void OnReceive(dynamic message)
        {
            Console.WriteLine(message);
            Thread.Sleep(100);
            Task.Run(() => throw new Exception())
                .ContinueWith(t => 1, TaskContinuationOptions.OnlyOnFaulted)
                .ContinueWith(t => 2, TaskContinuationOptions.OnlyOnRanToCompletion)
                .PipeTo(Self);
        }
    }
prints 1
every 100ms
Thomas Weiss
@ThomasWeiss
Feb 09 2018 08:46
I see, will try that syntax again then
my guess is that I get something back that's neither Faulted nor RanToCompletion and Akka doesn't know what to do with it?
Onur Gumus
@OnurGumus
Feb 09 2018 08:47
ah
yes this doesn't work for success case
you are right
you can use the first syntax then :)
I will try to check this why this doesn't work
Thomas Weiss
@ThomasWeiss
Feb 09 2018 08:47
it's fine for me, thanks again!
TaiAivaras
@TaiAivaras
Feb 09 2018 08:50
Hello, friends
What would be a nice approach to create a JS client to connect to AKKA.Net actor system? 🤔🤔
Onur Gumus
@OnurGumus
Feb 09 2018 08:55
a web application ?
TaiAivaras
@TaiAivaras
Feb 09 2018 08:55
anyone has some ideas?
ye ye
Onur Gumus
@OnurGumus
Feb 09 2018 08:55
I mean just put a restful service and call your actors from your controller
Thomas Weiss
@ThomasWeiss
Feb 09 2018 08:55
maybe using something like http://tjanczuk.github.io/edge?
TaiAivaras
@TaiAivaras
Feb 09 2018 08:55
i was thinking real time stuff
Onur Gumus
@OnurGumus
Feb 09 2018 08:56
oh
then something like signalr
Bartosz Sypytkowski
@Horusiath
Feb 09 2018 08:56
@OnurGumus @ThomasWeiss PipeTo has two optional parameters called to map task result or exception to actual message type. No need for using ContinueWith
Onur Gumus
@OnurGumus
Feb 09 2018 08:56
lol
another RTFM case :)
managerger
@managerger
Feb 09 2018 08:56
:-)
Thomas Weiss
@ThomasWeiss
Feb 09 2018 08:57
@Horusiath are you referring to the 2 success/error callbacks?
Onur Gumus
@OnurGumus
Feb 09 2018 08:57
I guess he was already trying that though
@Horusiath that api doesn't cover the cancellation though.
Thomas Weiss
@ThomasWeiss
Feb 09 2018 08:58
oooh the second overload
Onur Gumus
@OnurGumus
Feb 09 2018 08:58
a task can have 3 outcomes, success,fail or cancel
Thomas Weiss
@ThomasWeiss
Feb 09 2018 08:58
RTFM indeed :worried:
Bartosz Sypytkowski
@Horusiath
Feb 09 2018 08:58
@OnurGumus afaik cancel is OperationCancelledException
Onur Gumus
@OnurGumus
Feb 09 2018 08:58
let's try
Thomas Weiss
@ThomasWeiss
Feb 09 2018 08:59
(tbh I couldn't really RTFM because PipeTo is not very much documented: http://getakka.net/api/Akka.Actor.PipeToSupport.html)
Bartosz Sypytkowski
@Horusiath
Feb 09 2018 09:00
@TaiAivaras if you're using SignalR, you can create a dedicated actor from signalr Hub, that will work as an adapter between SignalR and Akka ActorSystem
TaiAivaras
@TaiAivaras
Feb 09 2018 09:02
@Horusiath You've done that before?
is SingnalR still a thing? does it even work with dotnet core?
Onur Gumus
@OnurGumus
Feb 09 2018 09:03
@Horusiath Cancellation is ignored by that API.
Bartosz Sypytkowski
@Horusiath
Feb 09 2018 09:03
@TaiAivaras it will be back on asp.net core 2.1 - also I've done it in the past: http://bartoszsypytkowski.com/log-your-akka-net-application-in-your-browser/
Onur Gumus
@OnurGumus
Feb 09 2018 09:03
 class ActorDummy : UntypedActor
    {
        CancellationTokenSource s = new CancellationTokenSource();
        public ActorDummy()
        {
            s.Cancel();
        }
        protected override void OnReceive(dynamic message)
        {
          Console.WriteLine(message);
            Thread.Sleep(100);
            Task.FromCanceled(s.Token)
                .PipeTo(Self, null, () => 1, (e) => e);
        }
    }
send an initial message and nothing else happens
so it is a missing piece.
TaiAivaras
@TaiAivaras
Feb 09 2018 09:04
@Horusiath I recall hearing that before, but ok
Onur Gumus
@OnurGumus
Feb 09 2018 09:09
yes code looks correct
Onur Gumus
@OnurGumus
Feb 09 2018 09:25
@Horusiath found the issue. The thing is when a task is cancelled , task.Exception is null.
so the call back is invoked, but with a null parameter.
which is a bit quirky.
Perhaps inventing a Status.Cancelled might be handier.
Bartosz Sypytkowski
@Horusiath
Feb 09 2018 10:35
@OnurGumus something to discuss
Artemov Ivan
@ZOXEXIVO
Feb 09 2018 10:41
Hello!
Today we have some troubles with our servers - CPU load was 100% at 8 servers and hot line was
Helios.Concurrency.DedicatedThreadPool+PoolWorker.ctor>b__a() (from <)
v1.0.8
Bartosz Sypytkowski
@Horusiath
Feb 09 2018 10:49
@ZOXEXIVO v1.0.8 is quite old, a lot has changed since then. Your line looks like a hot code responsible for remote transport - which also has changed (from Helio to DotNetty) around v1.2.
Onur Gumus
@OnurGumus
Feb 09 2018 11:07
@Horusiath regarding the issue you opened let me clarify, there is no null ref anywhere. It's just the exception property is null.
Nor there is any null reference exception.
Bartosz Sypytkowski
@Horusiath
Feb 09 2018 11:10
yes, that what I meant too
Onur Gumus
@OnurGumus
Feb 09 2018 11:10
Oh ok
Artemov Ivan
@ZOXEXIVO
Feb 09 2018 11:25
@Horusiath thank you
Joshua Garnett
@joshgarnett
Feb 09 2018 16:22
Has anyone ever run into issues with Distribute Pub/Sub failing to publish messages to subscribers? I’ve got a single node setup, I’ve verified the subscriber receives an ack, and that the publisher is publishing to the correct topic. After running for some period of time, the publish of messages never reach the subscriber.
I’ve just started debugging, so will keep digging on my end, just curious if that sounded familiar to anyone else.
Onur Gumus
@OnurGumus
Feb 09 2018 16:23
works for me, but I have run it for long time.
I have not.