Hi Vince, what you describe should work in principle, but I would like to understand your basic reasoning as to why orders shall have a persistent identity instead of creating one actor per tradable item and sending orders their way. In your design you will end up sending lots of price updates around, growing in number proportionally to the number of active orders, whereas in my proposal the update count would just depend on the number of traded items.
If you need to create one actor per order, then you could also consider sharding the price update service on a per-item basis. If you then just use the order number as the sharding ID, no special handling for shard re-balancing is needed on the update service side (but I think that was what you already meant in your description, I just wanted to be sure). Regards, Roland 9 feb 2014 kl. 15:38 skrev Vince Golding <[email protected]>: > I am in the process of investigating how I would go about implementing a > scalable fault tolerant order management system using an akka sharded > cluster. > > Initially all orders will be limit orders whereby they are entered with a > limit price and then executed once this limit price has been reached. > > My current thinking is to have individual orders represented as an FSM actor > which receives a stream of price events, updating the state of the order once > the price condition is met. > > I was intending to use a sharded cluster to distribute the orders across > multiple nodes. The order actors will be made persistent using akka > persistence so their state can be recovered after re-balancing etc. > > So that the order actors can receive price events after re-balancing, I was > going to create some sort of shard aware price publisher that the order actor > could subscribe to on start up. The publisher would then publish price events > via the sharded cluster. This would ensure the order actors would still > receive price events after a rebalance. > > Is this a reasonable way to handle event streams for actors which belong to a > sharded cluster? > > To enable querying the state of all orders in the cluster, I was going to > have each order actor register it's id in some central repository. This > repository could then be queried for orders which are in the cluster and > queries could then be sent to each order actor via the sharded cluster to > retrieve it's state. > > Is this a sensible way to handle the querying of actor state in a sharded > cluster? > > > > -- > >>>>>>>>>> Read the docs: http://akka.io/docs/ > >>>>>>>>>> Check the FAQ: http://akka.io/faq/ > >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user > --- > You received this message because you are subscribed to the Google Groups > "Akka User List" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/akka-user. > For more options, visit https://groups.google.com/groups/opt_out. Dr. Roland Kuhn Akka Tech Lead Typesafe – Reactive apps on the JVM. twitter: @rolandkuhn -- >>>>>>>>>> Read the docs: http://akka.io/docs/ >>>>>>>>>> Check the FAQ: http://akka.io/faq/ >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups "Akka User List" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/groups/opt_out.
