Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Updated this PR with the new topos_htable module since it depends on the previous htable module commits.
The new module uses htable module api functions for implementing the topos api callbacks needed for storing/loading/updating topology data. It creates 2 new htables called "topos_transaction" and "topos_dialog" upon modinit. Synchronizes via DMQ only the "topos_dialog" htable.
Basic testing of a call using 2 x DMQ nodes, load balanced via DNS show on kamcmd that dialog topology info is shared between the two nodes. If ACK/BYE lands on the peer node, topology info is loaded for "topos_dialog" htable and requests are routed correctly. If DMQ fails to sync "topos_dialog" htable in time, we will rely on 200+ACK/BYE retransmissions, for now.
We decided internally that this is the best 'SHM' solution that fits for us.
Comments or opinions about this, appreciated.
Thank you,
Stefan
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.