Conversation
…available quickly
|
Similar thing just happened in this PR's check for unrelated https://github.com/apache/mina/actions/runs/36310962285/job/108596661471?pr=72 |
|
Totally agree that we need to add a retry. As the test lay be run concurrently, there is no reason to expect that the AvailablePortFinder returns a port that will be available when we try to use it. We can't guarantee that this method will return an available port, it's a "best effort" situation. |
|
Note that this method is used in 18 tests... |
|
I have to think what to with this. Either we explicitly use anonymous bind (I guess some tests do not do it intentionally) or just write some common code for all of them where possible. |
|
May be using a method like: which is called this way; could do the trick (possibly passing the number of tries as a parameter, too) |
|
I'll push the suggested class and the modified test as soon as my daughter is on her way to school ;-) (and of course if the tests pass...) |
|
I have the tests passing with half the tests fixed, keep going |
Again a flaky test in 2.2.x branch.
https://github.com/apache/mina/actions/runs/35965588526/job/107523331814
In this case the issue is a time gap between
org.apache.mina.util.AvailablePortFinder#getNextAvailable()and actually binding it withorg.apache.mina.core.service.IoAcceptor#bind()sincegetNextAvailablecan be made uavailable again.The proposed change is to add a retry count in
org.apache.mina.transport.AbstractBindTest#bindto try a few times. In my local environment it doesn't sometimes even happen for 1k test runs, but it happens more frequently with GitHub actions.