ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vladimir Ozerov <voze...@gridgain.com>
Subject Re: Custom ThreadFactory
Date Thu, 12 Nov 2015 18:11:38 GMT
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 <andrewkornev@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.
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message