Control.sh usability & possible bugs

[Dmitry Pavlov]

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

[Anton Kalashnikov]

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" <[hidden email]>:

> 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

[Artem Budnikov]

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" <[hidden email]>:
>> 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

[Dmitry Pavlov]

Hi Artem, thank you for your reply.

Since this change is on its way, let's wait for 2.8.


Petr Ivanov, Alexey Goncharuck, Ivan Rakov, could you please step in and
provide your feedback related to Issue 1 & 2?





вт, 27 авг. 2019 г. в 17:30, Artem Budnikov <[hidden email]>:

> 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" <[hidden email]>:
> >> 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
>

[Alexey Goncharuk]

Dmitriy,

I confirm the first issue but did not get to the bottom of it yet; will
keep you posted.

вт, 27 авг. 2019 г. в 17:34, Dmitriy Pavlov <[hidden email]>:

> Hi Artem, thank you for your reply.
>
> Since this change is on its way, let's wait for 2.8.
>
>
> Petr Ivanov, Alexey Goncharuck, Ivan Rakov, could you please step in and
> provide your feedback related to Issue 1 & 2?
>
>
>
>
>
> вт, 27 авг. 2019 г. в 17:30, Artem Budnikov <[hidden email]>:
>
> > 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" <[hidden email]>:
> > >> 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
> >
>

[antonovsergey93]

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 <[hidden email]>:

> 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" <[hidden email]>:
> >> 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

[Alexey Goncharuk]

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 <[hidden email]>:

> 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 <[hidden email]>:
>
> > 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" <[hidden email]>:
> > >> 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
>

[Alexey Goncharuk]

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 <[hidden email]>:

> 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 <[hidden email]>:
>
>> 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 <[hidden email]
>> >:
>>
>> > 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" <[hidden email]>:
>> > >> 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
>>
>