Previously, connectBlocking(long, TimeUnit) would return a boolean indicating whether the connection was set up in the given window. If false was returned, we would continue to attempt connecting in the background. This PR updates connectBlocking(long, TimeUnit) to perform cleanup on timeout.
How Has This Been Tested?
Unit tests have been run
See "To Reproduce" steps on https://github.com/TooTallNate/Java-WebSocket/issues/1397 - I used the firewall rules listed, and then updated the sample app linked to run the default client in a in a loop (500 iterations) to verify there were no thread or memory leaks
Types of changes
[x] Breaking change (fix or feature that would cause existing functionality to change) - connectBlocking(long, TimeUnit) behavior has changed
Checklist:
[x] My code follows the code style of this project.
[x] All existing tests passed.
Note: I spent a couple hours spiking a unit test around this change but couldn't come up with anything solid. I found it difficult to simulate the "drop packets mid-connection" firewall rule listed in the linked issue. If we think this is necessary to test, advice on testing would be appreciated.
Related Issue
Fixes #1397
Motivation and Context
Previously,
connectBlocking(long, TimeUnit)
would return a boolean indicating whether the connection was set up in the given window. If false was returned, we would continue to attempt connecting in the background. This PR updatesconnectBlocking(long, TimeUnit)
to perform cleanup on timeout.How Has This Been Tested?
Types of changes
connectBlocking(long, TimeUnit)
behavior has changedChecklist:
Note: I spent a couple hours spiking a unit test around this change but couldn't come up with anything solid. I found it difficult to simulate the "drop packets mid-connection" firewall rule listed in the linked issue. If we think this is necessary to test, advice on testing would be appreciated.