You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If some specific Mats flows start to exhibit DLQs, but it is hard to find the reason why, it would often be nice if the MatsTrace had been KeepTrace.FULL.
While it is not possible to retrofit this information into a flow that has already started (and ended up on a DLQ), one could make a solution so that any new flows started that would also end up on DLQ had this information added.
The idea would be to make some kind of matching-solution, targetting a specific MatsFactory's specific MatsInitiator, only if specific initiatorIds were used (from), with a specific to-address, and possibly with a simple matching-solution on traceIds. If this stuff matched, the KeepTrace would be overridden to FULL.
This can both be done in Mats proper, and be implemented as an interceptor.
The text was updated successfully, but these errors were encountered:
If some specific Mats flows start to exhibit DLQs, but it is hard to find the reason why, it would often be nice if the MatsTrace had been KeepTrace.FULL.
While it is not possible to retrofit this information into a flow that has already started (and ended up on a DLQ), one could make a solution so that any new flows started that would also end up on DLQ had this information added.
The idea would be to make some kind of matching-solution, targetting a specific MatsFactory's specific MatsInitiator, only if specific initiatorIds were used (from), with a specific to-address, and possibly with a simple matching-solution on traceIds. If this stuff matched, the KeepTrace would be overridden to FULL.
This can both be done in Mats proper, and be implemented as an interceptor.
The text was updated successfully, but these errors were encountered: