[
https://issues.apache.org/jira/browse/CALCITE-3325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mehdi Salarkia updated CALCITE-3325:
------------------------------------
Description:
As we weere 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.
was:
As we weere 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}
> 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: Screen Shot 2019-09-05 at 5.18.19 PM.png
>
>
> As we weere 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)
