[
https://issues.apache.org/jira/browse/HUDI-3064?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated HUDI-3064:
---------------------------------
Labels: pull-request-available (was: )
> FileSystemBasedLockProviderTestClass - tryLock doesn't honor retries
> --------------------------------------------------------------------
>
> Key: HUDI-3064
> URL: https://issues.apache.org/jira/browse/HUDI-3064
> Project: Apache Hudi
> Issue Type: Task
> Reporter: Manoj Govindassamy
> Assignee: Manoj Govindassamy
> Priority: Blocker
> Labels: pull-request-available
> Fix For: 0.11.0
>
>
> 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.
>
>
> {code:java}
> @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);
> }
> } {code}
>
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
