Using ‘cron’ to cycle the monitor daemon would probably help – we don’t use them, so haven’t seen this issue.
My post on this topic a few months back was related to communications between Cloverleaf and an Application socket listener. In our case, it happened after about 7 hours of sending maximum messages (for the receiving application) through and required a thread stop/start to get the communications back on track. We were never given enough time to prove the issue, but the networks guys indicated that the receiving application did not send the TCP ACK back that we were expecting.
