driver.reset()

[Scisaga]

when call driver.reset() in crawler threads, eg. change a upstreaming proxy, remote JBrowserDriverServer act unreasonable. both thread num and mem consume grow rapidly.

related code: Context.java Line 90 - 99

  void reset(JBrowserDriverServer driver) {
    removeItems();
    synchronized (lock) {
      setUpUserDataDir();
      ContextItem newContext = new ContextItem();
      newContext.init(driver, this);
      items.add(newContext);
      itemMap.put(newContext.itemId.get(), newContext);
    }
  }

since removeItems() just hide web elements using Toolkit util according to your code, may be the related threads and mem is not released. i don't quite understand this part of your code, may be you can give me some hints, thanks.

BTW. is there any change proxy method for driver?

[hollingsworthd]

Thanks for the info. You're right, Stage.close() doesn't actually free resources which is a bug in how it's used here.

The goal of the reset API is to re-initialize the state of the browser without actually re-initializing or classloading JavaFX or starting a new Java child process. Calling new JBrowserDriver() is expensive--although in context of loading a typical modern webpage (which is very expensive) it's not too bad.

Context is equivalent to the state of a browser. ContextItems are windows within that browser, that share the overall browser state, and each JBrowserDriver is a wholly separate browser instance running in a separate process.

Basically reset closes each browser window, gives you a new instance of WebView which is the JavaFX browser built on WebKit, clears cookies, user data, and other settings.

[hollingsworthd]

BTW. is there any change proxy method for driver?

Not aside from reset

[andreaskas]

Anu updates on this issue? Memory leaks using reset() are still here. Thanks

[hollingsworthd]

None yet

[Gintasz]

Any updates? I'm planning to try java 9, does it still leak on it?