keith-turner commented on a change in pull request #2329:
URL: https://github.com/apache/accumulo/pull/2329#discussion_r740333841



##########
File path: 
core/src/main/java/org/apache/accumulo/fate/zookeeper/DistributedReadWriteLock.java
##########
@@ -218,22 +237,54 @@ public boolean tryLock() {
       }
       SortedMap<Long,byte[]> entries = qlock.getEarlierEntries(entry);
       Iterator<Entry<Long,byte[]>> iterator = entries.entrySet().iterator();
-      if (!iterator.hasNext())
+      if (!iterator.hasNext()) {
         throw new IllegalStateException("Did not find our own lock in the 
queue: " + this.entry
             + " userData " + new String(this.userData, UTF_8) + " lockType " + 
lockType());
-      return iterator.next().getKey().equals(entry);
+      }
+      if (!failBlockers) {
+        return iterator.next().getKey().equals(entry);
+      } else {
+        ZooStore<DistributedReadWriteLock> zs;
+        try {
+          zs = new ZooStore<>(zooPath, zrw);
+        } catch (KeeperException | InterruptedException e1) {
+          log.error("Error creating zoo store", e1);
+          return false;
+        }
+        final AdminUtil<DistributedReadWriteLock> util = new AdminUtil<>();
+        boolean result = true;
+        while (iterator.hasNext()) {
+          Entry<Long,byte[]> e = iterator.next();
+          if (!e.getKey().equals(entry)) {
+            result &= util.prepFail(zs, zrw, zooManagerPath, 
Long.toString(e.getKey(), 16));

Review comment:
       @dlmarion  could possible do something like the following... where the 
code in  `failPrecedingOperations()` would go through and transition operations 
to FAILED_IN_PROGRESS... also thinking that code could transition NEW things 
straight to FAILED instead of to FAILED_IN_PROGRESS but not sure.   However 
there is not waiting on these other operations.   The FATE framework will 
reserve a txid, take the top repo off the stack, and then call isReady().  If 
isReady returns non-zero it will unreserve and the txid and come back to it 
later.  So if isReady transitions things to FAILED_IN_PROGRESS then hopefully a 
later call to isReady can get the lock sooner.
   
   ```java
      class SomeRepo extends Repo {
           public long isReady(long tid,...) {
               long waitTime = tryToGetTableWriteLock(...);
   
              if(waitTime > 0 && failBlockers) {
                   // we did not get the the table write lock, so lets initiate 
the failure of all operations that precede us in the lock queue.... hopefully 
after these fail they will release the lock and we will get the lock on a later 
call to isRead()
                  failPrecedingOperations(tid)
              }
              
              return waitTime;
           }
       
      }
   ```




-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


Reply via email to