On Tue, Apr 22, 2014 at 11:32 AM, Olger Warnier <ol...@spectare.nl> wrote:
> > On Monday, April 21, 2014 9:07:03 AM UTC+2, Patrik Nordwall wrote: > >> On Sun, Apr 20, 2014 at 6:05 PM, Olger Warnier <ol...@spectare.nl> wrote: >>> >>> On Sunday, April 20, 2014 4:59:22 PM UTC+2, Patrik Nordwall wrote: >>> >>>> On Sun, Apr 20, 2014 at 2:47 PM, Olger Warnier <ol...@spectare.nl>wrote: >>>> >>>>> Hi Patrick, >>>>> >>>>> Sounds like an interesting approach, storing some meta-data at the >>>>> view may help to check / show the reliability of the system. >>>>> >>>>> At this moment the events are sent to a processor per node that >>>>> publishes the event (distributed pub sub) >>>>> >>>> >>>> That sounds good, as well. >>>> >>>> >>>>> When you talk about view, that's the akka-persistence view ? >>>>> >>>> >>>> Yes, persistence.View and persistence.Processor >>>> >>>> >>>>> So more or less, the sub processors could send messages to the View >>>>> and when there is a Persist() around it, it will be stored. >>>>> >>>> >>>> I'm not sure I understand what you mean here. Let me clarify my >>>> proposal with an example. Let's say we have a User aggregate root with some >>>> profile information that can be updated. The user is represented by a User >>>> EventsourcedProcessor actor, which is sharded. On the query side we want to >>>> be able to search users by first and last name, i.e. we want to store all >>>> users in a relational database table on the query side. >>>> >>> Yup, great sample. >>> >>>> >>>> The User actor persist FirstNameChanged, and inside the persist block >>>> it sends a Persistent(FirstNameChanged) message to the AllUsers Processor. >>>> On the query side we have a AllUsersView connected to that processor. When >>>> AllUsersView receives FirstNameChanged it updates the db table. >>>> >>> Indeed. In what way is the AllUsersView connected to that Processor ? >>> (in a distributed pub sub situation) >>> >> >> In a persistent >> View<http://doc.akka.io/docs/akka/2.3.2/scala/persistence.html#Views> you >> define the processorId that it will read the persistent messages from. It >> reads (replays) from the journal periodically, or when you send it a Update >> message. You can have many views connected to the same processor. The >> processor doesn't have to know anything about the views. In a distributed >> setup you will use a distributed/replicated >> journal<http://akka.io/community/> and >> thereby the view can be located on another machine than the processor. >> >> >>> (although, I have to understand in what way 'inside the persist block' >>> is to be interpreted. >>> >> >> Ah, I thought you were familiar with EventsourcedProcessor. Read up on it >> in the docs: >> http://doc.akka.io/docs/akka/2.3.2/scala/persistence.html#Event_sourcing >> http://doc.akka.io/docs/akka/2.3.2/scala/persistence.html#Event_sourcing >> >> > Clear, that's being followed, Understand your sentence now. > >> >>> >>>> >>>> To handle lost messages between User and AllUsers you might want to >>>> send an acknowledgement from AllUsers to User, and have a retry mechanism >>>> in User. I would implement that myself in User, but PersistentChannel might >>>> be an alternative. >>>> >>> Is it possible todo persistent channels with the distributed pub sub >>> stuff that's available in akka ? >>> >> >> Yes, PersistentChannel requires a confirmation from the destination, so >> if you wrap/forward the ConfirmablePersistent and send it via pub-sub it >> should be fine. It will not work if you publish to multiple subscribers. >> > > I need it with the publish. Is it possible to combine the > DistributedPubSubMediator and the ReliableProxy in some kind of way to get > guaranteed delivery (more or less) over pub sub ? > No, with multiple consumers you have to use something else. That is why persistent Views are an attractive way of publishing the events. > (I've read the akka-dev thread on reliable messaging and the use of a MQ > kind of thing for that, but I prefer to keep it clustered without a > specific additional component in between) > Yes, using an external message broker that has support for this is an alternative. Cheers, Patrik > > >>>> That is the most straight forward solution. The drawback is that >>>> FirstNameChanged is stored twice. Therefore I suggested the meta-data >>>> alternative. User sends Persistent(UserChangedNotification(processorId))) >>>> to the AllUsers Processor. When AllUsersView receives >>>> UserChangedNotification it creates a child actor, a View for the >>>> processorId in the UserChangedNotification, if it doesn't already have such >>>> a child. That view would replay all events of the User and can update the >>>> database table. It must keep track of how far it has replayed/stored in db, >>>> i.e. seqNr must be stored in the db. The child View can be stopped when it >>>> becomes inactive. >>>> >>> Will that work with a sharded cluster ? (and a 'View' may be running on >>> another node) >>> >> >> yes >> >> >>> >>> >>>> >>>> That alternative is more complicated, and I'm not sure it is worth it. >>>> >>> From a solution perspective, using the distributed pub sub, maybe with >>> persistent channels is what will do. >>> >>> Most of my questions have todo with using akka-persistence as a full >>> fledged DDD framework, not too hard without the sharding (although a view >>> for every aggregate root instance seems not to fit when you want to use >>> that for database connectivity that contains a view model). with the >>> sharding it is more complicated and a good structure to actually build a >>> view that is on 'some' node listening for events, doing' it's thing is a >>> handy part. >>> >> >> Thanks for your thoughts. I'm sure patterns and tools around this will >> evolve from the experience of using akka persistence in real applications. >> >> >>>>>> Cheers, > > Olger > > -- > >>>>>>>>>> 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. > -- Patrik Nordwall Typesafe <http://typesafe.com/> - Reactive apps on the JVM Twitter: @patriknw JOIN US. REGISTER TODAY! <http://www.scaladays.org/> Scala <http://www.scaladays.org/> Days <http://www.scaladays.org/> June 16th-18th, <http://www.scaladays.org/> Berlin <http://www.scaladays.org/> -- >>>>>>>>>> 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.
