dropwizard-guicier
dropwizard-guicier copied to clipboard
Document Singleton Scope Requirements
I don't think this is a bug in your system, but it would be helpful to have some documentation around where singleton needs to be used to prevent memory problems.
Our situation was as follows:
We migrated to using dropwizard-guicier
from creating the instances for the API resource classes. Basically this allowed us to go from:
environment.jersey().register(injector.getInstance(Foo.class));
to:
environment.jersey().register(Foo.class);
Everything looked like it worked well, but then it turned out that every request was creating a new instance of Foo and then jersey was holding on to that reference indefinitely, leading to eventual out of memory errors. This does not appear to be a problem for, e.g., Filters but it definitely is for API resources (I haven't had a chance to dig into it yet and find a root cause).
Changing the binding to scope it as a singleton removed this problem. My understanding is that HK2 bypasses this problem by considering certain things Singleton
as opposed to PerLookup
by default, though I am not as well versed on the details here.
For this project it would be helpful from a documentation standpoint to indicate which objects need to be marked as Singletons to prevent memory issues.
Relevant details:
- Dropwizard 1.3.14
- dropwizard-guicier: 1.3.5.2
Hmm, do you have a small app that reproduces the issue? You could maybe build on the existing example app if it's more convenient: https://github.com/jhaber/dropwizard-guicier-example
Internally we do binder.bind(Foo.class);
which will get picked up and registered as a Jersey resource by DropwizardModule
here
However, I would expect that to be roughly equivalent to environment.jersey().register(Foo.class)
so I'm a bit stumped
Also none of our Jersey resource classes are singletons
Weird, let me see if I can build a reliable reproduction.