Speeding up jersey-test?

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

Speeding up jersey-test?

Gili
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
Reply | Threaded
Open this post in threaded view
|

Re: Speeding up jersey-test?

Srinivas Naresh Bhimisetty
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]> 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
Sent from the Jersey mailing list archive at Nabble.com.

Reply | Threaded
Open this post in threaded view
|

Re: Speeding up jersey-test?

Pavel Bucek-2
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]> 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
Sent from the Jersey mailing list archive at Nabble.com.


Reply | Threaded
Open this post in threaded view
|

Re: Speeding up jersey-test?

Gili

    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]> 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
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
To unsubscribe from Speeding up jersey-test?, click here.

Reply | Threaded
Open this post in threaded view
|

Re: Speeding up jersey-test?

Gili
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]
>> </user/SendEmail.jtp?type=node&node=6250350&i=0&by-user=t>> 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>
>>     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 
>
> 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>.
>
Reply | Threaded
Open this post in threaded view
|

Re: Speeding up jersey-test?

zzantozz
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 <[hidden email]> 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
>>>
>>> &lt;http://jersey.576304.n2.nabble.com/Speeding-up-jersey-test-tp6239607p6239607.html?by-user=t&gt;
>>>     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
>>
>> 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
Sent from the Jersey mailing list archive at Nabble.com.

Reply | Threaded
Open this post in threaded view
|

Re: Speeding up jersey-test?

Gili
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 <[hidden email]> 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]
> >>>
> </user/SendEmail.jtp?type=node&node=6250350&i=0&by-user=t>>
> >>> 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>
> ;
> >>>     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
> >>
> >> 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-tp6239607p6288056.html
> Sent from the Jersey mailing list archive at Nabble.com.
>
Reply | Threaded
Open this post in threaded view
|

Re: Speeding up jersey-test?

Pavel Bucek-2
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..

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].

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]&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
>>>>>> &lt;
>>> http://jersey.576304.n2.nabble.com/Speeding-up-jersey-test-tp6239607p6239607.html?by-user=t&gt
>>> ;
>>>>>>      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
>>>>> 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
>>> 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
> Sent from the Jersey mailing list archive at Nabble.com.
>

Reply | Threaded
Open this post in threaded view
|

Re: Speeding up jersey-test?

Gili
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]&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
>>>>>> &lt;
>>> http://jersey.576304.n2.nabble.com/Speeding-up-jersey-test-tp6239607p6239607.html?by-user=t&gt
>>> ;
>>>>>>      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
>>>>> 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
>>> 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
> 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.

Reply | Threaded
Open this post in threaded view
|

Re: Speeding up jersey-test?

Pavel Bucek-2
On 4/20/11 6:34 PM, Gili wrote:
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.
Let's imagine following situation.

You have service A, which starts on demand and opens port B for listening when it is running.  You will execute jersey test, it will use port B and service A would not be able to start. It is a constructed case, but it might happen. From my point of view, it is always better to let the user control his resources, right? I guess I could state more real life examples - like for example DCC (IRC way to transfer files) - it defines port range which your client can use for receiving files. But they are opened when needed.. (service A from previous situation).

And when I'm thinking about this little bit more.. some containers do open other ports that its primary http transport (management kind of things, like jetty stop port).. this would be another thing which we will need to figure out how to deal with.

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?
sure, done.

Thanks,
Pavel

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]&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
>>>>>> &lt;
>>> http://jersey.576304.n2.nabble.com/Speeding-up-jersey-test-tp6239607p6239607.html?by-user=t&gt
>>> ;
>>>>>>      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
>>>>> 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
>>> 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
> 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.



View this message in context: Re: Speeding up jersey-test?
Sent from the Jersey mailing list archive at Nabble.com.

Reply | Threaded
Open this post in threaded view
|

Re: Speeding up jersey-test?

zzantozz
On Fri, Apr 22, 2011 at 5:25 AM, Pavel Bucek <[hidden email]> wrote:
On 4/20/11 6:34 PM, Gili wrote:
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.
Let's imagine following situation.

You have service A, which starts on demand and opens port B for listening when it is running.  You will execute jersey test, it will use port B and service A would not be able to start. It is a constructed case, but it might happen. From my point of view, it is always better to let the user control his resources, right? I guess I could state more real life examples - like for example DCC (IRC way to transfer files) - it defines port range which your client can use for receiving files. But they are opened when needed.. (service A from previous situation).

And when I'm thinking about this little bit more.. some containers do open other ports that its primary http transport (management kind of things, like jetty stop port).. this would be another thing which we will need to figure out how to deal with.

That pretty well covers it. To give a more concrete example, CI for my Jersey project is in a Hudson server that hosts several other jobs, some of which expect to be able to open certain ranges of ports. If Jersey were to start first, it could grab something from one of those ranges. Like I said before, I also like the idea of delegating to ServerSocket, but it shouldn't be the only available behavior.
Reply | Threaded
Open this post in threaded view
|

Re: Speeding up jersey-test?

Gili

   Okay. For what it's worth, GRIZZLY-1001 has been closed as FIXED so it's now possible to implement the solution that listens on any port. I suspect you could use a similar solution (using NetworkListener) to implement the port range. Please take a look.

Gili

zzantozz wrote
On Fri, Apr 22, 2011 at 5:25 AM, Pavel Bucek <[hidden email]> wrote:

>  On 4/20/11 6:34 PM, Gili wrote:
>
> 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.
>
> Let's imagine following situation.
>
> You have service A, which starts on demand and opens port B for listening
> when it is running.  You will execute jersey test, it will use port B and
> service A would not be able to start. It is a constructed case, but it might
> happen. From my point of view, it is always better to let the user control
> his resources, right? I guess I could state more real life examples - like
> for example DCC (IRC way to transfer files) - it defines port range which
> your client can use for receiving files. But they are opened when needed..
> (service A from previous situation).
>
> And when I'm thinking about this little bit more.. some containers do open
> other ports that its primary http transport (management kind of things, like
> jetty stop port).. this would be another thing which we will need to figure
> out how to deal with.
>
> That pretty well covers it. To give a more concrete example, CI for my
Jersey project is in a Hudson server that hosts several other jobs, some of
which expect to be able to open certain ranges of ports. If Jersey were to
start first, it could grab something from one of those ranges. Like I said
before, I also like the idea of delegating to ServerSocket, but it shouldn't
be the only available behavior.
Reply | Threaded
Open this post in threaded view
|

Re: Speeding up jersey-test?

Oleksiy Stashok-2
We have also implemented port range support for Grizzly NetworkListeners
[1].

WBR,
Alexey.

[1] http://java.net/jira/browse/GRIZZLY-1003


On 04/22/2011 03:10 PM, Gili wrote:

>     Okay. For what it's worth, GRIZZLY-1001 has been closed as FIXED so it's
> now possible to implement the solution that listens on any port. I suspect
> you could use a similar solution (using NetworkListener) to implement the
> port range. Please take a look.
>
> Gili
>
>
> zzantozz wrote:
>> On Fri, Apr 22, 2011 at 5:25 AM, Pavel Bucek
>> &lt;[hidden email]&gt; wrote:
>>
>>>   On 4/20/11 6:34 PM, Gili wrote:
>>>
>>> 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.
>>>
>>> Let's imagine following situation.
>>>
>>> You have service A, which starts on demand and opens port B for listening
>>> when it is running.  You will execute jersey test, it will use port B and
>>> service A would not be able to start. It is a constructed case, but it
>>> might
>>> happen. From my point of view, it is always better to let the user
>>> control
>>> his resources, right? I guess I could state more real life examples -
>>> like
>>> for example DCC (IRC way to transfer files) - it defines port range which
>>> your client can use for receiving files. But they are opened when
>>> needed..
>>> (service A from previous situation).
>>>
>>> And when I'm thinking about this little bit more.. some containers do
>>> open
>>> other ports that its primary http transport (management kind of things,
>>> like
>>> jetty stop port).. this would be another thing which we will need to
>>> figure
>>> out how to deal with.
>>>
>>> That pretty well covers it. To give a more concrete example, CI for my
>> Jersey project is in a Hudson server that hosts several other jobs, some
>> of
>> which expect to be able to open certain ranges of ports. If Jersey were to
>> start first, it could grab something from one of those ranges. Like I said
>> before, I also like the idea of delegating to ServerSocket, but it
>> shouldn't
>> be the only available behavior.
>>
>
> --
> View this message in context: http://jersey.576304.n2.nabble.com/Speeding-up-jersey-test-tp6239607p6296992.html
> Sent from the Jersey mailing list archive at Nabble.com.