users@jersey.java.net

[Jersey] Re: Speeding up jersey-test?

From: Gili <cowwoc_at_bbs.darktech.org>
Date: Wed, 20 Apr 2011 09:34:09 -0700 (PDT)

Hi Pavel,

On 20/04/2011 5:40 AM, Pavel Bucek-2 [via Jersey] wrote:
> Hello,
>
> I agree with Zzantozz, doesn't seem to me like thing which should be
> managed by Grizzly. In this case, user is responsible to manage
> available resources, not Grizzly, right? I can see your point and I can
> imagine some property passed to jersey test framework, which would
> specify port range..

     There are two different reasons I am against this proposal:

1. As far as I can tell, there is no thread-safe way to implement the
behavior you are asking for. The last thing we want are race-conditions
leading to false-positive test failures. ServerSocket has a nice
constructor that acquires an available port in a thread-safe manner, why
not use it?
2. I don't understand the need for it. When running unit tests, I would
like the unit tests to use any available port. I don't understand why
anyone would want to restrict the port range. Please explain.

> We do use similar setup when running our tests on Hudson. Hudson itself
> has mechanism to manage free ports and we pass this to Jersey test
> framework.
>
> Other thing is that we don't support running tests in parallel, as you
> correctly stated. In my opinion, this should be filed as a RFE, not a
> bug; you state "expected would be ..", but I can't see anything like it
> it JerseyTest javadoc [1].

     I'm okay with converting the issue to a RFE but I don't have
permissions to do so on my end. Can you make the change?

Thanks,
Gili

