Currently, configuration is being refactored and pools will be created internally only.
--Yakov 2015-02-04 12:40 GMT+03:00 Vladimir Ozerov <[email protected]>: > 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. >
