Allow timeout on handshake handler

[kc7bfi]

Allow a timeout on the sync() call. This is to prevent the call from hanging and never returning.

[jenkinskurento]

Hi there. Thanks for your PR.

I'm waiting for a Kurento member to verify that this patch is reasonable to test. If it is, they should reply with check out please on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

[jenkinskurento]

There were no errors, go have a cup of coffee...

[kc7bfi]

Any idea when this fix may be integrated into the main code?

[kc7bfi]

I'm not sure how to split multiple commits into different pull requests. However, I've added code to name the async threads used in the WebSocket service class.

[kc7bfi]

Any idea if an when this pull request can be added to the main development branch?

[kc7bfi]

Found some more places where the sync() call can hang and never return

[nordri]

Hi @kc7bfi

The new Kurento team is now very small (after Twilio adquisition of most of developers) and we are very busy with other issues. Sorry.

[Forcada]

Any news about if this will be accepted and integrated into the main code?

Kurento client was hanging when trying to reconnect with the Kurento Media server and this pull request solved the problem.

[pabloFuente]

Fix seems to improve ws reconnection capabilities.

[j1elo]

Sorry for the time it took, and thanks for the friendly reminder :-)
This gets in time to ship with release 6.11 In the end, the PR commit was (partially) reverted in 1827a7c

[j1elo]

Hi, after some afterwards testing and discussion, we took the decision to have @pabloFuente rolling this change back (done in 1827a7c), because it introduces a fundamental change in how connections to the media server WS API were managed, which is in essence a breaking change in functionality.

With sync mode, in their initial connection applications know when KMS is not responding or not even started, with an immediate feedback due to failed connection. Changing to future-based async means that this case would need to wait for the timeout to happen, before getting a connection failure. This breaks some of our tests, and it will also break applications that expect the old behavior. We cannot break applications.

On the other hand, the sync code does indeed have the issue of sometimes hanging indefinitely while trying a reconnect. More info: Connection to KMS hangs. This should be treated as a bug in itself, and seek proper fixing of the issue, instead of completely changing the connection paradigm from synchronous to asynchronous.

[mitch2na]

@j1elo Added a new PR that is backwards compatible #18