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. > > > > >
