Hi Ashley, Op vrijdag 27 juni 2014 06:57:17 UTC+2 schreef Ashley Aitken: > > Hi Jeroen, > > On Friday, 27 June 2014 05:13:54 UTC+8, Jeroen Gordijn wrote: > > Why do you need a view that watches multiple Processors? This can already >> be achieved. You create a child View for every Processor you would like to >> watch. The child simply forwards all messages to its parent. >> > > There are two (or three) reasons I would suggest, please correct me if I > am wrong: > > 1. What if there are a very very large number of Processors (e.g. for each > Customer aggregate root) > > Do we keep the Views for each Processor (as there could be more than one) > active all the time? If they are not active then (AFAIK) they will not be > updated and when a query comes in for that View they will need to be > activated and recover their state. >
How many aggregates do you expect? Actors are light weight and you can have ~2.5 million actors per GB of heap (source: akka.io). I would expect there to be more problems with keeping other state in memory. I would keep the actors active, until I am certain this will run into problems. > > > A View that could be notified of changes to any Processor of a specific > type could create/activate and update that Processor's View as needed so > that it is ready for a subsequent query. This could include putting the > view into an external store. > > 2. What if the Processors have a one to many association with another type > of Processor (e.g. each Customer can have many Songs) > > One of the roles of the read side in CQRS is to enable (possibly multiple) > denormalised read models. How do we maintain DenormalisedView of Processor > (e.g. Customer with Songs) without having all the Views of the associated > Processor also active? > > My first attempt would be to do exactly the same as I mentioned before. Just create actors that forward the events to the aggregator. I guess that this possibly lead to many actors. Otherwise I would create an actor per Processor and let the aggregators subscribe to that. This also gives you the possibility to enrich the message with some information which is not in the event. I am persisting an OrderSubmitted event. This event does not contain the orderId. In the view I do need the OrderId to correlate this event to the correct representation. The View knows the orderId and enriches the event by wrapping it in a Envelope with the orderId. Like: case OrderSubmitted => context.parent ! Envelope(orderId, OrderSubmitted) Otherwise every event needs to contain the AggregateId. > A DenormalisedView(s) that could be notified of changes to one of its > dependent Processors could create/activate that Processor's View and update > the denormalised view(s) based on that. > > 3. When both (1.) and (2.) above occur (which I think is quite common). > > If you can think of a way to efficiently do these at scale I would be very > interested to hear. From my understanding of CQRS it is common for the > read side to be able to subscribe to notification of changes to the event > store so as to efficiently handle the cases above. > I agree that receiving events would be a nice optimization, but you still need to know for which Aggregate the event is. This will show in your code. To be able to scale with the current solution you could use cluster sharding. However, I don't know the implementation details and don;t know how the polling is performed. Do 1000 Views lead to 1 poll every interval? > > Akka Persistence's current approach (as far as I can tell and confirmed > somewhat by Patrik) can't really handle the cases above efficiently or at > scale because of this lack of more general notifications (i.e. it just > updates active Views at regular intervals based solely on one specified > Processor). > The events could lead to faster eventually consistency. As events are published per aggregate (processorId) I do not see how this can be automatically merged into one stream without the need to change your software to include the aggregateId in every event. You could argue that including the id in every event makes things clearer anyway.... so in that case I follow you reasoning. > > Patrik in another thread suggested implementing the above scenarios using > notifications with an external distributed pub-sub and Pawel has done just > that in his fantastic DDD-Leaven-Akka examples using Apache Camel and > ActiveMQ (but there are still limitations, e.g. rebuilding denormalised > views). > > It's a shame that Akka Persistence doesn't seem (on its own) fully > functional for CQRS as yet (IMHO). It is still experimental, of course, so > there is great hope that something will be done to address this. > I was not aware of the DDD-Leaven-Akka thanks for mentioning that! I will look into it. Apart from optimization I do not feel hindered to create a CQRS application. However, I did not build a large scale application with it yet. Cheers, Jeroen -- >>>>>>>>>> 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/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/d/optout.
