users@jersey.java.net

[Jersey] Re: Speeding up jersey-test?

From: Pavel Bucek <pavel.bucek_at_oracle.com>
Date: Fri, 22 Apr 2011 12:25:35 +0200

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]
>> </user/SendEmail.jtp?type=node&node=6290108&i=0&by-user=t&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&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&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&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&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&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
>> <http://jersey.576304.n2.nabble.com/Speeding-up-jersey-test-tp6239607p6290108.html?by-user=t>
>>
>> To unsubscribe from Speeding up jersey-test?, click here.
>
>
> ------------------------------------------------------------------------
> View this message in context: Re: Speeding up jersey-test?
> <http://jersey.576304.n2.nabble.com/Speeding-up-jersey-test-tp6239607p6291385.html>
> Sent from the Jersey mailing list archive
> <http://jersey.576304.n2.nabble.com/> at Nabble.com.