Open pecko opened 9 years ago
@yegor256 please do something about this issue
@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.
@pecko I think the only solution possible is to wait, instead of failing, when the port is not available.
@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.
@pecko thanks for reporting! I topped your account for 15 mins, transaction 66241743
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.