One option would be to use a persistent actor as your read side as well,
store the last offset you have seen and stream from after that offset when
the actor has recovered completely, this way you can also provide snapshots
(and possible delete the actor to replay the entire history into a view
after adding functionality for example).
Another could be to persist the read side in some other way, a relational
database for example and do queries against that.
--
Johan
Akka Team
On Wed, Nov 9, 2016 at 5:34 PM, Juan Carlos Roig <jcr...@gmail.com> wrote:
> Hi everyone. Just waking up this thread (once again) with a related
> challenge/question
>
>
> I'm used to use PersistentView for my read model before they got
> deprecated.
>
> I have a CQRS architecture where both write and read sides are cluster
> singleton. In write side I use persistent actors to validate and store the
> events and then those events get replayed to the persistent views on the
> other sharded cluster. Those persistent views process the events and keep
> the read model in memory, so queries are sent to them and they respond
> accordingly. This is very easy to do as akka persistence takes care of
> actors initialisation both at persistent actors and views so that in case
> any actor gets restarted or rebalanced by the cluster it will be started
> and initialized recovering its previous state by using snapshots and events
> replay before processing any new incoming message.
>
> I'm trying to do the same using persistent query but I'm having some
> problems.
>
> I'm creating the persistent query inside the actor view and send the
> events to itself.
>
> Example:
>
> class DefaultAccountView extends Actor with ActorLogging {
> implicit val mat = ActorMaterializer()(context.system)
> implicit val ec = context.dispatcher
>
> val aggregateId = context.self.path.name
>
> def persistenceId: String = s"AccountAggregate$aggregateId"
>
> // Configure Persistence Query
> val queries = PersistenceQuery(context.system).readJournalFor[
> LeveldbReadJournal](LeveldbReadJournal.Identifier)
>
> val events = queries.eventsByPersistenceId(persistenceId, 0L,
> Long.MaxValue)
> .map(eventEnvelope => eventEnvelope.event)
> .to(Sink.actorRef(self, StreamCompleted))
> .run()
>
>
> def handleAccountQueries: Recevice = {
> case Query1 =>
> // Process query 1
> case Query 2 =>
> // Process query 2
> }
>
>
> def handleEvents: Receive = {
> case Event1 =>
> // process event 1 update state
>
> case Event2 =>
> // process event 2 update state
>
> }
>
>
> override def receive: Receive = handleAccountQueries orElse handleEvents
> }
>
> In that case the stream will be created every time the actor gets started
> and will replay all events. The problem is that being an actor belonging to
> a sharded cluster it will be started the first time it gets a message, that
> is, a query. What happens is the first message always gets processed before
> all events are replayed and hence it fails to give correct response as the
> state is not initialised, in other words, there's no initialisation
> lyfecycle like PersistentView has. I tried to use a custom object to signal
> the end of the stream (StreamCompleted) but obviously it is never sent as
> the stream never finishes (it keeps opened sending events generated in real
> time, which is what we need to keep the view updated). On a side note, it
> will be very nice to be able to easily use snapshots here too as replay all
> events every time the view starts might take a lot of time for high load
> actors.
>
> Is there any way to do this overcoming these problems?
>
> Shall I continue using PersistentView instead although they're deprecated?
>
> How are you guys propose to implement this use case if persistent views
> are deprecated?
>
> Regards,
>
> J. Carlos
>
> --
> >>>>>>>>>> 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 https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>
--
>>>>>>>>>> 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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
