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

Document Singleton Scope Requirements #59

Open
dclements opened this issue Oct 14, 2019 · 4 comments
Open

Document Singleton Scope Requirements #59

dclements opened this issue Oct 14, 2019 · 4 comments

Comments

@dclements
Copy link

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.

@dclements
Copy link
Author

Relevant details:

  • Dropwizard 1.3.14
  • dropwizard-guicier: 1.3.5.2

@jhaber
Copy link
Member

jhaber commented Oct 14, 2019

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

@jhaber
Copy link
Member

jhaber commented Oct 14, 2019

Also none of our Jersey resource classes are singletons

@dclements
Copy link
Author

Weird, let me see if I can build a reliable reproduction.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants