[DISCUSSION] Output IgniteSystemProperties via ignite.sh
Locked
[DISCUSSION] Output IgniteSystemProperties via ignite.sh
 
|
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
|
|
Good catch, as for me, do you plan some autogeneration here? > >> >>>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
|
|
Yes, of course.
I think we have to make IgniteSystemProperties enum and traverse it in runtime. Отправлено с iPhone > 21 авг. 2020 г., в 17:54, Zhenya Stanilovsky <[hidden email]> написал(а): > > > > Good catch, as for me, do you plan some autogeneration here? > >> >>> >>>> 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 >>> >>> >>> >>> |
|
|
Nikolay,
I fully support the idea as well but wonder if the "-X" is the best name. Is this a common practice to use the "-X"? Should we consider a longer name such as "-systemProps"? - Denis On Fri, Aug 21, 2020 at 7:57 AM Николай Ижиков <[hidden email]> wrote: > Yes, of course. > I think we have to make IgniteSystemProperties enum and traverse it in > runtime. > > Отправлено с iPhone > > > 21 авг. 2020 г., в 17:54, Zhenya Stanilovsky <[hidden email]> > написал(а): > > > > > > > > Good catch, as for me, do you plan some autogeneration here? > > > >> > >>> > >>>> 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
|
|
Hello, Denis.
Thanks, for the support. The name of the parameter is the matter of discussion, of course. I just take the JVM approach as an example. Let’s go with the -systemProps :) > 21 авг. 2020 г., в 18:04, Denis Magda <[hidden email]> написал(а): > > Nikolay, > > I fully support the idea as well but wonder if the "-X" is the best name. > Is this a common practice to use the "-X"? Should we consider a longer name > such as "-systemProps"? > > > - > Denis > > > On Fri, Aug 21, 2020 at 7:57 AM Николай Ижиков <[hidden email]> wrote: > >> Yes, of course. >> I think we have to make IgniteSystemProperties enum and traverse it in >> runtime. >> >> Отправлено с iPhone >> >>> 21 авг. 2020 г., в 17:54, Zhenya Stanilovsky <[hidden email]> >> написал(а): >>> >>> >>> >>> Good catch, as for me, do you plan some autogeneration here? >>> >>>> >>>>> >>>>>> 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
|
|
I think this is a helpful feature. I have created the issue:
https://issues.apache.org/jira/browse/IGNITE-13380 |
Re: [DISCUSSION] Output IgniteSystemProperties via ignite.sh
|
|
In reply to this post by Nikolay Izhikov-2
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 <[hidden email]>: > 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
|
|
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 <[hidden email]> написал(а): > > 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 <[hidden email]>: > >> 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
|
|
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 <[hidden email]> 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 <[hidden email]> написал(а): >> >> 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 <[hidden email]>: >> >>> 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
|
|
> 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 <[hidden email]> написал(а): > > 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 <[hidden email]> 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 <[hidden email]> написал(а): >>> >>> 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 <[hidden email]>: >>> >>>> 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
|
|
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 <[hidden email]>: > > 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 < > [hidden email]> написал(а): > > > > 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 <[hidden email]> 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 <[hidden email]> > написал(а): > >>> > >>> 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 <[hidden email]>: > >>> > >>>> 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 > >> > > > > > > |
|
|
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 <[hidden email]> 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 <[hidden email]>: > > > > 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 < > > [hidden email]> написал(а): > > > > > > 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 <[hidden email]> 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 <[hidden email] > > > > написал(а): > > >>> > > >>> 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 <[hidden email]>: > > >>> > > >>>> 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
|
|
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 <[hidden email]> написал(а): > > 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 <[hidden email]> > 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 <[hidden email]>: >> >>>> 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 < >>> [hidden email]> написал(а): >>>> >>>> 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 <[hidden email]> 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 <[hidden email] >>> >>> написал(а): >>>>>> >>>>>> 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 <[hidden email]>: >>>>>> >>>>>>> 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
|
|
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 <[hidden email]>: > 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 <[hidden email]> > написал(а): > > > > 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 < > [hidden email]> > > 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 <[hidden email]>: > >> > >>>> 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 < > >>> [hidden email]> написал(а): > >>>> > >>>> 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 <[hidden email]> > 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 < > [hidden email] > >>> > >>> написал(а): > >>>>>> > >>>>>> 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 <[hidden email]>: > >>>>>> > >>>>>>> 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
|
|
> 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 <[hidden email]> написал(а): > > 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 <[hidden email]>: > >> 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 <[hidden email]> >> написал(а): >>> >>> 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 < >> [hidden email]> >>> 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 <[hidden email]>: >>>> >>>>>> 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 < >>>>> [hidden email]> написал(а): >>>>>> >>>>>> 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 <[hidden email]> >> 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 < >> [hidden email] >>>>> >>>>> написал(а): >>>>>>>> >>>>>>>> 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 <[hidden email]>: >>>>>>>> >>>>>>>>> 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
|
|
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 <[hidden email]>: > > 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 <[hidden email]> > написал(а): > > > > 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 <[hidden email]>: > > > >> 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 <[hidden email]> > >> написал(а): > >>> > >>> 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 < > >> [hidden email]> > >>> 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 <[hidden email]>: > >>>> > >>>>>> 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 < > >>>>> [hidden email]> написал(а): > >>>>>> > >>>>>> 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 <[hidden email]> > >> 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 < > >> [hidden email] > >>>>> > >>>>> написал(а): > >>>>>>>> > >>>>>>>> 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 <[hidden email] > >: > >>>>>>>> > >>>>>>>>> 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
|
|
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 <[hidden email]> написал(а): > > 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 <[hidden email]>: > >>> 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 <[hidden email]> >> написал(а): >>> >>> 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 <[hidden email]>: >>> >>>> 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 <[hidden email]> >>>> написал(а): >>>>> >>>>> 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 < >>>> [hidden email]> >>>>> 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 <[hidden email]>: >>>>>> >>>>>>>> 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 < >>>>>>> [hidden email]> написал(а): >>>>>>>> >>>>>>>> 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 <[hidden email]> >>>> 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 < >>>> [hidden email] >>>>>>> >>>>>>> написал(а): >>>>>>>>>> >>>>>>>>>> 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 <[hidden email] >>> : >>>>>>>>>> >>>>>>>>>>> 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 >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>> >>>> >> >> |
«
Return to Apache Ignite Developers - Legacy Mail Archive
|
1 view|%1 views
| Free forum by Nabble | Edit this page |