On Sun, Mar 8, 2015 at 9:22 AM, Tal Pressman <kir...@gmail.com> wrote:
> Hi Björn,
>
> Thanks for your reply.
>
> Let me see if I understand correctly. If I have an actor with a counter,
> then this code would be problematic:
>
> class MyActor extends PersistentActor {
> var counter = 0
> override def receiveCommand: Receive = {
> case Increment =>
> counter += 1 // <<< shouldn't change state here
> val m = Count(counter)
> someActorRef ! m
> persistAsync(m) { _ =>
> sender ! Ack(counter)
> }
> }
> }
>
>
> But what if I don't want to wait for the actual persistence event to fire
> to process the message? Or worse, what if I *have* to change the state from
> *receive* and not the *persistAsync* handler?
>
I don't see what this has to do with snapshots, and what the problem could
be. This is not the kind of mutability that Björn warned about. He was
thinking about mutability of the instance passed to saveSnapshot.
>
> As a more concrete example, I am wondering what would happen if I use the
> AtLeastOnceDelivery trait. If I want to persist the deliveryId (or some
> other data derived from it) I have to call *deliver* directly from
> *receive*. However, that changes the trait's internal state without
> waiting for the *persistAsync* handler. On top of that, I have to somehow
> synchronize "my" state with the trait's when performing a snapshot.
>
You can do that, but then you risk that the message may not be delivered
(re-delivered) if things crash before the event has been saved.
Snapshots and persistent events are not re-ordered, so it is supposed to
just work, and that should not change because of persistAsync. Have you
seen any problems?
Regards,
Patrik
>
> So how would that all work together?
>
> Thanks,
> Tal
>
> On Wednesday, March 4, 2015 at 4:18:53 PM UTC+2, Björn Antonsson wrote:
>>
>> Hi Tal,
>>
>> If you only update the state to be snapshotted in the handlers that you
>> give to persistAsync, and send an immutable copy of the state to the
>> snapshot method, then you should be fine. The async nature of persistAsync
>> is that you continue processing messages while the persisting of the event
>> happens, but you are still guaranteed that only one handler at a time will
>> be executed in the actor, and that no other message processing is happening
>> in the actor while the handler is being run.
>>
>> Immutability of the state to snapshot is the key here, since the
>> "timestamp" and the state will be picked up at consistent point, and sent
>> of to the snapshot store, and then normal processing of messages will
>> continue inside the actor. If the state is mutated while in flight to the
>> snapshot store, then all bets are off.
>>
>> B/
>>
>> On 3 March 2015 at 16:38:39, Tal Pressman (kir...@gmail.com) wrote:
>>
>> Hi,
>>
>> Sorry in advance if this has already been answered somewhere, I couldn't
>> find it...
>>
>> I have a PersistentActor, and I use persistAsync to persist its events.
>> Now I want to add snapshots into the mix. So from what I understand from
>> the documentation, having a snapshot with a timestamp T means I wouldn't
>> get any events that were persisted prior to T. But when are these
>> timestamps generated? Is it possible that I will miss events? Is it
>> possible that an event that was already taken into account in the snapshot
>> be processed again?
>>
>> Thanks,
>> Tal
>> --
>> >>>>>>>>>> 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+...@googlegroups.com.
>> To post to this group, send email to akka...@googlegroups.com.
>> Visit this group at http://groups.google.com/group/akka-user.
>> For more options, visit https://groups.google.com/d/optout.
>>
>> --
>> Björn Antonsson
>> Typesafe Inc. <http://typesafe.com> – Reactive Apps on the JVM
>> twitter: bantonsson <http://twitter.com/bantonsson>
>>
>> JOIN US. REGISTER TODAY!
>> <http://event.scaladays.org/scaladays-sanfran-2015>
>> Scala <http://event.scaladays.org/scaladays-sanfran-2015>
>> Days <http://event.scaladays.org/scaladays-sanfran-2015>
>> March 16th-18th, <http://event.scaladays.org/scaladays-sanfran-2015>
>> San Francisco <http://event.scaladays.org/scaladays-sanfran-2015>
>>
> --
> >>>>>>>>>> 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
[image: Scala Days] <http://event.scaladays.org/scaladays-sanfran-2015>
--
>>>>>>>>>> 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.
