Skip to content

HttpRemoteTaskRunner: Fix markLazyWorkers for maxLazyWorkers == 0.#14532

Merged
gianm merged 1 commit intoapache:masterfrom
gianm:hrtr-zero-workers
Jul 6, 2023
Merged

HttpRemoteTaskRunner: Fix markLazyWorkers for maxLazyWorkers == 0.#14532
gianm merged 1 commit intoapache:masterfrom
gianm:hrtr-zero-workers

Conversation

@gianm
Copy link
Copy Markdown
Contributor

@gianm gianm commented Jul 6, 2023

RemoteTaskRunner already handles this. Use a similar approach in HttpRemoteTaskRunner.

* @param maxLazyWorkers maximum number of lazy workers to return
*/
Collection<Worker> markWorkersLazy(Predicate<ImmutableWorkerInfo> isLazyWorker, int maxWorkers);
Collection<Worker> markWorkersLazy(Predicate<ImmutableWorkerInfo> isLazyWorker, int maxLazyWorkers);
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Nit: This method name is probably not accurate anymore, because it does not mark workers as lazy. It gets the list of workers which are lazy and are safe to terminate. So maybe getLazyWorkersToTerminate?

Suggested change
Collection<Worker> markWorkersLazy(Predicate<ImmutableWorkerInfo> isLazyWorker, int maxLazyWorkers);
Collection<Worker> getLazyWorkersToTerminate(Predicate<ImmutableWorkerInfo> isLazyWorker, int maxToTerminate);

Copy link
Copy Markdown
Contributor Author

@gianm gianm Jul 6, 2023

Choose a reason for hiding this comment

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

I agree the name is funny, but I didn't want to rename it since it's an interface method. I figured for interfaces that people might be using in extensions, best to retain existing signatures unless there is an important functional reason to change them.

Copy link
Copy Markdown
Contributor

@kfaraz kfaraz left a comment

Choose a reason for hiding this comment

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

Change looks good. Minor comment about method name.

@gianm
Copy link
Copy Markdown
Contributor Author

gianm commented Jul 6, 2023

The only failure is due to #14531, which is unrelated.

@gianm gianm merged commit 037f09b into apache:master Jul 6, 2023
@gianm gianm deleted the hrtr-zero-workers branch July 6, 2023 18:51
gianm added a commit to gianm/druid that referenced this pull request Jul 7, 2023
Recently apache#14532 fixed a problem when maxLazyWorkers == 0 and lazyWorkers
starts out empty. Unfortunately, even after that patch, there remained
a more general version of this problem when maxLazyWorkers == lazyWorkers.size().
This patch fixes it.

I'm not sure if this would actually happen in production, because the
provisioning strategies do try to avoid calling markWorkersLazy until
previously-initiated terminations have finished. Nevertheless, it still
seems like a good thing to fix.
gianm added a commit that referenced this pull request Jul 7, 2023
…4545)

Recently #14532 fixed a problem when maxLazyWorkers == 0 and lazyWorkers
starts out empty. Unfortunately, even after that patch, there remained
a more general version of this problem when maxLazyWorkers == lazyWorkers.size().
This patch fixes it.

I'm not sure if this would actually happen in production, because the
provisioning strategies do try to avoid calling markWorkersLazy until
previously-initiated terminations have finished. Nevertheless, it still
seems like a good thing to fix.
@abhishekagarwal87 abhishekagarwal87 added this to the 27.0 milestone Jul 19, 2023
sergioferragut pushed a commit to sergioferragut/druid that referenced this pull request Jul 21, 2023
sergioferragut pushed a commit to sergioferragut/druid that referenced this pull request Jul 21, 2023
…ache#14545)

Recently apache#14532 fixed a problem when maxLazyWorkers == 0 and lazyWorkers
starts out empty. Unfortunately, even after that patch, there remained
a more general version of this problem when maxLazyWorkers == lazyWorkers.size().
This patch fixes it.

I'm not sure if this would actually happen in production, because the
provisioning strategies do try to avoid calling markWorkersLazy until
previously-initiated terminations have finished. Nevertheless, it still
seems like a good thing to fix.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants