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