cl_check_ack Error

[mike brown]

I am getting the following error sporadically when we receive a disconnect  from the downstream system to my outbound interface. (cerner)

[cmd :cmd :WARN/0:

Topic

[mike brown]

The TCP/IP Server does not always send an ACK if a new message arrives to the Server at the time the Server is writing out a reply for the last message.

In the engine, the reply message is written out by the main thread using a blocking socket, while the incoming message is read by a TCP subthread using a non-blocking socket.

If a client connects to the Server, the accepted socket is used by both the subthead and main thread for message reading/writing. In this case, the main thread writes out the reply message with blocking mode, but before it changes the socket to non-blocking, the subthread receives a new message. This causes the subthead to read with BLOCKING mode, causing the subthread to be blocked.

Possible process log file error messages were:

[pd :pdtd:WARN/0: client:04/11/2013 17:59:25] Timed out while awaiting replies on thread. Resending reserved OB Message

[tps :tps :ERR /0: client:04/11/2013 17:59:26] ‘KILL ‘ (returned by ‘cl_check_ack ‘) does not match { }

[Jim Kosloskey]

Do you have ‘outbound only’ and ‘Await Replies’ configured on the outbound thread?

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

[mike brown]

Yes, i have outbound only checked and await replies is set to -1 as are all my other outbound threads…

[Jim Kosloskey]

OK – strange that the receiving system would see another message before sending an acknowledgment (since with your configuration Cloverleaf will not send out a message until a reply is received) – or maybe I don’t understand the sequence of events.

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

[Jim Kosloskey]

I reread your post and noticed this:

[pd :pdtd:WARN/0: client:04/11/2013 17:59:25] Timed out while awaiting replies on thread. Resending reserved OB Message

That indicates you are not awaiting replies forever (-1) but rather there is some timeout period set.

If that is the case and the receiving system takes too long to reply, then your code for handling timeouts will occur and that may be sending another message before a reply is received (most likely the same message).

If you have a timeout other than ‘wait forever (-1)’ perhaps that needs to be increased?

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

[mike brown]

you mean change it from wait (-1) forever to say wait for 30 seconds?

but that would error the message right? just checking..

[David Barr]

It depends on how you set the timeout handling.

[Jim Kosloskey]

Mike,

If it truly is at -1 then you should not be getting the warning is what I am thinking.

Since you are receiving this warning it appears you are timing out which belies a setting of -1 for timeout.

Are you sure that WARN is for the thread in question?

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

[mike brown]

yes, i did verify, but it does not happen all the time, could it be network causing this?

thanks for your replies…

[mike brown]

Here is the full error, we (cloverleaf received a shutdown from cerner and this occurred…

md :cmd :INFO/0:     pmha_cmd:05/24/2017 00:26:02] Receiving a command

[cmd :cmd :INFO/0:     pmha_cmd:05/24/2017 00:26:02] Receiving a command

[cmd :cmd :INFO/0:     pmha_cmd:05/24/2017 00:26:02] Received command: ‘cerner_oa_oa prestart 30’

[cmd :cmd :INFO/0:     pmha_cmd:05/24/2017 00:26:02] Doing ‘prestart’ command on ‘cerner_oa_oa’

[prod:prod:INFO/0: cerner_oa_oa:05/24/2017 00:26:02] Checking for leaked handles in the General interpreter…

[prod:prod:INFO/0: cerner_oa_oa:05/24/2017 00:26:02] Checking for leaked handles in the TPS interpreter…

[cmd :cmd :INFO/0:     pmha_cmd:05/24/2017 00:26:02] Receiving a command

[cmd :cmd :INFO/0:     pmha_cmd:05/24/2017 00:26:02] Command client went away.  Closing connection.

[cmd :cmd :WARN/0:     pmha_cmd:05/24/2017 00:26:03] Thread is not running ‘cerner_oa_oa’

[cmd :cmd :INFO/0:     pmha_cmd:05/24/2017 00:26:03] prestart: restarting thread cerner_oa_oa

[prod:prod:INFO/0: cerner_oa_oa:05/24/2017 00:26:03] Starting protocol thread cerner_oa_oa as tid 5.

[prod:prod:INFO/0: cerner_oa_oa:05/24/2017 00:26:03] Applying EO config: ”

[cmd :cmd :INFO/0:     pmha_cmd:05/24/2017 00:26:05] Receiving a command

[cmd :cmd :INFO/0:     pmha_cmd:05/24/2017 00:26:05] Receiving a command

[cmd :cmd :INFO/0:     pmha_cmd:05/24/2017 00:26:05] Received command: ‘pmha_xlate xrel_post’

[cmd :cmd :INFO/0:   pmha_xlate:05/24/2017 00:26:05] Doing ‘xrel_post’ command with args ”

[cmd :cmd :INFO/0:     pmha_cmd:05/24/2017 00:26:05] Receiving a command

[cmd :cmd :INFO/0:     pmha_cmd:05/24/2017 00:26:05] Command client went away.  Closing connection.

[tps :tps :ERR /0: cerner_oa_oa:05/24/2017 00:26:09] ‘KILL ‘ (returned by ‘cl_check_ack ‘) does not match { }

[cmd :cmd :INFO/0:     pmha_cmd:05/24/2017 00:26:09] Receiving a command

[cmd :cmd :INFO/0:     pmha_cmd:05/24/2017 00:26:09] Receiving a command

[Michael Hertel]

This error is kind of ancient.

Usually I find that it is returning “KILL $my_mh” and if $my_mh is not valued (null), it returns “KILL  “. Which is what it is returning.

Part of the proc states:

#               Needs the following procs to run correctly:

#                       cl_sendOK_save (OB DATA TPS)

#                       cl_resend_ob_msg (REPLY GEN TPS)

#

Do you have these configured for this thread?

[mike brown]

no i do not,, i have cl_check_ack and SENDOK – is blank and reply OBSEND button is checked

[Michael Hertel]

So I think you may have found your answer.

Let us know if this still happens after you reconfigure.

[mike brown]

Here is the way all my outbounds are setup for years… see attachment

[Michael Hertel]

Sorry Mike, Someone else can take it from here.

I don’t use cl_check_ack.

And have only had bad luck trying to use the auto resend feature.

[mike brown]

thanks for trying and all your replies, i did check everything you mentioned…

[Author]

Replies