On Tue, Mar 10, 2015 at 11:36 AM, Tal Pressman <kir...@gmail.com> wrote:
> Hi,
>
> Thanks for your response. Let me (try to) clarify my questions.
>
> I guess I oversimplified my example so it, so I'll try again. I have an
> actor (persistent with at-least-once-delivery), and I want it to process
> messages "immediately" upon arrival. That is, I don't want to wait for the
> persistence handlers to fire before updating my state, delivering messages
> downstream, etc.. I would also like to be able to recover from crashes to a
> consistent state.
>
> So now let's look at an example actor (assuming recovery behaves exactly
> the same, but without the persistence calls):
>
> class MyActor extends PersistentActor with AtLeastOnceDelivery {
> var counter = 0
> override def receiveCommand: Receive = {
> case Increment =>
> counter += 1
> deliver(somewhere, id => Count(counter, id))
> persistAsync(Increment) { _ =>
> sender ! Persisted
> }
> case a@Ack(id) =>
> counter -= 1
> confirmDelivery(id)
> persistAsync(a) { _ =>
> // nothing to do here
> }
> case Snapshot =>
> saveSnapshot(Snapshot(counter, getDeliverySnapshot))
> }
> }
>
>
> Here, I would expect the counter to be the same as the number of
> unconfirmed messages as long as there are no crashes.
>
> Could I miss messages here? Would crashes always restore my actor to a
> consistent state as well?
>
The only potential problem I can see is if you have a crash immediately
after the first deliver or if the persistAsync fails. Then you have sent a
message that you have not any records of. After restart the same deliveryId
might get used again, but for a completely different message. That could be
a problem if you use the deliveryId in the destination for deduplication.
Also, the Ack of the first message might be in flight, and when it is
received it might be used to confirmDelivery of another message that was
sent in between.
That might be completely alright in your application and a reasonable
tradeoff for reducing the latency. You can mitigate the risk by using uuid
in the messages keeping track of mapping between uuid and deliveryId. In
that way you can discard Ack with unknown uuid.
The deliveryId is a counter that is incremented for each call to `deliver`.
It is assumed that it reach the same value after recovery, i.e. that the
same number of delivery calls were made. That is one of the reasons why its
important to use getDeliverySnapshot/setDeliverySnapshot when using
snapshots with AtLeastOnceDelivery.
/Patrik
>
> I didn't observe any problems, it was just something I thought about
> during the design phase, and since it relates to thread timings and crashes
> it would be kind of hard to create the problematic scenarios ahead-of-time.
>
> Thanks,
> Tal
>
>
> On Monday, March 9, 2015 at 3:55:39 PM UTC+2, Patrik Nordwall wrote:
>>
>> 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.
>>
>
>
>> 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?
>>
> --
> >>>>>>>>>> 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.
