[akka-user] Example project: Coding an elevator state machine with Akka FSM

Hi folks, I really fell in love with Akka when I discovered the Finite State Machine DSL and thought I'd share the love with an example project that demonstrates how to build an elevator state machine using TDD. Here's the project: https://github.com/tombray/akka-fsm-examples Here's the eleva

Re: [akka-user] streams: catch exceptions inside transformers of infinite streams

Hi Evgeniy, On Tue, Jul 29, 2014 at 4:38 PM, Evgeniy Ostapenko wrote: > Now akka-streams seems to be oriented on working with finite streams, > because: > 1) Any exception inside transformer kills all stream. > This is not an issue, if you want to represent processing errors you should make t

[akka-user] Re: child doesn't get notified or killed when remote parent is dead

To be honest, I don't know the answer but you can easily check what child actor receives. Just log every message child actor receives and see if comes any message that would indiciate that parent got killed. Buy according to docs

[akka-user] Re: Akka recovery from Failure

It's a little workaround but I guess it would work: in child actors, workers, acquire ActorRef for your master Actor using actorFor. If master dies its path will be reused and new master Actor will have same path so it doesn't matter that ActorRef changes W dniu wtorek, 29 lipca 2014 14:

Re: [akka-user] Re: How I can watch for actor child change

If specific states of child actors need to be tracked, one could use ClusterClient and have the supervisor (or masters) subscribe to a topic. State changes could be published there. On Tuesday, July 29, 2014 7:37:31 AM UTC-7, Sean Zhong wrote: > > Thanks, Martynas. > > On Tuesday, July 29, 2014

[akka-user] reddis based job queue framework in akka? similiar to reque?

Hello! Is there a akka based job/queue framework out there in the open source world? I'm looking for something similiar to https://github.com/resque/resque. Basically a queue that is built on top of redis. Resque also then has a base class where you build your custom worker processes that wil

[akka-user] streams: catch exceptions inside transformers of infinite streams

Now akka-streams seems to be oriented on working with finite streams, because: 1) Any exception inside transformer kills all stream. It is good for finite streams, but for infinite listener it is bad. Provider and Flow has not any modifier for change this behavior. 2) In case of finite stream

Re: [akka-user] Re: How I can watch for actor child change

Thanks, Martynas. On Tuesday, July 29, 2014 9:38:48 PM UTC+8, Martynas Mickevičius wrote: > > Hi Sean, > > I can not think of a clean way of doing that. One idea that popped into my > mind was to write a custom Mailbox implementation where it would be > possible to track mailbox owners. This is

Re: [akka-user] actor ask future manipulation

Thanks for your reply Martynas and code example I can run as described. It's very helpful to have your understanding confirmed when you are learning something new. I must be doing something wrong with the failed result subsequently. -- >> Read the docs: http://akka.io/docs/ >

Re: [akka-user] Re: How I can watch for actor child change

Hi Sean, I can not think of a clean way of doing that. One idea that popped into my mind was to write a custom Mailbox implementation where it would be possible to track mailbox owners. This is surely and definitely a hack. Maybe it will give you some nicer ideas. :) Writing custom ActorRef provi

Re: [akka-user] actor ask future manipulation

