Multi-dump uses wrong delete in old filesytem storage

RESOLVED FIXED in 35

Status

Socorro
Backend
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: lars, Assigned: lars)

Tracking

unspecified
x86_64
Linux

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [qa-])

(Assignee)

Description

5 years ago
This is the tale of crashmover getting slower and slower over a one week period.

This problem lives in the File System codebase circa 2008.  In the file system storage, there is the name and date branches. Date branch provides an time based index of crashes while the name branch stores the actual crashes themselves.  The date index is strange, though, it is a rare case of read once storage.  The act of reading it, destroys it.  This is the desired behavior because it guarantees that a crash will not be referenced twice - only new crashes that have never been seen before are discovered.  Deep within the file system classes, there are two delete functions, one called 'quickDelete' and the default one called 'remove'.  The selection of which one to use depends on if the date branch has an index for the crash.  The 'quickDelete' is for when the crash has been seen and the date index for it was destroyed.  The default 'remove' is thorough and does a needless exhaustive scan for a date index entry when a crash is deleted.  

The multidump code used the default 'remove' function because it is written to be generic and therefore doesn't know the context.  It takes the safe and thorough path.  The old crashmover code knows that it is safe to use the quick delete and so can be very efficient.  

the ultimate solution is to throw this codebase into the nearest active volcano and start using the the replacement written by our intern, rfw.  But since that is not yet ready, then I will patch this ancient code with a healing hack and hope to never see it again...

Comment 1

5 years ago
Commit pushed to master at https://github.com/mozilla/socorro

https://github.com/mozilla/socorro/commit/f64485608f4ee744c6aed86a82a706f59882389b
Merge pull request #1073 from twobraids/Bug836986-fs-delete

Fixes Bug 836986 - call the right delete in file system storage

Comment 2

5 years ago
Needs to be in stage branch so we can push it.
Target Milestone: --- → 35

Comment 3

5 years ago
This moved to stage yesterday, will be released today.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED

Comment 4

5 years ago
This is on stage but was not released due to instability in our production postgres. It will go out in the next release, though.

Updated

5 years ago
Whiteboard: [qa-]
You need to log in before you can comment on or make changes to this bug.