Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Introduce system for garbage collecting connection managers #851

Merged
merged 1 commit into from
Sep 20, 2019

Commits on Sep 20, 2019

  1. Introduce system for garbage collecting connection managers

    Introduces a system for garbage collecting connection managers in an
    attempt to solve #850.
    
    Previously, the number of connection managers (and by extension the
    number of connections that they were holding) would stay stable if a
    program used a stable number of threads. However, if threads were used
    disposably, the number of active connection managers out there could
    continue to grow unchecked, and each of those could be holding one or
    more dead connections which are no longer open, but still holding a file
    descriptor waiting to be unlinked in disposed of by Ruby's GC.
    
    This PR introduces a connection manager garbage collector that runs
    periodically whenever a new connection manager is created. Connection
    managers get a timestamp to indicate when they were last used, and the
    GC runs through each one and prunes any that haven't seen use within a
    certain threshold (currently, 120 seconds). This should have the effect
    of removing connection managers as they're not needed anymore, and thus
    resolving the socket leakage seen in #850.
    
    I had to make a couple implementation tweaks to get this working
    correctly. Namely:
    
    * The `StripeClient` class now tracks thread contexts instead of
      connection managers. This is so that when we're disposing of a
      connection manager, we can set `default_connection_manager` on its
      parent thread context to `nil` so that it's not still tracking a
      connection manager that we're trying to get rid of.
    
    * `StripeClient` instances can still be instantiated as before, but no
      longer internalize a reference to their own connection manager,
      instead falling back to the one in the current thread context. The
      rationale is that when trying to dispose of a connection manager, we'd
      also have to dispose of its reference in any outstanding
      `StripeClient` instances that might still be tracking it, and that
      starts to get a little unwieldy. I've left `#connection_manager` in
      place for backwards compatibility, but marked it as deprecated.
    brandur committed Sep 20, 2019
    Configuration menu
    Copy the full SHA
    c905edc View commit details
    Browse the repository at this point in the history