Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fixed race conditions with promises when closing Nodes #1429

Merged
merged 2 commits into from
Jul 11, 2019

Conversation

lodoyun
Copy link
Contributor

@lodoyun lodoyun commented Jul 10, 2019

Description

This PR fixes two problems with closeNode:
1 - MediaStream close promise was not resolved because the future_async_ was closed as part of the process, now the async will be closed after it notifies the completion of the task
2 - When WebRTCConnection is closed as part of closeNode because we're closing the last mediaStream in that connection, we would not resolve the removeStream promise. Now we make sure the stream is removed and the promise resolved before checking if we should close the connection

[] It needs and includes Unit Tests

Changes in Client or Server public APIs

[] It includes documentation for these changes in /doc.

Copy link
Contributor

@jcague jcague left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM in general. I'm just a bit concerned about the new async logic when closing the node in ErizoJS.

@@ -56,7 +56,7 @@ MediaStream::MediaStream() : closed_{false}, id_{"undefined"} {
future_async_ = new uv_async_t;
uv_async_init(uv_default_loop(), async_stats_, &MediaStream::statsCallback);
uv_async_init(uv_default_loop(), async_event_, &MediaStream::eventCallback);
uv_async_init(uv_default_loop(), future_async_, &MediaStream::promiseResolver);
uv_async_init(uv_default_loop(), future_async_, &MediaStream::closePromiseResolver);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

np: shouldn't we call this close_future_async_?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure 👍

`clientId: ${clientId}, streamId: ${node.streamId}`);
return;
}
const remainingConnections = client.maybeCloseConnection(connection.id);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

heads up: this could result in new issues given that maybeCloseConnection is now async

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree, and we will have to test and monitor this. However, having the WebRTCConnection object being destroyed because of maybeCloseConnection while removeStream is potentially still running is also not ideal.

obj->futures_manager_.cleanResolvedFutures();
obj->Ref();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

@lodoyun lodoyun merged commit 667b3cc into lynckia:master Jul 11, 2019
Arri98 pushed a commit to Arri98/licode that referenced this pull request Apr 6, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants