Max retries on pdl-tcpip protocol (client mode/outbound) ?

[Sundeep Kumar]

I have outbound threads all with pdl-tcpip protocol with mlp_tcp.pdl connecting as clients to different server systems in the hospital. Some time these servers just enter into a hang state and queues build up on the outbound threads on cloverleaf.

My question is : Is there a max retry attempts that the protocol thread makes to re-connect to these server before finally giving up ? This would explain whay sometimes when the other side server comes back up our outbound thread will just not try and connect.

Topic

[Jim Kosloskey]

Sundeep,

If you have Auto-Retry turned on in the thread configuration, then Cloverleaf(R) attempts to reconnect forever.

If, after a receiving system has a problem and restarts and you do not reconnect (but a ‘controlled’ restart does reconnect) then it is most likely the receiving system never released the port.

I am going to guess that all or most of these receiving systems are Windows. Is that true? For some reason most coders on Windows do not know how to release ports when calamity strikes.

It has been a long time since I coded at the Windows socket level but it was terrible. I always used third party socket management software and let them deal with Microsoft. I recall that it was a real pain to try and make persistant connections at the Windows socket layer. That is a skill I am not sure many Windows folks have mastered.

Any way, short of insisting the vendors of the receiving systems ‘pull their heads out’ and provide persistant connections, it may be the only resolution is to make sure a ‘controlled’ startup is done when those systems are ready to reconnect.

Jim Kosloskey

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

[Sundeep Kumar]

Jim Kosloskey wrote:

Sundeep,

If you have Auto-Retry turned on in the thread configuration, then Cloverleaf(R) attempts to reconnect forever.

If, after a receiving system has a problem and restarts and you do not reconnect (but a ‘controlled’ restart does reconnect) then it is most likely the receiving system never released the port.

I am going to guess that all or most of these receiving systems are Windows. Is that true? For some reason most coders on Windows do not know how to release ports when calamity strikes.

It has been a long time since I coded at the Windows socket level but it was terrible. I always used third party socket management software and let them deal with Microsoft. I recall that it was a real pain to try and make persistant connections at the Windows socket layer. That is a skill I am not sure many Windows folks have mastered.

Any way, short of insisting the vendors of the receiving systems ‘pull their heads out’ and provide persistant connections, it may be the only resolution is to make sure a ‘controlled’ startup is done when those systems are ready to reconnect.

Jim Kosloskey

Jim,

Thanks for your reply. Your explanation seems to make sense.  Yes most of the servers that cloverleaf forwards data too are windows servers. I am curious about the “controlled restart”. Is that same as manual restart ie a cloverleaf analyst going and manually stopping the outbound thread and restarting it ? Or is this an automated process that can be configured on the cloverleaf side ? One thought comes to mind is to have ops just run a basic script:

hcicmd -p -c “ pstop

hcidmd -p -c “ pstart”

Would this work as a controlled restart ?

[Jim Kosloskey]

Sundeep,

That could – it really depends on the receiving system and how badly mangled a state their TCP environment is in.

Sometimes the only working resolution is to stop both the Cloverleaf(R) thread and the receiving system connection. Then bring up the server connection (the receiving system) and assure it is really listening. Then start the client (the Cloverleaf(R) thread). That is what I know as a ‘controlled’ restart.

Even then I have experienced Windows applications that things so screwed up the system needs to be rebooted before even the above will work.

Each system may need a different resolution and possibly the same solution for the same system will not work in all instances.

I am only an hour away from you – maybe someday we will have lunch and you can give me the nickel tour of your facility. I am always interested in how everyone’s environment is working.

Jim Kosloskey

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

[Author]

Replies