Yakov, Can you explain how the need for the isXxxServiceShutdown() methods is being addressed with the new thread pool configuration?
D. On Wed, Feb 4, 2015 at 1:49 AM, Yakov Zhdanov <[email protected]> wrote: > 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. > > >
