Establish replication connections more efficiently in an edge case
Final Release Note
Initiating replication connections between Source and Receiver Servers is more efficient. Previously, in rare cases, the Source Server unnecessarily disconnect the connection and reconnected. [#136 (closed)]
Description
If the source server is started with a non-zero compression level (-cmplvl qualifier), and the receiver server is started with a zero compression level, the receiver server, as part of its initial handshake, sends a REPL_CMP2UNCMP message to the source server to let it know to send uncompressed records in the replication pipe. It is possible in rare cases, that before this message is sent, the source server closes the connection for other reasons (e.g. heartbeat from the receiver was not received for a while etc.). In that case, the receiver server could incorrectly send the REPL_CMP2UNCMP message as part the initial handshake with the source server on a new connection (which happens soon after the source server closes the old connection) and if this happens, the source server could get confused by this unexpected message at the start of a connection and close the connection once more with a message of the form "UNKNOWN msg (type = ...) received when waiting for msg (type = ...). Closing connection." in the source server log file.
The fix for this is that the receiver server does not send the REPL_CMP2UNCMP message (which was needed for the old connection) the moment a new connection is established with the source server.
Draft Release Note
The replication receiver server sends the correct handshake messages on a new connection with the source server. In YottaDB r1.10 and before, it was possible in rare cases for the source server to unnecessarily disconnect the connection.