users@jersey.java.net

[Jersey] Re: Speeding up jersey-test?

From: Gili <cowwoc_at_bbs.darktech.org>
Date: Fri, 22 Apr 2011 06:10:09 -0700 (PDT)

   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;pavel.bucek_at_oracle.com&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.