forked from YottaDB/YDB
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
[YottaDB#136] Reset connection-related state soon after connection ge…
…ts reset; Not doing so could affect new connection when it gets established This is an issue observed from a test failure (in the merge/tp_stress subtest) during internal testing. The primary failure symptom was an assert failure in the source server %GTM-F-ASSERT, Assert failed in sr_unix/gtmsource_process_ops.c line 1167 for expression (FALSE) The source server assert failed because it was expecting a REPL_INSTINFO message (msgtype == 29) but instead got a REPL_CMP2UNCMP message (msgtype == 25). The merge/tp_stress subtest induces a REPL_CMP2UNCMP situation using white-box code so the fact that the receiver sent a REPL_CMP2UNCMP message is not surprising. But the timing of the send is where the problem is. The issue is that we maintain the fact that a CMP2UNCMP message needs to be sent in a static variable "send_cmp2uncmp" and had set it to TRUE (in gtmrecv_poll_actions.c) but forgot to clear it before moving on to the new connection. So this leftover static variable caused the incorrect send and resulted in the assert failure of the source server. In pro, the source server would have issued an error message and closed the connection and opened a new connection with the receiver server. So the user would not notice any issues because of this (in the sense, the source server will not go down) even though they can see evidence of an unnecessary disconnect/reconnect sequence in the source server log. As part of the connection reset, we currently reset a few static variables of the old connection but do not reset the send_cmp2uncmp variable. There are a few other statics in use too and are best cleared whenever a connection gets reset. So that is how this fix proceeds. All statics related to the current connection are bundled up in a conn_state_t structure and maintained in the "curr_conn_state" static variable. Anytime a connection gets reset, the entire structure gets cleared.
- Loading branch information
Showing
1 changed file
with
72 additions
and
56 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters