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