Closed marshall-lee closed 9 years ago
@aserafin hopefully it will be merged very soon.
Thanks, I've totally overlooked it :)
Pushed to rubygems https://rubygems.org/gems/grape_logging/versions/1.1.1
btw this flaw is very serious. it's similar to saving every response body to memory. it was bloating our servers memory. application server process could reach about 3 GB memory consumption or more.
yes, I understand that. that's why it was merged and new version was released so quick
thanks!
Besides memory leakage this bug also slows down CPU.
Suppose our application process served 1_000_000
requests before. So one million callbacks will be registered. Each executing sql query will trigger million callbacks!
@marshall-lee is this PR have fixed all your leakage issues?
@dmitry We are testing it right now in a working application.
But in a sample application ObjectSpace
tracing is not showing leakage of middleware instances anymore. Before this patch every request leaked constantly three Grape::Middleware
instances.
I also don't know what will be in the case of unhandled exception. Does it still go through this middleware?
@marshall-lee looks like it is: https://github.com/aserafin/grape_logging/blob/master/lib/grape_logging/formatters/default.rb#L12
@dmitry @marshall-lee but that's only if you explicitly want to do it in the rescue :all
block, see here https://github.com/aserafin/grape_logging#logging-exceptions
@dmitry @aserafin please see #8
Middleware objects are temporary but
ActiveSupport::Notifications
subscription is global.Closure (created by middleware instance during single request) survives further garbage collections. Closure object reaches middleware instance, middleware instance reaches
env
hash andresponse
object (containing status code and body btw!) so they are all cannot be collected. There is a lot of leaking per-request memory that stays alive after the request is finished!