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 17:48:04 GMT
Ilya.

> I'm just saying that we can make it possible as a general principle.

+1 to remove as many internal flags as possible.


> 7 сент. 2020 г., в 20:20, Ilya Kasnacheev <ilya.kasnacheev@gmail.com> написал(а):
> 
> Hello!
> 
> I'm not arguing that it should not be discussed. I'm just saying that we
> can make it possible as a general principle.
> 
> Regards,
> -- 
> Ilya Kasnacheev
> 
> 
> пн, 7 сент. 2020 г. в 19:01, Nikolay Izhikov <nizhikov@apache.org>:
> 
>>> 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 <ilya.kasnacheev@gmail.com>
>> написал(а):
>>> 
>>> 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 <nizhikov@apache.org>:
>>> 
>>>> 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