How to acknowledge/reject received messages from BTP Eventmesh correctly, using "xb-msg-amqp-v100"

[haykma]

Hi Community,

i have a cap application/service, which uses nodejs module "@sap/xb-msg-amqp-v100" as client to receive messages from a btp eventmesh queue/topic.

Receiving messages works fine so far.

When i then read the payload of the message i want to check its semantic. If the payload does not meet my conditions i want to reject the message.
For rejecting a message, the amqp client has a method "failed" for its Message-Class. But when i call it, the client gets the message directly back for processing from the client. Thats not my understanding of a failed message. I would expect the message to be marked as failed and not to be delivered again and again to subscriped clients or to just recline the message for maybe other applications also subscribing to the queue/topic and not delivering to my client again.

To workaround this actually, i create a hashcode of the payload for a message and store it in an associative array for some time. if "storagetime" is expired, i call the method "done" from the Message-Class. Then the message is really deleted from the queue in btp eventmesh. For every received message with same hashcode on payload i just call the "failed" method again.
But it seems that such a message, for which i called the "failed" method until , can not be read/processed by any other client. When i use btp eventmesh as application and try to consume the message from the test-menu i see that there is a message in queue but when i press "consume message" it says that they are no messages.

Maybe i have a misunderstanding in how to acknowledge/reject messages?
Does anyone bring light into darkness?

kind regards
Matthias

[mig1]

Here are some notes from when I experienced the same thing. The queue has 1 retry attempt configured before it is sent to DMQ (actually, I have a re-try queue with another schedule as well), default is 0 meaning unlimited attempts.

I’ve found quite a nasty mistake in the messaging handler. You have the same in your services. Here goes: when we do inboundMessage.failed() the message is PUT BACK FOR NEW DELIVERY. Meaning, it will be in an infinity loop until done or TTL happens.

The correct approach is to pass the error to it, .catch((err) => inboundMessage.failed(err))then it will go to DMQ as expected. You can read more about in the documentation at https://www.npmjs.com/package/@sap/xb-msg-amqp-v100See DeliveryRejected vs DeliveryReleased:

“In the case of a processing error, failed will either send outcome DeliveryRejected (if an error object is provided) or DeliveryReleased otherwise.”

As long as no exceptions happens, no problem. But once they do… Not a good situation.

[Tobias_Griebe]

Hi mhay,

As mikael.gurenius5 mentioned, you also need to check the "Max Redelivery Count" parameter on your queue configuration. By default this is set to 0 = unlimited. In this case you have no other option, but you must acknowledge the message at one point in time. Rejecting the messaged will just cause it to be redelivered.

[Tobias_Griebe]

Hi mhay,

can you please try the following and see if this solves your problem:

When calling the message.failed() method, can you please provide some error.

message.failed(new Error("test"));

If a remember correctly...

• message.failed() -> sends a "release" to the broker
• message.failed(new Error("error")) -> sends a "reject" to the broker

In the end we would also need to look into the configuration details of your queue (max retries, TTL, etc.) and which QoS you use to connect to your queue.

Best regards,
Tobias

[haykma]

Hi tobias.griebe and thanks for answering,

i also tried to use an instance of exception class as parameter in failed-methode and i can't really see a difference.
My handler method for "data" event of the streaming-client is always directly triggered again with the event/message that was rejected by message.failed(new Error("message rejected")) in its previous triggering.

For tests i use the btp eventmesh application and the test-menu to produce a message. In real the event is triggered from successfactors integration center. But in both i did not use knowingly any of your mentioned options. Im just a consumer.

kind regards
Matthias

[philip_transfeld]

I was running into the same issue.

message.failed(new Error('test'));

The code snippet above solved the issue. My corresponding queue was having a retry count set to a value > 0