Hi Peter,
On Tue, Sep 16, 2014 at 10:56 PM, Peter <[email protected]>
wrote:
> Hi All
>
> I've been using akka-persistence (along with the DynamoDB journal plugin)
> and have a few concerns:
>
> It looks like a PersistentActor's events are replayed when it's created
> and/or after the last snapshot was loaded successfully.
> Only *after* that is done, the highest sequence number is read
> (onReplaySuccess) This seems backwards and wasteful, although I guess if
> the sequence number is only globally unique it's useless in determining the
> number of events to load. Looking at ProcessorImpl (which appears to still
> being used with PersistentActor??) one gets the impression the sequence
> number is locally scoped:
>
> private def nextSequenceNr(): Long = {
> sequenceNr += 1L
> sequenceNr
> }
>
> Am I missing something? It looks like ReplayMessages is performed with
> toSequenceNr = Long.maxValue rather than actual highest sequence number for
> the processor Id?
>
The sequence number is not global. It is one sequence number per
persistenceId.
> As ReplayMessages operation is performed on Processor startup, this also
> goes for a brand new Actor, if the overhead of this operation is high the
> penalty is paid every time, even for new Processors with no events. If this
> is postponed until after the max sequence number has been found (non
> existing in this case) this penalty could be avoided?
>
It is possible to replay events up to a specified sequence number, see
toSequenceNr in the Recover message. That means that the highest sequence
number is not necessarily the same as the last replayed event. It might be
possible to optimize this for the case when recovery replays to
Long.MaxValue. Please create an issue <https://github.com/akka/akka/issues>
for that if that is what you are looking for.
>
> My application needs to support 1,000,000s of Persistent Actors, with
> 10,000s of them running at any time (possibly a few 100,000). My concern is
> especially things like system restarts when I need to (re)create these
> PersistentActors at a rate of 1000/s or more sustained for 1 - 2 minutes.
> Is this realistic for akka-persistence? (supporting infrastructure
> qualifiers not withstanding).
>
That depends on a lot of things but it doesn't sound completely
unrealistic. You have to test it. You will probably use ClusterSharding
<http://doc.akka.io/docs/akka/2.3.6/contrib/cluster-sharding.html>,
which loads persistent actors on demand and that might be important for the
load profile when starting up the system.
Regards,
Patrik
>
> Thanks
>
> Peter
>
> --
> >>>>>>>>>> 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.
