Skip to content

Code cleanup around Pollers #1070

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Merged
merged 1 commit into from
Mar 11, 2022

Conversation

Spikhalskiy
Copy link
Contributor

@Spikhalskiy Spikhalskiy commented Mar 11, 2022

Fix for potential pollers deadlock if suspendPolling called twice.
Refactorings that make the code around Polling easier to follow.

@@ -110,6 +110,7 @@ public ActivityTask poll() {
ProtobufTimeUtils.toM3Duration(
response.getStartedTime(), response.getCurrentAttemptScheduledTime()));
isSuccessful = true;
return new ActivityTask(response, pollSemaphore::release);
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Paired with

if (!isSuccessful) pollSemaphore.release();

in finally, this location of return is cleaner for the reader.

@@ -168,15 +168,18 @@ public void awaitTermination(long timeout, TimeUnit unit) {

@Override
public void suspendPolling() {
log.info("suspendPolling: {}", this);
suspendLatch.set(new CountDownLatch(1));
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Absense of CAS here may replace and lose the latch which is already used by Pollers to block on. This way they will never be unblocked if suspentPolling was called twice.

if (pollerOptions == null) {
pollerOptions =
PollerOptions.newBuilder()
.setPollBackoffInitialInterval(Duration.ofMillis(200))
Copy link
Contributor Author

@Spikhalskiy Spikhalskiy Mar 11, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This code path is dead. We come here only in some tests where we do

        SingleWorkerOptions.newBuilder().build()

and these options and not important for these tests. As a result, these magic values 200 and 20 here are never used and better be removed from the production code paths to don't mislead the reader.
After this cleanup, it's actually clear that we never call PollerOptions#setPollBackoffMaximumInterval anywhere.

@@ -181,7 +181,7 @@ private static SingleWorkerOptions toLocalActivityOptions(
List<ContextPropagator> contextPropagators,
Scope metricsScope) {
return toSingleWorkerOptions(factoryOptions, options, clientOptions, contextPropagators)
.setPollerOptions(PollerOptions.newBuilder().build())
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ActivityWorker and WorkflowWorker PollerOptions specify this parameter explicitly.
To simplify the untangling for the reader, let's specify it for LocalActivityWorker explicitly too. 1 is the default value for pollThreadCount used inside PollerOptions.

@Spikhalskiy Spikhalskiy merged commit e7bafae into temporalio:master Mar 11, 2022
@Spikhalskiy Spikhalskiy deleted the pollers-code-cleanup branch April 15, 2022 19:59
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants