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
<http://doc.akka.io/docs/akka/current/additional/faq.html>
>>>>>>>>>> Search the archives:
https://groups.google.com/group/akka-user
<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
<http://groups.google.com/group/akka-user>.
For more options, visit https://groups.google.com/groups/opt_out
<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.
