nsivabalan opened a new pull request, #12737:
URL: https://github.com/apache/hudi/pull/12737

   ### Change Logs
   
   - Fixing concurrency handling during upgrade and downgrade. 
   We are making 3 fixes in this patch. 
   a. Introducing NoopLockProvider. During upgrade flows, we have a nested 
locking situation and some locks may not support Re-entrant behavior including 
InProcessLockProvider. So, for UpgradeHandler code blocks, we override the lock 
provider to use NoopLockProvider. 
   
   So, what this entails is: 
   ```
   
   df.write.format(hudi).save(path) -> say user configured zookeeper based lock 
provider. 
      .
      . writeClient.upsert 
            doInitTable
                lock using zookeeper based lock provider
                     upgrade
                              override lock provider to NoopLockProvider 
                                   rollback failed writes
                                   full table compaction 
                                   both of the above operations will not try to 
re-acquire the lock again using user configured LP(i.e zookeeper based lock 
provider). here we use NoopLockProvider. 
                 unlock
          continue w/ upsert. 
          .
   .
   
   ```
   
   
   2. We use a cache for TimeGenerator instances, one per table path. Again, in 
the above flow of events, even if we override the LP to NoopLockProvider, new 
instant time generation was using the same lock provider as user configured 
one. Reason was, we re-use the same TimeGenerator which was generated before 
the upgrade call. So, introduced an internal config named 
"_hoodie.time.generator.reuse.enable". By default we enable it. In the upgrade 
flows, we override it to false. And so, we create new instance of 
TimeGenerator. This means that, the lock provider used by the TimeGenerator 
will use NoopLockProvider as configured. 
   
   3. We were automatically overriding the LockProvider to InProcessLock 
provider if its a single writer and all inline table services. Made this logic 
to be guarded by the auto adjust lock config (hoodie.auto.adjust.lock.configs). 
So, no auto adjustment of lock configs will take place for straight forward out 
of the box use-case. 
   
   ### Impact
   
   Seamless upgrade irrespective of lock provider used. 
   
   ### Risk level (write none, low medium or high below)
   
   medium
   
   ### Documentation Update
   
   _Describe any necessary documentation update if there is any new feature, 
config, or user-facing change. If not, put "none"._
   
   - _The config description must be updated if new configs are added or the 
default value of the configs are changed_
   - _Any new feature or user-facing change requires updating the Hudi website. 
Please create a Jira ticket, attach the
     ticket number here and follow the 
[instruction](https://hudi.apache.org/contribute/developer-setup#website) to 
make
     changes to the website._
   
   ### Contributor's checklist
   
   - [ ] Read through [contributor's 
guide](https://hudi.apache.org/contribute/how-to-contribute)
   - [ ] Change Logs and Impact were stated clearly
   - [ ] Adequate tests were added if applicable
   - [ ] CI passed
   


-- 
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