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