-
-
Notifications
You must be signed in to change notification settings - Fork 145
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
Hide Watch method from Client.go and move into Attach method #593
Conversation
7dbefe0
to
93ee546
Compare
Codecov ReportAttention:
Additional details and impacted files@@ Coverage Diff @@
## main #593 +/- ##
==========================================
+ Coverage 50.71% 51.44% +0.72%
==========================================
Files 70 66 -4
Lines 10213 6978 -3235
==========================================
- Hits 5180 3590 -1590
+ Misses 4512 2912 -1600
+ Partials 521 476 -45 ☔ View full report in Codecov by Sentry. |
I will also review this. It will take some time. @karockai |
I think this task is not as simple as it might seem. To move You can refer to And we need to list what more to consider and decide on the scope of work. |
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.
There is one problem in this PR. After a client watching is changed to execute continuously after attaching a document, some tests in document_test have had an issue. Please see the scenario below.
...
This is because the watch stream created by attach
(step 1) is not closed even after detach
(step 2). So when the client tries to perform attach
(step 3), watch stream collides with the existing watch stream (I have to investigate more about this).
Since the watch stream automatically closes after MaxConnectionAge
+ MaxConnectionAgeGrace
which is configured in the server (for integration test, it is set to 8 seconds + 2 seconds
), time buffer you have set (which is total time.Sleep(5) + time.Sleep(5)
) will eventually close the stream. This is why your test is passing.
To conclude, you need to close the stream on detach. In the JS SDK, detachInternal()
's cancelWatchStream()
performs this task.
49ce076
to
93ee546
Compare
@karockai It seems like there is a data race on Concurrent deletion of
|
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.
Thank you for your contribution.
I'm still reviewing on watch()
on client.go
, but I left a brief comments and questions.
client/client.go
Outdated
} | ||
if _, err := handleResponse(pbResp); err != nil { | ||
return nil, err | ||
rch := make(chan WatchResponse, 3) |
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.
Is there any reason for setting buffer size to 3
?
pkg/document/document.go
Outdated
@@ -79,7 +79,7 @@ type Document struct { | |||
func New(key key.Key) *Document { | |||
return &Document{ | |||
doc: NewInternalDocument(key), | |||
events: make(chan DocEvent, 1), | |||
events: make(chan DocEvent, 3), |
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.
Is there any reason for setting buffer size to 3?
Same here.
@@ -36,7 +36,7 @@ func NewSubscription(subscriber *time.ActorID) *Subscription { | |||
return &Subscription{ | |||
id: xid.New().String(), | |||
subscriber: subscriber, | |||
events: make(chan DocEvent, 1), | |||
events: make(chan DocEvent, 3), |
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.
Is there any reason for setting buffer size to 3?
Same here.
test/integration/agent_test.go
Outdated
"github.com/yorkie-team/yorkie/test/helper" | ||
) | ||
|
||
func TestServer(t *testing.T) { |
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.
Is there any reason for removing this test?
@@ -287,13 +284,15 @@ func BenchmarkRPC(b *testing.B) { | |||
wg.Add(2) | |||
go func() { | |||
defer wg.Done() | |||
err := c1.Attach(ctx, doc1) | |||
rch1, err := c1.Attach(ctx, doc1) |
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.
I wonder if it is necessary to receive and check rch1
channel every time we perform Attach()
, even if the test does not require rch
channel.
Maybe setting rch1
to _
would be better.
If you think this suggestion is reasonable, please check other test codes changes that you have made to apply this suggestion.
test/integration/document_test.go
Outdated
|
||
// 03. abnormal behavior on removed state | ||
assert.NoError(t, cli.Remove(ctx, d1)) | ||
assert.ErrorIs(t, cli.Remove(ctx, d1), client.ErrDocumentNotAttached) | ||
assert.ErrorIs(t, cli.Sync(ctx, client.WithDocKey(d1.Key())), client.ErrDocumentNotAttached) | ||
assert.ErrorIs(t, cli.Detach(ctx, d1), client.ErrDocumentNotAttached) | ||
}) | ||
|
||
t.Run("removed document removal with watching test", func(t *testing.T) { |
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.
Is there any reason for removing this test?
defer func() { | ||
assert.NoError(t, c1.Detach(ctx, d1)) | ||
}() | ||
d2 := document.New(helper.TestDocKey(t), 2) |
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.
What does this second parameter 2
mean?
return | ||
} | ||
} | ||
} | ||
}() | ||
|
||
// 03. Watch the second client's document. | ||
expected = append(expected, watchResponsePair{ |
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.
Any reason for removing expected
code and changing len(responsePairs) == 3
to len(responsePairs) == 1
?
pkg/document/document.go
Outdated
@@ -79,7 +79,7 @@ type Document struct { | |||
func New(key key.Key) *Document { | |||
return &Document{ | |||
doc: NewInternalDocument(key), | |||
events: make(chan DocEvent, 1), | |||
events: make(chan DocEvent, 3), |
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.
Is there any reason for changing buffer to 3
?
@@ -36,7 +36,7 @@ func NewSubscription(subscriber *time.ActorID) *Subscription { | |||
return &Subscription{ | |||
id: xid.New().String(), | |||
subscriber: subscriber, | |||
events: make(chan DocEvent, 1), | |||
events: make(chan DocEvent, 3), |
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.
Is there any reason for changing buffer to
3
?
Same here.
7892142
to
fdc2e1c
Compare
…rface remove Client.Watch from external interface and move into Client.Attach, so watching a document will be executed continously after attaching continuously (and atomically).
cc29fac
to
25ed0ef
Compare
@hackerwins I will look this PR again and finish this task. |
@krapie Thanks for your interest. It would be good to recreate PR. |
What this PR does / why we need it:
Watch
method ofClient
to private.Attach
method to execute thewatch
method atomically after attaching.Which issue(s) this PR fixes:
Fixes #584
Special notes for your reviewer:
There is one problem in this PR. After a client watching is changed to execute continuously after attaching a document, some tests in
document_test
have had an issue. Please see the scenario below.There is no problem Until step 2 but step3 has.
The err is
closing transport due to: connection error: desc = "error reading from server: EOF", received prior goaway: code: NO_ERROR
and server log is
2023-07-30T23:53:36.646+0900 WARN r7 RPC : stream "/yorkie.v1.YorkieService/WatchDocument" 9.632547583s => "rpc error: code = Unknown desc = connection error: desc = \"transport is closing\""
I said above that it wouldn't be a problem in step 2, but it really isn't. Even though error checking tells there is no err after step 2, to pass tests a time buffer should be set between step 1 and step 2, and also step 2 and step 3. The time buffer should be more than 4 sec. The test couldn't be passed when there is no time buffer between step 2 and step 3,
After tried to solve this problem several days, I found that it is better to share this problem rather than try only myself.
further detail:
client side err is coming from
server side err is coming from
Does this PR introduce a user-facing change?:
Additional documentation:
Checklist: