Skip to content
This repository has been archived by the owner on Sep 3, 2022. It is now read-only.

Makes server robust to duplicate socket.io connection events #354

Merged
merged 1 commit into from May 28, 2015

Conversation

drewbryant
Copy link
Contributor

Address issue #352

@@ -242,16 +244,24 @@ export class SessionManager implements app.ISessionManager {
return;
}

var connectionId = socket.id;
Copy link
Contributor

Choose a reason for hiding this comment

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

Where does socket.id get set?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

socket.id is set behind the scenes within the socket.io library when it creates the connection wrapper

@gramster
Copy link
Contributor

LGTM. I assume there's no pre-emption in node, right? I.e. there's no race between testing a connection's presence in _connectionIdToSession and adding it to ._connectionIdToSession.

@drewbryant
Copy link
Contributor Author

Right, there can't be any interleaved instructions between the check for presence and adding it to _connectionIdToSession due to the single threaded nature and the lack of an intervening process.nextTick (so safe from possible race conditions in this case).

drewbryant added a commit that referenced this pull request May 28, 2015
Makes server robust to duplicate socket.io connection events
@drewbryant drewbryant merged commit 1b4812c into master May 28, 2015
@drewbryant drewbryant deleted the fix/dupe-socketio-conns branch May 28, 2015 17:57
rajivpb pushed a commit to rajivpb/datalab that referenced this pull request Jun 16, 2017
* Storage object deletion waits for consistency.

Fixes googledatalab#344.

GCS object deletions are eventually consistent, in that deleting an object in
a globally-available bucket may result in the object still appearing when
listing objects in the bucket:
  https://cloud.google.com/storage/docs/consistency#eventually_consistent_operations

This is a detail, but can lead to confusion for users: someone following the
examples in the tutorial notebooks may see rare-but-regular failures about an
object they just deleted continuing to exist. (We've seen this running the
notebooks as automated tests.) This PR teaches an object to poll the bucket
until it no longer appears. This is controllable by `wait_for_deletion`, and
defaults to **on**.

I've added two tests: first is a mock-based unit test, which works; the second
is intended as a first step towards integration tests. In this case, we assume
that the user running the test has ambient credentials that `google.datalab`
will discover.
rajivpb pushed a commit to rajivpb/datalab that referenced this pull request Jun 16, 2017
…oogledatalab#357)

* Revert "Storage object deletion waits for consistency. (googledatalab#354)"

This reverts commit 3c7e44d.

* Revert "sd package: all categorical columns are multi-label columns (googledatalab#351)"

This reverts commit f1522f7.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants