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 >
