Re: Naming style for configuration properties defining durations in Ignite 3

2022-12-27 Thread Roman Puchkovskiy
It's an interesting idea. That would solve the problem for configuration files (or other external representations of a configuration, like JMX or whatnot). As for the Java API, we could model durations with java.time.Duration instances, so it would be /** Node join timeout. */ @Value(hasDefault =

Re: Naming style for configuration properties defining durations in Ignite 3

2022-12-26 Thread Alexei Scherbakov
What about specifying dimensions in config, like joinTimeout=5s Internally it is always stored in millis. пт, 23 дек. 2022 г. в 11:53, Pavel Tupitsyn : > Agree with the proposal. > Those properties go into config files (json/hocon), and it is difficult to > navigate to relevant docs from

Re: Naming style for configuration properties defining durations in Ignite 3

2022-12-23 Thread Pavel Tupitsyn
Agree with the proposal. Those properties go into config files (json/hocon), and it is difficult to navigate to relevant docs from there. I would go with point 3 - longer suffixes like Millis - to make it unambiguous. On Fri, Dec 23, 2022 at 10:06 AM Roman Puchkovskiy <

Naming style for configuration properties defining durations in Ignite 3

2022-12-23 Thread Roman Puchkovskiy
Hi Igniters! In Ignite 3, in configuration schemas, we have some properties that define durations/intervals (usually, these are timeout durations). Almost always they are defined without mentioning the duration unit, like this: /** Node join timeout. */ @Value(hasDefault = true) public int