Behaviour of JerseyTest Grizzly Web Server on Unix

We have created a test suite and in order to run it we 开发者_运维知识库are using embedded Grizzly Web Server with JerseyTest framework.

We are extending a custom class from JerseyTest and in its constructor we are creating ApplicationDescriptor and then call superclass setupTestEnvironment() which essentially starts embedded grizzly web server.

Few of our test cases are extending this custom class to start grizzly server directly. However, we are not stopping this embedded server anywhere in the code.

The test cases run fine on windows but on Unix they fail with java.net.BindException port 9998 is in use by another process.

It becomes obvious these tests should fail with similar error on windows too if we are not stopping embedded web server in the code. How they are running fine on windows and failing on unix. Has this something to do with how Unix spawns threads or processes?

P.S. We have also tested whether port 9998 is in use by some other process using netstat -a | grep 9998 but no other process using that port could be found.

i had a similar problem and i did fix it by not using the default port if already used. just add following code to your test case:

@Override
protected int getPort(int defaultPort) {

    ServerSocket server = null;
    int port = -1;
    try {
        server = new ServerSocket(defaultPort);
        port = server.getLocalPort();
    } catch (IOException e) {
        // ignore
    } finally {
        if (server != null) {
            try {
                server.close();
            } catch (IOException e) {
                // ignore
            }
        }
    }
    if ((port != -1) || (defaultPort == 0)) {
        return port;
    }
    return getPort(0);
}

I had the same problem, when I was writing my integration tests. I didn't get to test on a Windows machine, but on my Unix machine I found the problem was that by default the JerseyTest class utilizes @After on it's tearDown method to close the embedded server. Since I had overridden this method to do clean up on my side, I had to call super.tearDown()

@After
public void tearDown() throws Exception{
    super.tearDown();
    ...
}

After doing this, everything worked as expected.