These are chat archives for akkadotnet/akka.net

4th
Oct 2016
Maciek Misztal
@mmisztal1980
Oct 04 2016 10:41
/@all my talk about akka.cluster running on service fabric wilk happen today oct4th At 2:35 pm CET. Streaming link can be found on http://azureday.pro
Peter Bergman
@peter-bannerflow
Oct 04 2016 11:32
@mmisztal1980 that sounds cool, will it be available afterwards?
Steven Harrap
@stevenharrap
Oct 04 2016 13:09
Hi. Is there a means of keeping a node in a cluster unavailable to other nodes until some condition is met? Or, alternatively, is there means of changing the role that a node has after the node has joined the cluster such that its new role would be of use (interest) to other nodes in the cluster. In either case I would like to be able to make requests from my new node to other cluster routers and pubsubs without work being routed to my new node. The idea being that I want my new node to have achieved a specific state before its let loose as a fully fledged member of my cluster.
verysimplenick
@verysimplenick
Oct 04 2016 14:00
Hi all, anybody here? :)
Maciek Misztal
@mmisztal1980
Oct 04 2016 14:05
It should appear on ch9 in a couple weeks
verysimplenick
@verysimplenick
Oct 04 2016 14:07
@mmisztal1980 can u help me? I want know that my actor(pool) stay without messages (or stop after child actors do some work), how I can read state of actor?
I want implement something like @Horusiath write here http://bartoszsypytkowski.com/dont-ask-tell-2/
Maciek Misztal
@mmisztal1980
Oct 04 2016 14:09
You can wait for a completion Message and Then reply tovthe Child with PoisonPill.Instance to kill it
verysimplenick
@verysimplenick
Oct 04 2016 14:09
NonActor->Tell actor->actor run some number of child actors, they after done send message for Sender something like "I'm done")
Maciek Misztal
@mmisztal1980
Oct 04 2016 14:09
r obce the Child sends the conpletion Message It can do a Context.Stop()
or once
verysimplenick
@verysimplenick
Oct 04 2016 14:10
yep, I do something like if (rulesCount <= 0) Context.Stop(Self);
but, how I can get status of actor? here -->actorPool.Tell(new Tuple<AggregateRuleGroup,double>(ruleGroup, lastProcessedDatetime));
Maciek Misztal
@mmisztal1980
Oct 04 2016 14:13
You need to Send Or Ask a Message asking for the status
verysimplenick
@verysimplenick
Oct 04 2016 14:13
In actorPool I use Context.Stop(Self); if child are done, but, now I need wait outer Actor something like WhenTerminated for IActorRef
only this way? loop with ask status?
Maciek Misztal
@mmisztal1980
Oct 04 2016 14:43
No :) there's more Then one way of doing It really
You need to see what works best for you
Stephen Newman
@goodisontoffee
Oct 04 2016 15:08
Are there any good tutorials out for how to put together a simple cluster using Lighthouse as a seed node with Akka 1.1.2?
Bartosz Sypytkowski
@Horusiath
Oct 04 2016 16:34
@goodisontoffee basically you start lighthouse process under well known ip:port, and pass that port into config for other nodes
Daniel D'Agostino
@dandago2_twitter
Oct 04 2016 17:10
I was wondering why supervision strategies/hierarchies are a big deal. Personally I think the whole "let it crash" ideology is very dangerous. As for the uses of supervision strategies/hierarchies, I can think of the following scenarios:
  1. Unhandled exceptions. You want somewhere central where to log and handle them after they bubble up. Fine.
  2. External problems. An SQL connection is giving problems, so you restart the actor. How would this help? You're supposed to scope your use of such external resources within using blocks anyway, so how would restarting the actor make a difference?
  3. Validation. A message received by the actor has missing data and you can't process it properly. In this case you would just log the problem and move on processing the next message.
    So, why is supervision a good idea, and in what scenarios?
