-
Notifications
You must be signed in to change notification settings - Fork 11
Added Label for Watch commands #5
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
Conversation
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.
Thanks for the working on this feature @psrvere! I have left some comments.
watch_connection.go
Outdated
label := msg.Command | ||
_, err = uuid.Parse(label) | ||
|
||
if err == nil { | ||
select { | ||
case c.firstUpdateCh <- msg: | ||
if !timer.Stop() { | ||
<-timer.C | ||
} |
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.
Trying to understand the flow here. Shouldn't we have multiple firstUpdateCh's - one for each Watch invocation associated with a unique uuid? The logic here could look up the uuid in a map and send it to the correct firstUpdateCh (for the respective watch command).
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.
Agreed. I have fixed this by creating a new channel whenever Watch is invoked and the same is stored in watchLabelFirstMsgChMap
watch_connection.go
Outdated
w.chOnce.Do(func() { | ||
w.msgCh = newWatchCommandChannel(w) | ||
// Create firstUpdateCh with buffer of 1 to avoid blocking | ||
w.msgCh.firstUpdateCh = make(chan *WatchResult, 1) | ||
w.msgCh.initMsgChan() | ||
}) | ||
|
||
// Subscribe to the command | ||
err := w.watchCommand(ctx, cmdName, args...) |
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.
The SDK here should generate a uuid and associate it with the given watch command (maybe create a map where they key is the uuid and the value is this invocation's respective firstMsgCh.
The uuid is sent to the server by the SDK and the server simply returns it back with the first response (note that the server should also be able to handle the case where no uuid is sent and in that case it simply returns an empty value)
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.
Changed this, Now uuid is generated in SDK and sent to server.
@JyotinderSingh - worked on the comments. Please review. Here is the flow for your understanding:
|
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.
Thanks for addressing the reviews @psrvere! The changes look good, have just added a clarification comment.
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.
Awesome, thanks for adding this!
This reverts commit 4ecce8f
What is the Problem?
SDK provides
Watch
api to subscribe Watch commands. This returns push response["GET", fingerprint, value]
so that users can get fingerprint immediately.Since multiplexing is allowed i.e. users can subscribe for multiple keys, example:
GET.WATCH k1
andGET.WATCH k2
, there is no way for SDK to know that if a received update is the first message for sayk2
or an update message fork1
.What is the Solution?
PR adds watch label (uuid) in diceDB
worker.go
. It is generated with every watch subscription. Label is received only in the first response by SDK.This PR adds two separate channels
firstUpdateCh
andupdateCh
for first response and subsequent updates of Watch subscriptions.Watch
api call is followed byChannel
api call to get channel for updates. Earlier, Channel initialisedinitMsgChan
routine which would check for updates from server.Now
Watch
api call initialisesinitMsgChan
andinitMsgChan
filters subscription first response and sends it tofirstUpdateCh
buffered channel which is then consumed byWatch
. In First response,msg.Command
is expected to be a valid uuid string. Label is not sent to the end user.All subsequent responses are sent to
updateCh
which is returned as response toChannel
api and users to consume updates on subscribed keys.