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

Allow snapshot compactions during deletes #7165

Merged
merged 6 commits into from
Oct 18, 2016
Merged

Allow snapshot compactions during deletes #7165

merged 6 commits into from
Oct 18, 2016

Conversation

jwilder
Copy link
Contributor

@jwilder jwilder commented Aug 17, 2016

Required for all non-trivial PRs
  • Rebased/mergable
  • Tests pass
  • CHANGELOG.md updated

If a delete takes a long time to process while writes to the
shard are occuring, it was possible for the cache to fill up
and writes to be rejected. This occurred because we disabled
all compactions while writing tombstone file to prevent deleted
data from re-appearing after a compaction completed.

Instead, we only disable the level compactions and allow snapshot
compactions to continue. Snapshots already handle deleted data
with the cache and wal.

Fixes #7161

Sorry, something went wrong.

@@ -532,10 +557,10 @@ func (c *Compactor) WriteSnapshot(cache *Cache) ([]string, error) {

// See if we were closed while writing a snapshot
Copy link
Contributor

Choose a reason for hiding this comment

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

This comment should be updated since opened and closing were removed

Copy link
Contributor

Choose a reason for hiding this comment

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

This comment still needs updating.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Oops... wrong line. Will fix

@pauldix
Copy link
Member

pauldix commented Aug 23, 2016

Not sure I'm reading this correctly, but it doesn't look like the snapshot compactions are ever actually disabled. There a reason to have that in there?

If a delete takes a long time to process while writes to the
shard are occuring, it was possible for the cache to fill up
and writes to be rejected.  This occurred because we disabled
all compactions while writing tombstone file to prevent deleted
data from re-appearing after a compaction completed.

Instead, we only disable the level compactions and allow snapshot
compactions to continue.  Snapshots already handle deleted data
with the cache and wal.

Fixes #7161
@jwilder jwilder force-pushed the jw-deletes branch 2 times, most recently from 3f5f96d to 629d117 Compare October 18, 2016 19:16
Copy link
Contributor

@e-dard e-dard left a comment

Choose a reason for hiding this comment

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

Not sure if snapshotterDone is setup right?

done chan struct{}
wg sync.WaitGroup
compactionsEnabled bool
mu sync.RWMutex
Copy link
Contributor

Choose a reason for hiding this comment

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

nit, would be good to separate out which fields are protected by mu.

// Abort any running goroutines (this could take a while)
e.Compactor.Close()
e.snapshotCompactionsEnabled = true
e.snapshotterDone = make(chan struct{})
Copy link
Contributor

Choose a reason for hiding this comment

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

snapshotterDone as far as I can see is never sent on or closed, so I'm not sure what its purpose it?

Copy link
Contributor

Choose a reason for hiding this comment

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

@e-dard, there were some lost commits from #7221 that need to get merged back in

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@e-dard @joelegasse Added #7221 commits back in.

@jwilder jwilder self-assigned this Oct 18, 2016
@jwilder jwilder merged commit 8f3da43 into master Oct 18, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants