Better memory management for CancellationToken

XMLWordPrintableJSON

    • Type: Improvement
    • Resolution: Unresolved
    • Priority: Major - P3
    • None
    • Affects Version/s: None
    • Component/s: None
    • Server Programmability
    • None
    • 3
    • None
    • None
    • None
    • None
    • None
    • None

      The current implementation uses futures and SharedPromise, and it makes a new future whenever a new cancelationToken is created. This design does not support listeners from unregistering themselves when they are no longer interested in the cancel event. Most common scenario is when the owner of the cancelToken finished its task. This causes long living services that owns a cancel source to accumulate listeners.

      Some services have natural points where they can safely reset the cancel source, but some services like TransactionCoordinator can only safely reset them after a step down.

            Assignee:
            Unassigned
            Reporter:
            Randolph Tan
            Votes:
            0 Vote for this issue
            Watchers:
            11 Start watching this issue

              Created:
              Updated: