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