Details
-
Task
-
Status: Closed
-
Blocker
-
Resolution: Fixed
-
None
-
None
Description
FileSystemBasedLockProviderTestClass's current tryLock implementation is buggy.
- numRetries is never incremented. So, it can potentially get into ininite loop
- it checks for once and assumes it would be always available later.
This is leading to TestHoodieClientMultiWriter flakiness.
@Override public boolean tryLock(long time, TimeUnit unit) { try { int numRetries = 0; while (fs.exists(new Path(lockPath + "/" + LOCK_NAME)) && (numRetries <= lockConfiguration.getConfig().getInteger(LOCK_ACQUIRE_NUM_RETRIES_PROP_KEY))) { Thread.sleep(lockConfiguration.getConfig().getInteger(LOCK_ACQUIRE_RETRY_WAIT_TIME_IN_MILLIS_PROP_KEY)); } synchronized (LOCK_NAME) { if (fs.exists(new Path(lockPath + "/" + LOCK_NAME))) { return false; } acquireLock(); } return true; } catch (IOException | InterruptedException e) { throw new HoodieLockException("Failed to acquire lock", e); } }