[🐛 Bug]: Memory leak running hub, due to HttpClient-x-SelectorManager threads never closed #13246

bhecquet · 2023-12-05T10:22:37Z

What happened?

Hello

On our hub (version 4.15.0, JDK 11.0.20), running 13 nodes, memory increase continuously as tests run. Attaching a VisualVM shows that it seems to be caused by an increasing number of HttpClient-x-SelectorManager threads that are not closed (seems similar to #12206 or #11336)

Operations are normal, except when max memory is reached. In this case, hub does not respond anymore

In the graphic above, you can see that 300 more threads have been created in an hour

Is there a way (to help) to track down the creator of the staled threads ? Thread dump doesn't help much


"HttpClient-111-SelectorManager" - Thread t@756
   java.lang.Thread.State: RUNNABLE
        at [email protected]/sun.nio.ch.WindowsSelectorImpl$SubSelector.poll0(Native Method)
        at [email protected]/sun.nio.ch.WindowsSelectorImpl$SubSelector.poll(WindowsSelectorImpl.java:357)
        at [email protected]/sun.nio.ch.WindowsSelectorImpl.doSelect(WindowsSelectorImpl.java:182)
        at [email protected]/sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:124)
        - locked <2eebf6a6> (a sun.nio.ch.Util$2)
        - locked <4a436b2f> (a sun.nio.ch.WindowsSelectorImpl)
        at [email protected]/sun.nio.ch.SelectorImpl.select(SelectorImpl.java:136)
        at platform/[email protected]/jdk.internal.net.http.HttpClientImpl$SelectorManager.run(HttpClientImpl.java:867)

   Locked ownable synchronizers:
        - None

Thanks

How can we reproduce the issue?

Start a hub
Start some nodes
Execute many tests. I think the more tests are run, the easier it's to point the issue

Relevant log output

no relevant logs available on hub

Operating System

Windows / Linux

Selenium version

4.11.0

What are the browser(s) and version(s) where you see this issue?

any browser

What are the browser driver(s) and version(s) where you see this issue?

any browser

Are you using Selenium Grid?

4.15.0

The text was updated successfully, but these errors were encountered:

github-actions · 2023-12-05T10:22:54Z

@bhecquet, 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!

diemol · 2023-12-05T10:27:49Z

@pujagani didn't you troubleshoot this already in another issue?

bhecquet · 2023-12-05T11:20:05Z

I did a memory dump. Put in Eclipse Memory Analyzer:

joerg1985 · 2023-12-05T16:37:42Z

I just have pushed a commit cdbe9c6 that might point into the direction why there are idling websocket. There was a misunderstanding in what cases the onError is called in the client, that the websocket could deliver any further messages. But when it is called the websocket is broken beyond repair and will not deliver any further messages.

bhecquet · 2023-12-05T16:41:50Z

We've analyzed the code in JdkHttpClient.java and the memory dump and we thought the problem might also be in the close method, where "websockets" list is not cleared, which could lead to references being kept
What do you think about that ?

pujagani · 2023-12-06T05:01:32Z

@pujagani didn't you troubleshoot this already in another issue?

The other issue was also related to a leak but that was pertaining to a leak happening in only a particular Java version. I have handled a similar one via #11345 earlier. But I think @joerg1985 has an idea for this one. If not, I am happy to take a look.

joerg1985 · 2023-12-06T11:49:29Z

@bhecquet the reference to the HttpClient should be dropped after some time, so this list should not be an issue.
Could you retest with selenium 4.16.0?

bhecquet · 2023-12-06T16:26:26Z

Hello, I just tested the 4.16.0 version, and I observe the same behaviour as with 4.15.0

joerg1985 · 2023-12-06T16:41:09Z

Okay one thing that should be checked, we have chain like this:

Client <---- WS ----> Grid <---- WS ----> Node <----- WS ------> Driver

Now the Driver does raise an error on the Websocket

Client <---- WS ----> Grid <---- WS ----> Node * disconnected * Driver

I don't think the other connections are also disconnected in this case.
To have an error from the driver site is alarming easy, this code will provoke it on my system:

