ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nikolay Izhikov <nizhi...@apache.org>
Subject Re: [DISCUSSION] Output IgniteSystemProperties via ignite.sh
Date Mon, 07 Sep 2020 15:34:47 GMT
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 <masharov.fv@gmail.com> написал(а):
> 
> 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 <ilya.kasnacheev@gmail.com>
> 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 <nizhikov@apache.org>:
>> 
>>>> 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 <
>>> stephen.darlington@gridgain.com> написал(а):
>>>> 
>>>> 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 <nizhikov@apache.org>
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 <ilya.kasnacheev@gmail.com
>>> 
>>> написал(а):
>>>>>> 
>>>>>> 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 <nizhikov@apache.org>:
>>>>>> 
>>>>>>> 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
>>>>> 
>>>> 
>>>> 
>>> 
>>> 
>> 


Mime
View raw message