> On July 16, 2015, 11:48 p.m., Kevin Sweeney wrote: > > src/main/java/org/apache/aurora/scheduler/storage/db/RowGarbageCollector.java, > > line 94 > > <https://reviews.apache.org/r/36561/diff/1/?file=1013918#file1013918line94> > > > > `deletedCount.get()` > > > > Or just move `deletedCount` and this log statement into the work block
Good catch, fixed. Can't easily move the log statement, unless we want something other than an aggregate log statement. > On July 16, 2015, 11:48 p.m., Kevin Sweeney wrote: > > src/main/java/org/apache/aurora/scheduler/storage/db/DbModule.java, line 120 > > <https://reviews.apache.org/r/36561/diff/1/?file=1013917#file1013917line120> > > > > Can this be sent to slf4j instead? From > > http://www.h2database.com/html/features.html#trace_options it looks like > > this can be done with TRACE_LEVEL_FILE=4 Sounded like a good idea, but the info-level logging is far too verbose. Left a TODO to revisit. - Bill ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/36561/#review91990 ----------------------------------------------------------- On July 16, 2015, 11:44 p.m., Bill Farner wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/36561/ > ----------------------------------------------------------- > > (Updated July 16, 2015, 11:44 p.m.) > > > Review request for Aurora and Kevin Sweeney. > > > Bugs: AURORA-1401 > https://issues.apache.org/jira/browse/AURORA-1401 > > > Repository: aurora > > > Description > ------- > > Use the application-level storage lock to prevent DB-level deadlock when > GCing rows. > > > Diffs > ----- > > src/main/java/org/apache/aurora/scheduler/storage/db/DbModule.java > 0b76caf717b6b7c36fcbbd41eb2adcac0cc0736b > > src/main/java/org/apache/aurora/scheduler/storage/db/RowGarbageCollector.java > ba7c677039270a1e1b413b50ee7091697ea543a6 > src/test/java/org/apache/aurora/scheduler/app/local/LocalSchedulerMain.java > 1597725ef67b98fb48569c0c3f36bea502ec6daf > > Diff: https://reviews.apache.org/r/36561/diff/ > > > Testing > ------- > > Tried to explore options for repeatably reproducing this in a test case, but > came up with nothing. With the lock mode we currently use (READ > UNCOMMITTED), i believe there is no way to acquire a lock and hold it after a > statement finishes executing. This means that only joins are susceptible to > deadlock, which would be ~impossible to reproduce repeatably. > > > Thanks, > > Bill Farner > >