var options = new ChromeOptions();        
options.setCapability("webSocketUrl", true); // <- bidi must be enabled to run into errors of the devtools connection
var driver = new ChromeDriver(options);

driver.close(); // <- runs into onError of the devtools connection, not the bidi connection
driver.quit();

@pujagani would you like to check this or should i give it a try at a undefined point in the future?
I think the fix for this would be to send a close message to the maybeHandler inside the WebSocketUpgradeHandler.exceptionCaught call, but this is more a educated guess.

pujagani · 2023-12-07T05:46:22Z

I can check this in a day or two. I am happy to help, though you are the expert in this area. I might ask questions as and when I need the guidance.

pujagani · 2023-12-12T08:53:05Z

I was able to reproduce the issue with Java 11 at a small scale but what I see is leftover SelectorManager threads. I am looking into triaging it further. The same does not occur with Java 21 since HttpClient implements AutoCloseable.
I am unable to see WebSocketImpl instances while profiling through. Are you running tests that use CDP heavily? @bhecquet

pujagani · 2023-12-15T07:41:43Z

Okay one thing that should be checked, we have chain like this:

Client <---- WS ----> Grid <---- WS ----> Node <----- WS ------> Driver

Now the Driver does raise an error on the Websocket

Client <---- WS ----> Grid <---- WS ----> Node * disconnected * Driver

I don't think the other connections are also disconnected in this case. To have an error from the driver site is alarming easy, this code will provoke it on my system:
var options = new ChromeOptions();        
options.setCapability("webSocketUrl", true); // <- bidi must be enabled to run into errors of the devtools connection
var driver = new ChromeDriver(options);

driver.close(); // <- runs into onError of the devtools connection, not the bidi connection
driver.quit();
@pujagani would you like to check this or should i give it a try at a undefined point in the future? I think the fix for this would be to send a close message to the maybeHandler inside the WebSocketUpgradeHandler.exceptionCaught call, but this is more a educated guess.

I am not able to run into the error in the above example. This issue does not mention leak due to errors, though I partially understand the thought process regarding it being related to CDP, but I don't fully understand your concern here. Can you help me understand please?

pujagani · 2023-12-15T08:50:11Z

I have tried running a CDP example with one hub and 5 nodes :

                  Augmenter augmenter = new Augmenter();
                  driver = augmenter.augment(driver);
                  DevTools devTools = ((HasDevTools) driver).getDevTools();
                  devTools.createSession();

                  ((HasAuthentication) driver).register(UsernameAndPassword.of("admin", "admin"));
                  driver.get("https://the-internet.herokuapp.com/basic_auth");
                  System.out.println(driver.findElement(By.tagName("p")).getText());
                  driver.quit();

I ran about 500 tests and cannot see a leak-like pattern. I am sharing my findings below.

pujagani · 2023-12-15T08:58:33Z

@bhecquet Can you help share the tests that you run or the nature of the tests? Do you run a lot of CDP or BiDi tests? I would appreciate a reproducible code script to triage this further.

bhecquet · 2023-12-15T10:28:50Z

Hello @pujagani , I will try to provide you a minimal test that reproduce the problem

joerg1985 · 2023-12-15T10:38:14Z

Running the code of #13316 in a loop does leak threads for me and also log's warnings:

11:20:32.724 WARN [DefaultChannelPipeline.onUnhandledInboundException] - An exceptionCaught() event was fired, and it reached at the tail of the pipeline. It usually means the last handler in the pipeline did not handle the exception.
org.openqa.selenium.WebDriverException: java.io.IOException: Output closed
Build info: version: '4.16.1', revision: '9b4c83354e'
System info: os.name: 'Windows 10', os.arch: 'amd64', os.version: '10.0', java.version: '21.0.1'
Driver info: driver.version: unknown
        at org.openqa.selenium.remote.http.jdk.JdkHttpClient$5.send(JdkHttpClient.java:304)
        at org.openqa.selenium.netty.server.WebSocketMessageHandler.lambda$channelRead0$0(WebSocketMessageHandler.java:47)
        at io.netty.util.concurrent.AbstractEventExecutor.runTask(AbstractEventExecutor.java:173)
        at io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:166)
        at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:470)
        at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:566)
        at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:997)
        at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
        at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
        at java.base/java.lang.Thread.run(Thread.java:1583)
Caused by: java.io.IOException: Output closed
        at java.net.http/jdk.internal.net.http.websocket.MessageEncoder.encodeText(MessageEncoder.java:145)
        at java.net.http/jdk.internal.net.http.websocket.TransportImpl$SendTask$1.onText(TransportImpl.java:376)
        at java.net.http/jdk.internal.net.http.websocket.TransportImpl$SendTask$1.onText(TransportImpl.java:367)
        at java.net.http/jdk.internal.net.http.websocket.MessageQueue.peek(MessageQueue.java:223)
        at java.net.http/jdk.internal.net.http.websocket.TransportImpl$SendTask.run(TransportImpl.java:555)
        at java.net.http/jdk.internal.net.http.common.SequentialScheduler$CompleteRestartableTask.run(SequentialScheduler.java:149)
        at java.net.http/jdk.internal.net.http.common.SequentialScheduler$SchedulableTask.run(SequentialScheduler.java:207)
        at java.net.http/jdk.internal.net.http.common.SequentialScheduler.runOrSchedule(SequentialScheduler.java:280)
        at java.net.http/jdk.internal.net.http.common.SequentialScheduler.runOrSchedule(SequentialScheduler.java:233)
        at java.net.http/jdk.internal.net.http.websocket.TransportImpl.sendText(TransportImpl.java:149)
        at java.net.http/jdk.internal.net.http.websocket.WebSocketImpl.sendText(WebSocketImpl.java:192)
        at org.openqa.selenium.remote.http.jdk.JdkHttpClient$5.lambda$send$1(JdkHttpClient.java:271)
        at org.openqa.selenium.remote.http.jdk.JdkHttpClient$5.send(JdkHttpClient.java:294)
        ... 9 more

The red line is where is stopped the client from starting new sessions.
Triggering the GC did not help to stop these threads.

pujagani · 2023-12-15T10:49:22Z

Thank you! But that is an error situation which involves enabling BiDi and using CDP. I agree that needs to be solved too. But I understand the issue here is mainly that threads are leaking when tests are running without any errors or I will know better once the example is shared.

bhecquet · 2023-12-15T17:18:26Z

I've a strange behavior when trying to reproduce the thread leak problem on my setup.
Sometimes, 2 threads (HttpClient-xx-SelectorManager) are created, and sometimes only once.
At least, I see the thread creation on driver augmenting, but in case 2 threads are created, the second seems to be created before driver is augmented.
Do you have an idea about what's happening ?

Moreover, I notice (it may be expected behaviour), that thread created when augmenting driver may wait 5 to terminate, after test ends

joerg1985 · 2023-12-15T17:34:35Z

This should be the one for the CdpEndpointFinder to get the websocket url of the DevTools, before the driver is created.

bhecquet · 2023-12-19T08:00:59Z

Hello,

I managed to reproduce the problem with limited setup:
1 hub, 1 node and the following code

package org.example;

import org.openqa.selenium.WebDriver;
import org.openqa.selenium.WebElement;
import org.openqa.selenium.chrome.ChromeOptions;
import org.openqa.selenium.devtools.DevTools;
import org.openqa.selenium.devtools.HasDevTools;
import org.openqa.selenium.devtools.v115.page.Page;
import org.openqa.selenium.devtools.v115.page.model.Viewport;
import org.openqa.selenium.remote.Augmenter;
import org.openqa.selenium.remote.DesiredCapabilities;
import org.openqa.selenium.remote.RemoteWebDriver;
import org.openqa.selenium.support.events.EventFiringDecorator;
import org.openqa.selenium.support.events.WebDriverListener;

import javax.imageio.ImageIO;
import java.awt.image.BufferedImage;
import java.io.ByteArrayInputStream;
import java.io.IOException;
import java.io.InputStream;
import java.lang.reflect.InvocationTargetException;
import java.lang.reflect.Method;
import java.net.URL;
import java.util.Optional;


public class Main {
    public static void main(String[] args) throws IOException, InterruptedException {
        for (int i = 0; i < 1; i++) {
            DesiredCapabilities capabilities = new DesiredCapabilities();
            ChromeOptions options = new ChromeOptions();

            WebDriver driver = new RemoteWebDriver(new URL("http://localhost:4444/wd/hub"), options);
            Thread.sleep(2000);
            driver = new EventFiringDecorator<>(new DriverExceptionListener(driver)).decorate(driver);
            driver = new Augmenter().augment(driver);
            driver.get("https://www.selenium.dev");
            BufferedImage image = captureWebPageUsingCDP(driver, driver.getWindowHandle());
            System.out.println(image.getHeight());
            driver.quit();
        }
    }

    public static BufferedImage captureWebPageUsingCDP(WebDriver driver, String windowHandle) throws IOException {

        DevTools devTools = ((HasDevTools) driver).getDevTools();

        devTools.createSession(windowHandle);
        try {
            Page.GetLayoutMetricsResponse layout = devTools.send(Page.getLayoutMetrics());
            String b64Image = devTools.send(Page.captureScreenshot(Optional.of(Page.CaptureScreenshotFormat.PNG), Optional.of(100), Optional.of(new Viewport(0, 0, layout.getCssContentSize().getWidth(), layout.getCssContentSize().getHeight(), 1)), Optional.of(true), Optional.of(true), Optional.of(true)));
            return loadFromB64String(b64Image);
        } finally {
            devTools.disconnectSession();
        }
    }

    public static BufferedImage loadFromB64String(String b64String) throws IOException {
        byte[] byteArray = b64String.getBytes();
        byte[] decodeBuffer = org.apache.commons.codec.binary.Base64.decodeBase64(byteArray);
        InputStream in = new ByteArrayInputStream(decodeBuffer);
        return ImageIO.read(in);
    }


    public static class DriverExceptionListener implements WebDriverListener {

        private WebDriver driver;

        public DriverExceptionListener(WebDriver driver) {
            this.driver = driver;
        }

        @Override
        public void beforeClick(WebElement arg0) {
        }

        @Override
        public void onError(Object target, Method method, Object[] args, InvocationTargetException e) {

            System.out.println("some error");
        }
    }
}

The key point seems to be the EventFiringDecorator
With it, threads remain for very long time (> 30 mins), and without, they are stopped after up to 11 mins (which in my opinion is still quite long 😄 )

I don't know if it's related but, on the node, when session stop, I get the following message:

08:42:57.967 INFO [ProxyNodeWebsockets.createWsEndPoint] - Establishing connection to ws://localhost:61152/devtools/browser/a8ae435c-61c8-468a-b6ee-31cd549d25f5
08:43:00.436 WARN [ProxyNodeWebsockets$ForwardingListener.onError] - Error proxying websocket command
java.io.IOException: Une connexion existante a d¹ Ûtre fermÚe par lÆh¶te distant
        at java.base/sun.nio.ch.SocketDispatcher.read0(Native Method)
        at java.base/sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:43)
        at java.base/sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:276)
        at java.base/sun.nio.ch.IOUtil.read(IOUtil.java:245)
        at java.base/sun.nio.ch.IOUtil.read(IOUtil.java:223)
        at java.base/sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:356)
        at java.net.http/jdk.internal.net.http.SocketTube.readAvailable(SocketTube.java:1153)
        at java.net.http/jdk.internal.net.http.SocketTube$InternalReadPublisher$InternalReadSubscription.read(SocketTube.java:821)
        at java.net.http/jdk.internal.net.http.SocketTube$SocketFlowTask.run(SocketTube.java:175)
        at java.net.http/jdk.internal.net.http.common.SequentialScheduler$SchedulableTask.run(SequentialScheduler.java:198)
        at java.net.http/jdk.internal.net.http.common.SequentialScheduler.runOrSchedule(SequentialScheduler.java:271)
        at java.net.http/jdk.internal.net.http.common.SequentialScheduler.runOrSchedule(SequentialScheduler.java:224)
        at java.net.http/jdk.internal.net.http.SocketTube$InternalReadPublisher$InternalReadSubscription.signalReadable(SocketTube.java:763)
        at java.net.http/jdk.internal.net.http.SocketTube$InternalReadPublisher$ReadEvent.signalEvent(SocketTube.java:941)
        at java.net.http/jdk.internal.net.http.SocketTube$SocketFlowEvent.handle(SocketTube.java:245)
        at java.net.http/jdk.internal.net.http.HttpClientImpl$SelectorManager.handleEvent(HttpClientImpl.java:957)
        at java.net.http/jdk.internal.net.http.HttpClientImpl$SelectorManager.lambda$run$3(HttpClientImpl.java:912)
        at java.base/java.util.ArrayList.forEach(ArrayList.java:1541)
        at java.net.http/jdk.internal.net.http.HttpClientImpl$SelectorManager.run(HttpClientImpl.java:912)
