On 10.03.14 10:35, delasoul wrote:
ok, but ordering must not be important anyway otherwise there will be
the same problems as when using a view for different source processors.
sure, the ordering issue happens in both cases. Just illustrated it
based on the aggregator example.
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..)
use the same supervisor for all views and the aggregator and an
all-for-one strategy.
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?
if update ordering doesn't really matter in your case, think about
letting the source processors update a database (or another processor)
directly via channels.
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.
Sounds good.
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
--
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.
