Skip to content
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

storage: fill the reservation before sending the snapshot response #10440

Conversation

petermattis
Copy link
Collaborator

@petermattis petermattis commented Nov 3, 2016

If we send the response before filling the reservation the RPC can be
sent over the network waking up the goroutine which initiated the
preemptive snapshot and allowing it to perform another one before the
reservation is filled. This second preemptive snapshot would get
rejected and cause full replication to take much longer to achieve
resulting in test flakiness.


This change is Reviewable

s.bookie.Fill(ctx, header.RangeDescriptor.RangeID)
}
}
defer fillReservation()
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is ugly. I'm open to suggestions.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could a sync.Once do the trick?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps, though the synchronization sync.Once provides isn't necessary.

@petermattis petermattis force-pushed the pmattis/fill-reservation-before-response branch from df6a951 to ecab915 Compare November 3, 2016 19:00
If we send the response before filling the reservation the RPC can be
sent over the network waking up the goroutine which initiated the
preemptive snapshot and allowing it to perform another one before the
reservation is filled. This second preemptive snapshot would get
rejected and cause full replication to take much longer to achieve
resulting in test flakiness.
@petermattis petermattis force-pushed the pmattis/fill-reservation-before-response branch from ecab915 to d9e812a Compare November 3, 2016 19:01
@petermattis
Copy link
Collaborator Author

Reworked this PR to have the snapshot sender wait for the stream EOF. PTAL.

@tamird
Copy link
Contributor

tamird commented Nov 3, 2016

:lgtm:


Reviewed 2 of 2 files at r2.
Review status: all files reviewed at latest revision, 2 unresolved discussions, all commit checks successful.


pkg/storage/raft_transport.go, line 605 at r2 (raw file):

func (c snapshotClientWithBreaker) Recv() (*SnapshotResponse, error) {
  m, err := c.MultiRaft_RaftSnapshotClient.Recv()
  if err != nil && err != io.EOF {

please add a comment!


Comments from Reviewable

@petermattis
Copy link
Collaborator Author

Review status: all files reviewed at latest revision, 2 unresolved discussions, all commit checks successful.


pkg/storage/raft_transport.go, line 605 at r2 (raw file):

Previously, tamird (Tamir Duberstein) wrote…

please add a comment!

What would the comment say? The code is pretty self-explanatory (at least, I thought it was). I'm going to merge because I'm heading out and this is causing serious flakiness, but I'll add a comment in a follow-on PR if we can decide on what it should say.

Comments from Reviewable

@petermattis petermattis merged commit 1d4694a into cockroachdb:master Nov 3, 2016
@petermattis petermattis deleted the pmattis/fill-reservation-before-response branch November 3, 2016 19:14
// NB: wait for EOF which ensures that all processing on the server side has
// completed (such as defers that might be run after the previous message was
// received).
if _, err := stream.Recv(); err != io.EOF {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is rather odd for two reasons 1. the resp is ignored, and 2. I imagine it would be part of a receiver loop

@tamird
Copy link
Contributor

tamird commented Nov 3, 2016

Review status: all files reviewed at latest revision, 3 unresolved discussions, all commit checks successful.


pkg/storage/raft_transport.go, line 605 at r2 (raw file):

Previously, petermattis (Peter Mattis) wrote…

What would the comment say? The code is pretty self-explanatory (at least, I thought it was). I'm going to merge because I'm heading out and this is causing serious flakiness, but I'll add a comment in a follow-on PR if we can decide on what it should say.

Eh, maybe you're right and this is fine.

pkg/storage/store.go, line 3094 at r2 (raw file):

Previously, vivekmenezes wrote…

This is rather odd for two reasons 1. the resp is ignored, and 2. I imagine it would be part of a receiver loop

I suppose we should log the response if we get something other than EOF.

Comments from Reviewable

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants