On May 27, 2010, at 5:29 PM, Bartosz Bobnis wrote:
> Hello,
>
> We've run into a problem when running a multitude of tests that
> extend a base class that extends the JerseyTest.
>
> We're using the GrizzlyWebTestContainer and have all the resources
> injected via Spring. Each test run individually is fine but when run
> as a whole a lot of threads are spun and OutOfMemoryExceptions
> occur. Increasing the memory allocated allowed the tests to run
> through but unacceptably slow.
>
What version of Grizzly are you using? perhaps there is an issue in
Grizzly when shutting down?
> SelectorThreads are spun per object spawned by the Factory that are
> asked for @Before each resource test. That is, each test spins a
> thread and the "suite" falls on its face.
>
The @After method will call this:
public void stop() {
LOGGER.info("Stopping the Grizzly Web Container...");
webServer.stop();
webServer.getSelectorThread().stopEndpoint();
}
> Unfortunately, the InMemoryTestContainer (desirable: skips the HTTP
> portion, focuses on the resources, a lot quicker) does not "see"
> provider classes
Can you describe a bit more about that?
> (even though it sees the root resources via spring injected
> context.xml) out of the box so a quick TestContainerFactory swap
> won't work. I suspect differences between WebAppDescriptor and
> LowLevelDescriptor is at fault.
>
Yes, there are some issues related to the transformation, it should be
more robust in reporting errors as it is not possible to map from web
to low level in all cases. But i am not sure the provider stuff is
related to this.
> My question is what are the best practices for writing test suites
> of this sort using the JerseyTest framework and JUnit 4? Currently
> the only annotations that are employed are @Test, @Before and
> @After. Ideally we'd like each test to be part of a suite of tests
> that has a WebTestContainer created at the beginning of the entire
> suite of tests rather than each individual test and have the
> WebAppDescriptor replaced @Before each individual @Test.
>
Currently JerseyTest is a bit limited in this respect. I think what we
require is an AbstractJerseyTest from which you can extend and decide
on the policy of starting and stopping the test container.
I think the only way you can control this at the moment is to right
your own test container factory to control stop and start per test
class instantiation.
Any thoughts Pavel?
As for a suite of tests that is be a little different to what we are
used to. If you can give an example of how you would like to write
your code we might be able to use that as a template to support that
style.
Paul.
> I am hoping this approach will solve excessive threads that hang
> around after starting/stopping the GrizzlyWebTestContainer but I'm
> open to any and all suggestions.
>
> Thank you,
>
> Bartosz Bobnis
> Software Developer
> Primal
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>