Fix unsubscribed server side behavior
#23715
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Good catch. Test coverage to demonstrate the expected behavior? |
|
Was working on this earlier, but added a regression test to show the expected behavior. cc @matthewd since we talked about this in Campfire. |
maclover7
force-pushed
the
fix-unsubscribe
branch
from
59e908c
to
28f40a7
Compare
| c.send_message command: 'subscribe', identifier: JSON.dump(channel: 'EchoChannel') | ||
| assert_equal({"identifier"=>"{\"channel\":\"EchoChannel\"}", "type"=>"confirm_subscription"}, c.read_message) | ||
| assert_equal(1, app.connections.count) | ||
| assert_equal(1, app.connections.first.subscriptions.method(:subscriptions).call.count) |
There was a problem hiding this comment.
This is ugly (and definitely not public API), but is still necessary to demonstrate the regression test.
|
@jeremy updated with regression test - all set to go? |
| @@ -54,7 +54,7 @@ def identifiers | |||
| end | |||
|
|
|||
| def unsubscribe_from_all | |||
| subscriptions.each { |id, channel| channel.unsubscribe_from_channel } | |||
| subscriptions.each { |id, channel| remove({ 'identifier' => id }) } | |||
There was a problem hiding this comment.
Can we use remove_subscription(channel) here? This feels like unnecessary indirection (and I think I'd actually argue we don't want the log lines).
maclover7
force-pushed
the
fix-unsubscribe
branch
3 times, most recently
from
97dc23c
to
0402df5
Compare
Before this commit, the `unsubscribed` callbacks in Action Cable server side channels were never called. This is because when a WebSocket "goodbye" message was sent from the client, the Action Cable server didn't properly clean up after the now closed WebSocket. This means that memory could possibly skyrocket with this behavior, since part of this commit is to properly remove closed subscriptions from the global subscriptions hash. Say you have 10,000 users currently connected, and then all 10,000 disconnect -- before this patch, Action Cable would still hold onto information (and Ruby objects!) for all of these now dead connections.
maclover7
force-pushed
the
fix-unsubscribe
branch
from
0402df5
to
cefcc0f
Compare
matthewd
added a commit
that referenced
this pull request
Feb 19, 2016
Fix `unsubscribed` server side behavior
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Closes #23708
Before this commit, the
unsubscribedcallbacks in Action Cable serverside channels were never called. This is because when a WebSocket
"goodbye" message was sent from the client, the Action Cable server
didn't properly clean up after the now closed WebSocket. This means that
memory could possibly skyrocket with this behavior, since part of this
commit is to properly remove closed subscriptions from the global
subscriptions hash. Say you have 10,000 users currently connected, and
then all 10,000 disconnect -- before this patch, Action Cable would
still hold onto information (and Ruby objects!) for all of these now
dead connections.
cc @dhh @matthewd