These are chat archives for akkadotnet/akka.net

30th
Oct 2016
Gregorius Soedharmo
@Arkatufus
Oct 30 2016 04:19
so, i was wondering... what are the limits of Props, what kind of objects can it persist when it comes to remote deployment
should i limit myself with POCO or can I get a bit more fancy with it?
Bartosz Sypytkowski
@Horusiath
Oct 30 2016 07:11

@Arkatufus when you're going to use Props for remote deployment, you must specify constructor, where each field value is valid to be serialized.

In more complex cases you may define something called surrogate: it's a replacement object to be serialized instead + some logic used to transform both objects in both ways. This is how IActorRef can be used between actor system boundaries.

Ophir Oren
@developer82
Oct 30 2016 07:56
I'm just starting out in the world of actor models, and I've started learning both AKKA.NET and Orleans. to compare both technologies. In Orleans the have something called a "Silo" which holds "Grains" (from my understanding a Grain is an Actor), but it's mentioned that the Silo manages the lifetime of that Actor - for instance shut it down when there are no messages arriving at a period of time in order to save memory. I'm wondering how to configure AKKA.NET to shut down an Actor if it's "idle" for some time. Is that possible?
Gregorius Soedharmo
@Arkatufus
Oct 30 2016 08:52
@Horusiath oh, ok, POCO with serializable attribute would be enough for most cases?
Marc Piechura
@marcpiechura
Oct 30 2016 09:01
@developer82 you can use http://getakka.net/docs/Receive%20timeout and then call Context.Stop(Self)
Bartosz Sypytkowski
@Horusiath
Oct 30 2016 09:19
@Arkatufus sure. You don't need [Serializable] attribute anyway
Gregorius Soedharmo
@Arkatufus
Oct 30 2016 10:15
@Horusiath I'll give that a go, thanks
Chris
@chris-eaton
Oct 30 2016 19:25
@ChaosD Ive solved this before by having some "normal" server code that read data from an external source and, at an appropriate point, it sends that data onto my actor system.
qwoz
@qwoz
Oct 30 2016 20:10
though with ReceiveTimeout and Context.Stop(Self) couldn't you run into a race condition? While you're processing the ReceiveTimeout message, another message comes in which will end up deadlettered. If that other message is part of some critical flow, you'd either need to implement retry logic around Telling that message to your actor or find another way to stop the actor. I believe this is handled via passivation in a cluster scenario.
Bartosz Sypytkowski
@Horusiath
Oct 30 2016 20:40
@qwoz @developer82 yes, you can run into messages being deadlettered here - and in Akka.Cluster.Sharding it's solved by passivation. In general cluster sharding gives managed actor lifecycle. It's a higher level abstraction (with some performance cost), but everything depends on the use case and characteristics of your system.