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.ign...@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" <dpav...@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
