Inbound Thread in Opening Status

[Tim Purvis]

For about a month now we are having an issue where one of our inbound threads goes into opening status and does not process any messages. When I contact the vendor they state that they have received acks back from all the messages that have been sent while our side said opening. The issue is resolved when I shut my side down have the vender their side and then I start my side again and then they start their side. It stays up for a couple of days but then the issue occurs again. Any ideas?

Topic

[Jim Kosloskey]

Tim,

FCirst I would check the Inbound SMAT in and (hopefully you have this turned on) the SMAT out for the Inbound thread.

I would validate that indeed during the period of time the thread is in an ‘opening’ state you really did receive messages and generated acks. I suspect that is not true.

That does not solve your issue but does indicate the sending system is or is not to be relied upon to report accurately the real message flow or there is someone else responding.

Ask the vendor to provide the acknowledgment messages they received (hopefully you are following the standard with the acknowledgments and are using MSH-3 through MSH-6 properly and are echoing their MSH-10 in the MSA as well as providing your own MSH-10 on the acknowledgment. That may be a clue that you have another thread somewhere listening on the same port.

Look into the process log when this occurs and see if there are any warnings or errors that indicate the remote side shut down.

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

[Tim Purvis]

Jim,

Yes we do have the Inbound SMAT file setup on the thread. I do not receive any messages into that file. I wll have them send me one of the acks that they are getting so i can verify that it is the ack that we are sending. Also, in the log file it is full of errors indicating the remote side probably shut down.

[Jim Kosloskey]

Tom,

Now I would really doubt they are receiving acknowledgments from anyone.

The remote side shutting down is an indication they are stopping for some reason but not releasing the port (there are a number of reasons that can occur see other forum discussions regarding this).

Is there a firewall in the way?

If no firewall is the sending system windows based (seems like a lot of windows applications do not know how to do TCP/IP properly)?

It would be ideal if you had access to the sending system and they had even half of the troubleshooting facilities Cloverleaf has so you can verify what is happening.

At this point I would definitively say it is unlikely Cloverleaf is the issue.

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

[Russ Ross]

Is the port number in the ephermal range?

On our AIX Cloverleaf server any port >= 32K (32,768) is in the ephemeral range and should be avoided being used for a cloverleaf interface listener because control of those ports can and do get grabbed away.

a usefull command I’ve used to help with trouble shooting suspect port conflicts is

lsof -i tcp

which will list all the port numbers and the pids using those ports.

With this information I can investigate the pid to see what is consuming that port in the event I have a port conflict this can pin point the culprit.

You might have to set a cloverleaf alert to catch as close as possible to the time when the interface goes to opening becuase if there is a port conflict it sounds like it doesn’t last all that long.

If your port number is below the epermal range then I would expect a port conflict to be more consistant than the random behavior you describe which would be expected for port numbers in the ephermal range.

Russ Ross
RussRoss318@gmail.com

[Author]

Replies