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
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:
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.
The text was updated successfully, but these errors were encountered:
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:to:
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 toPerLookup
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.
The text was updated successfully, but these errors were encountered: