Hi Roland, thx for the reply, comments inline.
cheers, Vince On Monday, February 10, 2014 8:15:33 AM UTC+1, rkuhn wrote: > > 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. > So with this approach I would create shards based on tradable items? One potential problem with this could be if the number of orders for a given tradable item becomes unmanageable for a single shard. Other than that, agree this would be a more sensible approach to keep the number of price updates down > > 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). > yes, this is along the lines of what I was thinking. > > Regards, > > Roland > > 9 feb 2014 kl. 15:38 skrev Vince Golding <vincego...@gmail.com<javascript:> > >: > > 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 akka-user+...@googlegroups.com <javascript:>. > To post to this group, send email to akka...@googlegroups.com<javascript:> > . > 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 <http://typesafe.com/> – Reactive apps on the JVM. > twitter: @rolandkuhn > <http://twitter.com/#!/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 akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/groups/opt_out.
