[Jersey] Re: Speeding up jersey-test?

From: Gili <>
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.


zzantozz wrote:
> On Fri, Apr 22, 2011 at 5:25 AM, Pavel Bucek
> &lt;; 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:
Sent from the Jersey mailing list archive at