Hi Emanuel,
thanks for providing this example. The one WebDriver instance is
correctly managed in the WebDriverProvider.end() method.
The FluentWebDriver instances are not managed in the same way - they are
not WebDriver instances and there is no lifecycle management. There
is an instance created for each page, each using the same WebDriver
instance as delegate.
I'm not sure this constitutes a memory leak, simply that the instances
are not removed at the end of the story execution. But that could
easily apply to other objects as well.
Are you experiencing any specific issues as a consequence of this? If
so, I'd would add a FluentLifecycleSteps class method that finds the
ThreadLocal instances of FluentWebDriver and nullifies them, and we can
annotate it @AfterStory.
Cheers
On 30/07/2014 21:39, Emanuel Campolo wrote:
Hi Mauro,
I could reproduce the memory leak. To do that, I created a project
from the jbehave-web archetype and made the some modifications in
order to get some logs.
I also refactored some of the page objects since the default test
cases had some errors due to etsy home page modifications.
This is the project:
https://github.com/emacampolo/etsy-jbehave/tree/jbehave-web-possible-memory-leak
And this is the class that prints the logs:
https://github.com/emacampolo/etsy-jbehave/blob/jbehave-web-possible-memory-leak/src/main/java/org/jbehave/tutorials/etsy/steps/JournaledStoriesSteps.java
Below you can find the output (I print all the ThreadLocal instances
that are subclasses of WebDriver or FluentWebDriver).
*Narrative:*
*In order to show the browsing cart functionality*
*As a user*
*I want to browse in a gallery*
*Scenario: Browsing around the site for items*
****************************************
*LOGGING BEFORE SCENARIO*
*
*
*Thread name: main*
*DoublyOverriddenFirefoxDriver: firefox on LINUX
(eea68437-dfb6-4783-9ebf-d3b2c95c9f28)*
****************************************
*Given I am on etsy.com <http://etsy.com>*
*When I want to browse through an art gallery*
*When I want to buy something from etsy.com <http://etsy.com>*
*When I want to browse the Art*
*When I choose the first art gallery*
*Then results will be displayed in the gallery*
*
*
****************************************
*LOGGING BEFORE CALLING END()*
*
*
*Thread name: main*
*org.seleniumhq.selenium.fluent.FluentWebDriver@1570e827*
*Thread name: main*
*org.seleniumhq.selenium.fluent.FluentWebDriver@27996370*
*Thread name: main*
*org.seleniumhq.selenium.fluent.FluentWebDriver@474f625f*
*Thread name: main*
*org.seleniumhq.selenium.fluent.FluentWebDriver@2cc36f8c*
*Thread name: main*
*DoublyOverriddenFirefoxDriver: firefox on LINUX
(eea68437-dfb6-4783-9ebf-d3b2c95c9f28)*
****************************************
*
*
*[INFO] 2 stories excluded by filter: +category browsing*
*
*
*
*
*(AfterStories)*
****************************************
*LOGGING AFTER STORIES*
*
*
*Thread name: main*
*org.seleniumhq.selenium.fluent.FluentWebDriver@1570e827*
*Thread name: main*
*org.seleniumhq.selenium.fluent.FluentWebDriver@27996370*
*Thread name: main*
*org.seleniumhq.selenium.fluent.FluentWebDriver@474f625f*
*Thread name: main*
*org.seleniumhq.selenium.fluent.FluentWebDriver@2cc36f8c*
****************************************
As you can see, by the time the suite is over, there are 4
FluentWebDriver instances (one for each page object that is created)
attached to the current thread.
On the other hand, you may notice that the
*DoublyOverriddenFirefoxDriver *is removed correctly.
There are a couple of approaches to solve this. First, let's validate
this issue.
Note: If you want to run it, please use the following filter since the
other test cases seems not to be working
mvn clean install -Dmeta.filter="+category browsing"
2014-07-30 13:47 GMT-03:00 Mauro Talevi <mauro.tal...@aquilonia.org
<mailto:mauro.tal...@aquilonia.org>>:
It's your right to use alternative implementations, but at least
the interfaces should be the same and the maven dependencies declared.
If you find there's a bug in an implementation, the best way to
address it is to provide a same project that reproduces it and
perhaps a patch for it.
On 30/07/2014 18:21, Emanuel Campolo wrote:
Please dont get me wrong. I do want to help. I've copied some
classes because i found out that I could have memory leak issues
using the FluentWebDriverPage.
I will send you some logs using a newly created project with the
jbehave-web archetype.
On Jul 30, 2014 1:09 PM, "Mauro Talevi"
<mauro.tal...@aquilonia.org <mailto:mauro.tal...@aquilonia.org>>
wrote:
It seems to me that you're not even using jbehave-web.
You've copied selected classes from it into your project and
using them in a way which is different from jbehave-web, e.g.
introducing another factory abstraction.
If you'd help on using jbehave-web, including resolving
issues with its current implementation, we'd be happy to help.
If you're writing your own framework, then we can't help.
Cheers
On 30/07/2014 17:52, Emanuel Campolo wrote:
Hi Mauro, thanks for taking your time to reply.
I mentioned PerStoryWebDriverSteps as an example of how the
framework cleans up the resources. In this case, when the
end() method is invoked, the ThreadLocal<WebDriver> instance
associated with the current thread is removed but, if you'd
used a FluentWebDriverPage instead of a WebDriverPage, a
ThreadLocal<FluentWebDriver> will not be eliminated from the
list of thread locals.
Even though im not using the jbehave-core for running my
tests, Im coding a lightweight selenium-based framework
using testng and the jbehave-web project.
As you can see below, I had to re write some of the classes
to solve this issue where resources are not being removed by
the DelegatingWebDriverProvider (javadoc and reference to
jbehave-web will be added):
https://github.com/emacampolo/hatchery/blob/master/src/main/java/com/hatchery/core/DefaultWebDriverProvider.java
https://github.com/emacampolo/hatchery/blob/master/src/main/java/com/hatchery/core/pages/FluentWebDriverPage.java
This is where I invoke the end() method
https://github.com/emacampolo/hatchery/blob/master/src/main/java/com/hatchery/core/Suite.java
2014-07-30 12:06 GMT-03:00 Mauro Talevi
<mauro.tal...@aquilonia.org
<mailto:mauro.tal...@aquilonia.org>>:
Hi,
the FluentWebDriverPage is simply a fluent-based facade
using a FluentWebDriver. The underlying
WebDriverProvider is the same as a non-fluent page and
is injected in the constructor.
The PerStoryWebDriverSteps should use exactly the same
underlying WebDriverProvider (autowired via some
dependency-injection mechanism), so if the provider
end() method is invoked you shouldn't need to do
anything else.
Are you experiencing or noticing a particular problem?
If so, could you share a project that reproduced it?
Cheers
On 29/07/2014 19:14, Emanuel Campolo wrote:
Hi all !
I've added the jbehave-web module to a personal
project where I use testng. I'm using the
FirefoxWebDriverProvider to manage the webdriver
instances, taking advantage of the ThreadLocal for
multithreaded tests.
My question is, even though I call the end() method
every time a test completes to remove the driver
assigned to the current thread, i don't know how to
the same thing to the FluentWebDriver (a thread
local variable that the FluentWebDriverPage has).
I noticed that , for example, the
PerStoryWebDriverSteps only executes
driverProvider.end() but as in mentioned above, i
didn't find any clean up for the FluentWebDriver
instances that FluentWebDriverPage creates.
Thanks in advance :)
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
