There you go:
https://issues.apache.org/jira/browse/IGNITE-1898
and
https://issues.apache.org/jira/browse/IGNITE-1899
Cheers
Andrey
> From: dsetrak...@apache.org
> Date: Thu, 12 Nov 2015 12:53:52 -0800
> Subject: Re: Custom ThreadFactory
> To: dev@ignite.apache.org
>
> On Thu, Nov 12, 2015 at 10:26 AM, Andrey Kornev <andrewkor...@hotmail.com>
> wrote:
>
> > 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.
> >
>
> Andrey, I think its best to summarize the design thoughts in a ticket. Then
> someone from the community will pick it up.
>
>
> >
> > 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.
> > > >
> >
> >
