ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ilya Kasnacheev <ilya.kasnach...@gmail.com>
Subject Re: [DISCUSSION] Output IgniteSystemProperties via ignite.sh
Date Mon, 07 Sep 2020 15:46:07 GMT
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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message