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 <antonovserge...@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.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
>
