-
Notifications
You must be signed in to change notification settings - Fork 151
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Auto reconnect #176
Auto reconnect #176
Conversation
Pull Request Test Coverage Report for Build 989870243
💛 - Coveralls |
o.monitorsMutex.Lock() | ||
defer o.monitorsMutex.Unlock() | ||
for id, request := range o.monitors { | ||
err = o.monitor(id, reconnect, request...) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
calling o.monitor
will re-establish the monitors.
the reponse to the monitor rpc call is the the contents of the tables we're monitoring which gets fed to cache.Populate()
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, so ovsdb takes care of re-syncing the monitor on reconnect? nice, etcd doesn't do that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah, the downside is you get all the things, not just the delta from when you were last connected... and with a large database it can take a while to process.
daf2ee5
to
f81bf29
Compare
0ac6d35
to
f3c218a
Compare
/lgtm as far as I can tell |
This commit adds the WithReconnect option that provides the ability for the library to handle automatically reconnecting then client when it is disconnected. Signed-off-by: Dave Tucker <dave@dtucker.co.uk>
f3c218a
to
2029ad7
Compare
This commit builds on the work released in v0.5.0 to provide disconnect notifications.
It adds the
WithReconnect
option that provides the ability for the library to handle automatically reconnecting then client when it is disconnected. This includes re-establishing any Monitors that a user may have established.Normal Operation
Disconnect()
andClose()
API calls do the same thing - clear all connection state and set the cache to nilDisconnectNotify
channelWithReconnect
Disconnect()
(or anything that closes the underlyingrpcClient
) will trigger reconnection. You will not get a notification on theDisconnectNotify
channel. The cache content is cleared BUT any event handlers will be retained.Close()
will do a full shutdown of the client. All connection state is cleared and the cache is set to nil. You will get a notification on theDisocnnectNotify
channelWithReconnect
includes a timeout (for the call toDialWithContext
and a user-provided backoff function, which can handle,ZeroBackoff
,ExponentialBackoff
and more.API Changes
Monitor
andMonitorAll
do not accept ajsonContext
argument any more. We instead generate a unique ID for every monitor and return this to the caller. This can then be used toMonitorCancel
if they wish. This is required to enable the auto-reconnect feature because we want to ensure the unique-ness of monitor id's across connection hiccups.Cache
gains aPurge
method to drop the contents of the cache but leave any eventHandlers intact so we can ensure we don't have stale entries in the cache on re-establishing a monitor.** Misc **
This also cleans adds locking of key state in the
client
ensure that things don't break catastrophically when the automatic reconnection is happening in a separate goroutine. This should also make the client safe to be shared across by more than one goroutine.Fixes #172