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
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
In the ThreadCachingPool whenever an object is picked from the ThreadLocal we cannot add it to the disposed queue directly since the
object will already be present in the live queue (or will be on release). Doing
that means that the object will be present both in the live and disposed
queue and also means that on reallocation we can multiple copies of the same
reference and can lead to that the live queue blows up in size.
In the `ThreadCachingPool` whenever an object is picked from the
`ThreadLocal` we cannot add it to the `disposed` queue directly since the
object will already be present in the `live` queue (or will be on release). Doing
that means that the object will be present both in the `live` and `disposed`
queue and also means that on reallocation we can multiple copies of the same
reference and can lead to that the `live` queue blows up in size.
Previously whenever an object was picked off the thread local cache it was
added back to the live queue even thought it was never removed from there.
This lead to indefinite growth of the live queue.
The reason will be displayed to describe this comment to others. Learn more.
It is indeed :) This seems acceptable to me, since it's in a test - but it does smell, and it smells like a missing abstraction. If we find ourselves digging deeper into this hole, one thing we could explore is to make the queues in the pool into some sort of service, so the pool takes an "ItemStorageService" or something that exposes the domain methods the pool is using the queues for. Then the test can inject its own "counting item storage" or whatever.
Something something back in my day we never did hacks.
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
In the
ThreadCachingPool
whenever an object is picked from theThreadLocal
we cannot add it to thedisposed
queue directly since theobject will already be present in the
live
queue (or will be on release). Doingthat means that the object will be present both in the
live
anddisposed
queue and also means that on reallocation we can multiple copies of the same
reference and can lead to that the
live
queue blows up in size.