From: Rolf Badorek Date: Mon, 23 Sep 2019 11:14:56 +0000 (+0300) Subject: Add Sentinel change notification handling logic X-Git-Tag: 1.2.1~24 X-Git-Url: https://gerrit.o-ran-sc.org/r/gitweb?a=commitdiff_plain;ds=sidebyside;h=b7f4971cb7d84e8288140901f4a9dfa773292421;hp=b7f4971cb7d84e8288140901f4a9dfa773292421;p=ric-plt%2Fsdl.git Add Sentinel change notification handling logic When new Redis master has been promoted, Sentinel publishes notification to '+switch-master' channel. Refer to below web page for further details: https://redis.io/topics/sentinel 'AsyncSentinelDatabaseDiscovery' will now subscribe notifications for above mentioned channel. Notification contains information of new Redis master, which is parsed from message and sent to upper layer via 'StateChangedCb' callback (if callback is set). When notifications are subscribed from Redis (from Sentinel this case), connection will go to "subscribed state", and only some pub/sub related commands are allowed. Due the above reason, we have two connections (command dispatchers). One to subscribe notifications and the other for Sentinel commands, like master inquiry. Refer to below web page for further details: https://redis.io/topics/pubsub In case that subscriber connection goes down, subscription for notifications is renewed once connection to Sentinel is working again. Extra master inquiry will be made because we might be missed notifications during connection cut. Latest master address is refreshed via 'StateChangedCb', even if has not changed compared to last informed address. This could be optimized, but as being very rare situation was not seen worth of extra logic. In case that the other connection (used for Sentinel commands) is cut, the related command dispatcher will re-connect in the background. Possible Sentinel commands during connection cut will fail and trigger retry after short delay (per already existing implementation). If some notifications are missed due some other reason than connection cut, SDL might go to the state that operations will made to Redis slave. In this situation write operations will fail with a new internal 'AsyncRedisCommandDispatcherErrorCode::WRITING_TO_SLAVE' error code, which is mapped to 'shareddatalayer::Error::BACKEND_FAILURE'. Recovery instructions adjusted a bit, so that re-creating SDL API instance is not optional recovery step (it is the only way to recover from above mentioned situation currently). Sentinel support is still disabled, missing implementation will be added soon as a separate commit(s). Signed-off-by: Rolf Badorek Change-Id: I1bb9e121985ee22278e780e50ab13f88acdc65c5 ---