These are chat archives for akkadotnet/akka.net

9th
Jul 2016
Arsene Tochemey GANDOTE
@Tochemey
Jul 09 2016 20:18
Hello I understand the Ask messaging pattern. However I could not get clearly the use of the PipeTo. Please experts educate me on this.
Aaron Stannard
@Aaronontheweb
Jul 09 2016 20:19
@Tochemey PipeTo turns delivers the results of a Task<T> to an ICanTell, which can be either an IActorRef or an ActorSelection
so whatever the T is when the Task completes
that will be delivered as a message to that ICanTell
this allows the actor to start multiple asynchronous operations and have those results get processed through the actor's mailbox as messages
you can also pass the results of a Task to a different actor and do all sorts of cool stuff with it using PipeTo
inside my WebCrawler demo app I use PipeTo to asynchronously download web pages that are going to be parsed by the crawler later
Arsene Tochemey GANDOTE
@Tochemey
Jul 09 2016 20:21
@Aaronontheweb Thank you for the explanation.
Aaron Stannard
@Aaronontheweb
Jul 09 2016 20:21
did it help?
Arsene Tochemey GANDOTE
@Tochemey
Jul 09 2016 20:22
I grabbed the latest part of <<you can also pass the results of a `Task` to a different actor and do all sorts of cool stuff with it using `PipeTo`>>
@Aaronontheweb I would like to know whether there is a plan for Akka Http port seeing that the java version has one that helps Spray to be built.
Aaron Stannard
@Aaronontheweb
Jul 09 2016 20:27
no plans right now; Akka.HTTP consists of 150k lines of code and took four developers working full time to implement. (did I get that right, @Horusiath ?) - it'd probably be faster for us to implement it since we're just porting it and not inventing from scratch. Right now we have the following three initiatives under way:
  1. Stablizing and releasing Akka.Cluster.Tools and Sharding; this includes the 1.5 release and making Wire the default serializer.
  2. Preparing Akka.Persistence for stable RTM release, which should happen soon;
  3. Laying the groundwork for .NET core support
Arsene Tochemey GANDOTE
@Tochemey
Jul 09 2016 20:32
@Aaronontheweb I wish I can contribute
@Aaronontheweb @Horusiath Congrats
Arsene Tochemey GANDOTE
@Tochemey
Jul 09 2016 21:18
Hello please what is the difference between TypedActor, UntypedActor and ReceiveActor. Also when to use each of them and what is the recommended?
MrR0b0t
@MMrR0b0TT
Jul 09 2016 21:19
Hi guys
Why when I pass a ICancelable parameter in my ScheduleTellOnce it didn't actually schedually the message?
Should I do something different?

this works:
Context.System.Scheduler.ScheduleTellOnce(TimeSpan.Zero, currentActor, message, Self);

this doesn't work, the currentActor didn't receive the message.
_cron = new Cancelable(Context.System.Scheduler);
Context.System.Scheduler.ScheduleTellOnce(TimeSpan.Zero, currentActor, message, Self, _cron);

Aaron Stannard
@Aaronontheweb
Jul 09 2016 21:57
@MMrR0b0TT not sure why that doesn't work - mind opening a bug report for it?
in the meantime, to get a Cancellable use the ScheduleTellOnceCancelable method
will return one automatically
MrR0b0t
@MMrR0b0TT
Jul 09 2016 21:58
yes, but in my case I would like to use it in a loop, so I was trying to instantiate it before
I will do more tests and a report it, thank you @Aaronontheweb
qwoz
@qwoz
Jul 09 2016 22:20
@Tochemey check out http://getakka.net/docs/Working%20with%20actors and https://github.com/akkadotnet/akka.net/blob/4acfa7c363bfa83ac71849a5a8487c8d6b1bbcb1/src/examples/TimeServer/TimeClient/Program.cs -- the first link describes UntypedActor vs ReceiveActor. The second link is an example of a TypedActor which can handle several different types. As to when to use one over the other, I think the benefits of strongly typed vs untyped should be fairly obvious. I haven't used TypedActor myself but if you compare the sources of each you should get a better understanding of the differences: https://github.com/akkadotnet/akka.net/tree/dev/src/core/Akka/Actor
Note that ReceiveActor extends UntypedActor which extends ActorBase. TypedActor directly extends ActorBase.
It looks like the main difference is that TypedActor doesn't expose Become(...) methods, so you can't switch receive behavior at runtime.
MrR0b0t
@MMrR0b0TT
Jul 09 2016 22:26

@Aaronontheweb I've checked here and I was calling the CancelIfNotNull() before in the Cancelable, because this Receive<> should schedule a group of jobs each time it receive a message and if is there any scheduled it should cancel it before. So, I change now, I put this in my receive. Do you guess is it good practice?

_cron.CancelIfNotNull();
_cron = new Cancelable(Context.System.Scheduler);