Improve logging of old clientID in Container: reduce impact on perf #3675
Comments
ghost
added
the
heliocliu
added a commit
that referenced
this issue
Sep 30, 2020
…d check perf (#3704) #3675 Change the old/expired clientId check to use the quorum instead of by keeping a list of old clientIds. This works by adding a shouldHaveLeft field to the ISequencedClient in the quorum, where a reconnecting client will set its old clientId shouldHaveLeft to true (if it still exists in the client). Then when we process a message, instead of checking against a list of old clientIds, we check if the clientId exists in the quorum (messages should only be coming from clients in the quorum) and if the clientId has been marked should have left. An inactive clientId in this situation would suggest a message from an old connection of the same client (which shouldn't happen).
heliocliu
added a commit
to heliocliu/FluidFramework-1
that referenced
this issue
Oct 1, 2020
…d check perf (microsoft#3704) microsoft#3675 Change the old/expired clientId check to use the quorum instead of by keeping a list of old clientIds. This works by adding a shouldHaveLeft field to the ISequencedClient in the quorum, where a reconnecting client will set its old clientId shouldHaveLeft to true (if it still exists in the client). Then when we process a message, instead of checking against a list of old clientIds, we check if the clientId exists in the quorum (messages should only be coming from clients in the quorum) and if the clientId has been marked should have left. An inactive clientId in this situation would suggest a message from an old connection of the same client (which shouldn't happen).
heliocliu
added a commit
that referenced
this issue
Oct 1, 2020
…d check perf (#3704) (#3801) #3675 Change the old/expired clientId check to use the quorum instead of by keeping a list of old clientIds. This works by adding a shouldHaveLeft field to the ISequencedClient in the quorum, where a reconnecting client will set its old clientId shouldHaveLeft to true (if it still exists in the client). Then when we process a message, instead of checking against a list of old clientIds, we check if the clientId exists in the quorum (messages should only be coming from clients in the quorum) and if the clientId has been marked should have left. An inactive clientId in this situation would suggest a message from an old connection of the same client (which shouldn't happen).
This was referenced Aug 18, 2021
This was referenced Sep 12, 2021
Open
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This is follow up to #3613
See more detailed discussion in #3656
This kind of logging can be done more elegantly.
I'd not track 100 clients - we can avoid it via following 2 checks:
The reason I prefer this approach over one in main (above mentioned PR) is that we do not need to allocate a bunch of memory, and we also do not need to scan that much memory on any op. That's a bunch of memory to scan on every op!
While quorum can have a lot of members, it is a hash map (under the cover), so checking client is relatively cheap, and does not use more memory.
The text was updated successfully, but these errors were encountered: