On Tue, Mar 4, 2014 at 5:50 PM, delasoul <[email protected]> wrote:
> sorry for the confusion:) (maybe I should not copy from former posts > without the context..) > Although you answered the wrong question the answer(s) were helpful anyway. > pls. see more inline > > > On Tuesday, 4 March 2014 16:53:24 UTC+1, Patrik Nordwall wrote: > >> >> >> >> On Tue, Mar 4, 2014 at 10:22 AM, delasoul <[email protected]> wrote: >> >>> >>> Hello Patrik, >>> >>> the source eventprocessor should not be the problem(as you said) - it >>> sends the Update msg in its eventhandler. >>> As I understood Martin in his first answer he suggested to use a view or >>> target processor to distribute events if there is more than one interested >>> party and I wonder how this would be done without using channels. >>> Thanks for the tip checking for recovery - but this would not work with >>> Views (recoveryRunning is on Processor). >>> >> >> I think we are misunderstanding each other. You have the AuthorListing >> processor, and wanted to add the AuthorListingView. You prefer to not use a >> frequent auto-update-interval in AuthorListingView. Therefore you send >> something from AuthorListing to AuthorListingView when AuthorListing is >> changed. This thing should not be the change itself, it should be a signal >> that triggers the Update message to the AuthorListingView, and it will >> replay from the journal. >> >> All good so far? >> > > Yes, that is understood and as mentioned before the msg sent from > AuthorListing to AuthorListingView on a change is never received directly > by the > AuthorListingView, as you can see in its idExtractor: > case ListingChanged(author) => (author, > Update(await = true)) > ah, I missed that, good > >> Then I thought your next question was how to avoid sending to many >> (unnecessary) Update signals from AuthorListing to AuthorListingView when >> AuthorListing is recovering (restarted). To that I suggested the check for >> recovery or throttling in AuthorListing. >> > >> Have I answered the wrong question? >> > > The original question I had was about when I have to update multiple > views with the same event. I thought it's not the best solution to just > send x Update > messages to x Views and Martin answered with > > > "You can always use a view (option 3) or a destination/target > processor (options 1 and 2) that distribute their events to plain actors > without using channels. This way you save redundant journal updates or > queries." > > and here I wonder how this would work without using a channel as my > understanding is that the target view/processor would resent messages when > recovered. e.g.: > > > class AuthorListingView extends View with ActorLogging { > var posts = Vector.empty[PostSummary] > > override def receive: Receive = { > case Persistent(s: PostSummary, _) => > posts :+= s > *context.system.eventStream.publish(ReceivedPost(s))* > > } > } > ok, now I understand, sorry for missing some context on the way You could use a channel for de-duplicating messages sent from AuthorListingView to the final destinations. Note that channel de-duplication is only best effort -- if the ack is lost the message can be re-delivered. /Patrik > > You already answered how this can be done for a Processor(checking > recoveryRunning) and in the meantime I think i have also found > the answer why this not a problem when using a View, but to be sure: > A View has a lastProcessedSequenceNr field to do incremental > updates(e.g.: when receiving an Update msg) - the question is if this field > is also > maintained between restarts of the View - if yes there will be no > problem... > > sorry again for the confusion and thanks for your help, > > michael > > > > > >> >> Regards, >> Patrik >> >> >> >> >>> >>> michael >>> >>> >>> On Tuesday, 4 March 2014 09:52:04 UTC+1, Patrik Nordwall wrote: >>>> >>>> >>>> >>>> >>>> On Tue, Mar 4, 2014 at 9:40 AM, delasoul <[email protected]> wrote: >>>> >>>>> I have just read your answer below again and wonder how you would do >>>>>> this without using channels? >>>>>> >>>>> When replaying, the view/processor would resend the same events >>>>> again, or am I missing something? >>>>> >>>> >>>> You mean when recovering the source processor? Then it should not >>>> publish the Update messages. If it is event sourced that is by definition >>>> the case. For a command sourced processor you can check if it is recovering >>>> and skip the publish, or perhaps better add some scrubbing so that it >>>> doesn't publish more than X Update messages per Y seconds. >>>> >>>> The important thing is that the view is only updated by normal means, >>>> i.e. Update message and auto-update-interval. Everything else is just >>>> optimizations. >>>> >>>> /Patrik >>>> >>>> >>>>> Also, it is probably not a good solution when the same event has to >>>>>> be sent to more than one view (using auto update would of course fix this >>>>>> problem...). >>>>>> >>>>>> >>>>>> You can always use a view (option 3) or a destination/target >>>>>> processor (options 1 and 2) that distribute their events to plain actors >>>>>> without using channels. This way you save redundant journal updates or >>>>>> queries. >>>>>> >>>>> -- >>>>> >>>>>>>>>> Read the docs: http://akka.io/docs/ >>>>> >>>>>>>>>> Check the FAQ: http://akka.io/faq/ >>>>> >>>>>>>>>> Search the archives: https://groups.google.com/grou >>>>> p/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. >>>>> >>>> >>>> >>>> >>>> -- >>>> >>>> Patrik Nordwall >>>> Typesafe <http://typesafe.com/> - Reactive apps on the JVM >>>> Twitter: @patriknw >>>> >>>> -- >>> >>>>>>>>>> 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. >>> >> >> >> >> -- >> >> Patrik Nordwall >> Typesafe <http://typesafe.com/> - Reactive apps on the JVM >> Twitter: @patriknw >> >> -- > >>>>>>>>>> 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. > -- Patrik Nordwall Typesafe <http://typesafe.com/> - Reactive apps on the JVM Twitter: @patriknw -- >>>>>>>>>> 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.