verysimplenick
@verysimplenick
Oct 04 2016 17:15
2) AFAIK In actor you can use try-catch as usually in parent actor (http://getakka.net/docs/concepts/supervision) u can implement your custom error handling here if (x is SqlException) { /* here put custom logic*/return Directive.Resume;}
Daniel D'Agostino
@dandago2_twitter
Oct 04 2016 17:15
why wouldn't you just try/catch in the actor itself?
verysimplenick
@verysimplenick
Oct 04 2016 17:16
why not? use it :) if child has unhandled only when work supervision
I lost , in prev message before >in parent
but I'm newbie in akka.net maybe something wrong understand
Marc Piechura
@marcpiechura
Oct 04 2016 17:23
Different parents may want to handle child errors differently, one may restart 3 times and then stop other one would like to stop connection attempts after first failure and so on
You loose this ability if you handle failures directly with try catch
Also you can't escalate failures if you handle them directly, maybe you want to stop all child's if one fails...
verysimplenick
@verysimplenick
Oct 04 2016 17:28
yep supervision it's good feature
Daniel D'Agostino
@dandago2_twitter
Oct 04 2016 17:34
can you give me an example where that approach would make sense?
verysimplenick
@verysimplenick
Oct 04 2016 17:36
I see something like this: file parsing actor if in 10 sec generated > 10k exceptions => maybe file change format => escalate to parent => stop all parsers => message to user, wait reaction
Daniel D'Agostino
@dandago2_twitter
Oct 04 2016 17:37
so you would use it in a distributed work scenario
yeah, that kind of makes sense
Bartosz Sypytkowski
@Horusiath
Oct 04 2016 18:08

@dandago2_twitter

AD 1. Problem with unhandled exceptions is that they are expensive (in the scale we're talking here) - imagine following case: you have message pipeline between 3 actors: A ⇒ B ⇒ C. Each actor has it's own in-memory state (which is also backed up in the database). Thanks to that, you don't need to reach the database each time you want to retrieve part of the state, greatly increasing the throughput. However if inside call pipeline C will blow up, and an error could be potentially 1) roll it back to the caller or 2) escalate upward parent hierarchy . Both cases would result in series of cascading failures, causing your actors to restart and requiring each one of them to retrieve it's state again from the database, crippling the overall performance of your system. With supervision strategy you can "cut the wire" and react before the error spreads out.

AD 2. In case of failing database connection restarting actor wouldn't make a difference - moreover it would probably blow up the rest of the system, as you'd hit 100% failure ratio, restarting an actor each time and trying to reconnect db again (which may not be dead but just slow under huge pressure) - hitting it thousands times per sec won't help anything. This is why we have circuit breakers and exponential backoff strategies.

AD 3. You don't throw exceptions for validation - this is terrible idea and one of the worst habits of .NET devs.

Andrew Young
@ayoung
Oct 04 2016 19:11
is there any advantage of keeping a Dictionary of your child actors over asking the Context.Child() to find the child for you?
Daniel D'Agostino
@dandago2_twitter
Oct 04 2016 19:33
thanks @Horusiath, are there any other useful scenarios to use supervision other than the aforementioned fan-out distributed work scenario?
@ayoung I think not; I actually think it is wasteful to use a dictionary of child actors, given that this information is already available to you
Bartosz Sypytkowski
@Horusiath
Oct 04 2016 20:18
@dandago2_twitter from what I know the supervision strategies will be removed in the future (take a look at jvm akka-typed, which is base for the future API of akka), to make actors even faster. There will be other patterns to cover existing scenarios.
Andrew Young
@ayoung
Oct 04 2016 22:20
if i have an actor hierarchy like this in a cluster hashPool -> processActor -> broadcastGroup how would I configure the broadcastGroup in HOCON?
the deployment path is unknown at that point because of the hashPool, right?
the path would be /hashPoolRouter/<some generated name>/processActor/broadcastGroup