I have had the same problem with threads staying in an ‘UP’ status, but never receiving a reply from the receiving system. Many times this results in a run away process that keeps spitting out ‘read returned error 78’.
What we have done here is to monitor within the recover_38 procs, the number of times we send to a specific connection without a response (assuming use of ACK/NAK). Once we reach a specified threshold, we touch a file with the following name:
siteName.processName.threadName.command
We use an external script that checks for these files and executes the appropriate command.
The threads either come back ‘UP’ and we start sending or they come up in an ‘OPENING’ state.
By coupling the timeout on the connection with a max number of resends, we can control how often a thread can get bounced.
Hope this helps.
Steve
Hello,
I have a problem similar to this, the process stays UP (dosent go to OPENING) but the transactions stop going out.
