Abacn commented on code in PR #36750:
URL: https://github.com/apache/beam/pull/36750#discussion_r2550360052
##########
sdks/java/core/src/main/java/org/apache/beam/sdk/fn/splittabledofn/RestrictionTrackers.java:
##########
@@ -101,8 +138,33 @@ protected RestrictionTrackerObserverWithProgress(
}
@Override
- public synchronized Progress getProgress() {
- return ((HasProgress) delegate).getProgress();
+ public Progress getProgress() {
+ return getProgress(FIRST_PROGRESS_TIMEOUT_SEC);
+ }
+
+ @VisibleForTesting
+ Progress getProgress(int timeOutSec) {
+ if (!hasInitialProgress) {
+ Progress progress = Progress.NONE;
+ try {
+ // lock can be held long by long-running tryClaim/trySplit. We
tolerate this scenario
Review Comment:
> if we're just trying to avoid blocking on the initial tryClaim
Yeah tryClaim blocking progress is current symptom, however I would prefer a
fix not depend on this as an assumption (i.e. whether the fix relies on timing
of caller to work). Otherwise there is risk when upstream/current class changed
the issue may recur.
Current approach `hasInitialProgress` state is only accessed within
getProgress() and more robust to changes
--
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]
