Message redelivery for New Java API - if an exception or un-acknowledgement happened

Sreekanth

I am exploring new Java API for solace integration. I have noticed that message redelivery is not happening if an exception happened in consumer thread. In JCMP api we were able close/ unbind and bind consumer. Spring cloud stream binder also doing same way. But new Java API I those apis's were not exposed. Please let me know How to achieve this functionality.

amackenzie

Hello,

That technique of unbinding and rebinding is not present in the Java API like it was in JCSMP. The way you handle that situation is different, however, I have some good news for your use case.

Coming very shortly in Java 1.4.0 is the ability to negatively acknowledge (NACK) messages with 2 different outcomes:

• FAILED - meaning the processing of the message encountered a problem in the consumer app and so the message should be redelivered from the broker (according to the redelivery settings on the queue). I think this is what you are looking for.
• REJECTED - a "poison" message outcome. The application has determined that the message is bad and redelivering it would not result in it being successful, so the broker should NOT redeliver and should send the message to a DMQ (if configured on the queue) or dropped (if no DMQ configured)

I think a NACK will be the best way to handle your exception on the message. Unbind/rebind was really a workaround for not having a NACK for individual messages.

amackenzie

Hello,

That technique of unbinding and rebinding is not present in the Java API like it was in JCSMP. The way you handle that situation is different, however, I have some good news for your use case.

Coming very shortly in Java 1.4.0 is the ability to negatively acknowledge (NACK) messages with 2 different outcomes:

• FAILED - meaning the processing of the message encountered a problem in the consumer app and so the message should be redelivered from the broker (according to the redelivery settings on the queue). I think this is what you are looking for.
• REJECTED - a "poison" message outcome. The application has determined that the message is bad and redelivering it would not result in it being successful, so the broker should NOT redeliver and should send the message to a DMQ (if configured on the queue) or dropped (if no DMQ configured)

I think a NACK will be the best way to handle your exception on the message. Unbind/rebind was really a workaround for not having a NACK for individual messages.

Sreekanth

@amackenzie Thanks for the answer!

When can we expect the new 1.4.0 release? And what would you suggest do We need to proceed with JCMP or spring cloud binder implementation or Its worth to wait for new release with Java API ?