----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/54774/#review159292 -----------------------------------------------------------
I would like to understand your thinking here: Why add so many todos if the necessary code change itself is rather small. Do you expect there is a certain risk here? - Stephan Erb On Dec. 15, 2016, 8:57 a.m., David McLaughlin wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/54774/ > ----------------------------------------------------------- > > (Updated Dec. 15, 2016, 8:57 a.m.) > > > Review request for Aurora, Joshua Cohen, Santhosh Kumar Shanmugham, and > Zameer Manji. > > > Bugs: AURORA-1861 > https://issues.apache.org/jira/browse/AURORA-1861 > > > Repository: aurora > > > Description > ------- > > Motivation: Thanks to the mybatis query metrics we added, we found that the > redundant query I'm removing here currently adds 20s to the snapshot creation > time. This is an extra 20s unavailability every time we snapshot on our prod > clusters. > > === > > Avoid double writing job updates to the Scheduler Snapshot. This should be > low-risk because: > > 1) Job Updates have *never* had an in-memory store implementation. > 2) They are also relatively new, so the chances of some old code processing > job updates from backups is fairly low? > > > Diffs > ----- > > > src/main/java/org/apache/aurora/scheduler/storage/log/SnapshotStoreImpl.java > d2c859055f905ac76ee8eb387dca103b9857ddbe > src/test/java/org/apache/aurora/scheduler/storage/backup/RecoveryTest.java > 7a11850e217dcb0148e4a4d33542c95b2e53a726 > > src/test/java/org/apache/aurora/scheduler/storage/log/SnapshotStoreImplIT.java > cf0a8f3ea11e9c48d1f16441af54dc781b33bdfc > > Diff: https://reviews.apache.org/r/54774/diff/ > > > Testing > ------- > > ./gradlew test > > I'll apply this to one of our test clusters before merging to master too. > > > Thanks, > > David McLaughlin > >