08:43:00.524 INFO [SessionSlot.stop] - Stopping session 6f6ab2d437e139e3bcf3611f09936cb8

pujagani · 2023-12-19T09:48:44Z

@bhecquet Thank you so much. This is what I was looking for. Let me try and reproduce it and take it from there. I am going to slim down the example further to identify the pain point.

pujagani · 2023-12-19T14:22:44Z

"With it, threads remain for very long time (> 30 mins), and without, they are stopped after up to 11 mins (which in my opinion is still quite long 😄 )" @bhecquet Can you help me understand this? Which threads are these? On the client side or hub side?

bhecquet · 2023-12-19T14:39:27Z

I was talking about the "HttpClient-xx-SelectorManager" threads on hub

pujagani · 2023-12-20T05:59:26Z

I can reproduce the leak and I now see the pattern mentioned above. Thank you for sharing the details.

pujagani · 2023-12-20T13:20:47Z

One observation here, if we augment the driver first and then use the decorator then the leak does not happen. Sharing the code snippet below:

  for (int i = 0; i < 500; i++) {
            ChromeOptions options = new ChromeOptions();

            WebDriver driver = new RemoteWebDriver(new URL("http://localhost:4444/wd/hub"), options, false);
            Thread.sleep(2000);
            driver = new Augmenter().augment(driver);
            driver = new EventFiringDecorator<>(new DriverExceptionListener(driver)).decorate(driver);
            driver.get("https://www.selenium.dev");
            BufferedImage image = captureWebPageUsingCDP(driver, driver.getWindowHandle());
            System.out.println(image.getHeight());
            driver.quit();
        }
    }

Using one hub and one node. Sharing the thread status of the Hub below:

I am trying to look into this further.

pujagani · 2023-12-21T05:49:00Z

@bhecquet Can you try the above suggestion and see if that helps?

bhecquet · 2023-12-21T08:26:00Z

@pujagani : thanks for the tip, it seems to work around the problem but I won't be able to test at scale in the next days (it's holiday time now 😋 )

pujagani · 2023-12-21T09:15:20Z

No rush, I understand. Please update here whenever you get a chance.

titusfortner · 2023-12-31T20:24:00Z

@pujagani do we need to figure this out, regardless? Would it make sense just not to allow passing in a decorated driver to the augmenter?

bhecquet · 2023-12-31T20:48:56Z

Hello @titusfortner,
My opinion is that if this happens in this case, there is something wrong somewhere in thread handling (easy to say, hard to find), and there is probably other cases we didn't notice yet

But it's only an opinion 😃

pujagani · 2024-01-09T05:05:08Z

"if we augment the driver first and then use the decorator then the leak does not happen", I think the combination of Augmenter and decorator might be preventing some calls to close method. We might not have to do anything here but mainly I need to find a logical reason to recommend to augment first and then decorate.

pujagani · 2024-01-11T12:01:48Z

I have revisited it, and there is absolutely no problem in handling the threads.
Logically it makes sense to Augment first and then decorate. I would like to explain why Augmenting a decorator does not work.
Keep in mind: When we call quit(), it checks if the current instance is an instance of HasDevTools, only then it closes the underlying web socket.

The case that does not work (reason in comments):

           WebDriver driver = new RemoteWebDriver(new URL("http://localhost:4444/wd/hub"), options, false);
           
          // Uses the driver we pass to run commands. So a RemoteWebDriver without HasDevTools implementation
          driver = new EventFiringDecorator<>(new DriverExceptionListener(driver)).decorate(driver);
           driver.get("https://www.selenium.dev");
           // Adds the HasDevTools implementation to support CDP
           driver = new Augmenter().augment(driver);

           BufferedImage image = captureWebPageUsingCDP(driver, driver.getWindowHandle());
           System.out.println(image.getHeight());

           // Underlying driver that decorator uses to call commands in this case the RemoteWebDriver without HasDevTools
           // Hence, the close method for closing the CDP websocket is not called, reason for leftover threads.
           driver.quit();

