Dmitry,
Thanks for your example! The approach looks similar to "problematic" on
used in jdk described in [1]. Fortunately, in our case buffer is quite
limited. On the other hand we always should be cautious because Ignite code
frequently is running on user threads (e.g. it is typical for SQL).
Maxim,
If multiple instances of Ignite is started in the same JVM and a user
thread will access first one instance of Ignite, then another, you will end
up with the static thread local holding the last WAL pointer from the
second grid. This is possible, for example, when a user thread commits a
Hi Ivan,
For example, I remember thread local buffer in our old WAL implementation:
org.apache.ignite.internal.processors.cache.persistence.wal.FsyncModeFileWriteAheadLogManager#tlb
Sincerely,
Dmitriy Pavlov
вт, 11 сент. 2018 г. в 13:05, Павлухин Иван :
> Dmitriy,
>
> Could you point to some
Alexey, Ivan,
Agree. Keeping strong references to the Thread object is the source of
memory leak with ThreadLocals variables
and the values that it stores. ThreadLocalMap is bound to the Thread
lifespan [1], so I think when we are using
everything right all will be GC'ed correctly.
Is this memory
Dmitriy,
Could you point to some piece of code implementing described pattern?
2018-09-11 13:02 GMT+03:00 Павлухин Иван :
> Alex,
>
> ThreadLocal subclass is used in IgniteH2Indexing for simple access to H2
> Connection from current thread. Such subclass has a capability to create
> connection
Alex,
ThreadLocal subclass is used in IgniteH2Indexing for simple access to H2
Connection from current thread. Such subclass has a capability to create
connection if one does not exist, so obtaining connection is merely
ThreadLocal.get. Also there are scheduled routines to cleanup connections
and
Hi Ivan,
I can imagine cases with temporary native or heap byte buffers in thread
locals used for IO operations.
These buffers are often Thread Local and I find it to be a perfectly ok
case.
вт, 11 сент. 2018 г. в 11:00, Alexey Goncharuk :
> Ivan,
>
> Can you elaborate on the issue with the
Ivan,
Can you elaborate on the issue with the thread local cleanup you've faced?
вт, 11 сент. 2018 г. в 9:13, Павлухин Иван :
> Guys,
>
> As we know ThreadLocal is an instrument which should be used with great
> care. And I recently faced with problems related to proper cleanup of
> ThreadLocal
Guys,
As we know ThreadLocal is an instrument which should be used with great
care. And I recently faced with problems related to proper cleanup of
ThreadLocal which is not needed anymore. In my opinion the best thing (in
ideal world) is to get rid of ThreadLocal where possible, but I guess that
Maxim,
Ignite supports starting multiple instances of Ignite in the same VM, so
having static thread locals for the fields you mentioned does not work.
Generally, I think thread-local should be bound to the lifespan of the
component it describes. Static thread-locals are hard to clean-up and
Igniters,
According to javadoc [1] class ThreadLocal:
`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).`
So, AFAIK non-static ThreadLocal usage means as `per thread - per class
instance`. What
11 matches
Mail list logo
