[SOL-66000] Error Queue functionality Enhancement - Exception Stack Trace, exception message

[Gautamatul]

I was working on the DLQ functionality came across a problem where when i siphoned the message from DLQ i was not able to figure out why the exception was thrown, i had to check the logs for all the messages which was very time taking.

I am migrating 2 apps from rabbit to solace where rabbit provide the functionality to get the exception message and stack trace from the headers of DLQ message, also the original queue name from where the exception was thrown.

"exception-stacktrace":"stackTrace"

"exception-message": "Destination [QueueName] not found in JNDI; nested exception is javax.naming.NameNotFoundException: JNDI lookup of "QueueName" failed - not found".

Rabbit sets these headers before publishing the message to DLQ this helps us identifying the issue why the exception was thrown should we reprocess them directly buy dropping to same queue or need to make any change before reprocessing them.

This is a great enhancements because if there are so many messages in DLQ we can siphon, save them in DB then we can select them and reprocess based on exception message or stack trace.

if the exception was thrown because one service was down or any technical reason we can directly reprocess or if the exception is business we can look into it and fix the problem.

I would request you set the custom headers exception message, stack trace & original queue name before publishing the message to DLQ.

https://solace.community/discussion/comment/4214#Comment_4214

Thanks,
Atul Gautam

[Gautamatul]

Hi Dev Team,

Please let me know if its been prioritised ? Or any alternative approach because this is an important functionality.

[Gautamatul]

The problem explained above is for solace spring cloud stream binder.

Problem - Once I siphon/consume the message from the Error Queue/ DeadLetterQueue I can not identify the root of cause why the exception was thrown at the first place. I need to look the logs, message and figure out the problem by simulation which is time taking process.

Solution - Before republishing the message to error queue, the header exceptionStackTrace, exceptionMessgae must be added to header as property. This will help understand the issue and whether to reprocess the message or need to modify the message and re drop to the queue.