Communication points that use TCP connections will only detect that the connection has been closed by the remote end when attempting to send or receive a message on the connection. Once Rhapsody attempts to send or receive a message on the connection, the end-of-file will be encountered, and the socket will be closed. If the communication point is a client then it will apply its connection retry strategy.

When communication points are in Output or Out->In mode they will wait for messages to be delivered before sending them. This means that there can be long periods of inactivity during which the state of the connection is assumed to be connected but it may have actually been closed by the remote end.

This can cause problems for client communication points because the remote end will not be available when it needs to send the message. After exhausting all the connection retry attempts the communication point will stop in error and a notification will be raised. Only at this point will users that have subscribed to this notification be aware that the remote end is unavailable. This can waste valuable time that could have been spent notifying the administrators of the remote end that their system is unavailable which could have been resolved by the time Rhapsody actually needed to send a message.

Connection Monitoring enables a client/server communication point to determine whether a remote host has dropped the connection without waiting for a message to be sent or received. After a 30-second period of inactivity on a socket (in other words, no reads or writes to the socket), the communication point attempts to read from the socket (with a minimal timeout to avoid blocking) to determine whether the remote end has closed the connection.

Connection Monitoring functionality applies to TCP Server, TCP Client, JavaScript TCP Server and JavaScript TCP Client communication points only, and only when they are in Output or Out->In mode.

To enable this functionality, add the following line to the rhapsody.properties file:

CommunicationPointExecutionService.monitorConnections=true

This will enable Connection Monitoring on all applicable communication points in the engine. It cannot be configured per communication point.

For these cases, it is preferable to modify the configuration of the communication point rather than disabling Connection Monitoring. One or more of the following settings should be modified to get the desired behavior. There may be rare cases where enabling Connection Monitoring is conceived of as undesirable because the remote end is known to be unreliable. Previously this may have been acceptable if by the time a message was ready to be sent, the remote end was available again. In this case, the communication point would have applied the connection retry strategy and successfully reconnected without having to stop in error. With Connection Monitoring enabled, the retry strategy would be applied much sooner which could potentially cause the communication point to stop in error when it would not have previously.

Property Setting Example
Connection Retries This should be set with enough of a delay and times as to allow the communication point to reconnect. If the communication point was sending one message every 45 minutes and the previous connection retry strategy would try for at least 15 minutes then the communication point could previously recover from a situation where the remote end was down for 1 hour without stopping in error. The connection retry strategy should be modified to keep retrying for 1 hour.
Scheduling If there are certain times of the day where the communication point is not sending a message and the remote end is expected to be down then the communication point should be scheduled to automatically stop during this time. Between 00:00 and 01:00 the remote end is expected to go down for maintenance then the communication point should be configured to start at 01:00 and stop at 00:00.
Idle Timeout Setting the idle timeout to less than 30 seconds will effectively bypass the Connection Monitoring by closing the connection proactively.

Setting the idle timeout to 20 seconds will cause the connection to close after 20 seconds of inactivity. Since the connection is closed before the 30 seconds of inactivity, Connection Monitoring will not occur. Since the connection is closed as being idle it will not apply the connection retry strategy until a message is available for sending.
Connection Mode Setting this to Disconnect if not sending/receiving will cause the connection to be closed immediately after the message has been sent (or the response received if in Out->In mode). The connection will now be closed after the message has been sent (or the response received if in Out->In mode) and so Connection Monitoring will not occur. The connection will be re-established for every message that is to be sent.