You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ignite.apache.org by "Andrey Kornev (JIRA)" <ji...@apache.org> on 2015/11/13 00:27:10 UTC

[jira] [Created] (IGNITE-1898) Make it possible to obtain the local Ignite instance statically

Andrey Kornev created IGNITE-1898:
-------------------------------------

             Summary: Make it possible to obtain the local Ignite instance statically
                 Key: IGNITE-1898
                 URL: https://issues.apache.org/jira/browse/IGNITE-1898
             Project: Ignite
          Issue Type: Improvement
          Components: general
            Reporter: Andrey Kornev
            Priority: Minor


Currently the ways to obtain the local instance of Ignite make use of the grid name or the node UUID with the corresponding {{Ignition.ignite()}} methods. However, during deserialization if would sometime be desirable to be able to obtain the local instance of Ignite (the one on which the given class is being deserialized) without relying on the grid name. Such instance can then be used to look up the node-local resources and any other context. The grid name is not reliable way to serialize/deserialize {{IgniteKernal}} in a situation when a single JVM has multiple Ignite nodes started (as is often the case in unit tests).

The proposed solution is to
# implement a custom ThreadFactory to be used with the public, system, utility and so on thread pools. For all newly created thread, the factory will create a thread local and initialize it with the current instance of Ignite.
# modify the classes that create their own threads, to do the same.
# provide a public static method on the Ignition class
{{public static Ignite getLocalNode();}}
that returns the value of the thread local. It throws {{IllegalStateException}} if the method is invoked from a non-Ignite thread.

This will guarantee that all threads started by a particular Ignite instance will have the instance reference available in their thread locals.




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)