HI Martin, The message is confirmed, at least I know that the confirm method is called. From my logs I can see that after I call confirm, the JournalProtocol$DeleteMessages message is sent. Also, if confirm would not work I would expect the second run to fail, as the messages would also be replayed there.
I will try to recreate the problem with a failing test. Cheers, Michael Am Donnerstag, 6. März 2014 10:24:31 UTC+1 schrieb Martin Krasser: > > Michael, > > You see redeliver messages because a channel re-delivers non-confirmed > messages after 5 seconds by default. See message > re-delivery<http://doc.akka.io/docs/akka/2.3.0/scala/persistence.html#message-re-delivery>and > API > docs<http://doc.akka.io/api/akka/2.3.0/#akka.persistence.PersistentChannelSettings>for > details. Looks like your application doesn't actually call confirm(). > Can it be that your ask-future is never completed? Try with a future of > which you're sure that it is completed for testing purposes. > > If this doesn't help, please create a ticket with a failing test. > > Thanks, > Martin > > On 06.03.14 09:27, Michael Pisula wrote: > > Hi Martin, > > thanks for the rapid response. > I forgot to mention, I suspected the same thing and added up to 10 seconds > of Thread.sleep to my test before stopping, no change. What's more, I see > the DeletionMessage and its confirmation in my log before the termination > message: > > 09:16:51.649 [default-akka.actor.default-dispatcher-9] DEBUG > a.s.Serialization(akka://default) - Using > serializer[akka.serialization.JavaSerializer] for message > [akka.persistence.JournalProtocol$DeleteMessages] > 09:16:51.654 [default-akka.actor.default-dispatcher-9] DEBUG > a.s.Serialization(akka://default) - Using > serializer[akka.serialization.JavaSerializer] for message > [akka.persistence.JournalProtocol$DeleteMessagesSuccess] > 09:16:53.405 [default-akka.actor.default-dispatcher-3] DEBUG > a.s.Serialization(akka://default) - Using > serializer[akka.serialization.JavaSerializer] for message > [akka.persistence.ReliableDelivery$Redeliver$] > 09:16:53.412 [default-akka.actor.default-dispatcher-3] DEBUG > a.s.Serialization(akka://default) - Using > serializer[akka.serialization.JavaSerializer] for message > [akka.persistence.ReliableDelivery$Redeliver] > 09:16:53.662 [default-akka.actor.default-dispatcher-3] DEBUG > a.s.Serialization(akka://default) - Using > serializer[akka.serialization.JavaSerializer] for message > [akka.dispatch.sysmsg.Terminate] > > The two redeliver messages afterwards irritate me a bit. But this log is > from the first run, and the second run will have no issues and the logs > looks the same. For the third run the problems start. > I checked my other tests, and these Redeliver Messages do not occur there, > still it is strange that the effect only (and consistently) occurs in the > third run. The first and second run will always succeed. > > Very puzzling. > > Cheers, > Michael > > > Am Donnerstag, 6. März 2014 09:04:41 UTC+1 schrieb Martin Krasser: >> >> Hi Michael, >> >> confirm() is an asynchronous operation. If your test ends before the >> confirmation is written to the journal or the confirmation is written >> concurrently to a follow-up test, you may see redeliveries. Refer to the >> akka-persistence tests for details how to wait for confirmation being >> written (i.e. listen on the system event stream for deletion commands when >> using persistent channels). It doesn't seem to be related with using ask. >> >> Hope that helps. >> >> Cheers, >> Martin >> >> On 06.03.14 08:46, Michael Pisula wrote: >> >> Hi, >> >> I am having an issue with the PersistentChannel. I use the channel for >> persistent re-sending of messages to a camel endpoint. >> I basically send the message through the channel to an actor, have this >> actor use ask to send the request to a camel producer actor, and handle the >> response using map on the future I get back from ask. I confirm the message >> once I receive the response. >> In my unit tests this works fine for the first run without a journal >> directory. The second run is also fine, I set the akka loglevel to debug, >> both log outputs are pretty much equal. The third run, however, will fail >> as messages from the second run are now redelivered. >> I use PersistentChannels in other parts as well, and have no issues >> there, so I suspect this might have to do with the ask pattern somehow. >> >> In pseudish code, this is a simple version of what I do: >> >> ConfirmablePersistent msg = ... >> Future future = Patterns.ask(producer, msg.payload(), timeout); >> future.map(... apply(response) { >> msg.confirm(); >> return response; >> }, getContext().dispatcher()); >> >> Mostly I tested this with 2.3.0-RC4, but I also gave it a run with the >> newly released 2.3.0. >> >> I will try to write a simple test in the akka codebase to reproduce >> this, but perhaps someone already has some helpful ideas in the meantime? >> >> Cheers, >> Michael >> >> -- >> >>>>>>>>>> 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/groups/opt_out. >> >> >> -- >> Martin Krasser >> >> blog: http://krasserm.blogspot.com >> code: http://github.com/krasserm >> twitter: http://twitter.com/mrt1nz >> >> > -- > 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/groups/opt_out.
