selenium icon indicating copy to clipboard operation
selenium copied to clipboard

[🚀 Feature]: use one `java.net.http.HttpClient` in JdkHttpClient

Open joerg1985 opened this issue 2 years ago • 3 comments

Feature and motivation

There were complains about the slow cleanup of the threads created by the JdkHttpClient. To fix this we registered a custom executor and shut it down, what caused other issues when there are still pending responses.

I would suggest to still call HttpClientFactory.createDefaut and return new JdkHttpClient instances, but they should all use the same java.net.http.HttpClient and not close it after use, only drop the reference. Further calls to a closed JdkHttpClient could raise a speaking Exception rather than just using the dead HttpClient and waiting for the timeout that will be raised in this case.

Usage example

Less threads are created, instances are faster ready to perform requests. Allready closed instances instantly fail with a speaking exception.

There might be side effects as this change will allow connection reuse between sessions of one java process to the same selenium server. I think this should not make any problems, but it might be possible.

joerg1985 avatar Sep 23 '23 16:09 joerg1985

@joerg1985, thank you for creating this issue. We will troubleshoot it as soon as we can.


Info for maintainers

Triage this issue by using labels.

If information is missing, add a helpful comment and then I-issue-template label.

If the issue is a question, add the I-question label.

If the issue is valid but there is no time to troubleshoot it, consider adding the help wanted label.

If the issue requires changes or fixes from an external project (e.g., ChromeDriver, GeckoDriver, MSEdgeDriver, W3C), add the applicable G-* label, and it will provide the correct link and auto-close the issue.

After troubleshooting the issue, please add the R-awaiting answer label.

Thank you!

github-actions[bot] avatar Sep 23 '23 16:09 github-actions[bot]

Info for those who "complains about the slow cleanup of the threads created by the JdkHttpClient". Try run it with JDK 21. It solved the issue in my case. I have a custom mulithread test framework build on Selenium 4.15 and compiled to Java 11. Running on Java 21.0.1 (backward compatibility) extensive SOAK tests (over 48 hours) on Ubuntu 20 AWS r5.2xlarge instance, showed garbage collector works perfectly. Total application threads oscillates up to ~2K (http threads 50-700). On JDK 11 or 17 it throws OutOfMemory in a few hours.

P.S. the issue is related to JDK bug https://bugs.openjdk.org/browse/JDK-8308364 so you may also try implement in Selenium a workaround descibed there.

piotrbo avatar Nov 23 '23 09:11 piotrbo

This issue is stale because it has been open 280 days with no activity. Remove stale label or comment or this will be closed in 14 days.

github-actions[bot] avatar Oct 06 '24 20:10 github-actions[bot]

This issue was closed because it has been stalled for 14 days with no activity.

github-actions[bot] avatar Oct 21 '24 10:10 github-actions[bot]

This issue has been automatically locked since there has not been any recent activity since it was closed. Please open a new issue for related bugs.

github-actions[bot] avatar Nov 20 '24 22:11 github-actions[bot]