ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yakov Zhdanov <yzhda...@apache.org>
Subject Re: "executorServiceShutdown" properties concept review.
Date Wed, 04 Feb 2015 09:49:42 GMT
Currently, configuration is being refactored and pools will be created
internally only.

--Yakov

2015-02-04 12:40 GMT+03:00 Vladimir Ozerov <vozerov@gridgain.com>:

> Hi,
>
> I'd like to start the discussion about infamous "shutdown" properties in
> configuration classes:
>
>    - IgniteConfiguration.executorServiceShutdown()
>    - IgniteConfiguration.ggfsExecutorServiceShutdown()
>    - IgniteConfiguration.managementExecutorServiceShutdown()
>    - IgniteConfiguration.peerClassLoadingExecutorServiceShutdown()
>    - IgniteConfiguration.systemExecutorServiceShutdown()
>    - IgniteConfiguration.restExecutorServiceShutdown()
>    - ClientConnectionConfiguration.restExecutorServiceShutdown()
>
> This yields in 12 additional methods in IgniteConfiguration and 2 in
> ClientConnectionConfiguration.
> Reason why we have these properties is clear: if you starts Ignite in
> embedded mode and provides his own thread pool, he may want to keep it
> running even after Ignite node is stopped.
>
> On the other hand, it seems to me that custom executor service is pretty
> unusal and rare use case.
>
> What if we create wrapper class encapsulating both executor service and
> shutdown flag? E.g.:
> IgniteExecutorServiceConfiguration {
>     ExecutorService getExecutorService();
>     bool isExecutorServiceShutdown();
> }
>
> This will remove 6 properties. +19 deprecated client-related properties
> which are also will be removed. In summary, we will be able to remove 25
> properties (of 103 currently) from IgniteConfiguration.
>
> Any thoughts on this?
>
> Vladimir.
>

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