Even better, Ignite might provide out-of-the-box access to the local instance
via a
thread local. It could be in a form of a static public
method on the Ignition class.
Ignite itself could benefit from
this feature as it does get it wrong occasionally. A good example of
this is the ClusterGroupAdapter class or any other class that serializes
the instance of IgniteKernal. Imagine the situation where you have a
single JVM with multiple Ignite nodes started -- Ignite requires the
grid names to be different. But since only the name of the grid is
serialized, during deserialization an invalid (unexpected, to put it
mildly) instance of IgniteKernal is looked up. I don't know how serious
it is, but it is probably a bug.
Regards
Andrey
> Date: Thu, 12 Nov 2015 21:11:38 +0300
> Subject: Re: Custom ThreadFactory
> From: voze...@gridgain.com
> To: dev@ignite.apache.org
>
> I would avoid running any external payloads in public pool because it could
> unpredictably affect Ignite internals. "Public" doesn't mean "opened for
> everyone" here.
>
> On the other hand, I abosuletly agree that removing possibility to
> configure custom pools was not very good idea. I do not see any problems
> with returning it back while still keeping "thread count" property for the
> most common use case when custom pool is not needed/
>
> On Thu, Nov 12, 2015 at 9:02 PM, Andrey Kornev <andrewkor...@hotmail.com>
> wrote:
>
> > Hello,
> >
> > If my memory doesn't fail me, in the pre-Ignite versions of GridGain, it
> > was possible to configure custom executor services which would then be used
> > to create the public, system, utility, etc. thread pools. In Ignite however
> > it's only possible to configure the size of the thread pools and not their
> > implementations.
> >
> > This is unfortunate as I'd like to be able to configure my own
> > ThreadFactory. My implementation would for example ensure that newly
> > created threads have their thread locals properly initialized (for example,
> > by storing the local instance of Ignite in it). Specific use case is being
> > able to get hold of the local Ignite instance during deserialization when
> > the JVM instance has multiple Ignite nodes started. Some of my classes must
> > be able to access resources that are local to the node on which they are
> > being deserialized. At the moment there is absolutely no way of achieving
> > something like that.
> >
> > I'm wondering if it would be possible to add this feature back to Ignite?
> > It seems to be indispensable for unit testing.
> >
> > Alternatively, to reduce the impact on the public API, an environment
> > variable that takes an FQN of the ThreadFactory to use would also work. It
> > would be injectable with the Ignite resources in the manner similar to how
> > it's done for the closures and factories...
> >
> > Regards
> > Andrey
> >
> > PS. While we're at it, I also remember that in the pre-Ignite versions it
> > was possible to inject an instance of the public executor service into the
> > closures. Not anymore. It causes the inconvenience of starting another
> > thread pool while there is already a public pool managed by Ignite with
> > plenty of threads idling most of the time... It feels wasteful.
> >
