pending message confirmation max and min

[Bobby Richards]

I would like to get a better understanding of persistent channels:

the confirmation max and min are a great feature but I need some clarification...

when pending max is hit messages are no longer sent but I assume the retires are still in effect and this is hopefully how confirmations will fall back below the min.

My question is that if in the case of a bad configuration setting or longer down time than expected on the receiving in, if all retries are exhausted what will happen then?  Am I sol?

On that note, is there a call similar to persistencefailure that I will get if all retries are exhausted? If all retries are deleted, is the message deleted/lost?  In a qa environment the receive side was held down longer than the retries so we lost messages.


Finally, I am not sure if this is related but we noticed that bringing some nodes down (with persistent channel) and then back up will not automatically resend unconfirmed persisted messages until a "fresh" message comes through, and then they are all sent.  Is there an equivalent to replay on channels?

Thanks,
Bobby

[Patrik Nordwall]

Hi Bobby,

On Fri, Feb 21, 2014 at 6:13 PM, Bobby Richards <bobby.r...@gmail.com> wrote:

I would like to get a better understanding of persistent channels:

the confirmation max and min are a great feature but I need some clarification...

when pending max is hit messages are no longer sent but I assume the retires are still in effect and this is hopefully how confirmations will fall back below the min.

yes

 

My question is that if in the case of a bad configuration setting or longer down time than expected on the receiving in, if all retries are exhausted what will happen then?  Am I sol?

You can can send the Reset message to the channel to force it to it to redeliver all unconfirmed messages. They would also be retried after a restart.

 

On that note, is there a call similar to persistencefailure that I will get if all retries are exhausted? If all retries are deleted, is the message deleted/lost?  In a qa environment the receive side was held down longer than the retries so we lost messages.

You can use redeliverFailureListener in the PersistentChannelSettings. It will be notified with RedeliverFailure when the number of redeliveries reaches `redeliverMax`. From there you can send Reset, or confirm these messages, preventing further redeliveries.

 

Finally, I am not sure if this is related but we noticed that bringing some nodes down (with persistent channel) and then back up will not automatically resend unconfirmed persisted messages until a "fresh" message comes through, and then they are all sent.  Is there an equivalent to replay on channels?

Reset is probably what you are looking for.

Cheers,

Patrik

 

Thanks,
Bobby

--
>>>>>>>>>> Read the docs: http://akka.io/docs/
>>>>>>>>>> Check the FAQ: http://akka.io/faq/
>>>>>>>>>> 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 akka-user+...@googlegroups.com.
To post to this group, send email to akka...@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/groups/opt_out.

--

Patrik Nordwall
Typesafe -  Reactive apps on the JVM
Twitter: @patriknw

[Bobby Richards]

perfect, thank you so much

[Patrik Nordwall]

21 feb 2014 kl. 20:19 skrev Bobby Richards <bobby.r...@gmail.com>:

perfect, thank you so much

You're welcome