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] <javascript:>.
> To post to this group, send email to [email protected]<javascript:>
> .
> 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
>
> 

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

Reply via email to