[HUDI-1982] Remove unnecessary synchronization

[chaplinthink]

Tips

• Thank you very much for contributing to Apache Hudi.
• Please review https://hudi.apache.org/contributing.html before opening a pull request.

What is the purpose of the pull request

synchronized is not necessary, because the sync operation already has WriteLock to ensure synchronization

Brief change log

(for example:)

• Modify AnnotationLocation checkstyle rule in checkstyle.xml

Verify this pull request

(Please pick either of the following options)

This pull request is a trivial rework / code cleanup without any test coverage.

(or)

This pull request is already covered by existing tests, such as (please describe tests).

(or)

This change added tests and can be verified as follows:

(example:)

• Added integration tests for end-to-end.
• Added HoodieClientWriteTest to verify the change.
• Manually verified the change by running a job locally.

Committer checklist

• Has a corresponding JIRA in PR title & commit

• Commit message is descriptive of the change

• CI is green

• Necessary doc changes done or have another open PR

• For large changes, please consider breaking it into sub-tasks under an umbrella JIRA.

[codecov-commenter]

Codecov Report

❌ Patch coverage is 0% with 6 lines in your changes missing coverage. Please review.
✅ Project coverage is 55.14%. Comparing base (08464a6) to head (2a77d2a).
⚠️ Report is 5641 commits behind head on master.

Files with missing lines	Patch %	Lines
...g/apache/hudi/timeline/service/RequestHandler.java	0.00%	6 Missing ⚠️

Additional details and impacted files

@@             Coverage Diff              @@
##             master    #3041      +/-   ##
============================================
+ Coverage     49.86%   55.14%   +5.28%     
- Complexity     3527     3865     +338     
============================================
  Files           488      488              
  Lines         23618    23616       -2     
  Branches       2528     2528              
============================================
+ Hits          11777    13023    +1246     
+ Misses        10802     9434    -1368     
- Partials       1039     1159     +120     

Flag	Coverage Δ
hudicli	39.55% <ø> (ø)
hudiclient	∅ <ø> (∅)
hudicommon	50.33% <ø> (+0.04%)	⬆️
hudiflink	63.26% <ø> (ø)
hudihadoopmr	51.43% <ø> (ø)
hudisparkdatasource	74.30% <ø> (ø)
hudisync	46.60% <ø> (ø)
huditimelineservice	64.65% <0.00%> (+0.28%)	⬆️
hudiutilities	70.83% <ø> (+61.55%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
...g/apache/hudi/timeline/service/RequestHandler.java	73.88% <0.00%> (+0.50%)	⬆️

... and 43 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[leesf]

hi, @chaplinthink I think it is necessary to use synchronization to sync view locally since the handler would handle different request from clients concurrently. cc @bvaradar

[chaplinthink]

I mean the implementation of view.sync(); already has WriteLock to handle multiple requests from clients concurrently @leesf

 try {
      writeLock.lock();
      runSync(oldTimeline, newTimeline);
    } finally {
      writeLock.unlock();
    }

[leesf]

@chaplinthink Thanks for the explanation, make sense to me. @vinothchandar @bvaradar do you have any other concern?

[vinothchandar]

I was mulling about the reloading of timeline that happens before the write lock.

@Override
  public void sync() {
    HoodieTimeline oldTimeline = getTimeline();
    HoodieTimeline newTimeline = metaClient.reloadActiveTimeline().filterCompletedAndCompactionInstants();
    try {
      writeLock.lock();
      runSync(oldTimeline, newTimeline);
    } finally {
      writeLock.unlock();
    }
  }

runSync() actually could init/reassign metaClient, so in theory removing synchornized could in theory make it non-serializable.

I would suggest that we either move the timeline reload into the write lock and leave this as-is. Whatever we change, we need to validate with more concurrent testing. So not sure if this is all worth the trouble.

Are you hitting real concurrency bottlenecks around this?

[chaplinthink]

Thanks a lot for reply. Do you mean the synchornized is to ensure HoodieTimeline newTimeline = metaClient.reloadActiveTimeline().filterCompletedAndCompactionInstants(); concurrently?

In fact, we are also to do this right ?

@Override
  public void sync() {
    HoodieTimeline oldTimeline = getTimeline();
    try {
      writeLock.lock();
      HoodieTimeline newTimeline = metaClient.reloadActiveTimeline().filterCompletedAndCompactionInstants();
      runSync(oldTimeline, newTimeline);
    } finally {
      writeLock.unlock();
    }
  }

I am confused when I see the code that we use synchornized and writeLock at the same time.

I agree to validate this with more concurrent testing. Currently i have not encountered concurrency bottlenecks.

[hudi-bot]

CI report:

• 2a77d2a Azure: FAILURE

Bot commands

@hudi-bot supports the following commands:

• @hudi-bot run azure re-run the last Azure build

[bvaradar]

@yihua : As you had fixed this issue in master, this PR can be closed. right ?

[yihua]

@yihua : As you had fixed this issue in master, this PR can be closed. right ?

Yes. @chaplinthink #8079 has simplified the synchronization with the fix to HoodieMetadataFileSystemView so this PR is no longer needed.