[
https://issues.apache.org/jira/browse/CALCITE-3325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16926905#comment-16926905
]
Josh Elser commented on CALCITE-3325:
-------------------------------------
{quote}From my understanding objects stored in ThreadLocal are not removed
until a garbage collection happens due to insufficient memory, see in
java.lang.ThreadLocal.ThreadLocalMap:
{quote}
That rings a bell.
{quote}The client code runs on jetty which has a fixed thread pool for serving
the requests. We use a client side connection pool Avatica connections. The
connections could be recycled and used between threads but the connection pool
could also create/drop connections as necessary.
{quote}
When do you reuse a Connection/Thread vs. create a new one? Is the ThreadPool
you use a standard fixed java.util.concurrent.ThreadPool? (e.g. created by
{{Executors.newFixedThreadPool(int)}}?)
The thing I am looking from you is some clear indication that this is not a
symptom that your test framework is inducing. Right now, it's not clear to me
whether there is a problem in Avatica or you're just doing something in your
test harness that is exacerbating the GC.
Finally, let me be super clear: marking the buffer as static is _very wrong_.
As the name indicates, there is no synchronization of this buffer. If you are
reusing this buffer, it's going to result in data corruption issues.
> Thread Local Buffer Variable (threadLocalBuffer) In ProtobufTranslationImpl
> Is Defined As Non Static Causing Memory Leak
> ------------------------------------------------------------------------------------------------------------------------
>
> Key: CALCITE-3325
> URL: https://issues.apache.org/jira/browse/CALCITE-3325
> Project: Calcite
> Issue Type: Bug
> Reporter: Mehdi Salarkia
> Priority: Major
> Attachments: Non-Static.snapshot, Non-static.png, Screen Shot
> 2019-09-05 at 5.05.20 PM.png, Screen Shot 2019-09-05 at 5.18.19 PM.png,
> Static.png, Static.snapshot
>
>
> As we were load testing our system on Apache Phoenix via the thin client
> which uses Avatica we ran into Garbage collection problems. After some
> investigation we could see there are a lot of unreferenced object due to this
> variable:
> {code:java}
> private final ThreadLocal<UnsynchronizedBuffer> threadLocalBuffer =
> new ThreadLocal<UnsynchronizedBuffer>() {
> @Override protected UnsynchronizedBuffer initialValue() {
> return new UnsynchronizedBuffer();
> }
> };
> {code}
> Which seems to be a reusable buffer for serializing/deserializing the data.
> From my understating there is a copy of this variable created per each
> instance of ProtobufTranslationImpl. However the proper use of ThreadLocal it
> seems to be one instance per thread and the current implementation seems to
> be missing the `static` keyword when defining the thread local variable:
> See [https://docs.oracle.com/javase/7/docs/api/java/lang/ThreadLocal.html]
> {code:java}
> ThreadLocal instances are typically private static fields in classes that
> wish to associate state with a thread (e.g., a user ID or Transaction ID).
> {code}
> See the attached snapshot from a memory dump we took.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
