Implement the client table for the new GCS #1674
Conversation
|
Test PASSed. |
|
Test PASSed. |
| // duplicate notifications. | ||
| if (client_data->is_insertion() && | ||
| RedisModule_KeyType(clients_key) != REDISMODULE_KEYTYPE_EMPTY) { | ||
| // NOTE(swang): Sets are not implemented yet, so we use ZSETs instead. |
There was a problem hiding this comment.
For the main data in the GCS we want to get rid of redis datastructure (e.g. for flushing or if somebody wants to use a different system for the GCS); for the client tables it's ok I think since it is very small and won't get flushed (and probably will move into etcd at some point), but for the other tables let's keep it in mind.
There was a problem hiding this comment.
That makes sense. If we want to remove the data structure from the server for the client table, we can go back to the design where a client scans the client table when it first subscribes. I just did not do that here since we don't have a "scan" API for the new GCS client.
|
I merged master into this branch and resolved conflicts. The major conflicts were with |
|
Test PASSed. |
|
Test PASSed. |
|
Test PASSed. |
|
Test PASSed. |
|
Test PASSed. |
|
Test PASSed. |
| RAY_CHECK(!client_id.is_nil()); | ||
| auto entry = client_cache_.find(client_id); | ||
| if (entry != client_cache_.end()) { | ||
| return entry->second; |
There was a problem hiding this comment.
Should this include a check for entry->second.is_insertion?
There was a problem hiding this comment.
No, it includes clients that have disconnected.
|
Test PASSed. |
stephanie-wang
force-pushed
the
client-table
branch
from
6cd7c22 to
e4d3fce
Compare
|
Test PASSed. |
|
Test PASSed. |
|
Added a couple fixes for some memory issues I was seeing in |
What do these changes do?
This adds a client table to the GCS, with pubsub functionality for new and deleted clients. After attaching the
AsyncGcsClientto an event loop, the caller should callClientTable::Connect()to notify others of its client information.Upon connection, the client will receive notifications about all other clients and whether they are alive or dead. Notifications may be duplicated but are delivered in order for idempotency. For convenience, these notifications are cached in the
ClientTable. Once a client has disconnected, its death will be published to all other clients, and it should not reconnect with the same client ID.