Lost Message

[Chuck Busch]

I am using PWIM 5.8 and very new to it.   I am in the process of building threads and testing them and I had something strange happen.  This morning my outbount thread had 5 messages queued up and I restarted it.  They all seeming went to the receiving system.  The receiving system is another interface engine (GE ConnectR).  I received all but 1 message and I cannot figure out why.  The reason that the outbount thread was queued is do to the fact that it is sending from PWIM to ConnectR through a firewall that keeps timing out.  I have my outbound thread set to await replies and my receiving thread set to send ACKS.  I have attached the message from SMAT, notice that the delivery state reads “successful”.  Any guidance would be greatly appreciated.

Topic

[James Cobane]

Chuck,

If the message is in SMAT, the engine was able to successfully transmit the message (but not necessarily have it process in the receiving system).  Did the receiving system acknowledge it?  I suspect that the receiving system did not process it even though it was sent.  Depending on the data contained in the acknowledgements received from ConnectR, you should be able to tie the acknowledgement received to the message that was sent.  If the message was acknowledged, then you can look to the vendor to figure out why they didn’t process.

Hope this helps.

Jim Cobane

Henry Ford Health

[Chuck Busch]

ConnectR did not respond to this message.  I was not able to find an acknowlegdement.  Which is I would have thought that CloverLeaf should have resent the message.  I have attached the settings I have for the Outbound thread.

[Jim Kosloskey]

Chuck,

You are waiting forever for a reply.

So if the receiving system never sends one you don’t get a chance to resend.

The check-ack proc only gets involved once you receive an ack as you have things configured.

email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.

[Keith McLeod]

How are you configured under Timeout Handling?  I beleive you either need to use the recover procs or set up your timeout handling to resend OB message.  If these aren’t configured, then you can milk the queue by bouncing the thread and losing each message basically.  You can test this using the tcp testing tool and not responding to the messages you send to it.

[Chuck Busch]

In my timeout handling I have the Reply Generation toggle button selected.  I assume I need to have the “Resend OB message” selected.  If there is anything else I need to select or any procs please let me know.  Thanks.

[Jim Kosloskey]

Chuck,

Well you need to set your Timeout to something other than -1. The value -1 means wait forever which means you will never time out thus never resend the message.

To determine what should go in there, try collaborating with the receiving system to get a feel for the maximum amount of time it might take for an acknowledgment to be sent. After all you don’t want to do too many resends only as an exception.

Note that value may need to be adjusted with testing.

Also note that if there is a firewall or VPN involved you could get into a situation where the receiving system will appear to never respond and thus you could do a lot of resends before you detect that.

email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.

[Author]

Replies