Re: Review Request 36561: Use the application-level storage lock to prevent DB-level deadlock when GCing rows.

2015-07-16 Thread Aurora ReviewBot 

---
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.

2015-07-16 Thread Kevin Sweeney 

---
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.

2015-07-16 Thread Bill Farner 

---
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

Re: Review Request 36561: Use the application-level storage lock to prevent DB-level deadlock when GCing rows.

2015-07-16 Thread Bill Farner 


> On July 16, 2015, 11:48 p.m., Kevin Sweeney wrote:
> > src/main/java/org/apache/aurora/scheduler/storage/db/RowGarbageCollector.java,
> >  line 94
> > 
> >
> > `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
> > 
> >
> > 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.

2015-07-16 Thread Kevin Sweeney 

---
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)


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)


`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
> 
>

Review Request 36561: Use the application-level storage lock to prevent DB-level deadlock when GCing rows.

2015-07-16 Thread Bill Farner 

---
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