The case that works (reason in comments):

            WebDriver driver = new RemoteWebDriver(new URL("http://localhost:4444/wd/hub"), options, false);
            Thread.sleep(2000);
            // Augmenting a RemoteWebdriver with HasDevTools implementation
            driver = new Augmenter().augment(driver);
            // Using the augmented driver with HasDevTools to creat a decorated driver
            driver = new EventFiringDecorator<>(new DriverExceptionListener(driver)).decorate(driver);
            driver.get("https://www.selenium.dev");
            BufferedImage image = captureWebPageUsingCDP(driver, driver.getWindowHandle());
            System.out.println(image.getHeight());
            // The decorated driver will call methods using the augmented driver which is an instance of HasDevTools
            // Hence, it closes the underlying sockets and frees up resources as expected.
            driver.quit();

I am trying to see if I can fix this in a meaningful manner else might have to go with Titus's suggestion.

Related to #13246

pujagani · 2024-01-12T08:25:39Z

I think the best option is to not allow passing in decorated drivers to the Augmenter.
For 2 reasons:

If we try to muck around with Augmenter to change the reference that the passed decorated driver holds, that doesn't feel right. Augmenter should only augment and not update anything.
Users can have their own WebDriver implementations or own Augmentable interfaces and we will not be able to identify all unexpected behaviors that can potentially creep in.

I have added a warning for this currently since not allowing that immediately might cause breaking changes for the users.
After waiting for minimum 2 versions (the rule of thumb in Selenium), we can use Require.precondition in our codebase to not allow passing in the decorated driver along with the explanation for the same.

@bhecquet I would recommend updating your codebase to decorate an augmented driver. Since that is the long term plan.

Note: This will not be a problem when we move to BiDi completely and port all commands to it. The Java porting POC for BiDi demonstrates that Augmenter will not be needed.

bhecquet · 2024-01-13T15:14:51Z

Thanks a lot @pujagani for the analysis
I've already updated my code accordingly

Regards

JmerAuchan · 2024-03-21T16:01:03Z

Hi,

Does this issue is fixed on last official release?

We use 4.15.0 and we have the issue on node on different machines .. They are unplugged on the grid after some hours with this message :

java.io.IOException: Too many open files

IlyaUk · 2024-06-21T07:17:01Z

