Travis builds fail unexcpected

[pecko]

Maybe, that isn't related to the jcabi-github project, but I have noticed the issue here.

While fixing #932 I have noticed that travis builds failed without some obvious reason. For instance, next build (almost the same) pass.

Examples:

https://travis-ci.org/jcabi/jcabi-github/builds/81745690 - failed https://travis-ci.org/jcabi/jcabi-github/builds/81745877 - passed

There are 3 builds with 3 different jdk and usually one failed. I think that it isn't related to JDK.

Maybe, fixing #1164 will help.

[dmarkov]

@yegor256 please do something about this issue

[yegor256]

@pecko this is why it fails:

java.net.BindException: No free port within range: 39125=com.sun.grizzly.http.SelectorThreadHandler@4a085f76
    at com.sun.grizzly.TCPSelectorHandler.initSelector(TCPSelectorHandler.java:432)
    at com.sun.grizzly.TCPSelectorHandler.preSelect(TCPSelectorHandler.java:378)
    at com.sun.grizzly.SelectorHandlerRunner.doSelect(SelectorHandlerRunner.java:188)
    at com.sun.grizzly.SelectorHandlerRunner.run(SelectorHandlerRunner.java:132)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
    at java.lang.Thread.run(Thread.java:745)

The build machine simply doesn't have enough TCP ports for running all our tests.

[yegor256]

@pecko I think the only solution possible is to wait, instead of failing, when the port is not available.

[pecko]

@yegor256

I also can happen when port is free, but it is still in TIME_WAIT state. The solution is to use

TCPSelectorHandler.setReuseAddress(true}

that is

Socket.setReuseAddress(true)

anywhere. See http://docs.oracle.com/javase/7/docs/api/java/net/Socket.html#setReuseAddress(boolean)

Basically, it allows the socket to be bound even though a previous connection is in a timeout state.

There are similar issue in com.jcabi.http.mock.MkGrizzlyContainer.reserve() (the https://github.com/jcabi/jcabi-github project). You use com.jcabi.github.RandomPort.port() to solve this issue, but it probably would be better do it in MkGrizzlyContainer.reserve() as well as whenever you acquire a port (have to be set before bind)

It maybe will not help in every case, but will be enhancement.

On Linux, you can look at such connections with:

netstat -on | grep TIME_WAIT

Sometimes, you will see a lot such connections.

[dmarkov]

@pecko thanks for reporting! I topped your account for 15 mins, transaction 66241743