You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ignite.apache.org by Ilya Kasnacheev <il...@gmail.com> on 2020/09/07 11:40:48 UTC
Re: [DISCUSSION] Output IgniteSystemProperties via ignite.sh
Hello!
I think this is a bad idea since it legitimizes wide use of IGNITE_
properties, which shows weakness of our configuration API, etc.
My take:
All of IGNITE_ properties which are useful (and will go to -X) should
instead be turned into configuration/metastore settings.
All of IGNITE_ properties which are dangerous and/or useless should be
removed.
Regards,
--
Ilya Kasnacheev
пт, 21 авг. 2020 г. в 16:50, Nikolay Izhikov <ni...@apache.org>:
> Hello, Igniters.
>
> For now, we have dozens of the `IgniteSystemProperties` [1] that can
> tweak Ignite behaviour in the very wide limits.
> But, the issue, for the administrator is the following
>
> - Documentation about existing properties can be outdated.
> - The only place of the truth is the source code.
> - It’s hard to understand what flag is supported in what version.
>
> I propose to implement output of all available properties with it’s
> descriptions in the `ignite.sh -X` command.
>
> Example of the JVM output:
>
> ```
> [16:25:49]~/src/ignite:[master]$ java -X
>
> -Xbatch disable background compilation
> -Xbootclasspath/a:<directories and zip/jar files separated by :>
> append to end of bootstrap class path
> -Xcheck:jni perform additional checks for JNI functions
> -Xcomp forces compilation of methods on first invocation
> -Xdebug provided for backward compatibility
> -Xdiag show additional diagnostic messages
> -Xfuture enable strictest checks, anticipating future default
> -Xint interpreted mode execution only
> -Xinternalversion
> displays more detailed JVM version information than
> the
>
> [16:28:45]~/src/ignite:[master]$ java -XX:+UnlockDiagnosticVMOptions
> -XX:+PrintFlagsFinal -version
>
> [Global flags]
> ccstrlist AOTLibrary =
> {product} {default}
> bool AbortVMOnCompilationFailure = false
> {diagnostic} {default}
> ccstr AbortVMOnException =
> {diagnostic} {default}
> ccstr AbortVMOnExceptionMessage =
> {diagnostic} {default}
> bool AbortVMOnSafepointTimeout = false
> {diagnostic} {default}
> bool AbortVMOnVMOperationTimeout = false
> {diagnostic} {default}
> intx AbortVMOnVMOperationTimeoutDelay = 1000
> {diagnostic} {default}
> int ActiveProcessorCount = -1
> {product} {default}
>
> ```
>
> Example of the Ignite output:
>
> ````
> > ignite.sh -X
> IGNITE_CONFIG_URL
> - System property to hold optional configuration URL.
> IGNITE_SSH_HOST -
> System property to hold SSH host for visor-started nodes.
> IGNITE_MIN_BUFFERED_COMMUNICATION_MSG_CNT - [DEPRECATED]
> System property to disable buffered communication if node sends less
> messages count than specified by this property. Default value is {@code
> 512}.
>
> …
>
> ```
>
> WDYT?
>
> [1]
> https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/IgniteSystemProperties.java#L56
Re: [DISCUSSION] Output IgniteSystemProperties via ignite.sh
Posted by Nikolay Izhikov <ni...@apache.org>.
Ilya.
> I'm just saying that we can make it possible as a general principle.
+1 to remove as many internal flags as possible.
> 7 сент. 2020 г., в 20:20, Ilya Kasnacheev <il...@gmail.com> написал(а):
>
> Hello!
>
> I'm not arguing that it should not be discussed. I'm just saying that we
> can make it possible as a general principle.
>
> Regards,
> --
> Ilya Kasnacheev
>
>
> пн, 7 сент. 2020 г. в 19:01, Nikolay Izhikov <ni...@apache.org>:
>
>>> We can make a compromise here: we list flags explicitly *but then, we
>>>
>>> decide that we don't keep backward compatibility anymore*, since the user
>>> of a new version can check whether their flag is still supported by using
>>> control.sh.
>>
>> It seems removal of any IgniteSystemProperty flag should be discussed
>> separately.
>>
>>
>>> 7 сент. 2020 г., в 18:46, Ilya Kasnacheev <il...@gmail.com>
>> написал(а):
>>>
>>> Hello!
>>>
>>> We do replace some flags with cfg properties, such as inline size, for
>>> example.
>>> A lot of other flags just duplicate cfg properties.
>>>
>>> We can make a compromise here: we list flags explicitly *but then, we
>>> decide that we don't keep backward compatibility anymore*, since the user
>>> of a new version can check whether their flag is still supported by using
>>> control.sh.
>>>
>>> WDYT?
>>>
>>> Regards,
>>> --
>>> Ilya Kasnacheev
>>>
>>>
>>> пн, 7 сент. 2020 г. в 18:34, Nikolay Izhikov <ni...@apache.org>:
>>>
>>>> Ilya.
>>>>
>>>>> to remove any expectation of forward compatibility.
>>>>
>>>> AFAIK we must keep these flags before Ignite3, due to the backward
>>>> compatibility.
>>>>
>>>>
>>>>> Flags should be a temporary measure
>>>>
>>>> This is not true, for now.
>>>> I feel your pain :)
>>>> Personally, I hate these flags, also.
>>>>
>>>> But they exist and the whole point of this change is to make the life of
>>>> Ignite users a bit easier.
>>>>
>>>>> 7 сент. 2020 г., в 17:32, Philipp Masharov <ma...@gmail.com>
>>>> написал(а):
>>>>>
>>>>> Let me notice that in Ignite 3.0 Wishlist [1] we have a bullet point
>>>>> "Remove as many IGNITE_ parameters as possible from
>>>> IgniteSystemProperties
>>>>> <
>>>>
>> https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/IgniteSystemProperties.html
>>>>> "
>>>>>
>>>>>
>>>>> [1]
>>>>>
>>>>
>> https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+3.0+Wishlist
>>>>> "
>>>>>
>>>>> On Mon, Sep 7, 2020 at 5:24 PM Ilya Kasnacheev <
>>>> ilya.kasnacheev@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Hello!
>>>>>>
>>>>>> Okay, we can do a simple list of these flags, but I would argue that
>> we
>>>>>> should:
>>>>>> - Avoid adding extra infrastructure such as flags' human readable
>> names,
>>>>>> embedded docs, etc. Flags should be a temporary measure. They are now.
>>>>>> Let's not make it look like they're there to stay.
>>>>>> - Explicitly mention in the -X output that these flags may be
>>>>>> removed/converted to configuration properties in the future, to remove
>>>> any
>>>>>> expectation of forward compatibility.
>>>>>>
>>>>>> They bother me for quite some time.
>>>>>>
>>>>>> Regards,
>>>>>> --
>>>>>> Ilya Kasnacheev
>>>>>>
>>>>>>
>>>>>> пн, 7 сент. 2020 г. в 17:17, Nikolay Izhikov <ni...@apache.org>:
>>>>>>
>>>>>>>> what’s the logic?
>>>>>>>
>>>>>>> I assume that this is a question to the author of these flags.
>>>>>>> If you have a specific flag you are interested in, please, write it.
>>>>>>>
>>>>>>> My point is simple - we already have these flags.
>>>>>>>
>>>>>>> We should explain to the user what we have and what can be configured
>>>>>> with
>>>>>>> these flags.
>>>>>>>
>>>>>>> There is no flag added or removed in this change.
>>>>>>> Just makes it more clear to the users.
>>>>>>>
>>>>>>>
>>>>>>>> 7 сент. 2020 г., в 17:12, Stephen Darlington <
>>>>>>> stephen.darlington@gridgain.com> написал(а):
>>>>>>>>
>>>>>>>> But to Ilya’s point, what’s the logic? Why are some things set using
>>>>>>> IGNITE_ properties, others on the command line and others in
>>>>>>> IgniteConfiguration? It’s confusing for the user and makes
>> maintenance
>>>>>>> harder.
>>>>>>>>
>>>>>>>> I’m not necessarily arguing against this change, though. Perfect
>> being
>>>>>>> the enemy of good and all that.
>>>>>>>>
>>>>>>>>> On 7 Sep 2020, at 13:02, Nikolay Izhikov <ni...@apache.org>
>>>> wrote:
>>>>>>>>>
>>>>>>>>> Hello, Ilya.
>>>>>>>>>
>>>>>>>>>> I think this is a bad idea since it legitimizes wide use of
>> IGNITE_
>>>>>>> properties, which shows weakness of our configuration API, etc.
>>>>>>>>>
>>>>>>>>> We already have IGNITE options in the product as a part of public
>>>> API.
>>>>>>> See `org.apache.ignite.IgniteSystemProperties`.
>>>>>>>>>
>>>>>>>>>> 7 сент. 2020 г., в 14:40, Ilya Kasnacheev <
>>>> ilya.kasnacheev@gmail.com
>>>>>>>
>>>>>>> написал(а):
>>>>>>>>>>
>>>>>>>>>> Hello!
>>>>>>>>>>
>>>>>>>>>> I think this is a bad idea since it legitimizes wide use of
>> IGNITE_
>>>>>>>>>> properties, which shows weakness of our configuration API, etc.
>>>>>>>>>>
>>>>>>>>>> My take:
>>>>>>>>>>
>>>>>>>>>> All of IGNITE_ properties which are useful (and will go to -X)
>>>> should
>>>>>>>>>> instead be turned into configuration/metastore settings.
>>>>>>>>>> All of IGNITE_ properties which are dangerous and/or useless
>> should
>>>>>> be
>>>>>>>>>> removed.
>>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>> --
>>>>>>>>>> Ilya Kasnacheev
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> пт, 21 авг. 2020 г. в 16:50, Nikolay Izhikov <nizhikov@apache.org
>>> :
>>>>>>>>>>
>>>>>>>>>>> Hello, Igniters.
>>>>>>>>>>>
>>>>>>>>>>> For now, we have dozens of the `IgniteSystemProperties` [1] that
>>>>>> can
>>>>>>>>>>> tweak Ignite behaviour in the very wide limits.
>>>>>>>>>>> But, the issue, for the administrator is the following
>>>>>>>>>>>
>>>>>>>>>>> - Documentation about existing properties can be outdated.
>>>>>>>>>>> - The only place of the truth is the source code.
>>>>>>>>>>> - It’s hard to understand what flag is supported in what version.
>>>>>>>>>>>
>>>>>>>>>>> I propose to implement output of all available properties with
>> it’s
>>>>>>>>>>> descriptions in the `ignite.sh -X` command.
>>>>>>>>>>>
>>>>>>>>>>> Example of the JVM output:
>>>>>>>>>>>
>>>>>>>>>>> ```
>>>>>>>>>>> [16:25:49]~/src/ignite:[master]$ java -X
>>>>>>>>>>>
>>>>>>>>>>> -Xbatch disable background compilation
>>>>>>>>>>> -Xbootclasspath/a:<directories and zip/jar files separated by :>
>>>>>>>>>>> append to end of bootstrap class path
>>>>>>>>>>> -Xcheck:jni perform additional checks for JNI functions
>>>>>>>>>>> -Xcomp forces compilation of methods on first
>> invocation
>>>>>>>>>>> -Xdebug provided for backward compatibility
>>>>>>>>>>> -Xdiag show additional diagnostic messages
>>>>>>>>>>> -Xfuture enable strictest checks, anticipating future
>>>>>>> default
>>>>>>>>>>> -Xint interpreted mode execution only
>>>>>>>>>>> -Xinternalversion
>>>>>>>>>>> displays more detailed JVM version information
>>>>>> than
>>>>>>>>>>> the
>>>>>>>>>>>
>>>>>>>>>>> [16:28:45]~/src/ignite:[master]$ java
>>>> -XX:+UnlockDiagnosticVMOptions
>>>>>>>>>>> -XX:+PrintFlagsFinal -version
>>>>>>>>>>>
>>>>>>>>>>> [Global flags]
>>>>>>>>>>> ccstrlist AOTLibrary =
>>>>>>>>>>> {product} {default}
>>>>>>>>>>> bool AbortVMOnCompilationFailure = false
>>>>>>>>>>> {diagnostic} {default}
>>>>>>>>>>> ccstr AbortVMOnException =
>>>>>>>>>>> {diagnostic} {default}
>>>>>>>>>>> ccstr AbortVMOnExceptionMessage =
>>>>>>>>>>> {diagnostic} {default}
>>>>>>>>>>> bool AbortVMOnSafepointTimeout = false
>>>>>>>>>>> {diagnostic} {default}
>>>>>>>>>>> bool AbortVMOnVMOperationTimeout = false
>>>>>>>>>>> {diagnostic} {default}
>>>>>>>>>>> intx AbortVMOnVMOperationTimeoutDelay = 1000
>>>>>>>>>>> {diagnostic} {default}
>>>>>>>>>>> int ActiveProcessorCount = -1
>>>>>>>>>>> {product} {default}
>>>>>>>>>>>
>>>>>>>>>>> ```
>>>>>>>>>>>
>>>>>>>>>>> Example of the Ignite output:
>>>>>>>>>>>
>>>>>>>>>>> ````
>>>>>>>>>>>> ignite.sh -X
>>>>>>>>>>> IGNITE_CONFIG_URL
>>>>>>>>>>> - System property to hold optional configuration URL.
>>>>>>>>>>> IGNITE_SSH_HOST
>>>>>>> -
>>>>>>>>>>> System property to hold SSH host for visor-started nodes.
>>>>>>>>>>> IGNITE_MIN_BUFFERED_COMMUNICATION_MSG_CNT -
>>>> [DEPRECATED]
>>>>>>>>>>> System property to disable buffered communication if node sends
>>>> less
>>>>>>>>>>> messages count than specified by this property. Default value is
>>>>>>> {@code
>>>>>>>>>>> 512}.
>>>>>>>>>>>
>>>>>>>>>>> …
>>>>>>>>>>>
>>>>>>>>>>> ```
>>>>>>>>>>>
>>>>>>>>>>> WDYT?
>>>>>>>>>>>
>>>>>>>>>>> [1]
>>>>>>>>>>>
>>>>>>>
>>>>>>
>>>>
>> https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/IgniteSystemProperties.java#L56
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>>>
>>
>>
Re: [DISCUSSION] Output IgniteSystemProperties via ignite.sh
Posted by Ilya Kasnacheev <il...@gmail.com>.
Hello!
I'm not arguing that it should not be discussed. I'm just saying that we
can make it possible as a general principle.
Regards,
--
Ilya Kasnacheev
пн, 7 сент. 2020 г. в 19:01, Nikolay Izhikov <ni...@apache.org>:
> > We can make a compromise here: we list flags explicitly *but then, we
> >
> > decide that we don't keep backward compatibility anymore*, since the user
> > of a new version can check whether their flag is still supported by using
> > control.sh.
>
> It seems removal of any IgniteSystemProperty flag should be discussed
> separately.
>
>
> > 7 сент. 2020 г., в 18:46, Ilya Kasnacheev <il...@gmail.com>
> написал(а):
> >
> > Hello!
> >
> > We do replace some flags with cfg properties, such as inline size, for
> > example.
> > A lot of other flags just duplicate cfg properties.
> >
> > We can make a compromise here: we list flags explicitly *but then, we
> > decide that we don't keep backward compatibility anymore*, since the user
> > of a new version can check whether their flag is still supported by using
> > control.sh.
> >
> > WDYT?
> >
> > Regards,
> > --
> > Ilya Kasnacheev
> >
> >
> > пн, 7 сент. 2020 г. в 18:34, Nikolay Izhikov <ni...@apache.org>:
> >
> >> Ilya.
> >>
> >>> to remove any expectation of forward compatibility.
> >>
> >> AFAIK we must keep these flags before Ignite3, due to the backward
> >> compatibility.
> >>
> >>
> >>> Flags should be a temporary measure
> >>
> >> This is not true, for now.
> >> I feel your pain :)
> >> Personally, I hate these flags, also.
> >>
> >> But they exist and the whole point of this change is to make the life of
> >> Ignite users a bit easier.
> >>
> >>> 7 сент. 2020 г., в 17:32, Philipp Masharov <ma...@gmail.com>
> >> написал(а):
> >>>
> >>> Let me notice that in Ignite 3.0 Wishlist [1] we have a bullet point
> >>> "Remove as many IGNITE_ parameters as possible from
> >> IgniteSystemProperties
> >>> <
> >>
> https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/IgniteSystemProperties.html
> >>> "
> >>>
> >>>
> >>> [1]
> >>>
> >>
> https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+3.0+Wishlist
> >>> "
> >>>
> >>> On Mon, Sep 7, 2020 at 5:24 PM Ilya Kasnacheev <
> >> ilya.kasnacheev@gmail.com>
> >>> wrote:
> >>>
> >>>> Hello!
> >>>>
> >>>> Okay, we can do a simple list of these flags, but I would argue that
> we
> >>>> should:
> >>>> - Avoid adding extra infrastructure such as flags' human readable
> names,
> >>>> embedded docs, etc. Flags should be a temporary measure. They are now.
> >>>> Let's not make it look like they're there to stay.
> >>>> - Explicitly mention in the -X output that these flags may be
> >>>> removed/converted to configuration properties in the future, to remove
> >> any
> >>>> expectation of forward compatibility.
> >>>>
> >>>> They bother me for quite some time.
> >>>>
> >>>> Regards,
> >>>> --
> >>>> Ilya Kasnacheev
> >>>>
> >>>>
> >>>> пн, 7 сент. 2020 г. в 17:17, Nikolay Izhikov <ni...@apache.org>:
> >>>>
> >>>>>> what’s the logic?
> >>>>>
> >>>>> I assume that this is a question to the author of these flags.
> >>>>> If you have a specific flag you are interested in, please, write it.
> >>>>>
> >>>>> My point is simple - we already have these flags.
> >>>>>
> >>>>> We should explain to the user what we have and what can be configured
> >>>> with
> >>>>> these flags.
> >>>>>
> >>>>> There is no flag added or removed in this change.
> >>>>> Just makes it more clear to the users.
> >>>>>
> >>>>>
> >>>>>> 7 сент. 2020 г., в 17:12, Stephen Darlington <
> >>>>> stephen.darlington@gridgain.com> написал(а):
> >>>>>>
> >>>>>> But to Ilya’s point, what’s the logic? Why are some things set using
> >>>>> IGNITE_ properties, others on the command line and others in
> >>>>> IgniteConfiguration? It’s confusing for the user and makes
> maintenance
> >>>>> harder.
> >>>>>>
> >>>>>> I’m not necessarily arguing against this change, though. Perfect
> being
> >>>>> the enemy of good and all that.
> >>>>>>
> >>>>>>> On 7 Sep 2020, at 13:02, Nikolay Izhikov <ni...@apache.org>
> >> wrote:
> >>>>>>>
> >>>>>>> Hello, Ilya.
> >>>>>>>
> >>>>>>>> I think this is a bad idea since it legitimizes wide use of
> IGNITE_
> >>>>> properties, which shows weakness of our configuration API, etc.
> >>>>>>>
> >>>>>>> We already have IGNITE options in the product as a part of public
> >> API.
> >>>>> See `org.apache.ignite.IgniteSystemProperties`.
> >>>>>>>
> >>>>>>>> 7 сент. 2020 г., в 14:40, Ilya Kasnacheev <
> >> ilya.kasnacheev@gmail.com
> >>>>>
> >>>>> написал(а):
> >>>>>>>>
> >>>>>>>> Hello!
> >>>>>>>>
> >>>>>>>> I think this is a bad idea since it legitimizes wide use of
> IGNITE_
> >>>>>>>> properties, which shows weakness of our configuration API, etc.
> >>>>>>>>
> >>>>>>>> My take:
> >>>>>>>>
> >>>>>>>> All of IGNITE_ properties which are useful (and will go to -X)
> >> should
> >>>>>>>> instead be turned into configuration/metastore settings.
> >>>>>>>> All of IGNITE_ properties which are dangerous and/or useless
> should
> >>>> be
> >>>>>>>> removed.
> >>>>>>>>
> >>>>>>>> Regards,
> >>>>>>>> --
> >>>>>>>> Ilya Kasnacheev
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> пт, 21 авг. 2020 г. в 16:50, Nikolay Izhikov <nizhikov@apache.org
> >:
> >>>>>>>>
> >>>>>>>>> Hello, Igniters.
> >>>>>>>>>
> >>>>>>>>> For now, we have dozens of the `IgniteSystemProperties` [1] that
> >>>> can
> >>>>>>>>> tweak Ignite behaviour in the very wide limits.
> >>>>>>>>> But, the issue, for the administrator is the following
> >>>>>>>>>
> >>>>>>>>> - Documentation about existing properties can be outdated.
> >>>>>>>>> - The only place of the truth is the source code.
> >>>>>>>>> - It’s hard to understand what flag is supported in what version.
> >>>>>>>>>
> >>>>>>>>> I propose to implement output of all available properties with
> it’s
> >>>>>>>>> descriptions in the `ignite.sh -X` command.
> >>>>>>>>>
> >>>>>>>>> Example of the JVM output:
> >>>>>>>>>
> >>>>>>>>> ```
> >>>>>>>>> [16:25:49]~/src/ignite:[master]$ java -X
> >>>>>>>>>
> >>>>>>>>> -Xbatch disable background compilation
> >>>>>>>>> -Xbootclasspath/a:<directories and zip/jar files separated by :>
> >>>>>>>>> append to end of bootstrap class path
> >>>>>>>>> -Xcheck:jni perform additional checks for JNI functions
> >>>>>>>>> -Xcomp forces compilation of methods on first
> invocation
> >>>>>>>>> -Xdebug provided for backward compatibility
> >>>>>>>>> -Xdiag show additional diagnostic messages
> >>>>>>>>> -Xfuture enable strictest checks, anticipating future
> >>>>> default
> >>>>>>>>> -Xint interpreted mode execution only
> >>>>>>>>> -Xinternalversion
> >>>>>>>>> displays more detailed JVM version information
> >>>> than
> >>>>>>>>> the
> >>>>>>>>>
> >>>>>>>>> [16:28:45]~/src/ignite:[master]$ java
> >> -XX:+UnlockDiagnosticVMOptions
> >>>>>>>>> -XX:+PrintFlagsFinal -version
> >>>>>>>>>
> >>>>>>>>> [Global flags]
> >>>>>>>>> ccstrlist AOTLibrary =
> >>>>>>>>> {product} {default}
> >>>>>>>>> bool AbortVMOnCompilationFailure = false
> >>>>>>>>> {diagnostic} {default}
> >>>>>>>>> ccstr AbortVMOnException =
> >>>>>>>>> {diagnostic} {default}
> >>>>>>>>> ccstr AbortVMOnExceptionMessage =
> >>>>>>>>> {diagnostic} {default}
> >>>>>>>>> bool AbortVMOnSafepointTimeout = false
> >>>>>>>>> {diagnostic} {default}
> >>>>>>>>> bool AbortVMOnVMOperationTimeout = false
> >>>>>>>>> {diagnostic} {default}
> >>>>>>>>> intx AbortVMOnVMOperationTimeoutDelay = 1000
> >>>>>>>>> {diagnostic} {default}
> >>>>>>>>> int ActiveProcessorCount = -1
> >>>>>>>>> {product} {default}
> >>>>>>>>>
> >>>>>>>>> ```
> >>>>>>>>>
> >>>>>>>>> Example of the Ignite output:
> >>>>>>>>>
> >>>>>>>>> ````
> >>>>>>>>>> ignite.sh -X
> >>>>>>>>> IGNITE_CONFIG_URL
> >>>>>>>>> - System property to hold optional configuration URL.
> >>>>>>>>> IGNITE_SSH_HOST
> >>>>> -
> >>>>>>>>> System property to hold SSH host for visor-started nodes.
> >>>>>>>>> IGNITE_MIN_BUFFERED_COMMUNICATION_MSG_CNT -
> >> [DEPRECATED]
> >>>>>>>>> System property to disable buffered communication if node sends
> >> less
> >>>>>>>>> messages count than specified by this property. Default value is
> >>>>> {@code
> >>>>>>>>> 512}.
> >>>>>>>>>
> >>>>>>>>> …
> >>>>>>>>>
> >>>>>>>>> ```
> >>>>>>>>>
> >>>>>>>>> WDYT?
> >>>>>>>>>
> >>>>>>>>> [1]
> >>>>>>>>>
> >>>>>
> >>>>
> >>
> https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/IgniteSystemProperties.java#L56
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>
> >>
> >>
>
>
Re: [DISCUSSION] Output IgniteSystemProperties via ignite.sh
Posted by Nikolay Izhikov <ni...@apache.org>.
> We can make a compromise here: we list flags explicitly *but then, we
>
> decide that we don't keep backward compatibility anymore*, since the user
> of a new version can check whether their flag is still supported by using
> control.sh.
It seems removal of any IgniteSystemProperty flag should be discussed separately.
> 7 сент. 2020 г., в 18:46, Ilya Kasnacheev <il...@gmail.com> написал(а):
>
> Hello!
>
> We do replace some flags with cfg properties, such as inline size, for
> example.
> A lot of other flags just duplicate cfg properties.
>
> We can make a compromise here: we list flags explicitly *but then, we
> decide that we don't keep backward compatibility anymore*, since the user
> of a new version can check whether their flag is still supported by using
> control.sh.
>
> WDYT?
>
> Regards,
> --
> Ilya Kasnacheev
>
>
> пн, 7 сент. 2020 г. в 18:34, Nikolay Izhikov <ni...@apache.org>:
>
>> Ilya.
>>
>>> to remove any expectation of forward compatibility.
>>
>> AFAIK we must keep these flags before Ignite3, due to the backward
>> compatibility.
>>
>>
>>> Flags should be a temporary measure
>>
>> This is not true, for now.
>> I feel your pain :)
>> Personally, I hate these flags, also.
>>
>> But they exist and the whole point of this change is to make the life of
>> Ignite users a bit easier.
>>
>>> 7 сент. 2020 г., в 17:32, Philipp Masharov <ma...@gmail.com>
>> написал(а):
>>>
>>> Let me notice that in Ignite 3.0 Wishlist [1] we have a bullet point
>>> "Remove as many IGNITE_ parameters as possible from
>> IgniteSystemProperties
>>> <
>> https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/IgniteSystemProperties.html
>>> "
>>>
>>>
>>> [1]
>>>
>> https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+3.0+Wishlist
>>> "
>>>
>>> On Mon, Sep 7, 2020 at 5:24 PM Ilya Kasnacheev <
>> ilya.kasnacheev@gmail.com>
>>> wrote:
>>>
>>>> Hello!
>>>>
>>>> Okay, we can do a simple list of these flags, but I would argue that we
>>>> should:
>>>> - Avoid adding extra infrastructure such as flags' human readable names,
>>>> embedded docs, etc. Flags should be a temporary measure. They are now.
>>>> Let's not make it look like they're there to stay.
>>>> - Explicitly mention in the -X output that these flags may be
>>>> removed/converted to configuration properties in the future, to remove
>> any
>>>> expectation of forward compatibility.
>>>>
>>>> They bother me for quite some time.
>>>>
>>>> Regards,
>>>> --
>>>> Ilya Kasnacheev
>>>>
>>>>
>>>> пн, 7 сент. 2020 г. в 17:17, Nikolay Izhikov <ni...@apache.org>:
>>>>
>>>>>> what’s the logic?
>>>>>
>>>>> I assume that this is a question to the author of these flags.
>>>>> If you have a specific flag you are interested in, please, write it.
>>>>>
>>>>> My point is simple - we already have these flags.
>>>>>
>>>>> We should explain to the user what we have and what can be configured
>>>> with
>>>>> these flags.
>>>>>
>>>>> There is no flag added or removed in this change.
>>>>> Just makes it more clear to the users.
>>>>>
>>>>>
>>>>>> 7 сент. 2020 г., в 17:12, Stephen Darlington <
>>>>> stephen.darlington@gridgain.com> написал(а):
>>>>>>
>>>>>> But to Ilya’s point, what’s the logic? Why are some things set using
>>>>> IGNITE_ properties, others on the command line and others in
>>>>> IgniteConfiguration? It’s confusing for the user and makes maintenance
>>>>> harder.
>>>>>>
>>>>>> I’m not necessarily arguing against this change, though. Perfect being
>>>>> the enemy of good and all that.
>>>>>>
>>>>>>> On 7 Sep 2020, at 13:02, Nikolay Izhikov <ni...@apache.org>
>> wrote:
>>>>>>>
>>>>>>> Hello, Ilya.
>>>>>>>
>>>>>>>> I think this is a bad idea since it legitimizes wide use of IGNITE_
>>>>> properties, which shows weakness of our configuration API, etc.
>>>>>>>
>>>>>>> We already have IGNITE options in the product as a part of public
>> API.
>>>>> See `org.apache.ignite.IgniteSystemProperties`.
>>>>>>>
>>>>>>>> 7 сент. 2020 г., в 14:40, Ilya Kasnacheev <
>> ilya.kasnacheev@gmail.com
>>>>>
>>>>> написал(а):
>>>>>>>>
>>>>>>>> Hello!
>>>>>>>>
>>>>>>>> I think this is a bad idea since it legitimizes wide use of IGNITE_
>>>>>>>> properties, which shows weakness of our configuration API, etc.
>>>>>>>>
>>>>>>>> My take:
>>>>>>>>
>>>>>>>> All of IGNITE_ properties which are useful (and will go to -X)
>> should
>>>>>>>> instead be turned into configuration/metastore settings.
>>>>>>>> All of IGNITE_ properties which are dangerous and/or useless should
>>>> be
>>>>>>>> removed.
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> --
>>>>>>>> Ilya Kasnacheev
>>>>>>>>
>>>>>>>>
>>>>>>>> пт, 21 авг. 2020 г. в 16:50, Nikolay Izhikov <ni...@apache.org>:
>>>>>>>>
>>>>>>>>> Hello, Igniters.
>>>>>>>>>
>>>>>>>>> For now, we have dozens of the `IgniteSystemProperties` [1] that
>>>> can
>>>>>>>>> tweak Ignite behaviour in the very wide limits.
>>>>>>>>> But, the issue, for the administrator is the following
>>>>>>>>>
>>>>>>>>> - Documentation about existing properties can be outdated.
>>>>>>>>> - The only place of the truth is the source code.
>>>>>>>>> - It’s hard to understand what flag is supported in what version.
>>>>>>>>>
>>>>>>>>> I propose to implement output of all available properties with it’s
>>>>>>>>> descriptions in the `ignite.sh -X` command.
>>>>>>>>>
>>>>>>>>> Example of the JVM output:
>>>>>>>>>
>>>>>>>>> ```
>>>>>>>>> [16:25:49]~/src/ignite:[master]$ java -X
>>>>>>>>>
>>>>>>>>> -Xbatch disable background compilation
>>>>>>>>> -Xbootclasspath/a:<directories and zip/jar files separated by :>
>>>>>>>>> append to end of bootstrap class path
>>>>>>>>> -Xcheck:jni perform additional checks for JNI functions
>>>>>>>>> -Xcomp forces compilation of methods on first invocation
>>>>>>>>> -Xdebug provided for backward compatibility
>>>>>>>>> -Xdiag show additional diagnostic messages
>>>>>>>>> -Xfuture enable strictest checks, anticipating future
>>>>> default
>>>>>>>>> -Xint interpreted mode execution only
>>>>>>>>> -Xinternalversion
>>>>>>>>> displays more detailed JVM version information
>>>> than
>>>>>>>>> the
>>>>>>>>>
>>>>>>>>> [16:28:45]~/src/ignite:[master]$ java
>> -XX:+UnlockDiagnosticVMOptions
>>>>>>>>> -XX:+PrintFlagsFinal -version
>>>>>>>>>
>>>>>>>>> [Global flags]
>>>>>>>>> ccstrlist AOTLibrary =
>>>>>>>>> {product} {default}
>>>>>>>>> bool AbortVMOnCompilationFailure = false
>>>>>>>>> {diagnostic} {default}
>>>>>>>>> ccstr AbortVMOnException =
>>>>>>>>> {diagnostic} {default}
>>>>>>>>> ccstr AbortVMOnExceptionMessage =
>>>>>>>>> {diagnostic} {default}
>>>>>>>>> bool AbortVMOnSafepointTimeout = false
>>>>>>>>> {diagnostic} {default}
>>>>>>>>> bool AbortVMOnVMOperationTimeout = false
>>>>>>>>> {diagnostic} {default}
>>>>>>>>> intx AbortVMOnVMOperationTimeoutDelay = 1000
>>>>>>>>> {diagnostic} {default}
>>>>>>>>> int ActiveProcessorCount = -1
>>>>>>>>> {product} {default}
>>>>>>>>>
>>>>>>>>> ```
>>>>>>>>>
>>>>>>>>> Example of the Ignite output:
>>>>>>>>>
>>>>>>>>> ````
>>>>>>>>>> ignite.sh -X
>>>>>>>>> IGNITE_CONFIG_URL
>>>>>>>>> - System property to hold optional configuration URL.
>>>>>>>>> IGNITE_SSH_HOST
>>>>> -
>>>>>>>>> System property to hold SSH host for visor-started nodes.
>>>>>>>>> IGNITE_MIN_BUFFERED_COMMUNICATION_MSG_CNT -
>> [DEPRECATED]
>>>>>>>>> System property to disable buffered communication if node sends
>> less
>>>>>>>>> messages count than specified by this property. Default value is
>>>>> {@code
>>>>>>>>> 512}.
>>>>>>>>>
>>>>>>>>> …
>>>>>>>>>
>>>>>>>>> ```
>>>>>>>>>
>>>>>>>>> WDYT?
>>>>>>>>>
>>>>>>>>> [1]
>>>>>>>>>
>>>>>
>>>>
>> https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/IgniteSystemProperties.java#L56
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>
>>
Re: [DISCUSSION] Output IgniteSystemProperties via ignite.sh
Posted by Ilya Kasnacheev <il...@gmail.com>.
Hello!
We do replace some flags with cfg properties, such as inline size, for
example.
A lot of other flags just duplicate cfg properties.
We can make a compromise here: we list flags explicitly *but then, we
decide that we don't keep backward compatibility anymore*, since the user
of a new version can check whether their flag is still supported by using
control.sh.
WDYT?
Regards,
--
Ilya Kasnacheev
пн, 7 сент. 2020 г. в 18:34, Nikolay Izhikov <ni...@apache.org>:
> Ilya.
>
> > to remove any expectation of forward compatibility.
>
> AFAIK we must keep these flags before Ignite3, due to the backward
> compatibility.
>
>
> > Flags should be a temporary measure
>
> This is not true, for now.
> I feel your pain :)
> Personally, I hate these flags, also.
>
> But they exist and the whole point of this change is to make the life of
> Ignite users a bit easier.
>
> > 7 сент. 2020 г., в 17:32, Philipp Masharov <ma...@gmail.com>
> написал(а):
> >
> > Let me notice that in Ignite 3.0 Wishlist [1] we have a bullet point
> > "Remove as many IGNITE_ parameters as possible from
> IgniteSystemProperties
> > <
> https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/IgniteSystemProperties.html
> >"
> >
> >
> > [1]
> >
> https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+3.0+Wishlist
> > "
> >
> > On Mon, Sep 7, 2020 at 5:24 PM Ilya Kasnacheev <
> ilya.kasnacheev@gmail.com>
> > wrote:
> >
> >> Hello!
> >>
> >> Okay, we can do a simple list of these flags, but I would argue that we
> >> should:
> >> - Avoid adding extra infrastructure such as flags' human readable names,
> >> embedded docs, etc. Flags should be a temporary measure. They are now.
> >> Let's not make it look like they're there to stay.
> >> - Explicitly mention in the -X output that these flags may be
> >> removed/converted to configuration properties in the future, to remove
> any
> >> expectation of forward compatibility.
> >>
> >> They bother me for quite some time.
> >>
> >> Regards,
> >> --
> >> Ilya Kasnacheev
> >>
> >>
> >> пн, 7 сент. 2020 г. в 17:17, Nikolay Izhikov <ni...@apache.org>:
> >>
> >>>> what’s the logic?
> >>>
> >>> I assume that this is a question to the author of these flags.
> >>> If you have a specific flag you are interested in, please, write it.
> >>>
> >>> My point is simple - we already have these flags.
> >>>
> >>> We should explain to the user what we have and what can be configured
> >> with
> >>> these flags.
> >>>
> >>> There is no flag added or removed in this change.
> >>> Just makes it more clear to the users.
> >>>
> >>>
> >>>> 7 сент. 2020 г., в 17:12, Stephen Darlington <
> >>> stephen.darlington@gridgain.com> написал(а):
> >>>>
> >>>> But to Ilya’s point, what’s the logic? Why are some things set using
> >>> IGNITE_ properties, others on the command line and others in
> >>> IgniteConfiguration? It’s confusing for the user and makes maintenance
> >>> harder.
> >>>>
> >>>> I’m not necessarily arguing against this change, though. Perfect being
> >>> the enemy of good and all that.
> >>>>
> >>>>> On 7 Sep 2020, at 13:02, Nikolay Izhikov <ni...@apache.org>
> wrote:
> >>>>>
> >>>>> Hello, Ilya.
> >>>>>
> >>>>>> I think this is a bad idea since it legitimizes wide use of IGNITE_
> >>> properties, which shows weakness of our configuration API, etc.
> >>>>>
> >>>>> We already have IGNITE options in the product as a part of public
> API.
> >>> See `org.apache.ignite.IgniteSystemProperties`.
> >>>>>
> >>>>>> 7 сент. 2020 г., в 14:40, Ilya Kasnacheev <
> ilya.kasnacheev@gmail.com
> >>>
> >>> написал(а):
> >>>>>>
> >>>>>> Hello!
> >>>>>>
> >>>>>> I think this is a bad idea since it legitimizes wide use of IGNITE_
> >>>>>> properties, which shows weakness of our configuration API, etc.
> >>>>>>
> >>>>>> My take:
> >>>>>>
> >>>>>> All of IGNITE_ properties which are useful (and will go to -X)
> should
> >>>>>> instead be turned into configuration/metastore settings.
> >>>>>> All of IGNITE_ properties which are dangerous and/or useless should
> >> be
> >>>>>> removed.
> >>>>>>
> >>>>>> Regards,
> >>>>>> --
> >>>>>> Ilya Kasnacheev
> >>>>>>
> >>>>>>
> >>>>>> пт, 21 авг. 2020 г. в 16:50, Nikolay Izhikov <ni...@apache.org>:
> >>>>>>
> >>>>>>> Hello, Igniters.
> >>>>>>>
> >>>>>>> For now, we have dozens of the `IgniteSystemProperties` [1] that
> >> can
> >>>>>>> tweak Ignite behaviour in the very wide limits.
> >>>>>>> But, the issue, for the administrator is the following
> >>>>>>>
> >>>>>>> - Documentation about existing properties can be outdated.
> >>>>>>> - The only place of the truth is the source code.
> >>>>>>> - It’s hard to understand what flag is supported in what version.
> >>>>>>>
> >>>>>>> I propose to implement output of all available properties with it’s
> >>>>>>> descriptions in the `ignite.sh -X` command.
> >>>>>>>
> >>>>>>> Example of the JVM output:
> >>>>>>>
> >>>>>>> ```
> >>>>>>> [16:25:49]~/src/ignite:[master]$ java -X
> >>>>>>>
> >>>>>>> -Xbatch disable background compilation
> >>>>>>> -Xbootclasspath/a:<directories and zip/jar files separated by :>
> >>>>>>> append to end of bootstrap class path
> >>>>>>> -Xcheck:jni perform additional checks for JNI functions
> >>>>>>> -Xcomp forces compilation of methods on first invocation
> >>>>>>> -Xdebug provided for backward compatibility
> >>>>>>> -Xdiag show additional diagnostic messages
> >>>>>>> -Xfuture enable strictest checks, anticipating future
> >>> default
> >>>>>>> -Xint interpreted mode execution only
> >>>>>>> -Xinternalversion
> >>>>>>> displays more detailed JVM version information
> >> than
> >>>>>>> the
> >>>>>>>
> >>>>>>> [16:28:45]~/src/ignite:[master]$ java
> -XX:+UnlockDiagnosticVMOptions
> >>>>>>> -XX:+PrintFlagsFinal -version
> >>>>>>>
> >>>>>>> [Global flags]
> >>>>>>> ccstrlist AOTLibrary =
> >>>>>>> {product} {default}
> >>>>>>> bool AbortVMOnCompilationFailure = false
> >>>>>>> {diagnostic} {default}
> >>>>>>> ccstr AbortVMOnException =
> >>>>>>> {diagnostic} {default}
> >>>>>>> ccstr AbortVMOnExceptionMessage =
> >>>>>>> {diagnostic} {default}
> >>>>>>> bool AbortVMOnSafepointTimeout = false
> >>>>>>> {diagnostic} {default}
> >>>>>>> bool AbortVMOnVMOperationTimeout = false
> >>>>>>> {diagnostic} {default}
> >>>>>>> intx AbortVMOnVMOperationTimeoutDelay = 1000
> >>>>>>> {diagnostic} {default}
> >>>>>>> int ActiveProcessorCount = -1
> >>>>>>> {product} {default}
> >>>>>>>
> >>>>>>> ```
> >>>>>>>
> >>>>>>> Example of the Ignite output:
> >>>>>>>
> >>>>>>> ````
> >>>>>>>> ignite.sh -X
> >>>>>>> IGNITE_CONFIG_URL
> >>>>>>> - System property to hold optional configuration URL.
> >>>>>>> IGNITE_SSH_HOST
> >>> -
> >>>>>>> System property to hold SSH host for visor-started nodes.
> >>>>>>> IGNITE_MIN_BUFFERED_COMMUNICATION_MSG_CNT -
> [DEPRECATED]
> >>>>>>> System property to disable buffered communication if node sends
> less
> >>>>>>> messages count than specified by this property. Default value is
> >>> {@code
> >>>>>>> 512}.
> >>>>>>>
> >>>>>>> …
> >>>>>>>
> >>>>>>> ```
> >>>>>>>
> >>>>>>> WDYT?
> >>>>>>>
> >>>>>>> [1]
> >>>>>>>
> >>>
> >>
> https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/IgniteSystemProperties.java#L56
> >>>>>
> >>>>
> >>>>
> >>>
> >>>
> >>
>
>
Re: [DISCUSSION] Output IgniteSystemProperties via ignite.sh
Posted by Nikolay Izhikov <ni...@apache.org>.
Ilya.
> to remove any expectation of forward compatibility.
AFAIK we must keep these flags before Ignite3, due to the backward compatibility.
> Flags should be a temporary measure
This is not true, for now.
I feel your pain :)
Personally, I hate these flags, also.
But they exist and the whole point of this change is to make the life of Ignite users a bit easier.
> 7 сент. 2020 г., в 17:32, Philipp Masharov <ma...@gmail.com> написал(а):
>
> Let me notice that in Ignite 3.0 Wishlist [1] we have a bullet point
> "Remove as many IGNITE_ parameters as possible from IgniteSystemProperties
> <https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/IgniteSystemProperties.html>"
>
>
> [1]
> https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+3.0+Wishlist
> "
>
> On Mon, Sep 7, 2020 at 5:24 PM Ilya Kasnacheev <il...@gmail.com>
> wrote:
>
>> Hello!
>>
>> Okay, we can do a simple list of these flags, but I would argue that we
>> should:
>> - Avoid adding extra infrastructure such as flags' human readable names,
>> embedded docs, etc. Flags should be a temporary measure. They are now.
>> Let's not make it look like they're there to stay.
>> - Explicitly mention in the -X output that these flags may be
>> removed/converted to configuration properties in the future, to remove any
>> expectation of forward compatibility.
>>
>> They bother me for quite some time.
>>
>> Regards,
>> --
>> Ilya Kasnacheev
>>
>>
>> пн, 7 сент. 2020 г. в 17:17, Nikolay Izhikov <ni...@apache.org>:
>>
>>>> what’s the logic?
>>>
>>> I assume that this is a question to the author of these flags.
>>> If you have a specific flag you are interested in, please, write it.
>>>
>>> My point is simple - we already have these flags.
>>>
>>> We should explain to the user what we have and what can be configured
>> with
>>> these flags.
>>>
>>> There is no flag added or removed in this change.
>>> Just makes it more clear to the users.
>>>
>>>
>>>> 7 сент. 2020 г., в 17:12, Stephen Darlington <
>>> stephen.darlington@gridgain.com> написал(а):
>>>>
>>>> But to Ilya’s point, what’s the logic? Why are some things set using
>>> IGNITE_ properties, others on the command line and others in
>>> IgniteConfiguration? It’s confusing for the user and makes maintenance
>>> harder.
>>>>
>>>> I’m not necessarily arguing against this change, though. Perfect being
>>> the enemy of good and all that.
>>>>
>>>>> On 7 Sep 2020, at 13:02, Nikolay Izhikov <ni...@apache.org> wrote:
>>>>>
>>>>> Hello, Ilya.
>>>>>
>>>>>> I think this is a bad idea since it legitimizes wide use of IGNITE_
>>> properties, which shows weakness of our configuration API, etc.
>>>>>
>>>>> We already have IGNITE options in the product as a part of public API.
>>> See `org.apache.ignite.IgniteSystemProperties`.
>>>>>
>>>>>> 7 сент. 2020 г., в 14:40, Ilya Kasnacheev <ilya.kasnacheev@gmail.com
>>>
>>> написал(а):
>>>>>>
>>>>>> Hello!
>>>>>>
>>>>>> I think this is a bad idea since it legitimizes wide use of IGNITE_
>>>>>> properties, which shows weakness of our configuration API, etc.
>>>>>>
>>>>>> My take:
>>>>>>
>>>>>> All of IGNITE_ properties which are useful (and will go to -X) should
>>>>>> instead be turned into configuration/metastore settings.
>>>>>> All of IGNITE_ properties which are dangerous and/or useless should
>> be
>>>>>> removed.
>>>>>>
>>>>>> Regards,
>>>>>> --
>>>>>> Ilya Kasnacheev
>>>>>>
>>>>>>
>>>>>> пт, 21 авг. 2020 г. в 16:50, Nikolay Izhikov <ni...@apache.org>:
>>>>>>
>>>>>>> Hello, Igniters.
>>>>>>>
>>>>>>> For now, we have dozens of the `IgniteSystemProperties` [1] that
>> can
>>>>>>> tweak Ignite behaviour in the very wide limits.
>>>>>>> But, the issue, for the administrator is the following
>>>>>>>
>>>>>>> - Documentation about existing properties can be outdated.
>>>>>>> - The only place of the truth is the source code.
>>>>>>> - It’s hard to understand what flag is supported in what version.
>>>>>>>
>>>>>>> I propose to implement output of all available properties with it’s
>>>>>>> descriptions in the `ignite.sh -X` command.
>>>>>>>
>>>>>>> Example of the JVM output:
>>>>>>>
>>>>>>> ```
>>>>>>> [16:25:49]~/src/ignite:[master]$ java -X
>>>>>>>
>>>>>>> -Xbatch disable background compilation
>>>>>>> -Xbootclasspath/a:<directories and zip/jar files separated by :>
>>>>>>> append to end of bootstrap class path
>>>>>>> -Xcheck:jni perform additional checks for JNI functions
>>>>>>> -Xcomp forces compilation of methods on first invocation
>>>>>>> -Xdebug provided for backward compatibility
>>>>>>> -Xdiag show additional diagnostic messages
>>>>>>> -Xfuture enable strictest checks, anticipating future
>>> default
>>>>>>> -Xint interpreted mode execution only
>>>>>>> -Xinternalversion
>>>>>>> displays more detailed JVM version information
>> than
>>>>>>> the
>>>>>>>
>>>>>>> [16:28:45]~/src/ignite:[master]$ java -XX:+UnlockDiagnosticVMOptions
>>>>>>> -XX:+PrintFlagsFinal -version
>>>>>>>
>>>>>>> [Global flags]
>>>>>>> ccstrlist AOTLibrary =
>>>>>>> {product} {default}
>>>>>>> bool AbortVMOnCompilationFailure = false
>>>>>>> {diagnostic} {default}
>>>>>>> ccstr AbortVMOnException =
>>>>>>> {diagnostic} {default}
>>>>>>> ccstr AbortVMOnExceptionMessage =
>>>>>>> {diagnostic} {default}
>>>>>>> bool AbortVMOnSafepointTimeout = false
>>>>>>> {diagnostic} {default}
>>>>>>> bool AbortVMOnVMOperationTimeout = false
>>>>>>> {diagnostic} {default}
>>>>>>> intx AbortVMOnVMOperationTimeoutDelay = 1000
>>>>>>> {diagnostic} {default}
>>>>>>> int ActiveProcessorCount = -1
>>>>>>> {product} {default}
>>>>>>>
>>>>>>> ```
>>>>>>>
>>>>>>> Example of the Ignite output:
>>>>>>>
>>>>>>> ````
>>>>>>>> ignite.sh -X
>>>>>>> IGNITE_CONFIG_URL
>>>>>>> - System property to hold optional configuration URL.
>>>>>>> IGNITE_SSH_HOST
>>> -
>>>>>>> System property to hold SSH host for visor-started nodes.
>>>>>>> IGNITE_MIN_BUFFERED_COMMUNICATION_MSG_CNT - [DEPRECATED]
>>>>>>> System property to disable buffered communication if node sends less
>>>>>>> messages count than specified by this property. Default value is
>>> {@code
>>>>>>> 512}.
>>>>>>>
>>>>>>> …
>>>>>>>
>>>>>>> ```
>>>>>>>
>>>>>>> WDYT?
>>>>>>>
>>>>>>> [1]
>>>>>>>
>>>
>> https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/IgniteSystemProperties.java#L56
>>>>>
>>>>
>>>>
>>>
>>>
>>
Re: [DISCUSSION] Output IgniteSystemProperties via ignite.sh
Posted by Philipp Masharov <ma...@gmail.com>.
Let me notice that in Ignite 3.0 Wishlist [1] we have a bullet point
"Remove as many IGNITE_ parameters as possible from IgniteSystemProperties
<https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/IgniteSystemProperties.html>"
[1]
https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+3.0+Wishlist
"
On Mon, Sep 7, 2020 at 5:24 PM Ilya Kasnacheev <il...@gmail.com>
wrote:
> Hello!
>
> Okay, we can do a simple list of these flags, but I would argue that we
> should:
> - Avoid adding extra infrastructure such as flags' human readable names,
> embedded docs, etc. Flags should be a temporary measure. They are now.
> Let's not make it look like they're there to stay.
> - Explicitly mention in the -X output that these flags may be
> removed/converted to configuration properties in the future, to remove any
> expectation of forward compatibility.
>
> They bother me for quite some time.
>
> Regards,
> --
> Ilya Kasnacheev
>
>
> пн, 7 сент. 2020 г. в 17:17, Nikolay Izhikov <ni...@apache.org>:
>
> > > what’s the logic?
> >
> > I assume that this is a question to the author of these flags.
> > If you have a specific flag you are interested in, please, write it.
> >
> > My point is simple - we already have these flags.
> >
> > We should explain to the user what we have and what can be configured
> with
> > these flags.
> >
> > There is no flag added or removed in this change.
> > Just makes it more clear to the users.
> >
> >
> > > 7 сент. 2020 г., в 17:12, Stephen Darlington <
> > stephen.darlington@gridgain.com> написал(а):
> > >
> > > But to Ilya’s point, what’s the logic? Why are some things set using
> > IGNITE_ properties, others on the command line and others in
> > IgniteConfiguration? It’s confusing for the user and makes maintenance
> > harder.
> > >
> > > I’m not necessarily arguing against this change, though. Perfect being
> > the enemy of good and all that.
> > >
> > >> On 7 Sep 2020, at 13:02, Nikolay Izhikov <ni...@apache.org> wrote:
> > >>
> > >> Hello, Ilya.
> > >>
> > >>> I think this is a bad idea since it legitimizes wide use of IGNITE_
> > properties, which shows weakness of our configuration API, etc.
> > >>
> > >> We already have IGNITE options in the product as a part of public API.
> > See `org.apache.ignite.IgniteSystemProperties`.
> > >>
> > >>> 7 сент. 2020 г., в 14:40, Ilya Kasnacheev <ilya.kasnacheev@gmail.com
> >
> > написал(а):
> > >>>
> > >>> Hello!
> > >>>
> > >>> I think this is a bad idea since it legitimizes wide use of IGNITE_
> > >>> properties, which shows weakness of our configuration API, etc.
> > >>>
> > >>> My take:
> > >>>
> > >>> All of IGNITE_ properties which are useful (and will go to -X) should
> > >>> instead be turned into configuration/metastore settings.
> > >>> All of IGNITE_ properties which are dangerous and/or useless should
> be
> > >>> removed.
> > >>>
> > >>> Regards,
> > >>> --
> > >>> Ilya Kasnacheev
> > >>>
> > >>>
> > >>> пт, 21 авг. 2020 г. в 16:50, Nikolay Izhikov <ni...@apache.org>:
> > >>>
> > >>>> Hello, Igniters.
> > >>>>
> > >>>> For now, we have dozens of the `IgniteSystemProperties` [1] that
> can
> > >>>> tweak Ignite behaviour in the very wide limits.
> > >>>> But, the issue, for the administrator is the following
> > >>>>
> > >>>> - Documentation about existing properties can be outdated.
> > >>>> - The only place of the truth is the source code.
> > >>>> - It’s hard to understand what flag is supported in what version.
> > >>>>
> > >>>> I propose to implement output of all available properties with it’s
> > >>>> descriptions in the `ignite.sh -X` command.
> > >>>>
> > >>>> Example of the JVM output:
> > >>>>
> > >>>> ```
> > >>>> [16:25:49]~/src/ignite:[master]$ java -X
> > >>>>
> > >>>> -Xbatch disable background compilation
> > >>>> -Xbootclasspath/a:<directories and zip/jar files separated by :>
> > >>>> append to end of bootstrap class path
> > >>>> -Xcheck:jni perform additional checks for JNI functions
> > >>>> -Xcomp forces compilation of methods on first invocation
> > >>>> -Xdebug provided for backward compatibility
> > >>>> -Xdiag show additional diagnostic messages
> > >>>> -Xfuture enable strictest checks, anticipating future
> > default
> > >>>> -Xint interpreted mode execution only
> > >>>> -Xinternalversion
> > >>>> displays more detailed JVM version information
> than
> > >>>> the
> > >>>>
> > >>>> [16:28:45]~/src/ignite:[master]$ java -XX:+UnlockDiagnosticVMOptions
> > >>>> -XX:+PrintFlagsFinal -version
> > >>>>
> > >>>> [Global flags]
> > >>>> ccstrlist AOTLibrary =
> > >>>> {product} {default}
> > >>>> bool AbortVMOnCompilationFailure = false
> > >>>> {diagnostic} {default}
> > >>>> ccstr AbortVMOnException =
> > >>>> {diagnostic} {default}
> > >>>> ccstr AbortVMOnExceptionMessage =
> > >>>> {diagnostic} {default}
> > >>>> bool AbortVMOnSafepointTimeout = false
> > >>>> {diagnostic} {default}
> > >>>> bool AbortVMOnVMOperationTimeout = false
> > >>>> {diagnostic} {default}
> > >>>> intx AbortVMOnVMOperationTimeoutDelay = 1000
> > >>>> {diagnostic} {default}
> > >>>> int ActiveProcessorCount = -1
> > >>>> {product} {default}
> > >>>>
> > >>>> ```
> > >>>>
> > >>>> Example of the Ignite output:
> > >>>>
> > >>>> ````
> > >>>>> ignite.sh -X
> > >>>> IGNITE_CONFIG_URL
> > >>>> - System property to hold optional configuration URL.
> > >>>> IGNITE_SSH_HOST
> > -
> > >>>> System property to hold SSH host for visor-started nodes.
> > >>>> IGNITE_MIN_BUFFERED_COMMUNICATION_MSG_CNT - [DEPRECATED]
> > >>>> System property to disable buffered communication if node sends less
> > >>>> messages count than specified by this property. Default value is
> > {@code
> > >>>> 512}.
> > >>>>
> > >>>> …
> > >>>>
> > >>>> ```
> > >>>>
> > >>>> WDYT?
> > >>>>
> > >>>> [1]
> > >>>>
> >
> https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/IgniteSystemProperties.java#L56
> > >>
> > >
> > >
> >
> >
>
Re: [DISCUSSION] Output IgniteSystemProperties via ignite.sh
Posted by Ilya Kasnacheev <il...@gmail.com>.
Hello!
Okay, we can do a simple list of these flags, but I would argue that we
should:
- Avoid adding extra infrastructure such as flags' human readable names,
embedded docs, etc. Flags should be a temporary measure. They are now.
Let's not make it look like they're there to stay.
- Explicitly mention in the -X output that these flags may be
removed/converted to configuration properties in the future, to remove any
expectation of forward compatibility.
They bother me for quite some time.
Regards,
--
Ilya Kasnacheev
пн, 7 сент. 2020 г. в 17:17, Nikolay Izhikov <ni...@apache.org>:
> > what’s the logic?
>
> I assume that this is a question to the author of these flags.
> If you have a specific flag you are interested in, please, write it.
>
> My point is simple - we already have these flags.
>
> We should explain to the user what we have and what can be configured with
> these flags.
>
> There is no flag added or removed in this change.
> Just makes it more clear to the users.
>
>
> > 7 сент. 2020 г., в 17:12, Stephen Darlington <
> stephen.darlington@gridgain.com> написал(а):
> >
> > But to Ilya’s point, what’s the logic? Why are some things set using
> IGNITE_ properties, others on the command line and others in
> IgniteConfiguration? It’s confusing for the user and makes maintenance
> harder.
> >
> > I’m not necessarily arguing against this change, though. Perfect being
> the enemy of good and all that.
> >
> >> On 7 Sep 2020, at 13:02, Nikolay Izhikov <ni...@apache.org> wrote:
> >>
> >> Hello, Ilya.
> >>
> >>> I think this is a bad idea since it legitimizes wide use of IGNITE_
> properties, which shows weakness of our configuration API, etc.
> >>
> >> We already have IGNITE options in the product as a part of public API.
> See `org.apache.ignite.IgniteSystemProperties`.
> >>
> >>> 7 сент. 2020 г., в 14:40, Ilya Kasnacheev <il...@gmail.com>
> написал(а):
> >>>
> >>> Hello!
> >>>
> >>> I think this is a bad idea since it legitimizes wide use of IGNITE_
> >>> properties, which shows weakness of our configuration API, etc.
> >>>
> >>> My take:
> >>>
> >>> All of IGNITE_ properties which are useful (and will go to -X) should
> >>> instead be turned into configuration/metastore settings.
> >>> All of IGNITE_ properties which are dangerous and/or useless should be
> >>> removed.
> >>>
> >>> Regards,
> >>> --
> >>> Ilya Kasnacheev
> >>>
> >>>
> >>> пт, 21 авг. 2020 г. в 16:50, Nikolay Izhikov <ni...@apache.org>:
> >>>
> >>>> Hello, Igniters.
> >>>>
> >>>> For now, we have dozens of the `IgniteSystemProperties` [1] that can
> >>>> tweak Ignite behaviour in the very wide limits.
> >>>> But, the issue, for the administrator is the following
> >>>>
> >>>> - Documentation about existing properties can be outdated.
> >>>> - The only place of the truth is the source code.
> >>>> - It’s hard to understand what flag is supported in what version.
> >>>>
> >>>> I propose to implement output of all available properties with it’s
> >>>> descriptions in the `ignite.sh -X` command.
> >>>>
> >>>> Example of the JVM output:
> >>>>
> >>>> ```
> >>>> [16:25:49]~/src/ignite:[master]$ java -X
> >>>>
> >>>> -Xbatch disable background compilation
> >>>> -Xbootclasspath/a:<directories and zip/jar files separated by :>
> >>>> append to end of bootstrap class path
> >>>> -Xcheck:jni perform additional checks for JNI functions
> >>>> -Xcomp forces compilation of methods on first invocation
> >>>> -Xdebug provided for backward compatibility
> >>>> -Xdiag show additional diagnostic messages
> >>>> -Xfuture enable strictest checks, anticipating future
> default
> >>>> -Xint interpreted mode execution only
> >>>> -Xinternalversion
> >>>> displays more detailed JVM version information than
> >>>> the
> >>>>
> >>>> [16:28:45]~/src/ignite:[master]$ java -XX:+UnlockDiagnosticVMOptions
> >>>> -XX:+PrintFlagsFinal -version
> >>>>
> >>>> [Global flags]
> >>>> ccstrlist AOTLibrary =
> >>>> {product} {default}
> >>>> bool AbortVMOnCompilationFailure = false
> >>>> {diagnostic} {default}
> >>>> ccstr AbortVMOnException =
> >>>> {diagnostic} {default}
> >>>> ccstr AbortVMOnExceptionMessage =
> >>>> {diagnostic} {default}
> >>>> bool AbortVMOnSafepointTimeout = false
> >>>> {diagnostic} {default}
> >>>> bool AbortVMOnVMOperationTimeout = false
> >>>> {diagnostic} {default}
> >>>> intx AbortVMOnVMOperationTimeoutDelay = 1000
> >>>> {diagnostic} {default}
> >>>> int ActiveProcessorCount = -1
> >>>> {product} {default}
> >>>>
> >>>> ```
> >>>>
> >>>> Example of the Ignite output:
> >>>>
> >>>> ````
> >>>>> ignite.sh -X
> >>>> IGNITE_CONFIG_URL
> >>>> - System property to hold optional configuration URL.
> >>>> IGNITE_SSH_HOST
> -
> >>>> System property to hold SSH host for visor-started nodes.
> >>>> IGNITE_MIN_BUFFERED_COMMUNICATION_MSG_CNT - [DEPRECATED]
> >>>> System property to disable buffered communication if node sends less
> >>>> messages count than specified by this property. Default value is
> {@code
> >>>> 512}.
> >>>>
> >>>> …
> >>>>
> >>>> ```
> >>>>
> >>>> WDYT?
> >>>>
> >>>> [1]
> >>>>
> https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/IgniteSystemProperties.java#L56
> >>
> >
> >
>
>
Re: [DISCUSSION] Output IgniteSystemProperties via ignite.sh
Posted by Nikolay Izhikov <ni...@apache.org>.
> what’s the logic?
I assume that this is a question to the author of these flags.
If you have a specific flag you are interested in, please, write it.
My point is simple - we already have these flags.
We should explain to the user what we have and what can be configured with these flags.
There is no flag added or removed in this change.
Just makes it more clear to the users.
> 7 сент. 2020 г., в 17:12, Stephen Darlington <st...@gridgain.com> написал(а):
>
> But to Ilya’s point, what’s the logic? Why are some things set using IGNITE_ properties, others on the command line and others in IgniteConfiguration? It’s confusing for the user and makes maintenance harder.
>
> I’m not necessarily arguing against this change, though. Perfect being the enemy of good and all that.
>
>> On 7 Sep 2020, at 13:02, Nikolay Izhikov <ni...@apache.org> wrote:
>>
>> Hello, Ilya.
>>
>>> I think this is a bad idea since it legitimizes wide use of IGNITE_ properties, which shows weakness of our configuration API, etc.
>>
>> We already have IGNITE options in the product as a part of public API. See `org.apache.ignite.IgniteSystemProperties`.
>>
>>> 7 сент. 2020 г., в 14:40, Ilya Kasnacheev <il...@gmail.com> написал(а):
>>>
>>> Hello!
>>>
>>> I think this is a bad idea since it legitimizes wide use of IGNITE_
>>> properties, which shows weakness of our configuration API, etc.
>>>
>>> My take:
>>>
>>> All of IGNITE_ properties which are useful (and will go to -X) should
>>> instead be turned into configuration/metastore settings.
>>> All of IGNITE_ properties which are dangerous and/or useless should be
>>> removed.
>>>
>>> Regards,
>>> --
>>> Ilya Kasnacheev
>>>
>>>
>>> пт, 21 авг. 2020 г. в 16:50, Nikolay Izhikov <ni...@apache.org>:
>>>
>>>> Hello, Igniters.
>>>>
>>>> For now, we have dozens of the `IgniteSystemProperties` [1] that can
>>>> tweak Ignite behaviour in the very wide limits.
>>>> But, the issue, for the administrator is the following
>>>>
>>>> - Documentation about existing properties can be outdated.
>>>> - The only place of the truth is the source code.
>>>> - It’s hard to understand what flag is supported in what version.
>>>>
>>>> I propose to implement output of all available properties with it’s
>>>> descriptions in the `ignite.sh -X` command.
>>>>
>>>> Example of the JVM output:
>>>>
>>>> ```
>>>> [16:25:49]~/src/ignite:[master]$ java -X
>>>>
>>>> -Xbatch disable background compilation
>>>> -Xbootclasspath/a:<directories and zip/jar files separated by :>
>>>> append to end of bootstrap class path
>>>> -Xcheck:jni perform additional checks for JNI functions
>>>> -Xcomp forces compilation of methods on first invocation
>>>> -Xdebug provided for backward compatibility
>>>> -Xdiag show additional diagnostic messages
>>>> -Xfuture enable strictest checks, anticipating future default
>>>> -Xint interpreted mode execution only
>>>> -Xinternalversion
>>>> displays more detailed JVM version information than
>>>> the
>>>>
>>>> [16:28:45]~/src/ignite:[master]$ java -XX:+UnlockDiagnosticVMOptions
>>>> -XX:+PrintFlagsFinal -version
>>>>
>>>> [Global flags]
>>>> ccstrlist AOTLibrary =
>>>> {product} {default}
>>>> bool AbortVMOnCompilationFailure = false
>>>> {diagnostic} {default}
>>>> ccstr AbortVMOnException =
>>>> {diagnostic} {default}
>>>> ccstr AbortVMOnExceptionMessage =
>>>> {diagnostic} {default}
>>>> bool AbortVMOnSafepointTimeout = false
>>>> {diagnostic} {default}
>>>> bool AbortVMOnVMOperationTimeout = false
>>>> {diagnostic} {default}
>>>> intx AbortVMOnVMOperationTimeoutDelay = 1000
>>>> {diagnostic} {default}
>>>> int ActiveProcessorCount = -1
>>>> {product} {default}
>>>>
>>>> ```
>>>>
>>>> Example of the Ignite output:
>>>>
>>>> ````
>>>>> ignite.sh -X
>>>> IGNITE_CONFIG_URL
>>>> - System property to hold optional configuration URL.
>>>> IGNITE_SSH_HOST -
>>>> System property to hold SSH host for visor-started nodes.
>>>> IGNITE_MIN_BUFFERED_COMMUNICATION_MSG_CNT - [DEPRECATED]
>>>> System property to disable buffered communication if node sends less
>>>> messages count than specified by this property. Default value is {@code
>>>> 512}.
>>>>
>>>> …
>>>>
>>>> ```
>>>>
>>>> WDYT?
>>>>
>>>> [1]
>>>> https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/IgniteSystemProperties.java#L56
>>
>
>
Re: [DISCUSSION] Output IgniteSystemProperties via ignite.sh
Posted by Stephen Darlington <st...@gridgain.com>.
But to Ilya’s point, what’s the logic? Why are some things set using IGNITE_ properties, others on the command line and others in IgniteConfiguration? It’s confusing for the user and makes maintenance harder.
I’m not necessarily arguing against this change, though. Perfect being the enemy of good and all that.
> On 7 Sep 2020, at 13:02, Nikolay Izhikov <ni...@apache.org> wrote:
>
> Hello, Ilya.
>
>> I think this is a bad idea since it legitimizes wide use of IGNITE_ properties, which shows weakness of our configuration API, etc.
>
> We already have IGNITE options in the product as a part of public API. See `org.apache.ignite.IgniteSystemProperties`.
>
>> 7 сент. 2020 г., в 14:40, Ilya Kasnacheev <il...@gmail.com> написал(а):
>>
>> Hello!
>>
>> I think this is a bad idea since it legitimizes wide use of IGNITE_
>> properties, which shows weakness of our configuration API, etc.
>>
>> My take:
>>
>> All of IGNITE_ properties which are useful (and will go to -X) should
>> instead be turned into configuration/metastore settings.
>> All of IGNITE_ properties which are dangerous and/or useless should be
>> removed.
>>
>> Regards,
>> --
>> Ilya Kasnacheev
>>
>>
>> пт, 21 авг. 2020 г. в 16:50, Nikolay Izhikov <ni...@apache.org>:
>>
>>> Hello, Igniters.
>>>
>>> For now, we have dozens of the `IgniteSystemProperties` [1] that can
>>> tweak Ignite behaviour in the very wide limits.
>>> But, the issue, for the administrator is the following
>>>
>>> - Documentation about existing properties can be outdated.
>>> - The only place of the truth is the source code.
>>> - It’s hard to understand what flag is supported in what version.
>>>
>>> I propose to implement output of all available properties with it’s
>>> descriptions in the `ignite.sh -X` command.
>>>
>>> Example of the JVM output:
>>>
>>> ```
>>> [16:25:49]~/src/ignite:[master]$ java -X
>>>
>>> -Xbatch disable background compilation
>>> -Xbootclasspath/a:<directories and zip/jar files separated by :>
>>> append to end of bootstrap class path
>>> -Xcheck:jni perform additional checks for JNI functions
>>> -Xcomp forces compilation of methods on first invocation
>>> -Xdebug provided for backward compatibility
>>> -Xdiag show additional diagnostic messages
>>> -Xfuture enable strictest checks, anticipating future default
>>> -Xint interpreted mode execution only
>>> -Xinternalversion
>>> displays more detailed JVM version information than
>>> the
>>>
>>> [16:28:45]~/src/ignite:[master]$ java -XX:+UnlockDiagnosticVMOptions
>>> -XX:+PrintFlagsFinal -version
>>>
>>> [Global flags]
>>> ccstrlist AOTLibrary =
>>> {product} {default}
>>> bool AbortVMOnCompilationFailure = false
>>> {diagnostic} {default}
>>> ccstr AbortVMOnException =
>>> {diagnostic} {default}
>>> ccstr AbortVMOnExceptionMessage =
>>> {diagnostic} {default}
>>> bool AbortVMOnSafepointTimeout = false
>>> {diagnostic} {default}
>>> bool AbortVMOnVMOperationTimeout = false
>>> {diagnostic} {default}
>>> intx AbortVMOnVMOperationTimeoutDelay = 1000
>>> {diagnostic} {default}
>>> int ActiveProcessorCount = -1
>>> {product} {default}
>>>
>>> ```
>>>
>>> Example of the Ignite output:
>>>
>>> ````
>>>> ignite.sh -X
>>> IGNITE_CONFIG_URL
>>> - System property to hold optional configuration URL.
>>> IGNITE_SSH_HOST -
>>> System property to hold SSH host for visor-started nodes.
>>> IGNITE_MIN_BUFFERED_COMMUNICATION_MSG_CNT - [DEPRECATED]
>>> System property to disable buffered communication if node sends less
>>> messages count than specified by this property. Default value is {@code
>>> 512}.
>>>
>>> …
>>>
>>> ```
>>>
>>> WDYT?
>>>
>>> [1]
>>> https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/IgniteSystemProperties.java#L56
>
Re: [DISCUSSION] Output IgniteSystemProperties via ignite.sh
Posted by Nikolay Izhikov <ni...@apache.org>.
Hello, Ilya.
> I think this is a bad idea since it legitimizes wide use of IGNITE_ properties, which shows weakness of our configuration API, etc.
We already have IGNITE options in the product as a part of public API. See `org.apache.ignite.IgniteSystemProperties`.
> 7 сент. 2020 г., в 14:40, Ilya Kasnacheev <il...@gmail.com> написал(а):
>
> Hello!
>
> I think this is a bad idea since it legitimizes wide use of IGNITE_
> properties, which shows weakness of our configuration API, etc.
>
> My take:
>
> All of IGNITE_ properties which are useful (and will go to -X) should
> instead be turned into configuration/metastore settings.
> All of IGNITE_ properties which are dangerous and/or useless should be
> removed.
>
> Regards,
> --
> Ilya Kasnacheev
>
>
> пт, 21 авг. 2020 г. в 16:50, Nikolay Izhikov <ni...@apache.org>:
>
>> Hello, Igniters.
>>
>> For now, we have dozens of the `IgniteSystemProperties` [1] that can
>> tweak Ignite behaviour in the very wide limits.
>> But, the issue, for the administrator is the following
>>
>> - Documentation about existing properties can be outdated.
>> - The only place of the truth is the source code.
>> - It’s hard to understand what flag is supported in what version.
>>
>> I propose to implement output of all available properties with it’s
>> descriptions in the `ignite.sh -X` command.
>>
>> Example of the JVM output:
>>
>> ```
>> [16:25:49]~/src/ignite:[master]$ java -X
>>
>> -Xbatch disable background compilation
>> -Xbootclasspath/a:<directories and zip/jar files separated by :>
>> append to end of bootstrap class path
>> -Xcheck:jni perform additional checks for JNI functions
>> -Xcomp forces compilation of methods on first invocation
>> -Xdebug provided for backward compatibility
>> -Xdiag show additional diagnostic messages
>> -Xfuture enable strictest checks, anticipating future default
>> -Xint interpreted mode execution only
>> -Xinternalversion
>> displays more detailed JVM version information than
>> the
>>
>> [16:28:45]~/src/ignite:[master]$ java -XX:+UnlockDiagnosticVMOptions
>> -XX:+PrintFlagsFinal -version
>>
>> [Global flags]
>> ccstrlist AOTLibrary =
>> {product} {default}
>> bool AbortVMOnCompilationFailure = false
>> {diagnostic} {default}
>> ccstr AbortVMOnException =
>> {diagnostic} {default}
>> ccstr AbortVMOnExceptionMessage =
>> {diagnostic} {default}
>> bool AbortVMOnSafepointTimeout = false
>> {diagnostic} {default}
>> bool AbortVMOnVMOperationTimeout = false
>> {diagnostic} {default}
>> intx AbortVMOnVMOperationTimeoutDelay = 1000
>> {diagnostic} {default}
>> int ActiveProcessorCount = -1
>> {product} {default}
>>
>> ```
>>
>> Example of the Ignite output:
>>
>> ````
>>> ignite.sh -X
>> IGNITE_CONFIG_URL
>> - System property to hold optional configuration URL.
>> IGNITE_SSH_HOST -
>> System property to hold SSH host for visor-started nodes.
>> IGNITE_MIN_BUFFERED_COMMUNICATION_MSG_CNT - [DEPRECATED]
>> System property to disable buffered communication if node sends less
>> messages count than specified by this property. Default value is {@code
>> 512}.
>>
>> …
>>
>> ```
>>
>> WDYT?
>>
>> [1]
>> https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/IgniteSystemProperties.java#L56