Skip to content
This repository has been archived by the owner on Jul 23, 2024. It is now read-only.

Improve waiting strategy for Integration tests - cont #409

Merged
merged 3 commits into from
Jun 8, 2023

Conversation

masayag
Copy link
Collaborator

@masayag masayag commented Jun 7, 2023

What this PR does / why we need it:
The PR replaces the former busy-wait implementation with a scheduled executor service.
With this implementation, a scheduled service will try invoking the given callback (for querying projects or waiting on a specific workflow status) for up to 2 minutes.

The PR also modifies the notification service integration tests to use the same RetryExecutorService class for waiting on the notification service to become available.

Which issue(s) this PR fixes (optional, use fixes #<issue_number>(, fixes #<issue_number>, ...) format, where issue_number might be a GitHub issue, or a Jira story (FLPATH-xxxx):
Fixes #FLPATH-399

Change type

  • New feature
  • Bug fix
  • Unit tests
  • Integration tests
  • CI
  • Documentation
  • Auto-generated SDK code

Impacted services

  • Workflow Service
  • Notification Service

Checklist

  • Subject and description added to both, commit and PR.
  • Relevant issues have been referenced.

Copy link
Collaborator

@pkliczewski pkliczewski left a comment

Choose a reason for hiding this comment

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

/lgtm

Comment on lines +47 to 54
if (System.currentTimeMillis() >= endTime) {
future.completeExceptionally(new TimeoutException("Retry limit reached."));
return;
}
Copy link
Contributor

Choose a reason for hiding this comment

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

Set a timeout in future.get() (i.e. future.get(endTime, TimeUnit.MILLISECONDS); does it have equivalent behavior to this block of code?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

No, setting a timeout using future.get(endTime, TimeUnit.MILLISECONDS) does not provide an equivalent behavior to the previous block of code in the RetryExecutorService.

The future.get(endTime, TimeUnit.MILLISECONDS) method call sets a timeout for waiting to retrieve the result from the future. If the result is not available within the specified timeout period, a TimeoutException will be thrown. However, it does not cancel the ongoing execution of the task or stop further retry attempts.

The PR replaces the former busy-wait implementation with
a scheduled executor service.
With this implementation, a scheduled service will try
invoking the given callback (for querying projects or
waiting on a specific workflow status) for up to 2 minutes.

Signed-off-by: Moti Asayag <masayag@redhat.com>
The PR modifies the notification service integration tests to use the
same RetryExecutorService class for waiting on the notification service
to become available.

Signed-off-by: Moti Asayag <masayag@redhat.com>
Signed-off-by: Moti Asayag <masayag@redhat.com>
@@ -24,7 +28,7 @@ public RetryExecutorService() {
*/
public T submitWithRetry(Callable<T> task) {
// @formatter:off
return submitWithRetry(task, () -> {}, () -> {}, 2 * 60 * 1000, 5000);
return submitWithRetry(task, () -> {}, () -> {}, MAX_RETRY_TIME, RETRY_DELAY);
Copy link
Contributor

Choose a reason for hiding this comment

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

I like this (and the commit message ;) )

@gciavarrini
Copy link
Contributor

/lgtm
/approve

@openshift-ci
Copy link

openshift-ci bot commented Jun 8, 2023

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: gciavarrini

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@openshift-ci openshift-ci bot added the approved label Jun 8, 2023
@openshift-merge-robot openshift-merge-robot merged commit bbb1307 into parodos-dev:main Jun 8, 2023
Future<T> future = executor.submit(() -> {
long startTime = System.currentTimeMillis();
long endTime = startTime + maxRetryTime;
CompletableFuture<T> future = new CompletableFuture<>();
Copy link
Contributor

Choose a reason for hiding this comment

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

why is this future here needed?

Copy link
Collaborator Author

@masayag masayag Jun 8, 2023

Choose a reason for hiding this comment

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

it stores the result and is used as a reference to its success or failure.
there are 2 "futures" here: one is responsible for the retries which are the scheduledFuture.
the other one is used to report the result in line 67.
would you suggest a different method of doing it?

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants