Avoid marking objects as both live and disposed #178
Conversation
pontusmelke
force-pushed
the
1.0-thread-caching-bug
branch
3 times, most recently
from
a52f03b to
76dd71b
Compare
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.
pontusmelke
force-pushed
the
1.0-thread-caching-bug
branch
from
76dd71b to
246ebaa
Compare
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.
|
|
||
| //This is terrible hack, but I really want to keep the queues private in | ||
| //ThreadCachingPool | ||
| private static MethodHandle queueGetter( String name ) |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Yeah I found this code, https://github.com/neo4j/neo4j/commits/3.1/community/bolt/src/main/java/org/neo4j/bolt/v1/packstream/utf8/SunMiscUTF8Encoder.java?author=jakewins, on teh internets and ran with it. Seemed legit.
|
I'll forward-merge to 1.1 as well |
Revert "Merge pull request #178 from pontusmelke/1.0-thread-caching-bug"
2 participants
In the
ThreadCachingPoolwhenever an object is picked from theThreadLocalwe cannot add it to thedisposedqueue directly since theobject will already be present in the
livequeue (or will be on release). Doingthat means that the object will be present both in the
liveanddisposedqueue and also means that on reallocation we can multiple copies of the same
reference and can lead to that the
livequeue blows up in size.