Hello,
I am seeing messages go to the transactional dead-letter queue when attempting to retry a failed message through ServiceInsight. Any suggestions on where to look to determine why this is occurring?
ServiceInsight v1.9.1
Thanks!
Jimmy
Hello,
I am seeing messages go to the transactional dead-letter queue when attempting to retry a failed message through ServiceInsight. Any suggestions on where to look to determine why this is occurring?
ServiceInsight v1.9.1
Thanks!
Jimmy
Hi Jimmy
Is the destination machine reachable? The queue still existent? Do you override the time to live on the messages? Could you paste an example message including the headers?
Regards
Daniel
Hi Daniel,
Is there a way for me to send you the msg\headers outside of posting to the topic/discussion?
Also, we are using AWS/SQS for queues and a Service Control adapter. In the retry scenario, does the message go back through the adapter or directly to SQS?
EDIT (additional requested info i missed providing): The endpoint/queue still exist and were available. We were not overriding the time to live.
Thanks,
Jimmy
Hi Jimmy
You can send the messages/headers to support at particular dot net If they are large you can upload them to a secure location and then add the link to the support email
Failed messages sent by the endpoints to the error queue are subject to a retry forever policy. This means that the adapter will retry forwarding such message to ServiceControl until it succeeds.
Sounds like the messages are deadlettered because they are retried too many times.
Have you set the poison message queue so that you can inspect the messages and see what exception is causing them to be moved into the poison message queue?
Regards
Daniel
Daniel,
Thanks for your help, it looks like we had configured the msmq side of the transport adapter to be non-transactional. Removing that allowed the retry feature to work as expected.
Jimmy