You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In rare circumstances (which have been observed), it is possible that CertMagic can gradually leak goroutines & memory by piling up a renewal queue if there are persistent errors for a lot of the obtain/renewal operations in a call to ManageAsync.
This is because the exponential backoff can span up to a month, and renewal checks are done every 12 hours by the maintenance goroutine, but the two don't coordinate: the maintenance goroutine has no idea that ManageAsync is still trying to renew. With the internal rate limiter and exponential backoff, it seems that it is possible for duplicate operations to pile up unnecessarily.
Either add some coordination so that cert ops are de-duplicated within the process, or adjust locking via storage so that locks are longer-lived, through errors and retries (but this will require us to put a liveliness timestamp in the lockfile, actively updating it every so often, as opposed to our current lazy method).
The text was updated successfully, but these errors were encountered:
In rare circumstances (which have been observed), it is possible that CertMagic can gradually leak goroutines & memory by piling up a renewal queue if there are persistent errors for a lot of the obtain/renewal operations in a call to ManageAsync.
This is because the exponential backoff can span up to a month, and renewal checks are done every 12 hours by the maintenance goroutine, but the two don't coordinate: the maintenance goroutine has no idea that ManageAsync is still trying to renew. With the internal rate limiter and exponential backoff, it seems that it is possible for duplicate operations to pile up unnecessarily.
Either add some coordination so that cert ops are de-duplicated within the process, or adjust locking via storage so that locks are longer-lived, through errors and retries (but this will require us to put a liveliness timestamp in the lockfile, actively updating it every so often, as opposed to our current lazy method).
The text was updated successfully, but these errors were encountered: