ok, but ordering must not be important anyway otherwise there will be the same problems as when using a view for different source processors. Also, ordering is probably not the only problem: what happens if e.g.: only one view gets restarted because of an error and replays? what happens if the aggregator gets restarted by its supervisor? (probably can use resume..) what to do in a clustered environment where views/aggregator can live on different nodes? (aggregator could be a cluster singleton, but still one has to deal with replaying views..) I think in the end the aggregator also has to persist its state somehow but then why to use a view between source processors and aggregator?
So, for aggregating I am planning to use pull not push for the moment, when the aggregator is queried it gets the state of all necessary views and builds the necessary response. The view can be in memory and updating or being started and replayed on demand, which also plays nice with cluster sharding. What do you think? thanks in advance, michael On Friday, 7 March 2014 11:55:52 UTC+1, Martin Krasser wrote: > > > On 07.03.14 10:27, delasoul wrote: > > Hello Martin, > > On Friday, 7 March 2014 08:39:27 UTC+1, Martin Krasser wrote: >> >> >> If ordering is not important for your use case, just setup n views and >> send their received messages to an aggregator for example. >> > Please note that in this case, the ordering of messages received in a >> live stream may differ from that in a replayed stream. >> > > > >> Could you pls. explain what you mean with " the ordering of messages >> received in a live stream may differ from that in a replayed stream"? >> > > assume you have: > > processor1, view1 -> shared aggregator > processor2, view2 -> shared aggregator > > where view1 and view2 just forward received messages to the shared > aggregator > > live updates: > > - processor1 ! m1 // aggregator receives m1 > - wait a bit ... > - processor2 ! m2 // aggregator receives m2 > - shutdown app ... > > replay (after application restart) > > - view2 happens to recover before view1 // aggregator receives m2 before m1 > > Hence, live message order != replay message order. > > > > thanks in advance, > > michael > >> >> > > -- > Martin Krasser > > blog: http://krasserm.blogspot.com > code: http://github.com/krasserm > twitter: http://twitter.com/mrt1nz > > -- >>>>>>>>>> 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 [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/d/optout.
