ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vladimir Ozerov <voze...@gridgain.com>
Subject "executorServiceShutdown" properties concept review.
Date Wed, 04 Feb 2015 09:40:29 GMT

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


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