ACKs and NACKs coming back as msgType DATA

[Darren Tomlinson]

every once and a while i am receiving ACKs and NACKs coming back as msgType DATA.  The original message must have made it through ok because i do not have any messages in the error database from being timed out or nacked.

i am seeing this happen every once and a while where i have the DATA reply messages go into the error database because of an unsupported TrxID.  Since these messages are inbound to an outbound thread, there is nothing defined to handle them, because i dont expect to see them, so the no TrxID is easy to figure out why it is happening.

my question is, does anyone else experience this from different receiving applications?  i have 3 that do it every once and a while.  what is the reasoning why these apps are sending these?  what is the solution?

Topic

[Rick Brown]

Increase your timeout for those threads.

[Darren Tomlinson]

i am already set to 60 seconds.  do you really think it needs to be higher than that?

[Tom Rioux]

Do you have the “Outbound Only” box checked on the Inbound Data tab?  Also, do you have your recover procs set up correctly?

[Darren Tomlinson]

i do not have “Outbound Only” checked in the inbound tab.

also, i would assume i would have the reply checking, timeout, ob_msg stuff set up right, seeing as i have 2 or 3 errors and thousands upon thousands of ADTs that have gone though with no snags.

[Michael Hertel]

Like Thomas mentioned, you need to have outbound only checked on outbound threads to prevent the message being interpreted as data after the timeout kicks in.

The pdl has a built in timeout that is less than the thread configuration.

[Darren Tomlinson]

could you please elaborate on the pdl timeout?

i understand the checking of Outbound Only, but in this instance, if a message is timing out and not recieving an ACK in time, wouldnt the original message still be stuck in State 14 until it got an official ACK?

i dont want it to seem like i am argueing with your answers, i just want a better understanding on how cloverleaf works behind the scenes.

[John Hamilton]

I would bet it it a result of the recover procs and the fact the remote system did get the message but failed to respode back in time because it was busy doing a backup or just busy for other reasones.

So it has two message to work but you are expecting only one response.

Make sense?  The only way to fix this is determine if there is set time that these responses are coming in.  Then either put a hold at that time. Or if you can’t find one jus extend your time out reply.

[Jim Kosloskey]

Darren,

Here is my understanding:

The PDL timeout only has to do with when a message is received and it is not complete (this can happen if the TCP packets are broken up). PDL will wait a certain length of time for the rest of the message to appear.

Typically the PDL timeout is not involved in the situation you are experiencing.

When a message is sent out of the outbound thread Cloverleaf(R) will wait for the prescribed time for a response (if the ‘Wait replies’ switch is set and the timeout time is set).

IF the ‘Outbound only’ box is checked, Cloverleaf(R) throws an ‘await reply’ switch after the message is sent. That switch being thrown indicates to Cloverleaf(R) that the next mesage received on the thread is to be treated as a reply (the appropriate metadata field gets set to REPLY not DATA).

IF the ‘Outbound Only’ box is not checked, Cloverleaf(R) does not throw that switch and all messages received are treated as DATA. That can still work but now it is your responsibility to provide appropriate Tcl procedure(s) to interpret the actual message and determine yourself whether the message is a reply or data.

In most situations the outbound thread is intended to be ‘broadcast’ in nature. That is the messages go out and the only thing expected back inbound is an acknowledgment the message was received so message pacing can be controlled.

There are cases wherein asynchronous message deliver technique (Query/Response paradigm) is attempted over a single port that the situation is (typically) a Query message is sent; an acknowledgment is received; but at the same time and at any time a response to the current or previous Query is received. One of the inbound mesages is an acknowledgment and the other is a requested response to a query. The acknowledgment has to be treatred properly for message pacing, but the Response has to be recognized as well so that it can be routed and potentially translated to the original Querying system. In this case the ‘Outbound Only’ box should not be checked – and special Tcl coding needs to occur to handle the various types of inbound messages appropriately.

I should mention another method for achieving asynchronous message delivery. That is to have the outbound thread for the Queries (and their acknowledgments) set up in the normal outbound thread fashoin (Outbound only checked). A separate inbound thread for the asynchronous Responses to the Queries. This is set up as a normal inbound thread. For Asycnhronous message delivery (Query/Response), I personally favor this method.

I do not think you should necessarily lose any messages if you do not have the ‘Outbound only’ checked, but since I can’t say I have ever run for very long with that situation, I really have not paid attention to the recovery aspects.

If I accidently set up an outbound thread with the incorrect setting, I detect it early in the testing or configuration process, correct it and move on.

Suffice to say if you do not expect actual inbound data on your outbound thread, set the ‘Outbound only’ on.

If my interpretation of the process is off , I am sure someone will offer corrections.

Thanks,

Jim Kosloskey

email: jim.kosloskey@jim-kosloskey.com

[Michael Hertel]

😛 Ditto what Jim said.  😛

I know you’re not arguing.

[Author]

Replies