Hi Prakhyat,

I can't comment on ahjohannessen proposal, but in general it is difficult
to create a view that aggregates the event streams of many persistent actor
instances, and it is also difficult to create a persistent view for each
persistent actor when you don't know the identifiers up front.

You can store the identifers in another persistent actor, and let that
actor be responsible for creating the views. This is not trivial, and one
of the reasons why we want to improve the persistent views. The core team
is swamped with other work so it will take a few more months until we can
start working on the improved persistent views.

Cluster sharding for the views will only work if you send messages to these
views, because cluster sharding entry actors are only activated when
messages are sent to them.

Regards,
Patrik

On Wed, Oct 15, 2014 at 2:37 PM, Prakhyat Mallikarjun <[email protected]
> wrote:

> Team,
>
> I am eagerly looking for the answer to this query. Any updates would be
> appreciated and helpful.
>
> -Prakhyat M M
>
>
> On Sunday, 12 October 2014 20:59:10 UTC+5:30, Prakhyat Mallikarjun wrote:
>>
>> Hi Ahjohannessen,
>>
>> I understand your point. And I thoroughly agree your inputs.
>>
>> But the point I want is make is as below....
>> Correct me if I am wrong, the view will always be in lag compared to the
>> persistent actor. It will always pull the events persisted by persistent
>> actor. The last seen sequence number in persistent actor might be different
>> from last pulled sequence number in persistent view.
>>
>> Just to take an example consider PersistentActor persist events in order
>> 1,2,3,4,5,6. The view pulls persisted event from journal in order
>> 1,2,3,4,5,6 at lag duration of 2-5 secs.
>>
>> Consider persistent actor persisted 1,2,3,4,5,6. View pull's event
>> 1,2,3,4. But while handling event 4, exception is thrown. The fault
>> tolerance case which we are discussing here is view should be
>> recreated/started from sequence 4 followed by 5,6.
>>
>> Correct me if my understanding is wrong.
>>
>> -Prakhyat M M
>>
>> On Sunday, 12 October 2014 19:35:58 UTC+5:30, ahjohannessen wrote:
>>>
>>> Prakhyat, it is really simple. Just wrap the message in case class
>>> ViewRead(msg: Any, sequenceNr: Long, persistenceId: String) and maintain a
>>> pointer of last seen sequenceNr per persistent actor, i.e. persistenceId.
>>> Then you can start "CatchUp" from that.
>>
>>  --
> >>>>>>>>>> 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.
>



-- 

Patrik Nordwall
Typesafe <http://typesafe.com/> -  Reactive apps on the JVM
Twitter: @patriknw

-- 
>>>>>>>>>>      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.

Reply via email to