We cannot use the public API inside of ignite core, but we can definitely broadcast messages whenever appropriate. Discovery SPI should only be used whenever transactionality and ordering need to be enforced, which is not the case here.
On Wed, Nov 29, 2017 at 2:21 PM, Alex Plehanov <plehanov.a...@gmail.com> wrote: > Hello, Dmitriy! > > Is it ok to use broadcast inside ignite-core? I didn't find any usage of > broadcast inside ignite, except examples, benchmarks and tests. > > For now statisticsEnabled is only property, which enable/disable cache JMX > metrics. > > 2017-11-30 0:58 GMT+03:00 Dmitriy Setrakyan <dsetrak...@apache.org>: > > > On Wed, Nov 29, 2017 at 12:22 PM, Alex Plehanov <plehanov.a...@gmail.com > > > > wrote: > > > > > Hello, Igniters! > > > > > > We need the ability to enable or disable statistics for caches in > > runtime. > > > For now, there is a cache configuration property which seems modifiable > > in > > > runtime and this, at first sight, works for local node. But there are > no > > > methods to enable or disable statistics for cache cluster wide. > > > > > > So, I propose: > > > > > > Create a new JMX operation in > > > CacheClusterMetricsMXBeanImpl/CacheLocalMetricsMXBeanImpl > > > to enable/disable statistics for cache. When invoked, operation must > set > > > statisticsEnabled flag in cache configurations. Then send a new type of > > > DiscoveryCustomMessage, which will set this flag for cache on other > nodes > > > in cluster. > > > > > > Do you have objections to this solution? > > > > > > > Why do we need a discovery message? A simple cluster broadcast should do. > > > > I think it makes sense to make this solution generic enough, so other JMX > > metrics could be enabled/disabled using the same mechanism. > > > > D. > > >
