Optimize Player Update Messaging

[lstertz]

Currently, player updates are periodically streamed from Edge to Cloud. To ensure data integrity (in the foreach of the collection of players known to Edge), the collection of players is currently copied. This won't be practical to do at scale.

A second concern from memory profiling is that the PlayerUpdates being streamed are not being garbage collected, essentially creating a memory leak. There may be a similar issue with all of the long-running streaming methods being used to communicate between the projects. This should first be troubleshooted for the PlayerUpdate stream, with an evaluation of whether the memory leak is resolved by using non-streaming methods or by implementing the streaming differently (if possible).

Definition of Done

• Player management by the streaming method is done efficiently in the anticipation of scale.
• Memory leaks caused by streaming are corrected, either through changes to the streaming itself or a transition to non-streaming messaging.
  • If the messaging is switched to non-streaming, then the player updates should be batched together in a single message.

[lstertz]

Upon further investigation, it was determined that the slow build-up of PlayerUpdates were not being garbage collected because the system had determined it was not yet necessary. Upon forcing a garbage collection, the messages were being cleaned up as expected.

The former concern for effectively iterating over players was managed with concurrent collections and the use of the enumerators, which prevents copies and locks, but can result in value inconsistencies as the enumeration can be changed by other threads. In the cases for how the player collections are being iterated, this is an acceptable circumstance.

In accordance with the above, the concerns have been addressed and this ticket is resolved.