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 ?