Add withExecutor to FluentWait to support concurrent drivers in custom thread pools

[bjuric]

Description

FluentWait blocked and behaved unpredictably when called concurrently from multiple web driver threads executing in a custom thread pool. This commit adds the ability to pass the Executor service that manages the thread pool to fluent wait.

Sample usage

  // pass custom executor to fluent wait
  new FluentWait(driver)
      .withTimeout(Duration.ofSeconds(10))
      .withExecutor(myCustomExecutor)
      ..

Motivation and Context

Many tools and frameworks built on Selenium offer options for running multiple web driver instances in parallel threads. Fluent wait can block and behave unpredictabily under some conditions where concurrent calls are made by threads in custom Executors. In such instances, it becomes necessary to use the custom Executor with FluentWait's underlying CompletableFuture.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist

• I have read the contributing document.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have added tests to cover my changes.
• All new and existing tests passed.

[CLAassistant]

All committers have signed the CLA.

[bjuric]

It's worth noting that launching Selenium with the following Java system property forces the CompletableFuture in FluentWait to run on the calling thread.

java.util.concurrent.ForkJoinPool.common.parallelism=0

There's no need to explicitly set the executor if you specify this property. This solves the concurrency issue with thread contention but also affects all instances where CompletableFutures are used throughout Selenium in that they would no longer run on separate threads. In some cases however, this might be a viable alternative to the withExecutor approach introduced in this PR. I guess it's good to have options.

[thegoldgoat]

Hello, not an expert here

This is related to #8727 isn't it?

[bjuric]

@thegoldgoat I think that one has the same underlying issue. I believe it to be a systemic issue in that CompleteableFutures are used throughout Selenium 4, and not just in FluentWait.

[thegoldgoat]

Thanks for the response!

Again, not an expert of this codebase

Is this PR ready to be tested by any chance?

Should I change something in my code?

Thanks again!

[bjuric]

@thegoldgoat try launching your app with the jvm option in my earlier comment above and use a custom thread pool. See also #8525

[thegoldgoat]

Great! Thanks a lot I'll let you know if that works

[thegoldgoat]

Hi, sorry for the late response.

Using that options everything works, thanks a lot!!

I hope the devs would investigate in this bug and consider your solution

[chrisgleissner]

What is blocking this PR from being merged?

[barancev]

We discuss the current implementation. And tend to revert back to legacy (blocking) implementation.

[barancev]

Sorry to say this, but we decided to return back to the legacy (blocking) implementation after clients' complains. It appears that many people use suboptimal approach to manage WebDriver instances using ThreadLocal variables. And running conditions in a separate thread makes them lose their driver. So we decided to revert this change in favour of backward compatibility.