[GitHub] [accumulo] keith-turner commented on issue #1358: Fix race conditions with commitsInProgress counter

2019-09-13 Thread GitBox
keith-turner commented on issue #1358: Fix race conditions with commitsInProgress counter URL: https://github.com/apache/accumulo/pull/1358#issuecomment-531274741 > For this particular PR it's still not clear to me why CommitSession.java needs to lock (block) the entire tablet to keep

[GitHub] [accumulo] keith-turner commented on issue #1358: Fix race conditions with commitsInProgress counter

2019-09-12 Thread GitBox
keith-turner commented on issue #1358: Fix race conditions with commitsInProgress counter URL: https://github.com/apache/accumulo/pull/1358#issuecomment-530944944 > So, the downside with your proposed solution is that the locking becomes very granular. That is to say, if a method needs to

[GitHub] [accumulo] keith-turner commented on issue #1358: Fix race conditions with commitsInProgress counter

2019-09-12 Thread GitBox
keith-turner commented on issue #1358: Fix race conditions with commitsInProgress counter URL: https://github.com/apache/accumulo/pull/1358#issuecomment-530861250 > Update to use Java Concurrency classes (as an example for the rest of the code base) I think this could be a nice

[GitHub] [accumulo] keith-turner commented on issue #1358: Fix race conditions with commitsInProgress counter

2019-09-12 Thread GitBox
keith-turner commented on issue #1358: Fix race conditions with commitsInProgress counter URL: https://github.com/apache/accumulo/pull/1358#issuecomment-530859174 The code is very complicated for Tablet, but the conceptual model is very simple. There is a single lock that protects most