Hi Rob, after the map you will have failed Future if you throw an exception inside a map. So your example seems correct. Check out this full compiling and running sample code: import scala.concurrent.Future import scala.concurrent.ExecutionContext.Implicits.global def mapIt(f: Future[Option[Int]

[akka-user] child doesn't get notified or killed when remote parent is dead

Test case: parent actor: in a local machine, child actor, in a remote machine. child actor is created by parent actor by akka remote deployment. Behavior observed: when the parent JVM is killed, the child actor is *NOT* stopped. I have not use child context.watch(parent) for this case. I oringa

Re: [akka-user] how to know supervised actor is stopped normally or abnormally?

Hi Roland, Yes, you are right, the task need to send a explicit "TASK_SUCESS_FINISH" message to notify the subscribe that task finish normally, all other cases is abnormal. The only pain point in this case is that I have to write the subscription twice. First the subscriber register it self as

[akka-user] Akka recovery from Failure

Hi, I’ve been doing a lot of reading into the Akka framework and have played with a few of the examples, and sort of understand is ‘embrace failure’ and ‘self heal’ ethos. But I have a use case using ‘exactly-once’ message delivery and I can’t see how to get Akka to handle failure or self heal.

[akka-user] Re: How I can watch for actor child change

The child's path is not known. I want get notified when a new child come up no matter what the path is. On Monday, July 28, 2014 2:48:28 PM UTC+8, 09goral wrote: > > use context.watch(ActorRef) to register for chaning of actor's life cycle. > > W dniu niedziela, 27 lipca 2014 09:23:14 UTC+2 uży

Re: [akka-user] Neo4j as overlay state-DB for a "graph of Akka Actors"

Hello Muthu, that is certainly an interesting use case you have. Would love to hear about the final solution you will end up with. I think that you should not store ActorRefs in the DB because they can get stale if the corresponding actor will be stopped and started again. Instead you can store o

[akka-user] actor ask future manipulation

The following code is part of a Play asynchronous action The actor actorRef replies to GETVALUE with Option[Int] I would like a response of None to give a failed future f but instead the exception is thrown val f = (actorRef ? GETVALUE) map { case Some(i; Int) => case None => throw new Except

[akka-user] Akka-Camel Custom Polling strategy

Hi, In our Akka based application there is a need to control the UntypedConsumerActors ( required for flow control) who listen on the endpoint URI's. Is there a way we can set up an custom poll strategy on these Endpoint URI and consumers so that it polls (consumes messages from Endpoint which

Re: [akka-user] ShardCoordinator/ShardRegion retryInterval

Hello Patrik, thank you for looking into this. But I think I was wrong about the retry interval: The Retry messageHandler first checks if the Coordinator is Some only then requestShardBufferHomes is called, therefore the remaining ShardRegion on Node A first has to receive a MemberRemoved Cluste

Re: [akka-user] Pooled router initialisation

Thank you Martynas thats perfect. On Tuesday, 29 July 2014 11:53:49 UTC+1, Martynas Mickevičius wrote: > > Hi Jabbar, > > if you still want to use pooled router you can specify arguments to routee > constructor in the props. For example: > > >1. val router1: ActorRef = >2. context.actorO

Re: [akka-user] Pooled router initialisation

Hi Jabbar, if you still want to use pooled router you can specify arguments to routee constructor in the props. For example: 1. val router1: ActorRef = 2. context.actorOf(FromConfig.props(Props(classOf[Worker], argument1, argument2)), "router1") On Tue, Jul 29, 2014 at 10:31 AM, Jabb

Re: [akka-user] ShardCoordinator/ShardRegion retryInterval

Hi Michael, I get your point. I'm not sure your workaround is correct for all scenarios. I will follow up on this next week. Perhaps we can improve this, but there are other cases when messages will be lost, so reliable delivery must anyway be added on top when it is needed. /Patrik > 29 jul

Re: [akka-user] Improving Akka Persistence wrt CQRS/ES/DDD

- a total order per persistenceId based on sequence numbers (= partial ordering in the "all events" stream) is a must have IMO. - ordering based on timestamps should be an application level concern (= timestamps in application-defined events and (re-)ordering done by application) Agreed, seqNrs

[akka-user] ShardCoordinator/ShardRegion retryInterval

Hello, we have for example a 2 node cluster, the ShardCoordinator runs on node B , sharded actors run on node A and node B. When node B goes down the coordinator is started on node A and gets replayed, which means that its state still hold outdated information about the ShardRegion(with its Shar

[akka-user] Pooled router initialisation

OK I found it. A non clustered group router with externally assigned routees. -- >> Read the docs: http://akka.io/docs/ >> Check the FAQ: >> http://doc.akka.io/docs/akka/current/additional/faq.html >> Search the archives: https://groups.google.com/g