We are having the following scenario:
This scenario causes that the message is lost.
Is there any possible solution to mitigate this within the gateway?
I configured a failure queue in the case that the message was not transferred to the backend. But this does not work for the above scenario. Because there is no response code from the backend.
I know there is a possibility to add a MQ Client in a transaction with the QMgr. This means that the client must send a commit back to the QMgr. as soon as the message is successfully transferred. If this commit is not retrieved by the QMgr. the message is rolled back to the queue by the QMgr. But this behavior must be configured by the MQ Client respectively by the Gateway.
Good afternoon. There are 2 ways to configure how a message is pulled from a Queue either On Take or On Completion. It sounds like you have 'On Take' set in the Policy Manager which will not wait to see how the policy is executed and does not account for any type of failure. I would recommend that you look at the On Completion model where the gateway will not remove the message from the queue until it is successfully transferred to the back end.
I used the option "On Completion" while I get the message from the Queue. My intention was to use the "Failure Queue" in case that the message cannot by delivered. This procedure is working as soon the backend response an error.
But in my case the backend has not returned an answer.
It seems that with the standard settings, the message is got from the queue and stored in the memory of the gateway while the gateway waits of an answer of the backend.
The "Failure Queue" Scenario is working in the case when the backend returns a negative Response code. But what is in the meanwhile, when the Gateway tries to send the message to the backend and a crash is happen on the gateway.
Then the message located in the memory is lost.
Are you using JMS for WebSphere over LDAP or Native MQ, and what version of the Gateway is in place? This will help walk through the implementation you are using. The gateway should place the message in the failure queue as long as the policy fails including MQ communication failure.
Excerpt from the documentation: (https://docops.ca.com/ca-api-gateway/9-3/en/security-configuration-in-policy-manager/tasks-menu-security-options/manage-mq-native-queues/mq-native-queue-properties):
Select this check box to route the message to a special queue if the service policy does not successfully complete.
The messages sent to the failure queue are not due to a Gateway failure, but rather from other causes such as routing failure, message content, etc.
If this check box is not selected, then the MQ Native configuration should ensure that messages that could not be processed do not remain in the queue indefinitely.