These are chat archives for petabridge/akka-bootcamp

10th
Jun 2015
Igor Ziselman
@constructor-igor
Jun 10 2015 08:27
how can I tell to actor system to create several instances om my concrete actor and run it in multi-threaded mode?
Arjen Smits
@Danthar
Jun 10 2015 08:30
Sounds like you want to use Routers: http://getakka.net/docs/working-with-actors/Routers
Igor Ziselman
@constructor-igor
Jun 10 2015 08:43
exactly! thank you.
Igor Ziselman
@constructor-igor
Jun 10 2015 09:01
type "FluentConfig" cannot be found (syntax error) in sample http://getakka.net/docs/deployment-scenarios/Console
Bartosz Sypytkowski
@Horusiath
Jun 10 2015 09:05
fluent config has been removed to https://github.com/rogeralsing/Akka.FluentConfig
Ivan R. Perez
@irperez
Jun 10 2015 15:10
@Horusiath going back to the Stash conversation in my scenario... I tried to follow your example using a bounded limit, but what I'm seeing is that Akka doesn't implement IWithBoundedStash yet. What would you recommend to do instead? I'm trying to keep as many messages as "reasonably" possible while the external resource is down. I have applied a sort of exponential backoff algorithm to check for the state of the external resource before opening the flood gates. But you are right, the stash could get too big. Just not sure how to handle it once it is over the limit or how to avoid out of memory exceptions due to the stash size.
Aaron Stannard
@Aaronontheweb
Jun 10 2015 16:10
@irperez sounds like we need to implement IWithBoundedStash to solve that problem
although I believe your actor will crash once it exceeds its maximum stash size
the problem you're describing would be a great fit for Akka.Streams (stream processing with built-in backoff), but that's a ways out
John Haigh
@haighis
Jun 10 2015 19:43
@irperez I myself having been trying to accomplish the same thing to keep messages while the external resource/service is down. I like the concept of Roger Alsing outlined in his post on stack overflow where you have a dbup and dbdown state. In a dbdown state you need a place to store those messages until the data store is once again available. I was thinking a persistent actor could be this place to store messages in a db down state, but after thinking about and and discussing with @Aaronontheweb I'm not sure
Maciek Misztal
@mmisztal1980
Jun 10 2015 21:00
I have a question regarding the Func<T> injection pattern. Typically you guys use it to ensure, that whenver an actor is re-started, a fresh instance of a dependency is injected into the actor instance. I take it, it's perfectly legal, to replace the Func<T> with dependency injection?
Aaron Stannard
@Aaronontheweb
Jun 10 2015 21:34
@mmisztal1980 yessir, we actually wrap a DI container inside a Func<T> inside one of our design patterns training samples
and use the DI container to resolve the dependency each time the Func gets called