You are viewing a plain text version of this content. The canonical link for it is here.
Posted to reviews@aurora.apache.org by Bill Farner <wf...@apache.org> on 2015/07/17 01:44:03 UTC
Review Request 36561: Use the application-level storage lock to
prevent DB-level deadlock when GCing rows.
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/36561/
-----------------------------------------------------------
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
Re: Review Request 36561: Use the application-level storage lock to
prevent DB-level deadlock when GCing rows.
Posted by Bill Farner <wf...@apache.org>.
> 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
>
>
Re: Review Request 36561: Use the application-level storage lock to
prevent DB-level deadlock when GCing rows.
Posted by Kevin Sweeney <ke...@apache.org>.
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/36561/#review91990
-----------------------------------------------------------
src/main/java/org/apache/aurora/scheduler/storage/db/DbModule.java (line 120)
<https://reviews.apache.org/r/36561/#comment145782>
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
src/main/java/org/apache/aurora/scheduler/storage/db/RowGarbageCollector.java (line 92)
<https://reviews.apache.org/r/36561/#comment145788>
`deletedCount.get()`
Or just move `deletedCount` and this log statement into the work block
- Kevin Sweeney
On July 16, 2015, 4: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, 4: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
>
>
Re: Review Request 36561: Use the application-level storage lock to
prevent DB-level deadlock when GCing rows.
Posted by Aurora ReviewBot <wf...@apache.org>.
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/36561/#review91996
-----------------------------------------------------------
Ship it!
Master (a654b28) is green with this patch.
./build-support/jenkins/build.sh
I will refresh this build result if you post a review containing "@ReviewBot retry"
- Aurora ReviewBot
On July 16, 2015, 11:59 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:59 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
>
>
Re: Review Request 36561: Use the application-level storage lock to
prevent DB-level deadlock when GCing rows.
Posted by Kevin Sweeney <ke...@apache.org>.
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/36561/#review91995
-----------------------------------------------------------
Ship it!
Ship It!
- Kevin Sweeney
On July 16, 2015, 4:59 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, 4:59 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
>
>
Re: Review Request 36561: Use the application-level storage lock to
prevent DB-level deadlock when GCing rows.
Posted by Bill Farner <wf...@apache.org>.
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/36561/
-----------------------------------------------------------
(Updated July 16, 2015, 11:59 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 (updated)
-----
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