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 <alexey.goncha...@gmail.com>: > Ivan, > > Can you elaborate on the issue with the thread local cleanup you've faced? > > вт, 11 сент. 2018 г. в 9:13, Павлухин Иван <vololo...@gmail.com>: > > > 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 > > it is quite hard (in real world). > > > > Also, a question comes to my mind. As ThreadLocal is so common in our > code, > > could you suggest some guidance or code fragments which address proper > > ThreadLocal > > lifecycle control and especially cleanup? > > > > 2018-09-10 12:46 GMT+03:00 Alexey Goncharuk <alexey.goncha...@gmail.com > >: > > > > > 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 > > they > > > often lead to leaks, so I would rather changed existing static > > > thread-locals to be non-static. > > > > > > --AG > > > > > > пн, 10 сент. 2018 г. в 11:54, Maxim Muzafarov <maxmu...@gmail.com>: > > > > > > > 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 the real cases of using non-static ThreadLocal class > > > fields > > > > in Ignite code project? When we need it? > > > > > > > > In Ignite code project I've found ThreadLocal usage as: > > > > - non-static - 67 > > > > - static - 68 > > > > > > > > Back to my example, I've checked FileWriteAheadLogManager. It has: > > > > 1) private final ThreadLocal<Boolean> interrupted [2] > > > > 2) private final ThreadLocal<WALPointer> lastWALPtr [3] > > > > I think both of these fields should be set and used as `static`. Can > > > anyone > > > > confirm it? > > > > > > > > > > > > [1] > > https://docs.oracle.com/javase/8/docs/api/java/lang/ThreadLocal.html > > > > [2] > > > > > > > > https://github.com/apache/ignite/blob/master/modules/ > > > core/src/main/java/org/apache/ignite/internal/processors/ > > > cache/persistence/wal/FileWriteAheadLogManager.java#L253 > > > > [3] > > > > > > > > https://github.com/apache/ignite/blob/master/modules/ > > > core/src/main/java/org/apache/ignite/internal/processors/ > > > cache/persistence/wal/FileWriteAheadLogManager.java#L340 > > > > -- > > > > -- > > > > Maxim Muzafarov > > > > > > > > > > > > > > > -- > > Best regards, > > Ivan Pavlukhin > > >
