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 > > >> > > > > > > > > > > >
