reddycharan commented on a change in pull request #1225: Issue #570: getting 
rid of unnecessary synchronization in InterleavedLedgerStorage
URL: https://github.com/apache/bookkeeper/pull/1225#discussion_r172354228
 
 

 ##########
 File path: 
bookkeeper-server/src/test/java/org/apache/bookkeeper/bookie/EntryLogTest.java
 ##########
 @@ -391,4 +400,137 @@ public void testGetEntryLogsSet() throws Exception {
 
         assertEquals(Sets.newHashSet(0L, 1L, 2L, 3L), 
logger.getEntryLogsSet());
     }
+
+    class LedgerStorageWriteTask implements Callable<Boolean> {
+        long ledgerId;
+        int entryId;
+        LedgerStorage ledgerStorage;
+
+        LedgerStorageWriteTask(long ledgerId, int entryId, LedgerStorage 
ledgerStorage) {
+            this.ledgerId = ledgerId;
+            this.entryId = entryId;
+            this.ledgerStorage = ledgerStorage;
+        }
+
+        @Override
+        public Boolean call() {
+            try {
+                ledgerStorage.addEntry(generateEntry(ledgerId, entryId));
+            } catch (IOException e) {
+                LOG.error("Got Exception for AddEntry call. LedgerId: " + 
ledgerId + " entryId: " + entryId, e);
+                return false;
+            }
+            return true;
+        }
+    }
+
+    class LedgerStorageReadTask implements Callable<Boolean> {
+        long ledgerId;
+        int entryId;
+        LedgerStorage ledgerStorage;
+
+        LedgerStorageReadTask(long ledgerId, int entryId, LedgerStorage 
ledgerStorage) {
+            this.ledgerId = ledgerId;
+            this.entryId = entryId;
+            this.ledgerStorage = ledgerStorage;
+        }
+
+        @Override
+        public Boolean call() {
 
 Review comment:
   first thing 
   
   1) calling .get() on future is inevitable, since thats the only way you 
would get the result of the future.
   
   > Instead of returning false on errors, you could throw Exception, and have 
that carry the context of the error (ledger id, entry id etc). This would 
simplify the loops in the test itself.
   
   2) even if I change the logic to throw exception instead of boolean in the 
case of failure, we are not getting rid of loops. Because incase of 
CancellationException we would get generic cancellation exception instead of 
any of our exception with customized message. So atleast for this case we need 
to do what we are doing.
   
   Again as I said this is matter of preference how we deal with return status 
of tasks/futures in junit test env. If you see it as a dealbreaker for you, 
I'll go ahead and change it to throw exception, as I don't see value in 
dragging this further.

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

Reply via email to