Hi @pujagani,
May I ask you please to clarify whether the issue with memory leaks were fixed or not?
We're using 4.21 and after some test runs the nodes become unreacheble:
Stopping driver service: Could not start a new session. Response code 500. Message: chrome not reachable. at org.openqa.selenium.grid.node.remote.RemoteNode.newSession([RemoteNode.java:157](http://remotenode.java:157/)) at org.openqa.selenium.grid.distributor.local.LocalDistributor.startSession([LocalDistributor.java:652](http://localdistributor.java:652/)) at org.openqa.selenium.grid.distributor.local.LocalDistributor.newSession([LocalDistributor.java:571](http://localdistributor.java:571/)) at org.openqa.selenium.grid.distributor.local.LocalDistributor$NewSessionRunnable.handleNewSessionRequest([LocalDistributor.java:831](http://localdistributor.java:831/)) at org.openqa.selenium.grid.distributor.local.LocalDistributor$NewSessionRunnable.lambda$run$1([LocalDistributor.java:791](http://localdistributor.java:791/)) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) at java.base/java.util.concurrent.ThreadPoolExecutor$[Worker.run](http://worker.run/)(Unknown Source) at java.base/[java.lang.Thread.run](http://java.lang.thread.run/)(Unknown Source)

pujagani · 2024-06-21T09:03:37Z

@IlyaUk Hey! So the issue reported here was reproduced under the circumstance of using Decorator and Augmenter together. The leak was not reproduced as expected so there was no fix that went in. Can you create another issue with the exact problem you are facing with details of how we can reproduce it? I can help take a look if I can reproduce it.

github-actions · 2024-07-05T20:19:57Z

This issue was closed because we did not receive any additional information after 14 days.

github-actions · 2024-08-04T22:48:44Z

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.

bhecquet added I-defect Something is not working as intended A-needs-triaging A Selenium member will evaluate this soon! labels Dec 5, 2023

diemol added B-grid Everything grid and server related and removed A-needs-triaging A Selenium member will evaluate this soon! labels Dec 5, 2023

pujagani mentioned this issue Dec 15, 2023

[java] Close http connection for RemoteNode #13313

Merged

8 tasks

bhecquet added a commit to bhecquet/seleniumRobot that referenced this issue Dec 21, 2023

work around SeleniumHQ/selenium#13246

a49ccc1

bhecquet added a commit to bhecquet/seleniumRobot that referenced this issue Dec 21, 2023

workaround SeleniumHQ/selenium#13246

6c2af66

pujagani added a commit that referenced this issue Jan 12, 2024

[java] Add a warning while passing a decorated driver to augmenter

4350eb1

Related to #13246

titusfortner added the J-awaiting answer Question asked of user; a reply moves it to triage again label Jun 21, 2024

github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale Jul 5, 2024

joerg1985 mentioned this issue Jul 6, 2024

Java selenium threads are not getting destroyed on driver.quit #14223

Closed

github-actions bot locked and limited conversation to collaborators Aug 4, 2024

Uh oh!

[🐛 Bug]: Memory leak running hub, due to HttpClient-x-SelectorManager threads never closed #13246

[🐛 Bug]: Memory leak running hub, due to HttpClient-x-SelectorManager threads never closed #13246

Comments

bhecquet commented Dec 5, 2023

What happened?

How can we reproduce the issue?

Relevant log output

Operating System

Selenium version

What are the browser(s) and version(s) where you see this issue?

What are the browser driver(s) and version(s) where you see this issue?

Are you using Selenium Grid?

github-actions bot commented Dec 5, 2023

Uh oh!

diemol commented Dec 5, 2023

Uh oh!

bhecquet commented Dec 5, 2023

Uh oh!

joerg1985 commented Dec 5, 2023

Uh oh!

bhecquet commented Dec 5, 2023

Uh oh!

pujagani commented Dec 6, 2023

Uh oh!

joerg1985 commented Dec 6, 2023

Uh oh!

bhecquet commented Dec 6, 2023

Uh oh!

joerg1985 commented Dec 6, 2023

Uh oh!

pujagani commented Dec 7, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

pujagani commented Dec 12, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

pujagani commented Dec 15, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

pujagani commented Dec 15, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

pujagani commented Dec 15, 2023

Uh oh!

bhecquet commented Dec 15, 2023

Uh oh!

joerg1985 commented Dec 15, 2023

Uh oh!

pujagani commented Dec 15, 2023

Uh oh!

bhecquet commented Dec 15, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

joerg1985 commented Dec 15, 2023

Uh oh!

bhecquet commented Dec 19, 2023

Uh oh!

pujagani commented Dec 19, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

pujagani commented Dec 19, 2023

Uh oh!

bhecquet commented Dec 19, 2023

Uh oh!

pujagani commented Dec 20, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

pujagani commented Dec 20, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

pujagani commented Dec 21, 2023

Uh oh!

bhecquet commented Dec 21, 2023

Uh oh!

pujagani commented Dec 21, 2023

Uh oh!

titusfortner commented Dec 31, 2023

Uh oh!

bhecquet commented Dec 31, 2023

pujagani commented Dec 7, 2023 •

edited

Loading

pujagani commented Dec 12, 2023 •

edited

Loading

pujagani commented Dec 15, 2023 •

edited

Loading

pujagani commented Dec 15, 2023 •

edited

Loading

bhecquet commented Dec 15, 2023 •

edited

Loading

pujagani commented Dec 19, 2023 •

edited

Loading

pujagani commented Dec 20, 2023 •

edited

Loading

pujagani commented Dec 20, 2023 •

edited

Loading

pujagani commented Jan 12, 2024 •

edited

Loading