[Jersey] Re: Speeding up jersey-test?

From: Oleksiy Stashok <>
Date: Fri, 22 Apr 2011 16:16:52 +0200

We have also implemented port range support for Grizzly NetworkListeners



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;; 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