Hi Ray,
On Mon, Mar 17, 2014 at 9:04 AM, Raymond Roestenburg < [email protected]> wrote: > Thanks Martin, but I'm not sure if all my assumptions are correct, and if > using a child channel is OK in all types of reincarnations. > > A couple of questions / assumptions: > > - I was expecting that a persistent channel would not redeliver confirmed > messages (within re-delivery time), and that a reincarnated processor using > a channel cannot cause re-delivery of confirmed messages because of replay. > Say I have a processor that responds to a client with a child persistent > channel, if the client asks and receives the ConfirmablePersistent and > confirms the message, (taking into account that I'm waiting for the > Delivered event to occur etc, understanding confirm is async etc), and I > kill the processor after this confirmation (and implicitly kill channel), > start a new incarnation (processor with same name), that new processor > using a new child persistent channel with the same id, the new persistent > channel should not send old messages to any client that have already been > confirmed, correct? > > What a long sentence, luckily here is a gist that you can look at, I'm > probably making a rookie mistake :-) I am receiving a message I'm not > expecting on line 75. Can you explain this? > > https://gist.github.com/RayRoestenburg/9595397 > > Yes, that is rather unexpected. I think the reason is that you use the same channel for delivery of the non-persistent GetNumber reply and the persistent DecrementAndGet reply. Thereby the sequence numbers becomes wrong somehow. GetNumber is not replayed. It works if you create two different persistent channels and use one for GetNumber and one for DecrementAndGet. That can perhaps be improved. Please open a ticket. > > - I am expecting that any message I send to a reincarnated processor will > be received after the replay of that processor. I don't have to deal with > the fact that replay is asynchronous from a client perspective. So far I've > seen that this works as expected in my tests, asking just to be sure. > That is correct. They are stashed until the recovery is completed. > > > - I first expected that a child _transient_ channel would just work across > reincarnations, not sending confirmed messages, and later on I thought, how > can it, since it is killed with the parent processor I'm killing. So the > new transient child channel (in the new parent) has no way to know to > ignore confirmed messages once it is created 'again' (better said a new > channel with the same id), since all of this is in memory. Correct? > No, it will de-duplicate in new incarnation also. The Persistent message in the Deliver message keeps track of the confirmations. > > - I _am_ expecting this to work with a persistent child channel, since it > will use its id to read again from storage and continue where it left off. > But the above gist shows otherwise? > Channel and PersistentChannel should behave the same in this example, but it looks like Channel doesn't have the above quirk. > > - The confirm() is async, and does not acknowledge back to the confirmer. > In theory the channel can redeliver the message if the confirmation takes > too long, there is no way for the channel to check if a confirmation should > have been received already, and even in a sort of timeout event, it would > still have to send it again. So in general, even with confirmations, the > receiver of messages sent from a channel must guard for duplicates (if that > is a requirement for the application of course). Now in my test the > redelivery interval is so long it should never happen, but just checking in > general this assumption is correct. > Yes, that is correct and documented. The confirmation can be lost (or be delayed) and then a retry is performed and duplicates will arrive, which must be handled by the destination. /Patrik > > > On Mon, Mar 17, 2014 at 7:11 AM, Martin Krasser > <[email protected]>wrote: > >> >> On 16.03.14 13:14, Raymond Roestenburg wrote: >> >> Ok you can also ignore this one, >> >> (this is a fantastic rubber ducking session by the way! ;-P) >> >> When I create the channel outside of the processor and reuse that, >> everything works as expected: >> >> https://gist.github.com/RayRoestenburg/9582319 >> >> Of course every new child channel cannot know which messages were >> delivered earlier. Duh. >> >> >> You should be able to use a child channel. Just make sure that the >> channel has the same id across incarnations. It is recommended to pass a >> channel id via Channel.props (more details at channel >> identifiers<http://doc.akka.io/docs/akka/2.3.0/scala/persistence.html#id9> >> ). >> >> >> >> On Sunday, March 16, 2014 12:42:27 PM UTC+1, Raymond Roestenburg wrote: >>> >>> Ok, I've got another question.. I've expanded the gist: >>> >>> https://gist.github.com/RayRoestenburg/9581923 >>> >>> I've added a channel to respond to clients to the NumberProcessor >>> example, (NumberProcessorWithChannel) and I see something unexpected again, >>> which might be me learning how this really works, or a bug? >>> >>> When a processor with the same name is started, I see replayed >>> messages going to the probe which I have previously confirmed. >>> Is that correct behavior? I would have expected that confirmed messages >>> are not sent back to clients. >>> >>> On Sunday, March 16, 2014 12:01:59 PM UTC+1, Raymond Roestenburg wrote: >>>> >>>> Please disregard, I misunderstood and found out why. >>>> >>>> The replayed message causes the response back to the probe. >>>> >>>> On Sunday, March 16, 2014 10:17:08 AM UTC+1, Raymond Roestenburg wrote: >>>>> >>>>> Hi guys, >>>>> >>>>> I'm writing up some examples for persistence and stumbled on a >>>>> strange issue. >>>>> Can you please have a look at this? The gist contains a unit test you >>>>> can drop straight into akka-persistence to verify it. >>>>> >>>>> https://gist.github.com/RayRoestenburg/9580479 >>>>> >>>>> I used to use ImplicitSender in the test, and found out that using >>>>> two probes actually made the test pass, something I think should not be >>>>> necessary. >>>>> >>>>> (There is always the chance that I totally misunderstand or made an >>>>> incorrect assumption, but I think this is a bug) >>>>> >>>>> Cheers, >>>>> Ray >>>>> >>>> -- >> >>>>>>>>>> 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. >> >> >> -- >> Martin Krasser >> >> blog: http://krasserm.blogspot.com >> code: http://github.com/krasserm >> twitter: http://twitter.com/mrt1nz >> >> -- >> >>>>>>>>>> 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. >> > > > > -- > Raymond Roestenburg > > code: http://github.com/RayRoestenburg > blog: http://roestenburg.agilesquad.com > twtr: @RayRoestenburg > book: http://manning.com/roestenburg > > -- > >>>>>>>>>> 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.
