ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexey Goncharuk <alexey.goncha...@gmail.com>
Subject Re: Control.sh usability & possible bugs
Date Tue, 27 Aug 2019 16:33:02 GMT
The ticket is created, the patch is attached:
https://issues.apache.org/jira/browse/IGNITE-12113

Also, I see some weird stuff going on in control.sh - I see no reason for
calling findAvailableJmxPort, restart file, interactive mode and restart
loop in the end. Looks like the script can be significantly simplified,
will create a separate ticket for this as well.

вт, 27 авг. 2019 г. в 19:06, Alexey Goncharuk <alexey.goncharuk@gmail.com>:

> Got to the bottom of the issue with empty output and no JAVA_HOME.
>
> The reason is the following line in bin/control.sh:
>
> javaMajorVersion "${JAVA_HOME}/bin/java"
>
> Since JAVA_HOME is empty, the argument passed to the function is invalid
> and terminates the script. I suggest to replace the "${JAVA_HOME}/bin/java"
> with just "$JAVA" because it is already determined earlier in the scope.
> The suggested fix works in my environment for all options of JAVA_HOME. I
> will create a ticket for 2.7.6 scope if there are no objections.
>
> Petr, do you have any idea how we can change the script to not fail
> silently and print at least some hint if it terminates early?
>
> вт, 27 авг. 2019 г. в 18:27, Sergey Antonov <antonovsergey93@gmail.com>:
>
>> Hi everyone!
>>
>> Issue 3 fixed in master.
>> In master control.sh now is:
>> *> control.sh --help*
>>
>> Control utility [ver. 2.8.0-SNAPSHOT#20190827-sha1:DEV]
>> 2019 Copyright(C) Apache Software Foundation
>> User: santonov
>> Time: 2019-08-27T18:22:45.023
>> Control utility script is used to execute admin commands on cluster or get
>> common cluster info. The command has the following syntax:
>>
>>   control.(sh|bat) [--host HOST_OR_IP] [--port PORT] [--user USER]
>> [--password PASSWORD] [--ping-interval PING_INTERVAL] [--ping-timeout
>> PING_TIMEOUT] [--ssl-protocol SSL_PROTOCOL[, SSL_PROTOCOL_2, ...,
>> SSL_PROTOCOL_N]] [--ssl-cipher-suites SSL_CIPHER_1[, SSL_CIPHER_2, ...,
>> SSL_CIPHER_N]] [--ssl-key-algorithm SSL_KEY_ALGORITHM] [--keystore-type
>> KEYSTORE_TYPE] [--keystore KEYSTORE_PATH] [--keystore-password
>> KEYSTORE_PASSWORD] [--truststore-type TRUSTSTORE_TYPE] [--truststore
>> TRUSTSTORE_PATH] [--truststore-password TRUSTSTORE_PASSWORD] [command]
>> <command_parameters>
>>
>>
>> This utility can do the following commands:
>>   Activate cluster:
>>     control.(sh|bat) --activate
>>
>>   Deactivate cluster:
>>     control.(sh|bat) --deactivate [--yes]
>>
>>   Print current cluster state:
>>     control.(sh|bat) --state
>>
>>   Print cluster baseline topology:
>>     control.(sh|bat) --baseline
>>
>>   Add nodes into baseline topology:
>>     control.(sh|bat) --baseline add
>> consistentId1[,consistentId2,....,consistentIdN] [--yes]
>>
>>   Remove nodes from baseline topology:
>>     control.(sh|bat) --baseline remove
>> consistentId1[,consistentId2,....,consistentIdN] [--yes]
>>
>>   Set baseline topology:
>>     control.(sh|bat) --baseline set
>> consistentId1[,consistentId2,....,consistentIdN] [--yes]
>>
>>   Set baseline topology based on version:
>>     control.(sh|bat) --baseline version topologyVersion [--yes]
>>
>>   Set baseline autoadjustment settings:
>>     control.(sh|bat) --baseline auto_adjust [disable|enable] [timeout
>> <timeoutMillis>] [--yes]
>>
>>   List or kill transactions:
>>     control.(sh|bat) --tx [--xid XID] [--min-duration SECONDS] [--min-size
>> SIZE] [--label PATTERN_REGEX] [--servers|--clients] [--nodes
>> consistentId1[,consistentId2,....,consistentIdN]] [--limit NUMBER]
>> [--order
>> DURATION|SIZE|START_TIME] [--kill] [--info] [--yes]
>>
>>   Print detailed information (topology and key lock ownership) about
>> specific transaction:
>>     control.(sh|bat) --tx --info <TX identifier as GridCacheVersion
>> [topVer=..., order=..., nodeOrder=...] (can be found in logs)>|<TX
>> identifier as UUID (can be retrieved via --tx command)>
>>
>>   View caches information in a cluster. For more details type:
>>     control.(sh|bat) --cache help
>>
>>   Print absolute paths of unused archived wal segments on each node:
>>     control.(sh|bat) --wal print
>> [consistentId1,consistentId2,....,consistentIdN]
>>
>>   Delete unused archived wal segments on each node:
>>     control.(sh|bat) --wal delete
>> [consistentId1,consistentId2,....,consistentIdN] [--yes]
>>
>>   View diagnostic information in a cluster. For more details type:
>>     control.(sh|bat) --diagnostic
>>
>>   Enable read-only mode on active cluster:
>>     control.(sh|bat) --read-only-on [--yes]
>>
>>   Disable read-only mode on active cluster:
>>     control.(sh|bat) --read-only-off [--yes]
>>
>> By default commands affecting the cluster require interactive
>> confirmation.
>> Use --yes option to disable it.
>>
>> Default values:
>>     HOST_OR_IP=127.0.0.1
>>     PORT=11211
>>     PING_INTERVAL=5000
>>     PING_TIMEOUT=30000
>>     SSL_PROTOCOL=TLS
>>     SSL_KEY_ALGORITHM=SunX509
>>     KEYSTORE_TYPE=JKS
>>     TRUSTSTORE_TYPE=JKS
>>
>> Exit codes:
>>     0 - successful execution.
>>     1 - invalid arguments.
>>     2 - connection failed.
>>     3 - authentication failed.
>>     4 - unexpected error.
>> Control utility has completed execution at: 2019-08-27T18:22:45.193
>> Execution time: 170 ms
>>
>> *> control.sh --cache help*
>>
>> Control utility [ver. 2.8.0-SNAPSHOT#20190827-sha1:DEV]
>> 2019 Copyright(C) Apache Software Foundation
>> User: santonov
>> Time: 2019-08-27T18:25:01.577
>> Command [CACHE] started
>> Arguments: --cache help --yes
>>
>> --------------------------------------------------------------------------------
>>   The '--cache subcommand' is used to get information about and perform
>> actions with caches. The command has the following syntax:
>>
>>   control.(sh|bat) [--host HOST_OR_IP] [--port PORT] [--user USER]
>> [--password PASSWORD] [--ping-interval PING_INTERVAL] [--ping-timeout
>> PING_TIMEOUT] [--ssl-protocol SSL_PROTOCOL[, SSL_PROTOCOL_2, ...,
>> SSL_PROTOCOL_N]] [--ssl-cipher-suites SSL_CIPHER_1[, SSL_CIPHER_2, ...,
>> SSL_CIPHER_N]] [--ssl-key-algorithm SSL_KEY_ALGORITHM] [--keystore-type
>> KEYSTORE_TYPE] [--keystore KEYSTORE_PATH] [--keystore-password
>> KEYSTORE_PASSWORD] [--truststore-type TRUSTSTORE_TYPE] [--truststore
>> TRUSTSTORE_PATH] [--truststore-password TRUSTSTORE_PASSWORD] --cache
>> [subcommand] <subcommand_parameters>
>>
>>   The subcommands that take [nodeId] as an argument ('list',
>> 'find_garbage', 'contention' and 'validate_indexes') will be executed on
>> the given node or on all server nodes if the option is not specified.
>> Other
>> commands will run on a random server node.
>>
>>
>>   Subcommands:
>>
>>   --cache idle_verify [--dump] [--skip-zeros] [--check-crc]
>> [--exclude-caches cacheName1,...,cacheNameN] [--cache-filter
>> DEFAULT|SYSTEM|PERSISTENT|NOT_PERSISTENT|USER|ALL]
>> [cacheName1,...,cacheNameN]
>>     Verify counters and hash sums of primary and backup partitions for the
>> specified caches/cache groups on an idle cluster and print out the
>> differences, if any. Cache filtering options configure the set of caches
>> that will be processed by idle_verify command. Default value for the set
>> of
>> cache names (or cache group names) is all cache groups. Default value for
>> --exclude-caches is empty set. Default value for --cache-filter is no
>> filtering. Therefore, the set of all caches is sequently filtered by cache
>> name regexps, by cache type and after all by exclude regexps.
>>
>>     Parameters:
>>       --check-crc  - check the CRC-sum of pages stored on disk before
>> verifying data consistency in partitions between primary and backup nodes.
>>
>>   --cache list regexPattern [--groups|--seq] [nodeId] [--config]
>> [--output-format multi-line]
>>     Show information about caches, groups or sequences that match a
>> regular
>> expression. When executed without parameters, this subcommand prints the
>> list of caches.
>>
>>     Parameters:
>>       --config                    - print all configuration parameters for
>> each cache.
>>       --output-format multi-line  - print configuration parameters per
>> line. This option has effect only when used with --config and without
>> [--groups|--seq].
>>       --groups                    - print information about groups.
>>       --seq                       - print information about sequences.
>>
>>   --cache validate_indexes [cacheName1,...,cacheNameN] [nodeId]
>> [--check-first N|--check-through K]
>>     Verify counters and hash sums of primary and backup partitions for the
>> specified caches/cache groups on an idle cluster and print out the
>> differences, if any. Cache filtering options configure the set of caches
>> that will be processed by idle_verify command. Default value for the set
>> of
>> cache names (or cache group names) is all cache groups. Default value for
>> --exclude-caches is empty set. Default value for --cache-filter is no
>> filtering. Therefore, the set of all caches is sequently filtered by cache
>> name regexps, by cache type and after all by exclude regexps.
>>
>>     Parameters:
>>       --check-first N    - validate only the first N keys
>>       --check-through K  - validate every Kth key
>>
>>   --cache contention minQueueSize [nodeId] [maxPrint]
>>     Show the keys that are point of contention for multiple transactions.
>>
>>   --cache distribution nodeId|null [cacheName1,...,cacheNameN]
>> [--user-attributes attrName1,...,attrNameN]
>>     Prints the information about partition distribution.
>>
>>   --cache reset_lost_partitions cacheName1,...,cacheNameN
>>     Reset the state of lost partitions for the specified caches.
>>
>>   --cache find_garbage [groupName1,...,groupNameN] [nodeId] [--delete]
>>     Find and optionally delete garbage from shared cache groups which
>> could
>> be left after cache destroy.
>>
>> Command [CACHE] finished with code: 0
>> Control utility has completed execution at: 2019-08-27T18:25:01.857
>> Execution time: 280 ms
>>
>> вт, 27 авг. 2019 г. в 17:30, Artem Budnikov <a.budnikov.ignite@gmail.com
>> >:
>>
>> > Hi everyone,
>> >
>> > Re Issue 3:
>> >
>> > That's a good idea, but as far as I remember this was done in
>> > https://jira.apache.org/jira/browse/IGNITE-10279 and is waiting to be
>> > released in Ignite 2.8.
>> >
>> > -Artem
>> >
>> > On 26.08.2019 15:18, Anton Kalashnikov wrote:
>> > > Hello, Igniters.
>> > >
>> > > +1 for Script help usability - issue 3
>> > >
>> > > Looks like it will be great if we avoid the repeated output of the
>> > commands, ex.:
>> > >
>> > > control.sh [--host HOST_OR_IP] [--port PORT] [--user USER] [--password
>> > PASSWORD]  [--ping-interval PING_INTERVAL] [--ping-timeout PING_TIMEOUT]
>> > [<command>] [--yes]
>> > >
>> > > Allowable <command>:
>> > > --activate - ...
>> > > --deactivate - ...
>> > > ...
>> > >
>> > > --
>> > > Best regards,
>> > > Anton Kalashnikov
>> > >
>> > >
>> > > 26.08.2019, 15:00, "Dmitriy Pavlov" <dpavlov@apache.org>:
>> > >> Hi Igniters,
>> > >>
>> > >> During voting on 2.7.6-rc1, I saw how experienced Ignite contributor
>> > >> committer and PMC member were trying to activate cluster using
>> > control.sh
>> > >> command.
>> > >>
>> > >> We usually just call cluster().active(true), but end users have to
>> use
>> > the
>> > >> script provided in the distribution.
>> > >>
>> > >> Related to control.sh there are 3 concerns:
>> > >>
>> > >> Issue 1: On Mac OS if there is an empty (unset) JAVA_HOME variable,
>> > script
>> > >> outputs noting and probably does not execute its comment.
>> > >>
>> > >> Petr Ivanov, Alexey Goncharuck, could you please double-check if it
>> > could
>> > >> be fixed?
>> > >>
>> > >> Issue 2: Control.sh was not able to connect to cluster (local). AFAIK
>> > >> multicast is still our defaults. so it should be possible to connect
>> to
>> > >> cluster without any options.
>> > >>
>> > >> Ivan Rakov, could you please chime in? Is it a local issue or bug?
>> > >>
>> > >> Issue 3: Script help usability
>> > >>
>> > >> Example of output:
>> > >>
>> > >>   Activate cluster:
>> > >>
>> > >>      control.sh [--host HOST_OR_IP] [--port PORT] [--user USER]
>> > [--password
>> > >> PASSWORD] [--ping-interval PING_INTERVAL] [--ping-timeout
>> PING_TIMEOUT]
>> > >> --activate
>> > >>
>> > >>    Deactivate cluster:
>> > >>
>> > >>      control.sh [--host HOST_OR_IP] [--port PORT] [--user USER]
>> > [--password
>> > >> PASSWORD] [--ping-interval PING_INTERVAL] [--ping-timeout
>> PING_TIMEOUT]
>> > >> --deactivate [--yes]
>> > >>
>> > >>   ...
>> > >>
>> > >> Why do we repeat tons of parameters each time? Is it better for
>> users to
>> > >> enlist options and commands separately?
>> > >>
>> > >>   control.sh [options] command
>> > >>
>> > >> and then enlist options
>> > >>
>> > >> [--host HOST_OR_IP]
>> > >>
>> > >> [--port PORT]
>> > >>
>> > >> [--user USER]
>> > >>
>> > >> [--password PASSWORD]
>> > >>
>> > >> [--ping-interval PING_INTERVAL]
>> > >>
>> > >> [--ping-timeout PING_TIMEOUT]
>> > >>
>> > >> and describe several commands we have?
>> > >>
>> > >> In coding WET is not the best solution. So maybe we could DRY in our
>> > help,
>> > >> should we?
>> > >>
>> > >> Artem Boudnikov, could you evaluate this idea?
>> > >>
>> > >> Sincerely,
>> > >> Dmitriy Pavlov
>> >
>>
>>
>> --
>> BR, Sergey Antonov
>>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message