>
> Pavel
>
> [1]
> http://jersey.java.net/nonav/apidocs/latest/jersey-test-framework/jersey-test-framework-core/com/sun/jersey/test/framework/JerseyTest.html
>
> On 4/20/11 1:33 AM, Gili wrote:
>
> > zzantozz,
> >
> > There is no way to guarantee that the port number passed from Jersey to
> > Grizzly will be available by the time the latter uses ServerSocket.
> The only
> > safe option I can think of is for Grizzly to use the ServerSocket
> > constructor that picks an available port at random (and locks it
> once it has
> > been acquired).
> >
> > Gili
> >
> >
> > zzantozz wrote:
> >> That doesn't really require Grizzly to search for open ports (as
> mentioned
> >> in the Grizzly issue in the comments for JERSEY-710). Another
> alternative
> >> would be to allow users to register a "PortSelector" or some such,
> which
> >> would have a method that lets Jersey query it for a port to use when
> >> starting Grizzly. Then users have control over the port ranges in
> use. Of
> >> course, having both options would be great.
> >>
> >> On Tue, Apr 19, 2011 at 12:21 PM, Gili&lt;[hidden email]
> </user/SendEmail.jtp?type=node&node=6290108&i=0&by-user=t>&gt;
> >> wrote:
> >>
> >>> I just filed http://java.net/jira/browse/JERSEY-710 because
> jersey-test
> >>> makes
> >>> it impossible to run unit tests in parallel.
> >>>
> >>> I believe it will be far easier to fix JERSEY-710 than JERSEY-705
> >>> (because
> >>> it doesn't involve static methods). Can someone please take a look
> at it?
> >>>
> >>> Thanks,
> >>> Gili
> >>>
> >>>
> >>> Gili wrote:
> >>>> Done: http://java.net/jira/browse/JERSEY-705
> >>>>
> >>>> Gili
> >>>>
> >>>> On 07/04/2011 11:01 AM, Pavel Bucek-2 [via Jersey] wrote:
> >>>>> Hello Naresh and Gili,
> >>>>>
> >>>>> this would be nice feature, I had something implemented some
> time ago
> >>>>> but I can't find it anymore. Feel free to file RFE for this so we
> >>>>> won't forget it again.
> >>>>>
> >>>>> Pavel
> >>>>>
> >>>>> On 04/07/2011 07:09 AM, Srinivas Naresh Bhimisetty wrote:
> >>>>>> Gili,
> >>>>>>
> >>>>>> as you observed, the JerseyTest starts and stops the test
> container
> >>>>>> before (@Before) and after (@After) each test method is executed.
> >>>>>> This sure could be the cause of the time being taken to execute
> each
> >>>>>> test method.
> >>>>>>
> >>>>>> Probably, changing the JerseyTest implementation to
> start/stop the
> >>>>>> test container only once (using the @BeforeClass, @AfterClass
> >>>>>> annotations), for all the test methods defined in a test class
> should
> >>>>>> help overcome this.
> >>>>>>
> >>>>>> - Naresh
> >>>>>>
> >>>>>> On Tue, Apr 5, 2011 at 12:18 AM, Gili<[hidden email]
> >>>>>>
> >>>
> &lt;/user/SendEmail.jtp?type=node&amp;node=6250350&amp;i=0&amp;by-user=t&gt;>
> >>>>>> wrote:
> >>>>>>
> >>>>>> Hi,
> >>>>>>
> >>>>>> Jersey-test is quite slow. Granted, the unit tests are
> doing a
> >>>>>> lot (starting
> >>>>>> up a web server, running the test and shutting down the web
> >>>>>> server) but the
> >>>>>> end-result is that each @Test takes a minimum of a second
> >>>>>> compared with
> >>>>>> milliseconds used by my other unit tests. I am using the
> Grizzly
> >>> web
> >>>>>> container.
> >>>>>>
> >>>>>> Is there a way to speed up these unit tests? How fast is
> >>>>>> InMemoryTestContainer? I can't use it on my end because it
> >>>>>> doesn't seem to
> >>>>>> be compatible with Guice but I'm just curious how if it
> makes a
> >>> big
> >>>>>> difference.
> >>>>>>
> >>>>>> Thanks,
> >>>>>> Gili
> >>>>>>
> >>>>>> --
> >>>>>> View this message in context:
> >>>>>>
> >>>>>>
> >>>
> http://jersey.576304.n2.nabble.com/Speeding-up-jersey-test-tp6239607p6239607.html
> <http://jersey.576304.n2.nabble.com/Speeding-up-jersey-test-tp6239607p6239607.html?by-user=t>
> >>>>>> &lt;
> >>>
> http://jersey.576304.n2.nabble.com/Speeding-up-jersey-test-tp6239607p6239607.html?by-user=t&gt
> <http://jersey.576304.n2.nabble.com/Speeding-up-jersey-test-tp6239607p6239607.html?by-user=t&gt&by-user=t>
> >>> ;
> >>>>>> Sent from the Jersey mailing list archive at Nabble.com.
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>
> ------------------------------------------------------------------------
> >>>>> If you reply to this email, your message will be added to the
> >>>>> discussion below:
> >>>>>
> >>>
> http://jersey.576304.n2.nabble.com/Speeding-up-jersey-test-tp6239607p6250350.html
> <http://jersey.576304.n2.nabble.com/Speeding-up-jersey-test-tp6239607p6250350.html?by-user=t>
> >>>>> To unsubscribe from Speeding up jersey-test?, click here
> >>>>> &lt;
> >>> ;.
> >>>
> >>> --
> >>> View this message in context:
> >>>
> http://jersey.576304.n2.nabble.com/Speeding-up-jersey-test-tp6239607p6288056.html
> <http://jersey.576304.n2.nabble.com/Speeding-up-jersey-test-tp6239607p6288056.html?by-user=t>
> >>> Sent from the Jersey mailing list archive at Nabble.com.
> >>>
> >
> > --
> > View this message in context:
> http://jersey.576304.n2.nabble.com/Speeding-up-jersey-test-tp6239607p6289070.html
> <http://jersey.576304.n2.nabble.com/Speeding-up-jersey-test-tp6239607p6289070.html?by-user=t>
> > Sent from the Jersey mailing list archive at Nabble.com.
> >
>
>
>
> ------------------------------------------------------------------------
> If you reply to this email, your message will be added to the
> discussion below:
> http://jersey.576304.n2.nabble.com/Speeding-up-jersey-test-tp6239607p6290108.html
>
> To unsubscribe from Speeding up jersey-test?, click here
> <http://jersey.576304.n2.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=6239607&code=Y293d29jQGJicy5kYXJrdGVjaC5vcmd8NjIzOTYwN3wxNTc0MzIxMjQ3>.
>



--
View this message in context: http://jersey.576304.n2.nabble.com/Speeding-up-jersey-test-tp6239607p6291385.html
Sent from the Jersey mailing list archive at Nabble.com.