Establish replication connections more efficiently in an edge case #237
Comments
nars1
added a commit
to nars1/YottaDB
that referenced
this issue
May 8, 2018
…ssed out in YottaDB#136) soon after connection gets reset Issue YottaDB#136 moved all state related information in gtmrecv_poll_actions.c into a structure variable "curr_conn_state". But there was another global variable "gtmrecv_send_cmp2uncmp" which was set in gtmrecv_process.c and was the same as "curr_conn_state.send_cmp2uncmp" which meant whenever "curr_conn_state.send_cmp2uncmp" got cleared (due to the memset changed introduced in YottaDB#136), "gtmrecv_send_cmp2uncmp" should have also been cleared. Not doing so, meant it was still possible for a stale old connection related state variable to be carried over to a new connection resulting in an assert failure in the source server in rare cases (just like YottaDB#136) in dbg or a connection loss and reconnect sequence in pro (this did happen in one in-house test failure). This is now fixed so both variables are kept in sync. It was originally thought of avoiding the duplication and replacing all usages of "gtmrecv_send_cmp2uncmp" with "curr_conn_state.send_cmp2uncmp" but it was not trivial due to the need to move the "conn_state_t" type definition from gtmsource_poll_actions.c into a header file so gtmrecv_process.c can also inherit that definition. And since this is an edge case, and there was a risk of other subtle regressions, the trivial change was adopted even though it is not as desirable.
nars1
added a commit
that referenced
this issue
May 8, 2018
…t in #136) soon after connection gets reset Issue #136 moved all state related information in gtmrecv_poll_actions.c into a structure variable "curr_conn_state". But there was another global variable "gtmrecv_send_cmp2uncmp" which was set in gtmrecv_process.c and was the same as "curr_conn_state.send_cmp2uncmp" which meant whenever "curr_conn_state.send_cmp2uncmp" got cleared (due to the memset changed introduced in #136), "gtmrecv_send_cmp2uncmp" should have also been cleared. Not doing so, meant it was still possible for a stale old connection related state variable to be carried over to a new connection resulting in an assert failure in the source server in rare cases (just like #136) in dbg or a connection loss and reconnect sequence in pro (this did happen in one in-house test failure). This is now fixed so both variables are kept in sync. It was originally thought of avoiding the duplication and replacing all usages of "gtmrecv_send_cmp2uncmp" with "curr_conn_state.send_cmp2uncmp" but it was not trivial due to the need to move the "conn_state_t" type definition from gtmsource_poll_actions.c into a header file so gtmrecv_process.c can also inherit that definition. And since this is an edge case, and there was a risk of other subtle regressions, the trivial change was adopted even though it is not as desirable.
ksbhaskar
changed the title
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Final Release Note
Initiating replication connections between Source and Receiver Servers is more efficient. Previously, in rare cases, the Source Server unnecessarily disconnected the connection and reconnected. This is very similar to (#136) but under slightly different circumstances. (#237)
Description
This issue is very similar to #136. See that issue's description for more details. A rare edge case was left out in that fix which showed up in an in-house test failure. This issue is created to fix that edge case.
Draft Release Note
The replication receiver server sends the correct handshake messages on a new connection with the source server. In prior versions of YottaDB, it was possible in rare cases for the source server to unnecessarily disconnect the connection.
The text was updated successfully, but these errors were encountered: