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 <[email protected]>: > > 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 < > [email protected]> написал(а): > > > > 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 <[email protected]> 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 <[email protected]> > написал(а): > >>> > >>> 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 <[email protected]>: > >>> > >>>> 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 > >> > > > > > >
