users@jersey.java.net

[Jersey] Re: Speeding up jersey-test?

From: Ryan Stewart <rds6235_at_gmail.com>
Date: Fri, 22 Apr 2011 07:51:30 -0500

On Fri, Apr 22, 2011 at 5:25 AM, Pavel Bucek <pavel.bucek_at_oracle.com> 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.