Cloverleaf seems to do unexpected resend of messages

On an Outbound thread, SMAT records every message sent whether as a result of a resend due to timeout or not.

I think this is the way you would want it to occur so that you have an accounting of how many resends took place. I know that is the way I want it.

I use this intelligence to assist me in setting the wait time to an appropriate value based in actual flow rather than what the vendor told me or just a SWAG.

As to whether or not the messages you see are due to resend as a result of timeout, there are a couple of ways I use to determine that.

I first use the SMAT files. That is reliable enough if you have some sort of unique control ID (MSH-10 for HL/7 number). That should always be the same for no matter how many resends there are. If you do not have a unique Control ID per message then doing some sort of comparson of the suspect messages or comparing the outbound order to the inbound order can work. Although matching up acknowledgments to messages becomes more difficult.

Another method is to turn up the engine noise level (I use enable all for this) and track what is happening. This can be an effort if the resends are not happening predictably as you will have to turn the noise level up and wait for the occurrence, then potentially wade through a lot of log.

You have to analyze the resend when apparently an ACK has been received very carefully.

Here is what can happen (I have experienced this)

1. message sent.

2. timeout waiting for acknowledgment hits

3. resend of message

4. acknowledgment of first message arrives sometimes followed immediately by the acknowledgment of the resent message. However, the second acknowledgment is treated by Cloverleaf as data and unless you have handling for that occurrence is tossed by Cloverleaf because the ‘awaiting replies’ switch is turned off (since a message – the first acknowledgment was received and thus considered to be the Reply).

So you end up with two messages and one acknowledgment. This can lead you to believe the acknowledgment arrived properly but was ignored.

Careful analysis of the SMAT files for the inbound and outbound messages for the outbound thread can determine with a fair amount of certainty what actually happened – and if the log detail is up then the exact occurrence of events can be determined and proven.

So to assist in this evaluation you need to have SMAT turned on for the acknowledgments.

I know a lot of folks don’t do that (including some here) but to my way of thinking, I would rather have that information for when the receiving system claims Cloverleaf screwed up.  Every time, that claim has been made, I have been able to prove the timing of acknowledgment to a Receiving System (assuming I have the SMAT file). They usually stop chanting their ‘its Cloverleaf’ mantra, go away, and magically the situation gets fixed.

They usually stop chanting their ‘its Cloverleaf’ mantra, go away, and magically the situation gets fixed.

😆 I love when that happens!

One of the things I’ve found helpful in determining original messages versus resends (esp. when there’s no unique message ID in the MSH), is that Sending Host in the SMAT tool will have the destination thread name for a resend instead of the originating thread name.