Dropping xlate output msg not in RESEND_DEST_OVERRIDE list

Hi Noel,

We see this behaviour on occasion as well and I couldn’t put my finger on it either. So did a few tests and I think I figured it out.

We have a few jump/hop threads:

So thread A will route to B_out, which is a tcp/ip connection sending the messages on to B_in. B_in will route to C and D.

Normally we will keep a smat of all threads, but in this case it’s weird to keep smats for B_out AND B_in, as the messages are the same. So we only keep a smat for B_out.

Now, if you take messages from smat B_out and resend them from B_in (inbound post), then you will get this message in the log:

So the engine notices that the messages are originally destined for another thread and you haven’t specified ‘destination threads’ while resending, so it will not process these messages. Problem here is that ‘outbound’ messages are suddenly used as ‘inbound’ messages and in the metadata it says to which thread the message needs to be routed.

If you have a smat on B_in and you resend messages from that smat, then all will work.

So to solve this you either specify destination threads when resending or uncheck the box ‘Include Metadata’ when resending or you will need to define the smat on B_in instead of B_out.

I appreciate it too! We have the same situation and to save space we are saving only one copy of the message. So if we resend from that copy, but send using different inbound and outbound threads, we will have the same problem. So now we know to specify both inbound and outbound threads, even if there is only one outbound thread.

That was the theory…

A few days ago I needed to resend some 200 messages again and remembered that I should specify the destination thread. I did, and still got the errors. It was late, I was irritated that I made a mistake causing messages to fail/not get send on, so tried some things which all didn’t work (including not sending the original metadata, I think).

In the end I resend from the outbound (B_out) thread. Grrr… Should try to replicate this, when I have some spare time left; I now think you need to do both: specify destination threads AND uncheck ‘Include Metadata’.

Robert, spare time?  What’s that?

That tis the post-mortem time (your post-mortem) 😆

I know, right? Once upon a time…

I recently ran into this same issue where we’re using the feature “Messages routed to this connection treated and inbound.” Which means I no longer have to use a TCL script to OVER the message to chain threads.

The problem appeared when we resent a few ADT messages from the ADT root thread to the NICU group. Once the messages hit the middle man thread and get “re” routed, the RESEND_DEST list caused all the messages to get killed inside the engine. I call these middle man threads “recirculators.”

Until Infor can address the issue, I wrote a TCL script to handle the issue of clearing the RESEND_DEST list when appropriate for the Recirc threads so the support team doesn’t have to second guess “from where” the resend messages at 2 AM.

Script is attached.

Thank you so much for your code, and the work behind it. I had a similar issue where I have to OVER a message from the outbound queue to the inbound queue, and it would not route to its new destination because that was not the same value in the original RESEND_DEST_OVERRIDE list.

Cloverleaf 6.1.2 on AIX.

I am experiencing this issue but, using the example that Jim presented:

I am sending from the B_in smat file, setting the destination thread and unchecking the “include Metadata” checkbox.  Still getting the RESEND_DEST_OVERRIDE response.

Hi Jon,

  If I read your post correctly, you should not get that error at all. As your SMAT source is B_in and the selected destination should be either C or D (or both). In this case, it’s just a normal resend (with or without metadata).

If this is the case then you’ll need to enable_all engine output on the B_in thread and try the resend again and then inspect log for the errors. If you did get that error, then I suspect there’s more to your situation than just

A -> B_out  ==>  B_in -> C, D.