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
{{ message }}
This repository has been archived by the owner on Mar 21, 2018. It is now read-only.
If you instantiate ridley in a block which should be GCed after run, like:
1.timesdoridley=Ridley.from_chef_configend
When the Ridley class gets destroyed, there's no finalizer to clean up the celluloid threads that are spawned because of it. That example is trivial, but in an instance where it's being instantiated from inside of a route in a web framework (like a sinatra get block, or before, etc) this can very quickly baloon your ruby VM and cause an OOM.
I've worked around it by changing my code to essentially use a global ridley object that gets passed around through dependency injection (which is probably what I should've been doing anyway), but It'd be nice if the ridley class had finalizer to clean up those celluloid actors.
The text was updated successfully, but these errors were encountered:
So.. I've dug through your Ridley::Client and it seems like there is in fact a finalizer that calls finalize_callback. I'm not sure why this wouldn't fire in the above scenario, but I don't think it is 😦
@Igneous this could have been a bug in Celluloid. We just upgraded to the latest released version of Celluloid - could you try and see if that fixes your issue?
Run it with ./test.rb 5 to spawn five instances of ridley, which, (I think) should be finalized immediately after that method call completes.. Hopefully, you'll see that after each loop, the object count and the thread count continues to increase.
If you want, you can add a sleep at the end of the script to see if those threads eventually terminate, but in my experience those celluloid actors stick around as long as the vm that spawned them stays running.
If you instantiate ridley in a block which should be GCed after run, like:
When the Ridley class gets destroyed, there's no finalizer to clean up the celluloid threads that are spawned because of it. That example is trivial, but in an instance where it's being instantiated from inside of a route in a web framework (like a sinatra get block, or before, etc) this can very quickly baloon your ruby VM and cause an OOM.
I've worked around it by changing my code to essentially use a global ridley object that gets passed around through dependency injection (which is probably what I should've been doing anyway), but It'd be nice if the ridley class had finalizer to clean up those celluloid actors.
The text was updated successfully, but these errors were encountered: