hudi-bot opened a new issue, #16257:
URL: https://github.com/apache/hudi/issues/16257

   In HUDI-1623, we introduced the TimeGenerator, but left a shouldLock flag on 
the interfaces which increases the complexity for maintainance.
   Basically, we need to make the lock provider as reentrant to alleviate the 
situration.
   
   Several ideas here (aborted):
   
   1. introduces the isLocked interface on the LockProvider and uses that to 
decide on whether we need a separate lock for the TimeGenerator (disapproved 
because this method has no guarantee of atomicity)
   
   2. create temporary marker files for passing the flag (does not midiate the 
complexity, the caller stills needs to care about whether we should add lock or 
not)
   3. set the shouldLock flag into the TimeGenerator instance (same as 2, does 
not really soves the problem)
   
   ## JIRA info
   
   - Link: https://issues.apache.org/jira/browse/HUDI-6930
   - Type: Improvement
   - Epic: https://issues.apache.org/jira/browse/HUDI-6243
   - Fix version(s):
     - 1.1.0
   
   
   ---
   
   
   ## Comments
   
   23/Sep/24 01:54;danny0405;Like described in the context, there is no good 
sulution now and it is not a blocker because TimeGenerator is a developer API, 
move it to phase2 and would rethink it in the future.;;;


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