[jira] [Updated] (IGNITE-13277) ignite-zookeeper does not work with Java 14
[
https://issues.apache.org/jira/browse/IGNITE-13277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Max Shonichev updated IGNITE-13277:
---
Component/s: zookeeper
> ignite-zookeeper does not work with Java 14
> ---
>
> Key: IGNITE-13277
> URL: https://issues.apache.org/jira/browse/IGNITE-13277
> Project: Ignite
> Issue Type: Bug
> Components: zookeeper
>Affects Versions: 2.7
>Reporter: Max Shonichev
>Priority: Major
>
> ignite-zookeeper module depends on 3.4 zookeeper branch, which is known to
> fail with Java 14, see https://issues.apache.org/jira/browse/ZOOKEEPER-3779
> Symptom:
> {noformat}
> Initiating client connection, connectString=127.0.0.1:2181
> sessionTimeout=3
> watcher=org.apache.ignite.spi.discovery.zk.internal.ZookeeperClient@49665f92
> [2020-07-20 18:18:43,512][WARN
> ][zk-null-SendThread(127.0.0.1:2181)][ClientCnxn] Session 0x0 for server
> 127.0.0.1/:2181, unexpected error, closing socket connection and
> attempting reconnect
> java.lang.IllegalArgumentException: Unable to canonicalize address
> 127.0.0.1/:2181 because it's not resolvable
> {noformat}
> Workaround: none yet, need to upgrade ignite-zookeeper to 3.5 branch or wait
> ticket ZOOKEEPER-3779 closed.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13277) ignite-zookeeper does not work with Java 14
[
https://issues.apache.org/jira/browse/IGNITE-13277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Max Shonichev updated IGNITE-13277:
---
Labels: Java14 (was: )
> ignite-zookeeper does not work with Java 14
> ---
>
> Key: IGNITE-13277
> URL: https://issues.apache.org/jira/browse/IGNITE-13277
> Project: Ignite
> Issue Type: Bug
> Components: zookeeper
>Affects Versions: 2.7
>Reporter: Max Shonichev
>Priority: Major
> Labels: Java14
>
> ignite-zookeeper module depends on 3.4 zookeeper branch, which is known to
> fail with Java 14, see https://issues.apache.org/jira/browse/ZOOKEEPER-3779
> Symptom:
> {noformat}
> Initiating client connection, connectString=127.0.0.1:2181
> sessionTimeout=3
> watcher=org.apache.ignite.spi.discovery.zk.internal.ZookeeperClient@49665f92
> [2020-07-20 18:18:43,512][WARN
> ][zk-null-SendThread(127.0.0.1:2181)][ClientCnxn] Session 0x0 for server
> 127.0.0.1/:2181, unexpected error, closing socket connection and
> attempting reconnect
> java.lang.IllegalArgumentException: Unable to canonicalize address
> 127.0.0.1/:2181 because it's not resolvable
> {noformat}
> Workaround: none yet, need to upgrade ignite-zookeeper to 3.5 branch or wait
> ticket ZOOKEEPER-3779 closed.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13277) ignite-zookeeper does not work with Java 14
[
https://issues.apache.org/jira/browse/IGNITE-13277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Max Shonichev updated IGNITE-13277:
---
Affects Version/s: 2.7
> ignite-zookeeper does not work with Java 14
> ---
>
> Key: IGNITE-13277
> URL: https://issues.apache.org/jira/browse/IGNITE-13277
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.7
>Reporter: Max Shonichev
>Priority: Major
>
> ignite-zookeeper module depends on 3.4 zookeeper branch, which is known to
> fail with Java 14, see https://issues.apache.org/jira/browse/ZOOKEEPER-3779
> Symptom:
> {noformat}
> Initiating client connection, connectString=127.0.0.1:2181
> sessionTimeout=3
> watcher=org.apache.ignite.spi.discovery.zk.internal.ZookeeperClient@49665f92
> [2020-07-20 18:18:43,512][WARN
> ][zk-null-SendThread(127.0.0.1:2181)][ClientCnxn] Session 0x0 for server
> 127.0.0.1/:2181, unexpected error, closing socket connection and
> attempting reconnect
> java.lang.IllegalArgumentException: Unable to canonicalize address
> 127.0.0.1/:2181 because it's not resolvable
> {noformat}
> Workaround: none yet, need to upgrade ignite-zookeeper to 3.5 branch or wait
> ticket ZOOKEEPER-3779 closed.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-13277) ignite-zookeeper does not work with Java 14
Max Shonichev created IGNITE-13277:
--
Summary: ignite-zookeeper does not work with Java 14
Key: IGNITE-13277
URL: https://issues.apache.org/jira/browse/IGNITE-13277
Project: Ignite
Issue Type: Bug
Reporter: Max Shonichev
ignite-zookeeper module depends on 3.4 zookeeper branch, which is known to fail
with Java 14, see https://issues.apache.org/jira/browse/ZOOKEEPER-3779
Symptom:
{noformat}
Initiating client connection, connectString=127.0.0.1:2181 sessionTimeout=3
watcher=org.apache.ignite.spi.discovery.zk.internal.ZookeeperClient@49665f92
[2020-07-20 18:18:43,512][WARN
][zk-null-SendThread(127.0.0.1:2181)][ClientCnxn] Session 0x0 for server
127.0.0.1/:2181, unexpected error, closing socket connection and
attempting reconnect
java.lang.IllegalArgumentException: Unable to canonicalize address
127.0.0.1/:2181 because it's not resolvable
{noformat}
Workaround: none yet, need to upgrade ignite-zookeeper to 3.5 branch or wait
ticket ZOOKEEPER-3779 closed.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (IGNITE-9539) Add SQL column precision existence check if scale parameter is setted
[ https://issues.apache.org/jira/browse/IGNITE-9539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Max Shonichev closed IGNITE-9539. - Ignite Flags: (was: Docs Required) > Add SQL column precision existence check if scale parameter is setted > - > > Key: IGNITE-9539 > URL: https://issues.apache.org/jira/browse/IGNITE-9539 > Project: Ignite > Issue Type: Bug >Reporter: PetrovMikhail >Priority: Major > Labels: sql-engine > > We should handle situation when user sets only scale without precision in > decimal column constraints. According to > [http://www.h2database.com/html/datatypes.html#decimal_type] it's not valid > behavior. > Currently, we ignore it. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-9539) Add SQL column precision existence check if scale parameter is setted
[
https://issues.apache.org/jira/browse/IGNITE-9539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16983977#comment-16983977
]
Max Shonichev commented on IGNITE-9539:
---
According to [http://www.h2database.com/html/datatypes.html#decimal_type]
{{DECIMAL(precisionInt)}} is both valid as is {{DECIMAL(precisionInt,scale)}}
> Add SQL column precision existence check if scale parameter is setted
> -
>
> Key: IGNITE-9539
> URL: https://issues.apache.org/jira/browse/IGNITE-9539
> Project: Ignite
> Issue Type: Bug
>Reporter: PetrovMikhail
>Priority: Major
> Labels: sql-engine
>
> We should handle situation when user sets only scale without precision in
> decimal column constraints. According to
> [http://www.h2database.com/html/datatypes.html#decimal_type] it's not valid
> behavior.
> Currently, we ignore it.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (IGNITE-9539) Add SQL column precision existence check if scale parameter is setted
[ https://issues.apache.org/jira/browse/IGNITE-9539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Max Shonichev resolved IGNITE-9539. --- Resolution: Invalid > Add SQL column precision existence check if scale parameter is setted > - > > Key: IGNITE-9539 > URL: https://issues.apache.org/jira/browse/IGNITE-9539 > Project: Ignite > Issue Type: Bug >Reporter: PetrovMikhail >Priority: Major > Labels: sql-engine > > We should handle situation when user sets only scale without precision in > decimal column constraints. According to > [http://www.h2database.com/html/datatypes.html#decimal_type] it's not valid > behavior. > Currently, we ignore it. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12011) MetricUpdater timeout can't be configured
Max Shonichev created IGNITE-12011:
--
Summary: MetricUpdater timeout can't be configured
Key: IGNITE-12011
URL: https://issues.apache.org/jira/browse/IGNITE-12011
Project: Ignite
Issue Type: Bug
Affects Versions: 3.0
Reporter: Max Shonichev
Fix For: 3.0
{noformat}
/** Metrics update frequency. */
private static final long METRICS_UPDATE_FREQ = 3000;
...
/** {@inheritDoc} */
@Override protected void onKernalStart0() throws IgniteCheckedException {
metricsUpdateTask = ctx.timeout().schedule(new MetricsUpdater(),
METRICS_UPDATE_FREQ, METRICS_UPDATE_FREQ);
}
{noformat}
Would be great if metric updater timeout was externally configured.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (IGNITE-11583) Seems that copypasted code from ignite.sh is irrelevant in control.sh
[
https://issues.apache.org/jira/browse/IGNITE-11583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Max Shonichev updated IGNITE-11583:
---
Fix Version/s: 2.8
> Seems that copypasted code from ignite.sh is irrelevant in control.sh
> -
>
> Key: IGNITE-11583
> URL: https://issues.apache.org/jira/browse/IGNITE-11583
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Max Shonichev
>Priority: Minor
> Fix For: 2.8
>
>
> That piece of code in *control.sh* is copypasted from *ignite.sh*, however,
> as main class for control utility is *CommandHandler* instead of
> *CommandLineStartup*, the whole _loop until $RESTART_SUCCESS_FILE is created_
> logic just never works.
> {noformat}
> ERRORCODE="-1"
> while [ "${ERRORCODE}" -ne "130" ]
> do
> if [ "${INTERACTIVE:-}" == "1" ] ; then
> case $osname in
> Darwin*)
> "$JAVA" ${JVM_OPTS} ${QUIET:-} "${DOCK_OPTS}"
> "${RESTART_SUCCESS_OPT}" ${JMX_MON:-} \
> -DIGNITE_UPDATE_NOTIFIER=false -DIGNITE_HOME="${IGNITE_HOME}"
> \
> -DIGNITE_PROG_NAME="$0" ${JVM_XOPTS:-} -cp "${CP}"
> ${MAIN_CLASS} $@
> ;;
> *)
> "$JAVA" ${JVM_OPTS} ${QUIET:-} "${RESTART_SUCCESS_OPT}"
> ${JMX_MON:-} \
> -DIGNITE_UPDATE_NOTIFIER=false -DIGNITE_HOME="${IGNITE_HOME}"
> \
> -DIGNITE_PROG_NAME="$0" ${JVM_XOPTS:-} -cp "${CP}"
> ${MAIN_CLASS} $@
> ;;
> esac
> else
> case $osname in
> Darwin*)
> "$JAVA" ${JVM_OPTS} ${QUIET:-} "${DOCK_OPTS}"
> "${RESTART_SUCCESS_OPT}" ${JMX_MON:-} \
> -DIGNITE_UPDATE_NOTIFIER=false
> -DIGNITE_HOME="${IGNITE_HOME}" \
> -DIGNITE_PROG_NAME="$0" ${JVM_XOPTS:-} -cp "${CP}"
> ${MAIN_CLASS} $@
> ;;
> *)
> "$JAVA" ${JVM_OPTS} ${QUIET:-} "${RESTART_SUCCESS_OPT}"
> ${JMX_MON:-} \
> -DIGNITE_UPDATE_NOTIFIER=false
> -DIGNITE_HOME="${IGNITE_HOME}" \
> -DIGNITE_PROG_NAME="$0" ${JVM_XOPTS:-} -cp "${CP}"
> ${MAIN_CLASS} $@
> ;;
> esac
> fi
> ERRORCODE="$?"
> if [ ! -f "${RESTART_SUCCESS_FILE}" ] ; then
> break
> else
> rm -f "${RESTART_SUCCESS_FILE}"
> fi
> done
> if [ -f "${RESTART_SUCCESS_FILE}" ] ; then
> rm -f "${RESTART_SUCCESS_FILE}"
> fi
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11583) Seems that copypasted code from ignite.sh is irrelevant in control.sh
[
https://issues.apache.org/jira/browse/IGNITE-11583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Max Shonichev updated IGNITE-11583:
---
Affects Version/s: 2.5
> Seems that copypasted code from ignite.sh is irrelevant in control.sh
> -
>
> Key: IGNITE-11583
> URL: https://issues.apache.org/jira/browse/IGNITE-11583
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Max Shonichev
>Priority: Minor
>
> That piece of code in *control.sh* is copypasted from *ignite.sh*, however,
> as main class for control utility is *CommandHandler* instead of
> *CommandLineStartup*, the whole _loop until $RESTART_SUCCESS_FILE is created_
> logic just never works.
> {noformat}
> ERRORCODE="-1"
> while [ "${ERRORCODE}" -ne "130" ]
> do
> if [ "${INTERACTIVE:-}" == "1" ] ; then
> case $osname in
> Darwin*)
> "$JAVA" ${JVM_OPTS} ${QUIET:-} "${DOCK_OPTS}"
> "${RESTART_SUCCESS_OPT}" ${JMX_MON:-} \
> -DIGNITE_UPDATE_NOTIFIER=false -DIGNITE_HOME="${IGNITE_HOME}"
> \
> -DIGNITE_PROG_NAME="$0" ${JVM_XOPTS:-} -cp "${CP}"
> ${MAIN_CLASS} $@
> ;;
> *)
> "$JAVA" ${JVM_OPTS} ${QUIET:-} "${RESTART_SUCCESS_OPT}"
> ${JMX_MON:-} \
> -DIGNITE_UPDATE_NOTIFIER=false -DIGNITE_HOME="${IGNITE_HOME}"
> \
> -DIGNITE_PROG_NAME="$0" ${JVM_XOPTS:-} -cp "${CP}"
> ${MAIN_CLASS} $@
> ;;
> esac
> else
> case $osname in
> Darwin*)
> "$JAVA" ${JVM_OPTS} ${QUIET:-} "${DOCK_OPTS}"
> "${RESTART_SUCCESS_OPT}" ${JMX_MON:-} \
> -DIGNITE_UPDATE_NOTIFIER=false
> -DIGNITE_HOME="${IGNITE_HOME}" \
> -DIGNITE_PROG_NAME="$0" ${JVM_XOPTS:-} -cp "${CP}"
> ${MAIN_CLASS} $@
> ;;
> *)
> "$JAVA" ${JVM_OPTS} ${QUIET:-} "${RESTART_SUCCESS_OPT}"
> ${JMX_MON:-} \
> -DIGNITE_UPDATE_NOTIFIER=false
> -DIGNITE_HOME="${IGNITE_HOME}" \
> -DIGNITE_PROG_NAME="$0" ${JVM_XOPTS:-} -cp "${CP}"
> ${MAIN_CLASS} $@
> ;;
> esac
> fi
> ERRORCODE="$?"
> if [ ! -f "${RESTART_SUCCESS_FILE}" ] ; then
> break
> else
> rm -f "${RESTART_SUCCESS_FILE}"
> fi
> done
> if [ -f "${RESTART_SUCCESS_FILE}" ] ; then
> rm -f "${RESTART_SUCCESS_FILE}"
> fi
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11583) Seems that copypasted code from ignite.sh is irrelevant in control.sh
Max Shonichev created IGNITE-11583:
--
Summary: Seems that copypasted code from ignite.sh is irrelevant
in control.sh
Key: IGNITE-11583
URL: https://issues.apache.org/jira/browse/IGNITE-11583
Project: Ignite
Issue Type: Bug
Reporter: Max Shonichev
That piece of code in *control.sh* is copypasted from *ignite.sh*, however, as
main class for control utility is *CommandHandler* instead of
*CommandLineStartup*, the whole _loop until $RESTART_SUCCESS_FILE is created_
logic just never works.
{noformat}
ERRORCODE="-1"
while [ "${ERRORCODE}" -ne "130" ]
do
if [ "${INTERACTIVE:-}" == "1" ] ; then
case $osname in
Darwin*)
"$JAVA" ${JVM_OPTS} ${QUIET:-} "${DOCK_OPTS}"
"${RESTART_SUCCESS_OPT}" ${JMX_MON:-} \
-DIGNITE_UPDATE_NOTIFIER=false -DIGNITE_HOME="${IGNITE_HOME}" \
-DIGNITE_PROG_NAME="$0" ${JVM_XOPTS:-} -cp "${CP}"
${MAIN_CLASS} $@
;;
*)
"$JAVA" ${JVM_OPTS} ${QUIET:-} "${RESTART_SUCCESS_OPT}"
${JMX_MON:-} \
-DIGNITE_UPDATE_NOTIFIER=false -DIGNITE_HOME="${IGNITE_HOME}" \
-DIGNITE_PROG_NAME="$0" ${JVM_XOPTS:-} -cp "${CP}"
${MAIN_CLASS} $@
;;
esac
else
case $osname in
Darwin*)
"$JAVA" ${JVM_OPTS} ${QUIET:-} "${DOCK_OPTS}"
"${RESTART_SUCCESS_OPT}" ${JMX_MON:-} \
-DIGNITE_UPDATE_NOTIFIER=false -DIGNITE_HOME="${IGNITE_HOME}" \
-DIGNITE_PROG_NAME="$0" ${JVM_XOPTS:-} -cp "${CP}"
${MAIN_CLASS} $@
;;
*)
"$JAVA" ${JVM_OPTS} ${QUIET:-} "${RESTART_SUCCESS_OPT}"
${JMX_MON:-} \
-DIGNITE_UPDATE_NOTIFIER=false -DIGNITE_HOME="${IGNITE_HOME}" \
-DIGNITE_PROG_NAME="$0" ${JVM_XOPTS:-} -cp "${CP}"
${MAIN_CLASS} $@
;;
esac
fi
ERRORCODE="$?"
if [ ! -f "${RESTART_SUCCESS_FILE}" ] ; then
break
else
rm -f "${RESTART_SUCCESS_FILE}"
fi
done
if [ -f "${RESTART_SUCCESS_FILE}" ] ; then
rm -f "${RESTART_SUCCESS_FILE}"
fi
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10896) Add ability to use simultaneous cache filtering options with control.sh --cache idle_verify
[
https://issues.apache.org/jira/browse/IGNITE-10896?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Max Shonichev updated IGNITE-10896:
---
Description:
Now I can use only one of next options
1) --exclude-caches cache1,...,cacheN
2) --cache-filter ALL|SYSTEM|PERSISTENT|NOT_PERSISTENT
3) cache1,...,cacheN
Trying to use two or more of this options currently results in error:
{noformat}
Error: Should use only one of option: --excludeCaches, --cache-filter or pass
caches explicitly
{noformat}
Instead, utility should do the following:
1) when two or more options specified, result cache set to make dump of should
be logical AND of results of each option applied individually.
ex.
{noformat}
cache.* --cache-filter PERSISTENT
{noformat}
should select all persistent caches starting from 'cache'
{noformat}
--cache-filter ALL
--exclude-caches wrong-.*-caches
{noformat}
should select all caches but matching 'wrong-.*-caches' regexp
etc.
2) filtering options passed to control utility should be logged into result
dump file, so that user could understand that dump was taken from subset of
cluster caches
3) when result of filter or filters AND'ing is empty set of cache names,
proper error message should be given and no dump file generated.
e.g.
{noformat}Error: can't find any cache matching cache names '--skup-zerus' and
cache filter 'PERSISTENT', dump won't be generated.{noformat}
was:
Now I can use only one of next options
1) --exclude-caches cache1,...,cacheN
2) --cache-filter ALL|SYSTEM|PERSISTENT|NOT_PERSISTENT
3) cache1,...,cacheN
Trying to use two or more of this options currently results in error:
{noformat}
Error: Should use only one of option: --excludeCaches, --cache-filter or pass
caches explicitly
{noformat}
Instead, utility should do the following:
1) when two or more options specified, result cache set to make dump of should
be logical AND of results of each option applied individually.
ex.
{noformat}
cache.* --cache-filter PERSISTENT
{noformat}
should select all persistent caches starting from 'cache'
{noformat}
--cache-filter ALL
--exclude-caches wrong-.*-caches
{noformat}
should select all caches but matching 'wrong-.*-caches' regexp
etc.
2) filtering options passed to control utility should be logged into result
dump file, so that user could understand that dump was taken from subset of
cluster caches
3) when result of filter or filters AND'ing is empty set of cache names,
proper error message should be given and no dump file generated.
e.g.
{noformat}Error: can't find any cache with cache names '--skup-zerus' and cache
filter 'PERSISTENT', dump won't be generated.{noformat}
> Add ability to use simultaneous cache filtering options with control.sh
> --cache idle_verify
> ---
>
> Key: IGNITE-10896
> URL: https://issues.apache.org/jira/browse/IGNITE-10896
> Project: Ignite
> Issue Type: Improvement
>Reporter: ARomantsov
>Priority: Major
> Fix For: 2.8
>
>
> Now I can use only one of next options
> 1) --exclude-caches cache1,...,cacheN
> 2) --cache-filter ALL|SYSTEM|PERSISTENT|NOT_PERSISTENT
> 3) cache1,...,cacheN
> Trying to use two or more of this options currently results in error:
> {noformat}
> Error: Should use only one of option: --excludeCaches, --cache-filter or pass
> caches explicitly
> {noformat}
> Instead, utility should do the following:
> 1) when two or more options specified, result cache set to make dump of
> should be logical AND of results of each option applied individually.
> ex.
> {noformat}
> cache.* --cache-filter PERSISTENT
> {noformat}
> should select all persistent caches starting from 'cache'
> {noformat}
>--cache-filter ALL
>--exclude-caches wrong-.*-caches
> {noformat}
> should select all caches but matching 'wrong-.*-caches' regexp
> etc.
> 2) filtering options passed to control utility should be logged into result
> dump file, so that user could understand that dump was taken from subset of
> cluster caches
> 3) when result of filter or filters AND'ing is empty set of cache names,
> proper error message should be given and no dump file generated.
> e.g.
> {noformat}Error: can't find any cache matching cache names '--skup-zerus' and
> cache filter 'PERSISTENT', dump won't be generated.{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10896) Add ability to use simultaneous cache filtering options with control.sh --cache idle_verify
[
https://issues.apache.org/jira/browse/IGNITE-10896?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Max Shonichev updated IGNITE-10896:
---
Description:
Now I can use only one of next options
1) --exclude-caches cache1,...,cacheN
2) --cache-filter ALL|SYSTEM|PERSISTENT|NOT_PERSISTENT
3) cache1,...,cacheN
Trying to use two or more of this options currently results in error:
{noformat}
Error: Should use only one of option: --excludeCaches, --cache-filter or pass
caches explicitly
{noformat}
Instead, utility should do the following:
1) when two or more options specified, result cache set to make dump of should
be logical AND of results of each option applied individually.
ex.
{noformat}
cache.* --cache-filter PERSISTENT
{noformat}
should select all persistent caches starting from 'cache'
{noformat}
--cache-filter ALL
--exclude-caches wrong-.*-caches
{noformat}
should select all caches but matching 'wrong-.*-caches' regexp
etc.
2) filtering options passed to control utility should be logged into result
dump file, so that user could understand that dump was taken from subset of
cluster caches
3) when result of filter or filters AND'ing is empty set of cache names,
proper error message should be given and no dump file generated.
e.g.
{noformat}Error: can't find any cache with cache names '--skup-zerus' and cache
filter 'PERSISTENT', dump won't be generated.{noformat}
was:
Now I can use only one of next options
1) --exclude-caches cache1,...,cacheN
2) --cache-filter ALL|SYSTEM|PERSISTENT|NOT_PERSISTENT
3) cache1,...,cacheN
Trying to use options
> Add ability to use simultaneous cache filtering options with control.sh
> --cache idle_verify
> ---
>
> Key: IGNITE-10896
> URL: https://issues.apache.org/jira/browse/IGNITE-10896
> Project: Ignite
> Issue Type: Improvement
>Reporter: ARomantsov
>Priority: Major
> Fix For: 2.8
>
>
> Now I can use only one of next options
> 1) --exclude-caches cache1,...,cacheN
> 2) --cache-filter ALL|SYSTEM|PERSISTENT|NOT_PERSISTENT
> 3) cache1,...,cacheN
> Trying to use two or more of this options currently results in error:
> {noformat}
> Error: Should use only one of option: --excludeCaches, --cache-filter or pass
> caches explicitly
> {noformat}
> Instead, utility should do the following:
> 1) when two or more options specified, result cache set to make dump of
> should be logical AND of results of each option applied individually.
> ex.
> {noformat}
> cache.* --cache-filter PERSISTENT
> {noformat}
> should select all persistent caches starting from 'cache'
> {noformat}
>--cache-filter ALL
>--exclude-caches wrong-.*-caches
> {noformat}
> should select all caches but matching 'wrong-.*-caches' regexp
> etc.
> 2) filtering options passed to control utility should be logged into result
> dump file, so that user could understand that dump was taken from subset of
> cluster caches
> 3) when result of filter or filters AND'ing is empty set of cache names,
> proper error message should be given and no dump file generated.
> e.g.
> {noformat}Error: can't find any cache with cache names '--skup-zerus' and
> cache filter 'PERSISTENT', dump won't be generated.{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10896) Add ability to use simultaneous cache filtering options with control.sh --cache idle_verify
[ https://issues.apache.org/jira/browse/IGNITE-10896?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Max Shonichev updated IGNITE-10896: --- Summary: Add ability to use simultaneous cache filtering options with control.sh --cache idle_verify (was: Add ability to use more than one key with control.sh --cache idle_verify) > Add ability to use simultaneous cache filtering options with control.sh > --cache idle_verify > --- > > Key: IGNITE-10896 > URL: https://issues.apache.org/jira/browse/IGNITE-10896 > Project: Ignite > Issue Type: Improvement >Reporter: ARomantsov >Priority: Major > Fix For: 2.8 > > > Now I can use only one of next options > 1) --exclude-caches cache1,...,cacheN > 2) --cache-filter ALL|SYSTEM|PERSISTENT|NOT_PERSISTENT > 3) cache1,...,cacheN > Trying to use options -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10896) Add ability to use more than one key with control.sh --cache idle_verify
[ https://issues.apache.org/jira/browse/IGNITE-10896?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Max Shonichev updated IGNITE-10896: --- Description: Now I can use only one of next options 1) --exclude-caches cache1,...,cacheN 2) --cache-filter ALL|SYSTEM|PERSISTENT|NOT_PERSISTENT 3) cache1,...,cacheN Trying to use options was: Now I can use only one of next options 1) --exclude-caches cache1,...,cacheN 2) --cache-filter ALL|SYSTEM|PERSISTENT|NOT_PERSISTENT 3) cache1,...,cacheN I suppose that using 1 and 2 or 2 and 3 make this command more flexiable > Add ability to use more than one key with control.sh --cache idle_verify > > > Key: IGNITE-10896 > URL: https://issues.apache.org/jira/browse/IGNITE-10896 > Project: Ignite > Issue Type: Improvement >Reporter: ARomantsov >Priority: Major > Fix For: 2.8 > > > Now I can use only one of next options > 1) --exclude-caches cache1,...,cacheN > 2) --cache-filter ALL|SYSTEM|PERSISTENT|NOT_PERSISTENT > 3) cache1,...,cacheN > Trying to use options -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9455) Total allocated size memory metric is always zero for metastore data region.
[ https://issues.apache.org/jira/browse/IGNITE-9455?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Max Shonichev updated IGNITE-9455: -- Labels: jmx (was: ) > Total allocated size memory metric is always zero for metastore data region. > > > Key: IGNITE-9455 > URL: https://issues.apache.org/jira/browse/IGNITE-9455 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.6 >Reporter: Pavel Pereslegin >Assignee: Pavel Pereslegin >Priority: Major > Labels: jmx > Fix For: 2.8 > > Attachments: Reproducer.java > > > Persistence enabled and metrics for all regions enabled, but total allocated > size is always zero for metastore data region > Even if we change NO_OP allocated page tracker to a real page tracker in > CacheStoreHolder this metric counts incorrectly, because this region is > recreated, > Reproducer attached. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11021) PME join 5 server nodes -15%
[ https://issues.apache.org/jira/browse/IGNITE-11021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Max Shonichev updated IGNITE-11021: --- Summary: PME join 5 server nodes -15% (was: PME join server node -15%) > PME join 5 server nodes -15% > > > Key: IGNITE-11021 > URL: https://issues.apache.org/jira/browse/IGNITE-11021 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.5 >Reporter: Max Shonichev >Priority: Blocker > Fix For: 2.5 > > > PME benchmark drop -15% on server node join -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11022) PME leave coordinator node -31%
[ https://issues.apache.org/jira/browse/IGNITE-11022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Max Shonichev updated IGNITE-11022: --- Description: PME benchmark on coordinator node leave drop -31% (was: PME benchmark on server node leave drop -31%) > PME leave coordinator node -31% > --- > > Key: IGNITE-11022 > URL: https://issues.apache.org/jira/browse/IGNITE-11022 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.5 >Reporter: Max Shonichev >Priority: Blocker > Fix For: 2.5 > > > PME benchmark on coordinator node leave drop -31% -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11025) PME leave 5 server nodes -45%
Max Shonichev created IGNITE-11025: -- Summary: PME leave 5 server nodes -45% Key: IGNITE-11025 URL: https://issues.apache.org/jira/browse/IGNITE-11025 Project: Ignite Issue Type: Bug Affects Versions: 2.5 Reporter: Max Shonichev Fix For: 2.5 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11024) PME leave server node -69%
Max Shonichev created IGNITE-11024: -- Summary: PME leave server node -69% Key: IGNITE-11024 URL: https://issues.apache.org/jira/browse/IGNITE-11024 Project: Ignite Issue Type: Bug Affects Versions: 2.5 Reporter: Max Shonichev Fix For: 2.5 PME benchmark leave server node -69% -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11022) PME leave server node -31%
Max Shonichev created IGNITE-11022: -- Summary: PME leave server node -31% Key: IGNITE-11022 URL: https://issues.apache.org/jira/browse/IGNITE-11022 Project: Ignite Issue Type: Bug Affects Versions: 2.5 Reporter: Max Shonichev Fix For: 2.5 PME benchmark on server node leave drop -31% -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11021) PME join 5 server nodes -15%
[ https://issues.apache.org/jira/browse/IGNITE-11021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Max Shonichev updated IGNITE-11021: --- Description: PME benchmark drop -15% on 5 server nodes join (was: PME benchmark drop -15% on server node join) > PME join 5 server nodes -15% > > > Key: IGNITE-11021 > URL: https://issues.apache.org/jira/browse/IGNITE-11021 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.5 >Reporter: Max Shonichev >Priority: Blocker > Fix For: 2.5 > > > PME benchmark drop -15% on 5 server nodes join -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11022) PME leave coordinator node -31%
[ https://issues.apache.org/jira/browse/IGNITE-11022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Max Shonichev updated IGNITE-11022: --- Summary: PME leave coordinator node -31% (was: PME leave server node -31%) > PME leave coordinator node -31% > --- > > Key: IGNITE-11022 > URL: https://issues.apache.org/jira/browse/IGNITE-11022 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.5 >Reporter: Max Shonichev >Priority: Blocker > Fix For: 2.5 > > > PME benchmark on server node leave drop -31% -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11021) PME join server node -15%
Max Shonichev created IGNITE-11021: -- Summary: PME join server node -15% Key: IGNITE-11021 URL: https://issues.apache.org/jira/browse/IGNITE-11021 Project: Ignite Issue Type: Bug Affects Versions: 2.5 Reporter: Max Shonichev Fix For: 2.5 PME benchmark drop -15% on server node join -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10946) --excludeCaches do not fit unified argument naming format
Max Shonichev created IGNITE-10946:
--
Summary: --excludeCaches do not fit unified argument naming format
Key: IGNITE-10946
URL: https://issues.apache.org/jira/browse/IGNITE-10946
Project: Ignite
Issue Type: Bug
Affects Versions: 2.5
Reporter: Max Shonichev
Fix For: 2.5
IGNITE-10279 unifies options / arguments naming format.
but in the mean time, new option _excludeCaches_ introduced to _--cache
idle_verify_ do not fit that format:
A piece of help:
{noformat}
--cache idle_verify [--dump] [--skip-zeros] [--excludeCaches
cache1,...,cacheN|[--cache-filter
ALL|SYSTEM|PERSISTENT|NOT_PERSISTENT]|cache1,...,cacheN]
Verify counters and hash sums of primary and backup partitions for the
specified caches on an idle cluster and print out the differences, if any.
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10837) control.sh --baseline should output node IP addresses
Max Shonichev created IGNITE-10837: -- Summary: control.sh --baseline should output node IP addresses Key: IGNITE-10837 URL: https://issues.apache.org/jira/browse/IGNITE-10837 Project: Ignite Issue Type: Improvement Affects Versions: 2.5, 2.8 Reporter: Max Shonichev Fix For: 2.8 control.sh --baseline outputs node's consistent IDs it would be very useful, if it also output node's IP addresses. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10837) control.sh --baseline should output node IP addresses
[ https://issues.apache.org/jira/browse/IGNITE-10837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Max Shonichev updated IGNITE-10837: --- Ignite Flags: (was: Docs Required) > control.sh --baseline should output node IP addresses > - > > Key: IGNITE-10837 > URL: https://issues.apache.org/jira/browse/IGNITE-10837 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.5, 2.8 >Reporter: Max Shonichev >Priority: Major > Fix For: 2.8 > > > control.sh --baseline outputs node's consistent IDs > it would be very useful, if it also output node's IP addresses. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10571) Crash in exchange worker during memory recovery on rebalance
Max Shonichev created IGNITE-10571:
--
Summary: Crash in exchange worker during memory recovery on
rebalance
Key: IGNITE-10571
URL: https://issues.apache.org/jira/browse/IGNITE-10571
Project: Ignite
Issue Type: Bug
Affects Versions: 2.4
Reporter: Max Shonichev
1. start grid (2 nodes), preload data, start 1 client node
2. kill 1 server node
3. wait 10 sec
4. restart server node
upon 2-3 iteration, node crashes JVM during memory recovery
{noformat}
Stack: [0x7fdcbb2f5000,0x7fdcbb3f6000], sp=0x7fdcbb3f4160, free
space=1020k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
v ~StubRoutines::jshort_disjoint_arraycopy
J 3894 C2
org.apache.ignite.internal.processors.cache.persistence.tree.io.BPlusLeafIO.copyItems(JJIIIZ)V
(55 bytes) @ 0x7fdeadba2949 [0x7fdeadba28e0+0x69]
J 3893 C2
org.apache.ignite.internal.processors.cache.persistence.tree.io.BPlusIO.insert(JILjava/lang/Object;[BJZ)[B
(44 bytes) @ 0x7fdeadba2514 [0x7fdeadba24a0+0x74]
J 3887 C2
org.apache.ignite.internal.pagemem.wal.record.delta.InsertRecord.applyDelta(Lorg/apache/ignite/internal/pagemem/PageMemory;J)V
(24 bytes) @ 0x7fdeadbab0c8 [0x7fdeadbab060+0x68]
J 3895% C2
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.restoreMemory(Lorg/apache/ignite/internal/processors/cache/persistence/GridCacheDatabaseSharedManager$CheckpointStatus;ZLorg/apache/ignite/internal/processors/cache/persistence/pagemem/PageMemoryEx;)Lorg/apache/ignite/internal/pagemem/wal/WALPointer;
(1298 bytes) @ 0x7fdeadb3eb00 [0x7fdeadb3d3a0+0x1760]
j
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.restoreMemory(Lorg/apache/ignite/internal/processors/cache/persistence/GridCacheDatabaseSharedManager$CheckpointStatus;)Lorg/apache/ignite/internal/pagemem/wal/WALPointer;+13
j
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.readCheckpointAndRestoreMemory(Ljava/util/List;)V+173
j
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.initCachesOnLocalJoin()V+147
j
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(Z)V+794
j
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body()V+547
j org.apache.ignite.internal.util.worker.GridWorker.run()V+82
j java.lang.Thread.run()V+11
v ~StubRoutines::call_stub
V [libjvm.so+0x697a76]
[error occurred during error reporting (printing native stack), id 0xb]
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8225) Add a command to control script to print current topology version
[
https://issues.apache.org/jira/browse/IGNITE-8225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16708519#comment-16708519
]
Max Shonichev commented on IGNITE-8225:
---
[~ruchirc] got any progress on this ticket?
> Add a command to control script to print current topology version
> -
>
> Key: IGNITE-8225
> URL: https://issues.apache.org/jira/browse/IGNITE-8225
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexey Goncharuk
>Assignee: ruchir choudhry
>Priority: Critical
> Fix For: 2.8
>
>
> The command should be {{./control.sh --topology}} and should print a short
> summary about the current topology (topology version, number of client nodes,
> number of server nodes, baseline topology information)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9859) add debug logging on refreshPartitions cause
[ https://issues.apache.org/jira/browse/IGNITE-9859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Max Shonichev updated IGNITE-9859: -- Description: Need some additional log messages for debugging PME issues. > add debug logging on refreshPartitions cause > > > Key: IGNITE-9859 > URL: https://issues.apache.org/jira/browse/IGNITE-9859 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.5 >Reporter: Max Shonichev >Priority: Major > Fix For: 2.8 > > Attachments: > IGNITE_9859__add_debug_logging_on_resendPartitions_cause.patch > > > Need some additional log messages for debugging PME issues. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10425) Node failed to add to topology due to problem with detecting local Address
Max Shonichev created IGNITE-10425:
--
Summary: Node failed to add to topology due to problem with
detecting local Address
Key: IGNITE-10425
URL: https://issues.apache.org/jira/browse/IGNITE-10425
Project: Ignite
Issue Type: Bug
Affects Versions: 2.5
Reporter: Max Shonichev
Fix For: 2.8
When localhost has resolvable DNS name to 127.0.0.1, running two nodes on with
"localHost" property set to 127.0.0.1 might result in following exception:
{noformat}
Caused by: class org.apache.ignite.spi.IgniteSpiException: Failed to add node
to topology because remote node is configured to use loopback address, but
local node is not (consider changing 'localAddress' configuration parameter)
[locNodeAddrs=[prtagent07.gridgain.local/0:0:0:0:0:0:0:1,
prtagent07.gridgain.local/127.0.0.1, /172.25.2.7,
/2001:0:9d38:6abd:24c2:3fcd:53e6:fdf8], rmtNodeAddrs=[127.0.0.1],
creatorNodeId=28c5fc84-30aa-4d24-a576-ac9a866a4a8b]
at
org.apache.ignite.spi.discovery.tcp.ServerImpl.joinTopology(ServerImpl.java:970)
at
org.apache.ignite.spi.discovery.tcp.ServerImpl.spiStart(ServerImpl.java:377)
at
org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.spiStart(TcpDiscoverySpi.java:1955)
at
org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:297)
... 15 more
{noformat}
This looks extremely silly, both nodes are started locally and still can't
connect to each other
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10424) CacheException thrown instead of SqlException
[
https://issues.apache.org/jira/browse/IGNITE-10424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Max Shonichev updated IGNITE-10424:
---
Summary: CacheException thrown instead of SqlException (was: expected
SqlException not thrown)
> CacheException thrown instead of SqlException
> -
>
> Key: IGNITE-10424
> URL: https://issues.apache.org/jira/browse/IGNITE-10424
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Max Shonichev
>Priority: Major
> Labels: sql
> Fix For: 2.8
>
>
> When running query
> {noformat}
> SELECT SUM(field2*10) FROM tmp_table_age_name_wage;
> {noformat}
> Apache Ignite 2.4 threw SqlException Numeric value out of range:
> "100";
> Apache Ignite 2.5 does not wrap underlying exception and throws
> javax.cache.CacheException instead
> {noformat}
> SELECT SUM(field2*10) FROM tmp_table_age_name_wage;
> Expected error:
> Numeric value out of range
> Actual error:
> Error: javax.cache.CacheException: Failed to execute map query on remote node
> [nodeId=76cea51c-87a3-4054-b39e-1ad6d01c0df6, errMsg=Failed to execute SQL
> query. Numeric value out of range: "100"; SQL statement:
> SELECT
> SUM(__Z0.FIELD2 * 10) __C0_0
> FROM PUBLIC.TMP_TABLE_AGE_NAME_WAGE __Z0 [22003-195]] (state=5,code=0)
> java.sql.SQLException: javax.cache.CacheException: Failed to execute map
> query on remote node [nodeId=76cea51c-87a3-4054-b39e-1ad6d01c0df6,
> errMsg=Failed to execute SQL query. Numeric value out of range:
> "100"; SQL statement:
> SELECT
> SUM(__Z0.FIELD2 * 10) __C0_0
> FROM PUBLIC.TMP_TABLE_AGE_NAME_WAGE __Z0 [22003-195]]
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinConnection.sendRequest(JdbcThinConnection.java:779)
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute0(JdbcThinStatement.java:210)
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute(JdbcThinStatement.java:473)
> at sqlline.Commands.execute(Commands.java:823)
> at sqlline.Commands.sql(Commands.java:733)
> at sqlline.SqlLine.dispatch(SqlLine.java:795)
> at sqlline.SqlLine.runCommands(SqlLine.java:1706)
> at sqlline.Commands.run(Commands.java:1317)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> sqlline.ReflectiveCommandHandler.execute(ReflectiveCommandHandler.java:38)
> at sqlline.SqlLine.dispatch(SqlLine.java:791)
> at sqlline.SqlLine.initArgs(SqlLine.java:595)
> at sqlline.SqlLine.begin(SqlLine.java:643)
> at sqlline.SqlLine.start(SqlLine.java:373)
> at sqlline.SqlLine.main(SqlLine.java:265)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10424) expected SqlException not thrown
Max Shonichev created IGNITE-10424:
--
Summary: expected SqlException not thrown
Key: IGNITE-10424
URL: https://issues.apache.org/jira/browse/IGNITE-10424
Project: Ignite
Issue Type: Bug
Affects Versions: 2.5
Reporter: Max Shonichev
Fix For: 2.8
When running query
{noformat}
SELECT SUM(field2*10) FROM tmp_table_age_name_wage;
{noformat}
Apache Ignite 2.4 threw SqlException Numeric value out of range:
"100";
Apache Ignite 2.5 does not wrap underlying exception and throws
javax.cache.CacheException instead
{noformat}
SELECT SUM(field2*10) FROM tmp_table_age_name_wage;
Expected error:
Numeric value out of range
Actual error:
Error: javax.cache.CacheException: Failed to execute map query on remote node
[nodeId=76cea51c-87a3-4054-b39e-1ad6d01c0df6, errMsg=Failed to execute SQL
query. Numeric value out of range: "100"; SQL statement:
SELECT
SUM(__Z0.FIELD2 * 10) __C0_0
FROM PUBLIC.TMP_TABLE_AGE_NAME_WAGE __Z0 [22003-195]] (state=5,code=0)
java.sql.SQLException: javax.cache.CacheException: Failed to execute map query
on remote node [nodeId=76cea51c-87a3-4054-b39e-1ad6d01c0df6, errMsg=Failed to
execute SQL query. Numeric value out of range: "100"; SQL statement:
SELECT
SUM(__Z0.FIELD2 * 10) __C0_0
FROM PUBLIC.TMP_TABLE_AGE_NAME_WAGE __Z0 [22003-195]]
at
org.apache.ignite.internal.jdbc.thin.JdbcThinConnection.sendRequest(JdbcThinConnection.java:779)
at
org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute0(JdbcThinStatement.java:210)
at
org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute(JdbcThinStatement.java:473)
at sqlline.Commands.execute(Commands.java:823)
at sqlline.Commands.sql(Commands.java:733)
at sqlline.SqlLine.dispatch(SqlLine.java:795)
at sqlline.SqlLine.runCommands(SqlLine.java:1706)
at sqlline.Commands.run(Commands.java:1317)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
sqlline.ReflectiveCommandHandler.execute(ReflectiveCommandHandler.java:38)
at sqlline.SqlLine.dispatch(SqlLine.java:791)
at sqlline.SqlLine.initArgs(SqlLine.java:595)
at sqlline.SqlLine.begin(SqlLine.java:643)
at sqlline.SqlLine.start(SqlLine.java:373)
at sqlline.SqlLine.main(SqlLine.java:265)
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10424) expected SqlException not thrown
[
https://issues.apache.org/jira/browse/IGNITE-10424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Max Shonichev updated IGNITE-10424:
---
Labels: sql (was: )
> expected SqlException not thrown
>
>
> Key: IGNITE-10424
> URL: https://issues.apache.org/jira/browse/IGNITE-10424
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Max Shonichev
>Priority: Major
> Labels: sql
> Fix For: 2.8
>
>
> When running query
> {noformat}
> SELECT SUM(field2*10) FROM tmp_table_age_name_wage;
> {noformat}
> Apache Ignite 2.4 threw SqlException Numeric value out of range:
> "100";
> Apache Ignite 2.5 does not wrap underlying exception and throws
> javax.cache.CacheException instead
> {noformat}
> SELECT SUM(field2*10) FROM tmp_table_age_name_wage;
> Expected error:
> Numeric value out of range
> Actual error:
> Error: javax.cache.CacheException: Failed to execute map query on remote node
> [nodeId=76cea51c-87a3-4054-b39e-1ad6d01c0df6, errMsg=Failed to execute SQL
> query. Numeric value out of range: "100"; SQL statement:
> SELECT
> SUM(__Z0.FIELD2 * 10) __C0_0
> FROM PUBLIC.TMP_TABLE_AGE_NAME_WAGE __Z0 [22003-195]] (state=5,code=0)
> java.sql.SQLException: javax.cache.CacheException: Failed to execute map
> query on remote node [nodeId=76cea51c-87a3-4054-b39e-1ad6d01c0df6,
> errMsg=Failed to execute SQL query. Numeric value out of range:
> "100"; SQL statement:
> SELECT
> SUM(__Z0.FIELD2 * 10) __C0_0
> FROM PUBLIC.TMP_TABLE_AGE_NAME_WAGE __Z0 [22003-195]]
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinConnection.sendRequest(JdbcThinConnection.java:779)
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute0(JdbcThinStatement.java:210)
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute(JdbcThinStatement.java:473)
> at sqlline.Commands.execute(Commands.java:823)
> at sqlline.Commands.sql(Commands.java:733)
> at sqlline.SqlLine.dispatch(SqlLine.java:795)
> at sqlline.SqlLine.runCommands(SqlLine.java:1706)
> at sqlline.Commands.run(Commands.java:1317)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> sqlline.ReflectiveCommandHandler.execute(ReflectiveCommandHandler.java:38)
> at sqlline.SqlLine.dispatch(SqlLine.java:791)
> at sqlline.SqlLine.initArgs(SqlLine.java:595)
> at sqlline.SqlLine.begin(SqlLine.java:643)
> at sqlline.SqlLine.start(SqlLine.java:373)
> at sqlline.SqlLine.main(SqlLine.java:265)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10383) Partition Full message finished info printed out in logs after full message sent info
Max Shonichev created IGNITE-10383:
--
Summary: Partition Full message finished info printed out in logs
after full message sent info
Key: IGNITE-10383
URL: https://issues.apache.org/jira/browse/IGNITE-10383
Project: Ignite
Issue Type: Bug
Reporter: Max Shonichev
see excerpt from logs:
{noformat}
==[crd]==
2018-11-19 18:57:55.845 [INFO
][sys-#3636%DPL_GRID%DplGridNodeName%][o.a.i.i.p.c.d.d.p.GridDhtPartitionsExchangeFuture]
Finish exchange future [startVer=AffinityTopologyVersion [topVer=282,
minorTopVer=0], resVer=AffinityTopologyVersion [topVer=282, minorTopVer=0],
err=null]
2018-11-19 18:57:55.845 [INFO
][sys-#3636%DPL_GRID%DplGridNodeName%][o.a.i.i.p.c.d.d.p.GridDhtPartitionsExchangeFuture]
Sending Full Message performed in 3 ms.
2018-11-19 18:57:55.845 [INFO
][sys-#3636%DPL_GRID%DplGridNodeName%][o.a.i.i.p.c.d.d.p.GridDhtPartitionsExchangeFuture]
Sending Full Message to all nodes performed in 5 ms.
2018-11-19 18:59:01.289 [INFO
][sys-#3610%DPL_GRID%DplGridNodeName%][o.a.i.i.p.c.GridCachePartitionExchangeManager]
Finished full message creation [msgTopVer=AffinityTopologyVersion [topVer=282,
minorTopVer=0], groups=[CacheGroupContext
[grp=CACHEGROUP_PARTICLE_union-module_com.sbt.cdm.model.uss27.d
2018-11-19 18:59:01.898 [INFO
][sys-#3610%DPL_GRID%DplGridNodeName%][o.a.i.i.p.c.GridCachePartitionExchangeManager]
Finished sending full message [msgTopVer=AffinityTopologyVersion [topVer=282,
minorTopVer=0], groups=[CacheGroupContext
[grp=CACHEGROUP_PARTICLE_union-module_com.sbt.cdm.model.uss27.di
==[non-crd]==
2018-11-19 18:57:56.693 [INFO
][sys-#8210%DPL_GRID%DplGridNodeName%][o.a.i.i.p.c.d.d.p.GridDhtPartitionsExchangeFuture]
Received full message, will finish exchange
[node=5f56aea6-3ecf-4a55-b2e1-cdafdb534e32, resVer=AffinityTopologyVersion
[topVer=282, minorTopVer=0]]
2018-11-19 18:57:57.466 [INFO
][sys-#8210%DPL_GRID%DplGridNodeName%][o.a.i.i.p.c.CacheAffinitySharedManager]
Affinity recalculation (on server join) performed in 773 ms.
2018-11-19 18:57:58.077 [INFO
][sys-#8210%DPL_GRID%DplGridNodeName%][o.a.i.i.p.c.d.d.p.GridDhtPartitionsExchangeFuture]
Affinity changes applied in 1384 ms.
2018-11-19 18:57:58.210 [INFO
][sys-#8210%DPL_GRID%DplGridNodeName%][o.a.i.i.p.c.d.d.p.GridDhtPartitionsExchangeFuture]
Finish exchange future [startVer=AffinityTopologyVersion [topVer=282,
minorTopVer=0], resVer=AffinityTopologyVersion [topVer=282, minorTopVer=0],
err=null]
{noformat}
'Finished sending full message' is printed out way too after message was sent
and seemingly received by other node.
That confuses PME analyse, please fix it
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10383) Partition Full message finished info printed out in logs after full message sent info
[
https://issues.apache.org/jira/browse/IGNITE-10383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Max Shonichev updated IGNITE-10383:
---
Affects Version/s: 2.5
> Partition Full message finished info printed out in logs after full message
> sent info
> -
>
> Key: IGNITE-10383
> URL: https://issues.apache.org/jira/browse/IGNITE-10383
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Max Shonichev
>Priority: Major
>
> see excerpt from logs:
> {noformat}
> ==[crd]==
> 2018-11-19 18:57:55.845 [INFO
> ][sys-#3636%DPL_GRID%DplGridNodeName%][o.a.i.i.p.c.d.d.p.GridDhtPartitionsExchangeFuture]
> Finish exchange future [startVer=AffinityTopologyVersion [topVer=282,
> minorTopVer=0], resVer=AffinityTopologyVersion [topVer=282, minorTopVer=0],
> err=null]
> 2018-11-19 18:57:55.845 [INFO
> ][sys-#3636%DPL_GRID%DplGridNodeName%][o.a.i.i.p.c.d.d.p.GridDhtPartitionsExchangeFuture]
> Sending Full Message performed in 3 ms.
> 2018-11-19 18:57:55.845 [INFO
> ][sys-#3636%DPL_GRID%DplGridNodeName%][o.a.i.i.p.c.d.d.p.GridDhtPartitionsExchangeFuture]
> Sending Full Message to all nodes performed in 5 ms.
> 2018-11-19 18:59:01.289 [INFO
> ][sys-#3610%DPL_GRID%DplGridNodeName%][o.a.i.i.p.c.GridCachePartitionExchangeManager]
> Finished full message creation [msgTopVer=AffinityTopologyVersion
> [topVer=282, minorTopVer=0], groups=[CacheGroupContext
> [grp=CACHEGROUP_PARTICLE_union-module_com.sbt.cdm.model.uss27.d
> 2018-11-19 18:59:01.898 [INFO
> ][sys-#3610%DPL_GRID%DplGridNodeName%][o.a.i.i.p.c.GridCachePartitionExchangeManager]
> Finished sending full message [msgTopVer=AffinityTopologyVersion
> [topVer=282, minorTopVer=0], groups=[CacheGroupContext
> [grp=CACHEGROUP_PARTICLE_union-module_com.sbt.cdm.model.uss27.di
> ==[non-crd]==
> 2018-11-19 18:57:56.693 [INFO
> ][sys-#8210%DPL_GRID%DplGridNodeName%][o.a.i.i.p.c.d.d.p.GridDhtPartitionsExchangeFuture]
> Received full message, will finish exchange
> [node=5f56aea6-3ecf-4a55-b2e1-cdafdb534e32, resVer=AffinityTopologyVersion
> [topVer=282, minorTopVer=0]]
> 2018-11-19 18:57:57.466 [INFO
> ][sys-#8210%DPL_GRID%DplGridNodeName%][o.a.i.i.p.c.CacheAffinitySharedManager]
> Affinity recalculation (on server join) performed in 773 ms.
> 2018-11-19 18:57:58.077 [INFO
> ][sys-#8210%DPL_GRID%DplGridNodeName%][o.a.i.i.p.c.d.d.p.GridDhtPartitionsExchangeFuture]
> Affinity changes applied in 1384 ms.
> 2018-11-19 18:57:58.210 [INFO
> ][sys-#8210%DPL_GRID%DplGridNodeName%][o.a.i.i.p.c.d.d.p.GridDhtPartitionsExchangeFuture]
> Finish exchange future [startVer=AffinityTopologyVersion [topVer=282,
> minorTopVer=0], resVer=AffinityTopologyVersion [topVer=282, minorTopVer=0],
> err=null]
> {noformat}
> 'Finished sending full message' is printed out way too after message was sent
> and seemingly received by other node.
> That confuses PME analyse, please fix it
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10383) Partition Full message finished info printed out in logs after full message sent info
[
https://issues.apache.org/jira/browse/IGNITE-10383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Max Shonichev updated IGNITE-10383:
---
Fix Version/s: 2.5
> Partition Full message finished info printed out in logs after full message
> sent info
> -
>
> Key: IGNITE-10383
> URL: https://issues.apache.org/jira/browse/IGNITE-10383
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Max Shonichev
>Priority: Major
> Fix For: 2.5
>
>
> see excerpt from logs:
> {noformat}
> ==[crd]==
> 2018-11-19 18:57:55.845 [INFO
> ][sys-#3636%DPL_GRID%DplGridNodeName%][o.a.i.i.p.c.d.d.p.GridDhtPartitionsExchangeFuture]
> Finish exchange future [startVer=AffinityTopologyVersion [topVer=282,
> minorTopVer=0], resVer=AffinityTopologyVersion [topVer=282, minorTopVer=0],
> err=null]
> 2018-11-19 18:57:55.845 [INFO
> ][sys-#3636%DPL_GRID%DplGridNodeName%][o.a.i.i.p.c.d.d.p.GridDhtPartitionsExchangeFuture]
> Sending Full Message performed in 3 ms.
> 2018-11-19 18:57:55.845 [INFO
> ][sys-#3636%DPL_GRID%DplGridNodeName%][o.a.i.i.p.c.d.d.p.GridDhtPartitionsExchangeFuture]
> Sending Full Message to all nodes performed in 5 ms.
> 2018-11-19 18:59:01.289 [INFO
> ][sys-#3610%DPL_GRID%DplGridNodeName%][o.a.i.i.p.c.GridCachePartitionExchangeManager]
> Finished full message creation [msgTopVer=AffinityTopologyVersion
> [topVer=282, minorTopVer=0], groups=[CacheGroupContext
> [grp=CACHEGROUP_PARTICLE_union-module_com.sbt.cdm.model.uss27.d
> 2018-11-19 18:59:01.898 [INFO
> ][sys-#3610%DPL_GRID%DplGridNodeName%][o.a.i.i.p.c.GridCachePartitionExchangeManager]
> Finished sending full message [msgTopVer=AffinityTopologyVersion
> [topVer=282, minorTopVer=0], groups=[CacheGroupContext
> [grp=CACHEGROUP_PARTICLE_union-module_com.sbt.cdm.model.uss27.di
> ==[non-crd]==
> 2018-11-19 18:57:56.693 [INFO
> ][sys-#8210%DPL_GRID%DplGridNodeName%][o.a.i.i.p.c.d.d.p.GridDhtPartitionsExchangeFuture]
> Received full message, will finish exchange
> [node=5f56aea6-3ecf-4a55-b2e1-cdafdb534e32, resVer=AffinityTopologyVersion
> [topVer=282, minorTopVer=0]]
> 2018-11-19 18:57:57.466 [INFO
> ][sys-#8210%DPL_GRID%DplGridNodeName%][o.a.i.i.p.c.CacheAffinitySharedManager]
> Affinity recalculation (on server join) performed in 773 ms.
> 2018-11-19 18:57:58.077 [INFO
> ][sys-#8210%DPL_GRID%DplGridNodeName%][o.a.i.i.p.c.d.d.p.GridDhtPartitionsExchangeFuture]
> Affinity changes applied in 1384 ms.
> 2018-11-19 18:57:58.210 [INFO
> ][sys-#8210%DPL_GRID%DplGridNodeName%][o.a.i.i.p.c.d.d.p.GridDhtPartitionsExchangeFuture]
> Finish exchange future [startVer=AffinityTopologyVersion [topVer=282,
> minorTopVer=0], resVer=AffinityTopologyVersion [topVer=282, minorTopVer=0],
> err=null]
> {noformat}
> 'Finished sending full message' is printed out way too after message was sent
> and seemingly received by other node.
> That confuses PME analyse, please fix it
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10284) performance drop on PME time during 1 server node left
Max Shonichev created IGNITE-10284: -- Summary: performance drop on PME time during 1 server node left Key: IGNITE-10284 URL: https://issues.apache.org/jira/browse/IGNITE-10284 Project: Ignite Issue Type: Bug Reporter: Max Shonichev 7 server nodes (1 node per host), 120 caches, G1GC, 32768 partitions 1 client tx loading 1. start cluster, fix baseline, preload data 2. start tx transfer task 3. kill 1 server node 4. wait for topology snapshot change, measure PME time 5. restart killed node 6. wait for topology snapshot change, measure PME time for 1 server LEAVE, we see 7%-10% degradation, BUG for 1 server JOIN, we see performance degradation on first exchange (evt=NODE_LEFT) and performance increase on second exchange (evt=CacheAffinityChange), overall 40-60% increase. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10284) performance drop on PME time during 1 server node left
[ https://issues.apache.org/jira/browse/IGNITE-10284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Max Shonichev updated IGNITE-10284: --- Ignite Flags: (was: Docs Required) > performance drop on PME time during 1 server node left > -- > > Key: IGNITE-10284 > URL: https://issues.apache.org/jira/browse/IGNITE-10284 > Project: Ignite > Issue Type: Bug >Reporter: Max Shonichev >Priority: Major > > 7 server nodes (1 node per host), 120 caches, G1GC, 32768 partitions 1 client > tx loading > 1. start cluster, fix baseline, preload data > 2. start tx transfer task > 3. kill 1 server node > 4. wait for topology snapshot change, measure PME time > 5. restart killed node > 6. wait for topology snapshot change, measure PME time > for 1 server LEAVE, we see 7%-10% degradation, BUG > for 1 server JOIN, we see performance degradation on first exchange > (evt=NODE_LEFT) and performance increase on second exchange > (evt=CacheAffinityChange), overall 40-60% increase. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10283) `control.sh --baseline` does not output other nodes when cluster is inactive
Max Shonichev created IGNITE-10283:
--
Summary: `control.sh --baseline` does not output other nodes when
cluster is inactive
Key: IGNITE-10283
URL: https://issues.apache.org/jira/browse/IGNITE-10283
Project: Ignite
Issue Type: Bug
Reporter: Max Shonichev
Fix For: 2.7
1. start 2 nodes from clean LFS
2. control.sh --baseline
expected: 0 baseline nodes, 2 other nodes
actual: 0 baseline nodes, 0 other nodes, BUG
{noformat}
Control utility [ver. 2.5.1-p150#20181101-sha1:b46a69df]
2018 Copyright(C) Apache Software Foundation
User: mshonichev
Cluster state: inactive
Current topology version: 2
Baseline nodes not found.
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10282) control.sh: implement proper shell arguments escaping due to the possible usage of regular expression in --cache command
Max Shonichev created IGNITE-10282:
--
Summary: control.sh: implement proper shell arguments escaping due
to the possible usage of regular expression in --cache command
Key: IGNITE-10282
URL: https://issues.apache.org/jira/browse/IGNITE-10282
Project: Ignite
Issue Type: Bug
Reporter: Max Shonichev
Fix For: 2.7
mandatory argument regexPattern after --cache list command is not
shell-escaped, which leads to unexpected behaviour
{noformat}
$ IGNITE_HOME=`pwd` bin/control.sh --cache list '*' --config
Control utility [ver. 2.5.1-p150#20181101-sha1:b46a69df]
2018 Copyright(C) Apache Software Foundation
User: mshonichev
Check arguments.
Error: Invalid UUID string: benchmarks
{noformat}
{noformat}
$ IGNITE_HOME=`pwd` bin/control.sh --cache list '.*' --config
Control utility [ver. 2.5.1-p150#20181101-sha1:b46a69df]
2018 Copyright(C) Apache Software Foundation
User: mshonichev
Check arguments.
Error: Invalid UUID string: ..
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8469) Non-heap memory leak for calling cluster activation multi times
[
https://issues.apache.org/jira/browse/IGNITE-8469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16678452#comment-16678452
]
Max Shonichev commented on IGNITE-8469:
---
Seems that two grids with the same PDS scenario is not reproducible anymore,
second node just refuses to start, process dies, thus no leaks, right? :)
{noformat}
[19:12:05,058][SEVERE][main][IgniteKernal] Got exception while starting (will
rollback startup routine).
class org.apache.ignite.IgniteCheckedException: Failed to start processor:
GridProcessorAdapter []
at
org.apache.ignite.internal.IgniteKernal.startProcessor(IgniteKernal.java:1784)
at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1008)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2020)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1725)
at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1153)
at
org.apache.ignite.internal.IgnitionEx.startConfigurations(IgnitionEx.java:1071)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:957)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:856)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:726)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:695)
at org.apache.ignite.Ignition.start(Ignition.java:348)
at
org.apache.ignite.startup.cmdline.CommandLineStartup.main(CommandLineStartup.java:301)
Caused by: class org.apache.ignite.IgniteCheckedException: Failed to acquire
file lock during 10 sec, (locked by [ba1467ea-0180-4f18-8151-973cb56ef4a7][]):
/opt/tmp/gg/db/ign_8469/lock
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$FileLockHolder.tryLock(GridCacheDatabaseSharedManager.java:4303)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.acquireFileLock(GridCacheDatabaseSharedManager.java:593)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.start0(GridCacheDatabaseSharedManager.java:496)
at
org.apache.ignite.internal.processors.cache.GridCacheSharedManagerAdapter.start(GridCacheSharedManagerAdapter.java:61)
at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.start(GridCacheProcessor.java:741)
at
org.apache.ignite.internal.IgniteKernal.startProcessor(IgniteKernal.java:1781)
... 11 more
[19:12:05,059][WARNING][main][IgniteKernal] Attempt to stop starting grid. This
operation cannot be guaranteed to be successful.
[19:12:05,070][INFO][main][FilePageStoreManager] Cleanup cache stores [total=0,
left=0, cleanFiles=false]
[19:12:05,076][INFO][main][IgniteKernal]
>>> +--+
>>> Ignite ver.
>>> stopped OK
>>> +--+
>>> Grid uptime: 00:00:11.197
{noformat}
[~Mmuzaf] was it your case? Or you'd started two Ignition manually within one
JVM?
> Non-heap memory leak for calling cluster activation multi times
> ---
>
> Key: IGNITE-8469
> URL: https://issues.apache.org/jira/browse/IGNITE-8469
> Project: Ignite
> Issue Type: Bug
> Components: persistence
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Major
> Fix For: 2.7
>
>
> Calling multiple time cluster (with enabled persistence and started client
> nodes) activation {{ig3CB.cluster().active(true);}} leads to non-heap memory
> leak.
> Line
> {{org/apache/ignite/internal/pagemem/impl/PageMemoryNoStoreImpl.java:234}}
> looks suspicious because of in case method
> {{org.apache.ignite.internal.pagemem.impl.PageMemoryNoStoreImpl#start}}
> callled multi times (e.g. activate(true) called multi times) we lost info
> about allocated regions.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8469) Non-heap memory leak for calling cluster activation multi times
[
https://issues.apache.org/jira/browse/IGNITE-8469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16678378#comment-16678378
]
Max Shonichev commented on IGNITE-8469:
---
Thank you for feedback, I'll try to test scenario with two clusters as well and
report later
> Non-heap memory leak for calling cluster activation multi times
> ---
>
> Key: IGNITE-8469
> URL: https://issues.apache.org/jira/browse/IGNITE-8469
> Project: Ignite
> Issue Type: Bug
> Components: persistence
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Major
> Fix For: 2.7
>
>
> Calling multiple time cluster (with enabled persistence and started client
> nodes) activation {{ig3CB.cluster().active(true);}} leads to non-heap memory
> leak.
> Line
> {{org/apache/ignite/internal/pagemem/impl/PageMemoryNoStoreImpl.java:234}}
> looks suspicious because of in case method
> {{org.apache.ignite.internal.pagemem.impl.PageMemoryNoStoreImpl#start}}
> callled multi times (e.g. activate(true) called multi times) we lost info
> about allocated regions.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-8469) Non-heap memory leak for calling cluster activation multi times
[
https://issues.apache.org/jira/browse/IGNITE-8469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16677009#comment-16677009
]
Max Shonichev edited comment on IGNITE-8469 at 11/6/18 5:02 PM:
ok, here are final results with 100 iterations activate/deactivate scenario:
without fix, total process memory is slowly increasing approx each 20
iterations:
{noformat}
10298776
...
10283356
10284384
...
10286432
{noformat}
with fix, total process memory is changed a little first few runs, than remains
constant all 90+ iterations
{noformat}
14501520
10099096
10232216
10232216
10297752
...
10297752
{noformat}
so, it seems, that this scenario also shows memory leak fixed, [~Mmuzaf],
[~agoncharuk] please confirm
was (Author: mshonichev):
ok, here are final results with 100 iterations activate/deactivate scenario:
without fix, total process memory is slowly increasing approx each 20
iterations:
{noformat}
10298776
...
10283356
10284384
...
10286432
{noformat}
with fix, total process memory is changed a little first few runs, than remains
constant all 90+ iterations
{noformat}
14501520
10099096
10232216
10232216
10297752
...
10297752
{noformat}
so, it seems, that this scenario also shows memory leak fixed, [~Mmuzaf],
please confirm
> Non-heap memory leak for calling cluster activation multi times
> ---
>
> Key: IGNITE-8469
> URL: https://issues.apache.org/jira/browse/IGNITE-8469
> Project: Ignite
> Issue Type: Bug
> Components: persistence
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Major
> Fix For: 2.7
>
>
> Calling multiple time cluster (with enabled persistence and started client
> nodes) activation {{ig3CB.cluster().active(true);}} leads to non-heap memory
> leak.
> Line
> {{org/apache/ignite/internal/pagemem/impl/PageMemoryNoStoreImpl.java:234}}
> looks suspicious because of in case method
> {{org.apache.ignite.internal.pagemem.impl.PageMemoryNoStoreImpl#start}}
> callled multi times (e.g. activate(true) called multi times) we lost info
> about allocated regions.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8469) Non-heap memory leak for calling cluster activation multi times
[
https://issues.apache.org/jira/browse/IGNITE-8469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16677009#comment-16677009
]
Max Shonichev commented on IGNITE-8469:
---
ok, here are final results with 100 iterations activate/deactivate scenario:
without fix, total process memory is slowly increasing approx each 20
iterations:
{noformat}
10298776
...
10283356
10284384
...
10286432
{noformat}
with fix, total process memory is changed a little first few runs, than remains
constant all 90+ iterations
{noformat}
14501520
10099096
10232216
10232216
10297752
...
10297752
{noformat}
so, it seems, that this scenario also shows memory leak fixed, [~Mmuzaf],
please confirm
> Non-heap memory leak for calling cluster activation multi times
> ---
>
> Key: IGNITE-8469
> URL: https://issues.apache.org/jira/browse/IGNITE-8469
> Project: Ignite
> Issue Type: Bug
> Components: persistence
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Major
> Fix For: 2.7
>
>
> Calling multiple time cluster (with enabled persistence and started client
> nodes) activation {{ig3CB.cluster().active(true);}} leads to non-heap memory
> leak.
> Line
> {{org/apache/ignite/internal/pagemem/impl/PageMemoryNoStoreImpl.java:234}}
> looks suspicious because of in case method
> {{org.apache.ignite.internal.pagemem.impl.PageMemoryNoStoreImpl#start}}
> callled multi times (e.g. activate(true) called multi times) we lost info
> about allocated regions.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8469) Non-heap memory leak for calling cluster activation multi times
[
https://issues.apache.org/jira/browse/IGNITE-8469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16676934#comment-16676934
]
Max Shonichev commented on IGNITE-8469:
---
Possibly, I'm seeing a different kind of leak, about this scenario:
{quote}Global scenario for this leak is:
1.Start topology with client nodes, presistence enabled
2.Set active(true) for cluster. This activation should fail by some
circumstances (e.g. some locks exists)
3.IgniteCacheDatabaseSharedManager started and onActive method called here. New
memory segment allocated for client node
4.Set active(true) again. Activation successfull, non heap memory leak
introduced{quote}
1. should I start client nodes with persistence enabled ?!
2. how to achive 'locks exist' condition to fail activation?
3. should IgniteCacheDatabaseSharedManager be started manually or you've meant
that this is automagically called under the hood upon active(true)?
> Non-heap memory leak for calling cluster activation multi times
> ---
>
> Key: IGNITE-8469
> URL: https://issues.apache.org/jira/browse/IGNITE-8469
> Project: Ignite
> Issue Type: Bug
> Components: persistence
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Major
> Fix For: 2.7
>
>
> Calling multiple time cluster (with enabled persistence and started client
> nodes) activation {{ig3CB.cluster().active(true);}} leads to non-heap memory
> leak.
> Line
> {{org/apache/ignite/internal/pagemem/impl/PageMemoryNoStoreImpl.java:234}}
> looks suspicious because of in case method
> {{org.apache.ignite.internal.pagemem.impl.PageMemoryNoStoreImpl#start}}
> callled multi times (e.g. activate(true) called multi times) we lost info
> about allocated regions.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-8469) Non-heap memory leak for calling cluster activation multi times
[
https://issues.apache.org/jira/browse/IGNITE-8469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16676922#comment-16676922
]
Max Shonichev edited comment on IGNITE-8469 at 11/6/18 3:59 PM:
[~Mmuzaf] what is exact reproducer for that issue? I'm executing 100 iterations
of activate-deactivate and see small increase in total pages sum per process
for both fixed and original version
I'm using
{noformat}
pmap -x | grep 'total' | awk '{print $3}'
{noformat}
to detect whole memory allocated for apache ignite process
was (Author: mshonichev):
[~Mmuzaf] what is exact reproducer for that issue? I'm executing 100 iterations
of activate-deactivate and see small increase in total pages sum per process
for both fixed and original version
I'm using
{noformat}
pmap -x | grep 'Total' | awk '{print $3}'
{noformat}
to detect whole memory allocated for apache ignite process
> Non-heap memory leak for calling cluster activation multi times
> ---
>
> Key: IGNITE-8469
> URL: https://issues.apache.org/jira/browse/IGNITE-8469
> Project: Ignite
> Issue Type: Bug
> Components: persistence
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Major
> Fix For: 2.7
>
>
> Calling multiple time cluster (with enabled persistence and started client
> nodes) activation {{ig3CB.cluster().active(true);}} leads to non-heap memory
> leak.
> Line
> {{org/apache/ignite/internal/pagemem/impl/PageMemoryNoStoreImpl.java:234}}
> looks suspicious because of in case method
> {{org.apache.ignite.internal.pagemem.impl.PageMemoryNoStoreImpl#start}}
> callled multi times (e.g. activate(true) called multi times) we lost info
> about allocated regions.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-8469) Non-heap memory leak for calling cluster activation multi times
[
https://issues.apache.org/jira/browse/IGNITE-8469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16676922#comment-16676922
]
Max Shonichev edited comment on IGNITE-8469 at 11/6/18 3:58 PM:
[~Mmuzaf] what is exact reproducer for that issue? I'm executing 100 iterations
of activate-deactivate and see small increase in total pages sum per process
for both fixed and original version
I'm using
{noformat}
pmap -x | grep 'Total' | awk '{print $3}'
{noformat}
to detect whole memory allocated for apache ignite process
was (Author: mshonichev):
[~Mmuzaf] what is exact reproducer for that issue? I'm executing 100 iterations
of activate-deactivate and see small increase in total pages sum per process
for both fixed and original version
> Non-heap memory leak for calling cluster activation multi times
> ---
>
> Key: IGNITE-8469
> URL: https://issues.apache.org/jira/browse/IGNITE-8469
> Project: Ignite
> Issue Type: Bug
> Components: persistence
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Major
> Fix For: 2.7
>
>
> Calling multiple time cluster (with enabled persistence and started client
> nodes) activation {{ig3CB.cluster().active(true);}} leads to non-heap memory
> leak.
> Line
> {{org/apache/ignite/internal/pagemem/impl/PageMemoryNoStoreImpl.java:234}}
> looks suspicious because of in case method
> {{org.apache.ignite.internal.pagemem.impl.PageMemoryNoStoreImpl#start}}
> callled multi times (e.g. activate(true) called multi times) we lost info
> about allocated regions.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8469) Non-heap memory leak for calling cluster activation multi times
[
https://issues.apache.org/jira/browse/IGNITE-8469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16676922#comment-16676922
]
Max Shonichev commented on IGNITE-8469:
---
[~Mmuzaf] what is exact reproducer for that issue? I'm executing 100 iterations
of activate-deactivate and see small increase in total pages sum per process
for both fixed and original version
> Non-heap memory leak for calling cluster activation multi times
> ---
>
> Key: IGNITE-8469
> URL: https://issues.apache.org/jira/browse/IGNITE-8469
> Project: Ignite
> Issue Type: Bug
> Components: persistence
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Major
> Fix For: 2.7
>
>
> Calling multiple time cluster (with enabled persistence and started client
> nodes) activation {{ig3CB.cluster().active(true);}} leads to non-heap memory
> leak.
> Line
> {{org/apache/ignite/internal/pagemem/impl/PageMemoryNoStoreImpl.java:234}}
> looks suspicious because of in case method
> {{org.apache.ignite.internal.pagemem.impl.PageMemoryNoStoreImpl#start}}
> callled multi times (e.g. activate(true) called multi times) we lost info
> about allocated regions.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10138) Description is not provided for operations of org.apache.ignite.mxbean.TransactionMetricsMxBean
Max Shonichev created IGNITE-10138: -- Summary: Description is not provided for operations of org.apache.ignite.mxbean.TransactionMetricsMxBean Key: IGNITE-10138 URL: https://issues.apache.org/jira/browse/IGNITE-10138 Project: Ignite Issue Type: Bug Affects Versions: 2.5 Reporter: Max Shonichev Fix For: 2.5 Description mismatch for bean 'TransactionMetrics.TransactionMetricsMxBeanImpl' operation 'commitTime()': expected 'Last commit time.', actual 'Operation exposed for management' operation 'rollbackTime()': expected 'Last rollback time.', actual 'Operation exposed for management' operation 'txCommits()': expected 'Number of transaction commits.', actual 'Operation exposed for management' operation 'txRollbacks()': expected 'Number of transaction rollbacks.', actual 'Operation exposed for management' -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9859) add debug logging on refreshPartitions cause
[ https://issues.apache.org/jira/browse/IGNITE-9859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Max Shonichev updated IGNITE-9859: -- Attachment: (was: IGNITE_9859__add_debug_logging_on_resendPartitions_cause.patch) > add debug logging on refreshPartitions cause > > > Key: IGNITE-9859 > URL: https://issues.apache.org/jira/browse/IGNITE-9859 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.5 >Reporter: Max Shonichev >Priority: Major > Fix For: 2.5 > > Attachments: > IGNITE_9859__add_debug_logging_on_resendPartitions_cause.patch > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9859) add debug logging on refreshPartitions cause
[ https://issues.apache.org/jira/browse/IGNITE-9859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Max Shonichev updated IGNITE-9859: -- Attachment: IGNITE_9859__add_debug_logging_on_resendPartitions_cause.patch > add debug logging on refreshPartitions cause > > > Key: IGNITE-9859 > URL: https://issues.apache.org/jira/browse/IGNITE-9859 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.5 >Reporter: Max Shonichev >Priority: Major > Fix For: 2.5 > > Attachments: > IGNITE_9859__add_debug_logging_on_resendPartitions_cause.patch > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9859) add debug logging on refreshPartitions cause
[ https://issues.apache.org/jira/browse/IGNITE-9859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Max Shonichev updated IGNITE-9859: -- Attachment: IGNITE_9859__add_debug_logging_on_resendPartitions_cause.patch > add debug logging on refreshPartitions cause > > > Key: IGNITE-9859 > URL: https://issues.apache.org/jira/browse/IGNITE-9859 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.5 >Reporter: Max Shonichev >Priority: Major > Fix For: 2.5 > > Attachments: > IGNITE_9859__add_debug_logging_on_resendPartitions_cause.patch > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9859) add debug logging on refreshPartitions cause
[ https://issues.apache.org/jira/browse/IGNITE-9859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Max Shonichev updated IGNITE-9859: -- Summary: add debug logging on refreshPartitions cause (was: add debug logging on resendPartitions cause) > add debug logging on refreshPartitions cause > > > Key: IGNITE-9859 > URL: https://issues.apache.org/jira/browse/IGNITE-9859 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.5 >Reporter: Max Shonichev >Priority: Major > Fix For: 2.5 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9859) add debug logging on resendPartitions cause
Max Shonichev created IGNITE-9859: - Summary: add debug logging on resendPartitions cause Key: IGNITE-9859 URL: https://issues.apache.org/jira/browse/IGNITE-9859 Project: Ignite Issue Type: Improvement Affects Versions: 2.5 Reporter: Max Shonichev Fix For: 2.5 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7616) GridDataStreamExecutor and GridCallbackExecutor JMX beans return incorrect values due to invalid interface registration.
[ https://issues.apache.org/jira/browse/IGNITE-7616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16593431#comment-16593431 ] Max Shonichev commented on IGNITE-7616: --- Wouldn't it be better expose correct interface instead of struggling with conversion of values to incompatible interface? > GridDataStreamExecutor and GridCallbackExecutor JMX beans return incorrect > values due to invalid interface registration. > > > Key: IGNITE-7616 > URL: https://issues.apache.org/jira/browse/IGNITE-7616 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.4 >Reporter: Max Shonichev >Assignee: David Harvey >Priority: Major > Labels: jmx > Fix For: 2.7 > > > Two of newly added management beans as a result of implementing feature > request https://issues.apache.org/jira/browse/IGNITE-7217 have bugs: > # GridDataStreamExecutor is registered as conforming to ThreadPoolMXBean > interface, though actually it is an incompatible StripedExecutor. > # GridCallbackExecutor is registered as conforming to ThreadPoolMXBean > interface, though actually it is an incompatible > IgniteStripedThreadPoolExecutor. > # ThreadPoolMXBeanAdapter checks whether adapted instance is > ThreadPoolExecutor, and as interfaces are incompatible, most of the JMX > attributes of GridCallbackExecutor and GridDataStreamExecutor are returned as > -1 or null. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8898) rename command argument '--force' to '--yes' for control.sh
Max Shonichev created IGNITE-8898: - Summary: rename command argument '--force' to '--yes' for control.sh Key: IGNITE-8898 URL: https://issues.apache.org/jira/browse/IGNITE-8898 Project: Ignite Issue Type: Improvement Affects Versions: 2.5 Reporter: Max Shonichev control.sh requires admin to provide `--force` to auto-confirm actions requiring manual confirmation as deactivation of the grid or setting new baseline. Semantically, this is not 'forcing', but 'auto-confirmation', so please, rename `--force` argument of control.sh to `--yes`. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8622) Zookeeper and TCP discovery SPI' getSpiState method inconsistent
[ https://issues.apache.org/jira/browse/IGNITE-8622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Max Shonichev updated IGNITE-8622: -- Labels: jmx (was: ) > Zookeeper and TCP discovery SPI' getSpiState method inconsistent > > > Key: IGNITE-8622 > URL: https://issues.apache.org/jira/browse/IGNITE-8622 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.5 >Reporter: Max Shonichev >Priority: Minor > Labels: jmx > Fix For: 2.6 > > > getSpiState of TcpDiscoverySpi Mbean returns uppercased human-readable state, > e.g. 'CONNECTED' > getSpiState of ZookeeperDiscoverySpi Mbean returns camelcased one, e.g. > 'Connected' -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8622) Zookeeper and TCP discovery SPI' getSpiState method inconsistent
Max Shonichev created IGNITE-8622: - Summary: Zookeeper and TCP discovery SPI' getSpiState method inconsistent Key: IGNITE-8622 URL: https://issues.apache.org/jira/browse/IGNITE-8622 Project: Ignite Issue Type: Bug Affects Versions: 2.5 Reporter: Max Shonichev Fix For: 2.6 getSpiState of TcpDiscoverySpi Mbean returns uppercased human-readable state, e.g. 'CONNECTED' getSpiState of ZookeeperDiscoverySpi Mbean returns camelcased one, e.g. 'Connected' -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8621) TcpDiscoverySpi's UpTime/StartTimestamp methods do not work
Max Shonichev created IGNITE-8621: - Summary: TcpDiscoverySpi's UpTime/StartTimestamp methods do not work Key: IGNITE-8621 URL: https://issues.apache.org/jira/browse/IGNITE-8621 Project: Ignite Issue Type: Bug Affects Versions: 2.5 Reporter: Max Shonichev Fix For: 2.6 Attachments: Screenshot from 2018-05-28 12-57-13.png getUpTime and getStartTimestamp methods of TcpDiscoverySpiMBeanImpl returns 0, which does not look like normal value also, getUpTimeFormatted returns 00:00:00.000 and getStartTimestampFormatted returns Jan 1, 1970 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (IGNITE-8082) No management bean for ZookeeperDiscoverySpi
[ https://issues.apache.org/jira/browse/IGNITE-8082?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Max Shonichev closed IGNITE-8082. - > No management bean for ZookeeperDiscoverySpi > > > Key: IGNITE-8082 > URL: https://issues.apache.org/jira/browse/IGNITE-8082 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.5 >Reporter: Max Shonichev >Assignee: Sergey Chugunov >Priority: Major > Fix For: 2.5 > > Attachments: Screenshot from 2018-05-28 12-54-17.png, Screenshot from > 2018-05-28 12-57-13.png > > > TcpDiscoverySpi provides management bean, allowing user to obtain > configuration and metrics from it via JMX. > However, Zookeeper discovery spi provides no management bean, please add it > with similar attributes. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8082) No management bean for ZookeeperDiscoverySpi
[ https://issues.apache.org/jira/browse/IGNITE-8082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16492486#comment-16492486 ] Max Shonichev commented on IGNITE-8082: --- TcpDiscoverySpi MBean: !Screenshot from 2018-05-28 12-57-13.png! ZookeeperDiscoverySpi MBean !Screenshot from 2018-05-28 12-54-17.png! > No management bean for ZookeeperDiscoverySpi > > > Key: IGNITE-8082 > URL: https://issues.apache.org/jira/browse/IGNITE-8082 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.5 >Reporter: Max Shonichev >Assignee: Sergey Chugunov >Priority: Major > Fix For: 2.5 > > Attachments: Screenshot from 2018-05-28 12-54-17.png, Screenshot from > 2018-05-28 12-57-13.png > > > TcpDiscoverySpi provides management bean, allowing user to obtain > configuration and metrics from it via JMX. > However, Zookeeper discovery spi provides no management bean, please add it > with similar attributes. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8082) No management bean for ZookeeperDiscoverySpi
[ https://issues.apache.org/jira/browse/IGNITE-8082?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Max Shonichev updated IGNITE-8082: -- Attachment: Screenshot from 2018-05-28 12-54-17.png > No management bean for ZookeeperDiscoverySpi > > > Key: IGNITE-8082 > URL: https://issues.apache.org/jira/browse/IGNITE-8082 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.5 >Reporter: Max Shonichev >Assignee: Sergey Chugunov >Priority: Major > Fix For: 2.5 > > Attachments: Screenshot from 2018-05-28 12-54-17.png, Screenshot from > 2018-05-28 12-57-13.png > > > TcpDiscoverySpi provides management bean, allowing user to obtain > configuration and metrics from it via JMX. > However, Zookeeper discovery spi provides no management bean, please add it > with similar attributes. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8082) No management bean for ZookeeperDiscoverySpi
[ https://issues.apache.org/jira/browse/IGNITE-8082?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Max Shonichev updated IGNITE-8082: -- Attachment: Screenshot from 2018-05-28 12-57-13.png > No management bean for ZookeeperDiscoverySpi > > > Key: IGNITE-8082 > URL: https://issues.apache.org/jira/browse/IGNITE-8082 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.5 >Reporter: Max Shonichev >Assignee: Sergey Chugunov >Priority: Major > Fix For: 2.5 > > Attachments: Screenshot from 2018-05-28 12-54-17.png, Screenshot from > 2018-05-28 12-57-13.png > > > TcpDiscoverySpi provides management bean, allowing user to obtain > configuration and metrics from it via JMX. > However, Zookeeper discovery spi provides no management bean, please add it > with similar attributes. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (IGNITE-8064) fix typos in JMX beans description
[ https://issues.apache.org/jira/browse/IGNITE-8064?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Max Shonichev closed IGNITE-8064. - > fix typos in JMX beans description > -- > > Key: IGNITE-8064 > URL: https://issues.apache.org/jira/browse/IGNITE-8064 > Project: Ignite > Issue Type: Bug >Reporter: Max Shonichev >Priority: Trivial > Attachments: IGNITE-8064.patch > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (IGNITE-8430) implement getCurrentCoordinator method in IgniteMXBean
[ https://issues.apache.org/jira/browse/IGNITE-8430?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Max Shonichev closed IGNITE-8430. - > implement getCurrentCoordinator method in IgniteMXBean > -- > > Key: IGNITE-8430 > URL: https://issues.apache.org/jira/browse/IGNITE-8430 > Project: Ignite > Issue Type: New Feature >Affects Versions: 2.5 >Reporter: Max Shonichev >Assignee: Anton Kalashnikov >Priority: Major > Fix For: 2.5 > > > Currently, user can obtain coordinator node id via JMX attribute Coordinator > of TcpDiscoverySpi OR ZookeeperDiscoverySpi MBean. > However, to get this attribute, external utility JMX must first understand > which discovery SPI implementation is used at current grid, which is > inconvenient. Would be much better if that attribute was located in same > instance no matter which Disco SPI was configured. > Please, add String CurrentCoordinator attribute to Ignite MX bean with > following meaning: > - for the cases, when node does not know current coordinator (e.g. > getCoordinator returns null), attribute should be empty string '' > - for the case, when node knows current coordinator, return following > coordinator properties formatted as string, separated by ',': >-- Coordinator IP address >-- Coordinator node ID >-- Coordinator node order >-- Coordinator Fully Qualified Domain Name -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (IGNITE-8278) Nightly built package does not run
[
https://issues.apache.org/jira/browse/IGNITE-8278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Max Shonichev closed IGNITE-8278.
-
confirmed
> Nightly built package does not run
> --
>
> Key: IGNITE-8278
> URL: https://issues.apache.org/jira/browse/IGNITE-8278
> Project: Ignite
> Issue Type: Bug
>Reporter: Max Shonichev
>Assignee: Peter Ivanov
>Priority: Critical
>
> Trying to run build from
> http://172.25.1.150:8111/viewLog.html?buildId=1209266=Releases_NightlyRelease_RunApacheIgniteNightlyRelease=artifacts
> results in error:
> {noformat}
> Exception in thread "main" java.lang.ExceptionInInitializerError
> at
> org.apache.ignite.startup.cmdline.CommandLineStartup.(CommandLineStartup.java:99)
> Caused by: java.lang.IllegalStateException: Failed to parse version:
> 2.5.0.20180415-0
> at
> org.apache.ignite.lang.IgniteProductVersion.fromString(IgniteProductVersion.java:314)
> at
> org.apache.ignite.internal.IgniteVersionUtils.(IgniteVersionUtils.java:71)
> {noformat}
> Possibly this is due to empty build timestamp in ignite.properties.
> {noformat}
> ignite.version=2.5.0.20180415
> ignite.build=0
> ignite.revision=DEV
> ignite.rel.date=15042018
> ignite.update.status.params=ver=2.5.0.20180415=apache-ignite
> ignite.update.notifier.enabled.by.default=true
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-8431) createTcpClient crash when starting two local nodes with different IP, but same ports
[
https://issues.apache.org/jira/browse/IGNITE-8431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Max Shonichev updated IGNITE-8431:
--
Attachment: grid.1.node.1.0.log.tar.gz
> createTcpClient crash when starting two local nodes with different IP, but
> same ports
> -
>
> Key: IGNITE-8431
> URL: https://issues.apache.org/jira/browse/IGNITE-8431
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Max Shonichev
>Priority: Major
> Attachments: 2.4-base.xml, caches.xml, client.xml, disco-tcp.xml,
> grid.1.node.1.0.log.tar.gz, grid.1.node.20001.0.log, server.xml
>
>
> node #1 (server) starts on 127.0.1.1,
> node #2 (client) starts on 127.0.1.2
> for both nodes, corresponding IP address set as 'localHost' in the
> configuration.
> however, upon starting, client immediately asserts with following stack trace:
> {noformat}
> java.lang.AssertionError
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createTcpClient(TcpCommunicationSpi.java:3446)
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createNioClient(TcpCommunicationSpi.java:2958)
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.reserveClient(TcpCommunicationSpi.java:2841)
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage0(TcpCommunicationSpi.java:2692)
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage(TcpCommunicationSpi.java:2651)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:1643)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.sendToGridTopic(GridIoManager.java:1715)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.send(GridCacheIoManager.java:1160)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.sendLocalPartitions(GridDhtPartitionsExchangeFuture.java:1468)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.clientOnlyExchange(GridDhtPartitionsExchangeFuture.java:1071)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:723)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body0(GridCachePartitionExchangeManager.java:2419)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2299)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-8431) createTcpClient crash when starting two local nodes with different IP, but same ports
[
https://issues.apache.org/jira/browse/IGNITE-8431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Max Shonichev updated IGNITE-8431:
--
Attachment: grid.1.node.20001.0.log
> createTcpClient crash when starting two local nodes with different IP, but
> same ports
> -
>
> Key: IGNITE-8431
> URL: https://issues.apache.org/jira/browse/IGNITE-8431
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Max Shonichev
>Priority: Major
> Attachments: 2.4-base.xml, caches.xml, client.xml, disco-tcp.xml,
> grid.1.node.20001.0.log, server.xml
>
>
> node #1 (server) starts on 127.0.1.1,
> node #2 (client) starts on 127.0.1.2
> for both nodes, corresponding IP address set as 'localHost' in the
> configuration.
> however, upon starting, client immediately asserts with following stack trace:
> {noformat}
> java.lang.AssertionError
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createTcpClient(TcpCommunicationSpi.java:3446)
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createNioClient(TcpCommunicationSpi.java:2958)
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.reserveClient(TcpCommunicationSpi.java:2841)
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage0(TcpCommunicationSpi.java:2692)
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage(TcpCommunicationSpi.java:2651)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:1643)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.sendToGridTopic(GridIoManager.java:1715)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.send(GridCacheIoManager.java:1160)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.sendLocalPartitions(GridDhtPartitionsExchangeFuture.java:1468)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.clientOnlyExchange(GridDhtPartitionsExchangeFuture.java:1071)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:723)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body0(GridCachePartitionExchangeManager.java:2419)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2299)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-8431) createTcpClient crash when starting two local nodes with different IP, but same ports
[
https://issues.apache.org/jira/browse/IGNITE-8431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Max Shonichev updated IGNITE-8431:
--
Attachment: client.xml
> createTcpClient crash when starting two local nodes with different IP, but
> same ports
> -
>
> Key: IGNITE-8431
> URL: https://issues.apache.org/jira/browse/IGNITE-8431
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Max Shonichev
>Priority: Major
> Attachments: 2.4-base.xml, caches.xml, client.xml, disco-tcp.xml,
> grid.1.node.20001.0.log, server.xml
>
>
> node #1 (server) starts on 127.0.1.1,
> node #2 (client) starts on 127.0.1.2
> for both nodes, corresponding IP address set as 'localHost' in the
> configuration.
> however, upon starting, client immediately asserts with following stack trace:
> {noformat}
> java.lang.AssertionError
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createTcpClient(TcpCommunicationSpi.java:3446)
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createNioClient(TcpCommunicationSpi.java:2958)
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.reserveClient(TcpCommunicationSpi.java:2841)
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage0(TcpCommunicationSpi.java:2692)
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage(TcpCommunicationSpi.java:2651)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:1643)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.sendToGridTopic(GridIoManager.java:1715)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.send(GridCacheIoManager.java:1160)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.sendLocalPartitions(GridDhtPartitionsExchangeFuture.java:1468)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.clientOnlyExchange(GridDhtPartitionsExchangeFuture.java:1071)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:723)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body0(GridCachePartitionExchangeManager.java:2419)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2299)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-8431) createTcpClient crash when starting two local nodes with different IP, but same ports
[
https://issues.apache.org/jira/browse/IGNITE-8431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Max Shonichev updated IGNITE-8431:
--
Attachment: caches.xml
> createTcpClient crash when starting two local nodes with different IP, but
> same ports
> -
>
> Key: IGNITE-8431
> URL: https://issues.apache.org/jira/browse/IGNITE-8431
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Max Shonichev
>Priority: Major
> Attachments: 2.4-base.xml, caches.xml, disco-tcp.xml, server.xml
>
>
> node #1 (server) starts on 127.0.1.1,
> node #2 (client) starts on 127.0.1.2
> for both nodes, corresponding IP address set as 'localHost' in the
> configuration.
> however, upon starting, client immediately asserts with following stack trace:
> {noformat}
> java.lang.AssertionError
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createTcpClient(TcpCommunicationSpi.java:3446)
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createNioClient(TcpCommunicationSpi.java:2958)
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.reserveClient(TcpCommunicationSpi.java:2841)
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage0(TcpCommunicationSpi.java:2692)
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage(TcpCommunicationSpi.java:2651)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:1643)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.sendToGridTopic(GridIoManager.java:1715)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.send(GridCacheIoManager.java:1160)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.sendLocalPartitions(GridDhtPartitionsExchangeFuture.java:1468)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.clientOnlyExchange(GridDhtPartitionsExchangeFuture.java:1071)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:723)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body0(GridCachePartitionExchangeManager.java:2419)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2299)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-8431) createTcpClient crash when starting two local nodes with different IP, but same ports
[
https://issues.apache.org/jira/browse/IGNITE-8431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Max Shonichev updated IGNITE-8431:
--
Attachment: 2.4-base.xml
> createTcpClient crash when starting two local nodes with different IP, but
> same ports
> -
>
> Key: IGNITE-8431
> URL: https://issues.apache.org/jira/browse/IGNITE-8431
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Max Shonichev
>Priority: Major
> Attachments: 2.4-base.xml, caches.xml, disco-tcp.xml, server.xml
>
>
> node #1 (server) starts on 127.0.1.1,
> node #2 (client) starts on 127.0.1.2
> for both nodes, corresponding IP address set as 'localHost' in the
> configuration.
> however, upon starting, client immediately asserts with following stack trace:
> {noformat}
> java.lang.AssertionError
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createTcpClient(TcpCommunicationSpi.java:3446)
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createNioClient(TcpCommunicationSpi.java:2958)
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.reserveClient(TcpCommunicationSpi.java:2841)
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage0(TcpCommunicationSpi.java:2692)
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage(TcpCommunicationSpi.java:2651)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:1643)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.sendToGridTopic(GridIoManager.java:1715)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.send(GridCacheIoManager.java:1160)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.sendLocalPartitions(GridDhtPartitionsExchangeFuture.java:1468)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.clientOnlyExchange(GridDhtPartitionsExchangeFuture.java:1071)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:723)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body0(GridCachePartitionExchangeManager.java:2419)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2299)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-8431) createTcpClient crash when starting two local nodes with different IP, but same ports
[
https://issues.apache.org/jira/browse/IGNITE-8431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Max Shonichev updated IGNITE-8431:
--
Attachment: disco-tcp.xml
> createTcpClient crash when starting two local nodes with different IP, but
> same ports
> -
>
> Key: IGNITE-8431
> URL: https://issues.apache.org/jira/browse/IGNITE-8431
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Max Shonichev
>Priority: Major
> Attachments: 2.4-base.xml, caches.xml, disco-tcp.xml, server.xml
>
>
> node #1 (server) starts on 127.0.1.1,
> node #2 (client) starts on 127.0.1.2
> for both nodes, corresponding IP address set as 'localHost' in the
> configuration.
> however, upon starting, client immediately asserts with following stack trace:
> {noformat}
> java.lang.AssertionError
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createTcpClient(TcpCommunicationSpi.java:3446)
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createNioClient(TcpCommunicationSpi.java:2958)
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.reserveClient(TcpCommunicationSpi.java:2841)
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage0(TcpCommunicationSpi.java:2692)
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage(TcpCommunicationSpi.java:2651)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:1643)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.sendToGridTopic(GridIoManager.java:1715)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.send(GridCacheIoManager.java:1160)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.sendLocalPartitions(GridDhtPartitionsExchangeFuture.java:1468)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.clientOnlyExchange(GridDhtPartitionsExchangeFuture.java:1071)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:723)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body0(GridCachePartitionExchangeManager.java:2419)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2299)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-8431) createTcpClient crash when starting two local nodes with different IP, but same ports
[
https://issues.apache.org/jira/browse/IGNITE-8431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Max Shonichev updated IGNITE-8431:
--
Attachment: server.xml
> createTcpClient crash when starting two local nodes with different IP, but
> same ports
> -
>
> Key: IGNITE-8431
> URL: https://issues.apache.org/jira/browse/IGNITE-8431
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Max Shonichev
>Priority: Major
> Attachments: 2.4-base.xml, caches.xml, disco-tcp.xml, server.xml
>
>
> node #1 (server) starts on 127.0.1.1,
> node #2 (client) starts on 127.0.1.2
> for both nodes, corresponding IP address set as 'localHost' in the
> configuration.
> however, upon starting, client immediately asserts with following stack trace:
> {noformat}
> java.lang.AssertionError
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createTcpClient(TcpCommunicationSpi.java:3446)
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createNioClient(TcpCommunicationSpi.java:2958)
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.reserveClient(TcpCommunicationSpi.java:2841)
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage0(TcpCommunicationSpi.java:2692)
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage(TcpCommunicationSpi.java:2651)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:1643)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.sendToGridTopic(GridIoManager.java:1715)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.send(GridCacheIoManager.java:1160)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.sendLocalPartitions(GridDhtPartitionsExchangeFuture.java:1468)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.clientOnlyExchange(GridDhtPartitionsExchangeFuture.java:1071)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:723)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body0(GridCachePartitionExchangeManager.java:2419)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2299)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-8431) createTcpClient crash when starting two local nodes with different IP, but same ports
[
https://issues.apache.org/jira/browse/IGNITE-8431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Max Shonichev updated IGNITE-8431:
--
Attachment: client.xml
> createTcpClient crash when starting two local nodes with different IP, but
> same ports
> -
>
> Key: IGNITE-8431
> URL: https://issues.apache.org/jira/browse/IGNITE-8431
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Max Shonichev
>Priority: Major
> Attachments: 2.4-base.xml, caches.xml, disco-tcp.xml, server.xml
>
>
> node #1 (server) starts on 127.0.1.1,
> node #2 (client) starts on 127.0.1.2
> for both nodes, corresponding IP address set as 'localHost' in the
> configuration.
> however, upon starting, client immediately asserts with following stack trace:
> {noformat}
> java.lang.AssertionError
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createTcpClient(TcpCommunicationSpi.java:3446)
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createNioClient(TcpCommunicationSpi.java:2958)
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.reserveClient(TcpCommunicationSpi.java:2841)
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage0(TcpCommunicationSpi.java:2692)
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage(TcpCommunicationSpi.java:2651)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:1643)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.sendToGridTopic(GridIoManager.java:1715)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.send(GridCacheIoManager.java:1160)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.sendLocalPartitions(GridDhtPartitionsExchangeFuture.java:1468)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.clientOnlyExchange(GridDhtPartitionsExchangeFuture.java:1071)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:723)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body0(GridCachePartitionExchangeManager.java:2419)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2299)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-8431) createTcpClient crash when starting two local nodes with different IP, but same ports
[
https://issues.apache.org/jira/browse/IGNITE-8431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Max Shonichev updated IGNITE-8431:
--
Attachment: (was: client.xml)
> createTcpClient crash when starting two local nodes with different IP, but
> same ports
> -
>
> Key: IGNITE-8431
> URL: https://issues.apache.org/jira/browse/IGNITE-8431
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Max Shonichev
>Priority: Major
> Attachments: 2.4-base.xml, caches.xml, disco-tcp.xml, server.xml
>
>
> node #1 (server) starts on 127.0.1.1,
> node #2 (client) starts on 127.0.1.2
> for both nodes, corresponding IP address set as 'localHost' in the
> configuration.
> however, upon starting, client immediately asserts with following stack trace:
> {noformat}
> java.lang.AssertionError
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createTcpClient(TcpCommunicationSpi.java:3446)
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createNioClient(TcpCommunicationSpi.java:2958)
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.reserveClient(TcpCommunicationSpi.java:2841)
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage0(TcpCommunicationSpi.java:2692)
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage(TcpCommunicationSpi.java:2651)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:1643)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.sendToGridTopic(GridIoManager.java:1715)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.send(GridCacheIoManager.java:1160)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.sendLocalPartitions(GridDhtPartitionsExchangeFuture.java:1468)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.clientOnlyExchange(GridDhtPartitionsExchangeFuture.java:1071)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:723)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body0(GridCachePartitionExchangeManager.java:2419)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2299)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-8431) createTcpClient crash when starting two local nodes with different IP, but same ports
Max Shonichev created IGNITE-8431:
-
Summary: createTcpClient crash when starting two local nodes with
different IP, but same ports
Key: IGNITE-8431
URL: https://issues.apache.org/jira/browse/IGNITE-8431
Project: Ignite
Issue Type: Bug
Affects Versions: 2.5
Reporter: Max Shonichev
node #1 (server) starts on 127.0.1.1,
node #2 (client) starts on 127.0.1.2
for both nodes, corresponding IP address set as 'localHost' in the
configuration.
however, upon starting, client immediately asserts with following stack trace:
{noformat}
java.lang.AssertionError
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createTcpClient(TcpCommunicationSpi.java:3446)
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createNioClient(TcpCommunicationSpi.java:2958)
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.reserveClient(TcpCommunicationSpi.java:2841)
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage0(TcpCommunicationSpi.java:2692)
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage(TcpCommunicationSpi.java:2651)
at
org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:1643)
at
org.apache.ignite.internal.managers.communication.GridIoManager.sendToGridTopic(GridIoManager.java:1715)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.send(GridCacheIoManager.java:1160)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.sendLocalPartitions(GridDhtPartitionsExchangeFuture.java:1468)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.clientOnlyExchange(GridDhtPartitionsExchangeFuture.java:1071)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:723)
at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body0(GridCachePartitionExchangeManager.java:2419)
at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2299)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
at java.lang.Thread.run(Thread.java:748)
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-8430) implement getCurrentCoordinator method in IgniteMXBean
[ https://issues.apache.org/jira/browse/IGNITE-8430?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Max Shonichev updated IGNITE-8430: -- Affects Version/s: 2.5 Fix Version/s: 2.5 Description: Currently, user can obtain coordinator node id via JMX attribute Coordinator of TcpDiscoverySpi OR ZookeeperDiscoverySpi MBean. However, to get this attribute, external utility JMX must first understand which discovery SPI implementation is used at current grid, which is inconvenient. Would be much better if that attribute was located in same instance no matter which Disco SPI was configured. Please, add String CurrentCoordinator attribute to Ignite MX bean with following meaning: - for the cases, when node does not know current coordinator (e.g. getCoordinator returns null), attribute should be empty string '' - for the case, when node knows current coordinator, return following coordinator properties formatted as string, separated by ',': -- Coordinator IP address -- Coordinator node ID -- Coordinator node order -- Coordinator Fully Qualified Domain Name Summary: implement getCurrentCoordinator method in IgniteMXBean (was: gety) > implement getCurrentCoordinator method in IgniteMXBean > -- > > Key: IGNITE-8430 > URL: https://issues.apache.org/jira/browse/IGNITE-8430 > Project: Ignite > Issue Type: New Feature >Affects Versions: 2.5 >Reporter: Max Shonichev >Priority: Major > Fix For: 2.5 > > > Currently, user can obtain coordinator node id via JMX attribute Coordinator > of TcpDiscoverySpi OR ZookeeperDiscoverySpi MBean. > However, to get this attribute, external utility JMX must first understand > which discovery SPI implementation is used at current grid, which is > inconvenient. Would be much better if that attribute was located in same > instance no matter which Disco SPI was configured. > Please, add String CurrentCoordinator attribute to Ignite MX bean with > following meaning: > - for the cases, when node does not know current coordinator (e.g. > getCoordinator returns null), attribute should be empty string '' > - for the case, when node knows current coordinator, return following > coordinator properties formatted as string, separated by ',': >-- Coordinator IP address >-- Coordinator node ID >-- Coordinator node order >-- Coordinator Fully Qualified Domain Name -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8430) gety
Max Shonichev created IGNITE-8430: - Summary: gety Key: IGNITE-8430 URL: https://issues.apache.org/jira/browse/IGNITE-8430 Project: Ignite Issue Type: New Feature Reporter: Max Shonichev -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7108) Apache Ignite 2.5 RPM and DEB packages
[ https://issues.apache.org/jira/browse/IGNITE-7108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16450203#comment-16450203 ] Max Shonichev commented on IGNITE-7108: --- Confirm. Also tested following scenarios: - enabled apache-ign...@default-config.xml service for restart with physical server restart - checked firewall rules : two nodes successfully connect with/without enabled firewalld During those tests I found that there are no simple means for user to tweak Apache Ignite service JVM settings other than manually hack service.sh/ignite.sh, which I would consider bad practice, because files installed with package will be overwritten upon package upgrade. We should add something like /etc/defaults/apache-ignite in future. Also, would be nice to have simple means to start Apache Ignite examples with configs from /usr/share/doc/apache-ignite/examples/config. Those findings do not block IGNITE-7108 ticket merge, because current state of work is rather solid, packages for Redhat/Ubuntu are buildable, installable and runnable. IMO, we should adopt patch it to master, later on we can create appropriate tickets after receiving some user feedback. > Apache Ignite 2.5 RPM and DEB packages > -- > > Key: IGNITE-7108 > URL: https://issues.apache.org/jira/browse/IGNITE-7108 > Project: Ignite > Issue Type: New Feature > Components: binary >Reporter: Peter Ivanov >Assignee: Peter Ivanov >Priority: Critical > Labels: important > Fix For: 2.5 > > > # (/) Update RPM build process to unify with DEB build. > # (/) Prepare build of DEB package (using architecture and layout from RPM > package). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-7108) Apache Ignite 2.5 RPM and DEB packages
[ https://issues.apache.org/jira/browse/IGNITE-7108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16448424#comment-16448424 ] Max Shonichev edited comment on IGNITE-7108 at 4/23/18 4:49 PM: Tested following scenarios: - build .rpm - build .deb - install .rpm (centos) - install .deb (ubuntu) - start apache-ign...@default-config.xml service - stop apache-ign...@default-config.xml service - status of apache-ign...@default-config.xml service - would be nice to improve usability later - restart apache-ign...@default-config.xml service - remove installed package without running service - remove installed package with running service - service is not stopped during remove - update from apache 2.4.0 package (centos) - service is not stopped during update all seems ok. was (Author: mshonichev): Tested following scenarios: - build .rpm - build .deb - install .rpm (centos) - install .deb (ubuntu) - start apache-ign...@default-config.xml service - stop apache-ign...@default-config.xml service - status of apache-ign...@default-config.xml service - restart apache-ign...@default-config.xml service - remove installed package without running service - remove installed package with running service - update from apache 2.4.0 package (centos) all seems ok. > Apache Ignite 2.5 RPM and DEB packages > -- > > Key: IGNITE-7108 > URL: https://issues.apache.org/jira/browse/IGNITE-7108 > Project: Ignite > Issue Type: New Feature > Components: binary >Reporter: Peter Ivanov >Assignee: Peter Ivanov >Priority: Critical > Labels: important > Fix For: 2.5 > > > # (/) Update RPM build process to unify with DEB build. > # (/) Prepare build of DEB package (using architecture and layout from RPM > package). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7108) Apache Ignite 2.5 RPM and DEB packages
[ https://issues.apache.org/jira/browse/IGNITE-7108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16448424#comment-16448424 ] Max Shonichev commented on IGNITE-7108: --- Tested following scenarios: - build .rpm - build .deb - install .rpm (centos) - install .deb (ubuntu) - start apache-ign...@default-config.xml service - stop apache-ign...@default-config.xml service - status of apache-ign...@default-config.xml service - restart apache-ign...@default-config.xml service - remove installed package without running service - remove installed package with running service - update from apache 2.4.0 package (centos) all seems ok. > Apache Ignite 2.5 RPM and DEB packages > -- > > Key: IGNITE-7108 > URL: https://issues.apache.org/jira/browse/IGNITE-7108 > Project: Ignite > Issue Type: New Feature > Components: binary >Reporter: Peter Ivanov >Assignee: Peter Ivanov >Priority: Critical > Labels: important > Fix For: 2.5 > > > # (/) Update RPM build process to unify with DEB build. > # (/) Prepare build of DEB package (using architecture and layout from RPM > package). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7108) Apache Ignite 2.5 RPM and DEB packages
[
https://issues.apache.org/jira/browse/IGNITE-7108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16448422#comment-16448422
]
Max Shonichev commented on IGNITE-7108:
---
It seems a little inconvenient to me that user must always put config filename
to perform any operation with service.
basic use case: admin wants to quickly check status of service
{noformat}
# systemctl status apache-ignite
● apache-ignite.service
Loaded: not-found (Reason: No such file or directory)
Active: inactive (dead)
{noformat}
Wow-wow, why is it dead? It is actually not, but you'd asked it wrong:
{noformat}
# systemctl status apache-ign...@default-config.xml
● apache-ign...@default-config.xml.service - Apache Ignite In-Memory Computing
Platform Service
Loaded: loaded (/etc/systemd/system/apache-ignite@.service; disabled; vendor
preset: enabled)
Active: active (running) since Mon 2018-04-23 16:23:26 UTC; 14min ago
Process: 69 ExecStart=/usr/share/apache-ignite/bin/service.sh start %i
(code=exited, status=0/SUCCESS)
Process: 67 ExecStartPre=/usr/bin/env bash
/usr/share/apache-ignite/bin/service.sh set-firewall (code=exited,
status=0/SUCCESS)
Process: 66 ExecStartPre=/bin/chown ignite:ignite /var/run/apache-ignite
(code=exited, status=0/SUCCESS)
Process: 65 ExecStartPre=/bin/mkdir /var/run/apache-ignite (code=exited,
status=0/SUCCESS)
Main PID: 70 (ignite.sh)
CGroup:
/docker/a198605103cc6e6b20ac411ed8b3c80d5f669e5dedd23e03c60bb71a355ebe1a/system.slice/system-apache\x2dignite.slice/apache-ign...@default-config.xml.service
├─ 70 /bin/bash /usr/share/apache-ignite/bin/ignite.sh
/etc/apache-ignite/default-config.xml
└─165 /usr/bin/java -Xms1g -Xmx1g -server -XX:+AggressiveOpts
-XX:MaxMetaspaceSize=256m -DIGNITE_QUIET=true
-DIGNITE_SUCCESS_FILE=/usr/share/apache-ignite/work/ignit
e_success_1d84d0dc-b239-4449-adae-5800891b9765 -Dcom.sun.management.jmxremote
-Dcom.sun.management.jmxremote.port=49112
-Dcom.sun.management.jmxremote.authenticate=false -Dco
m.sun.management.jmxremote.ssl=false -DIGNITE_HOME=/usr/share/apache-ignite
-DIGNITE_PROG_NAME=/usr/share/apache-ignite/bin/ignite.sh -cp
/usr/share/apache-ignite/libs/*:/usr
/share/apache-ignite/libs/ignite-indexing/*:/usr/share/apache-ignite/libs/ignite-spring/*:/usr/share/apache-ignite/libs/licenses/*
org.apache.ignite.startup.cmdline.CommandLi
neStartup /etc/apache-ignite/default-config.xml
Apr 23 16:23:26 a198605103cc systemd[1]: Starting Apache Ignite In-Memory
Computing Platform Service...
Apr 23 16:23:26 a198605103cc systemd[1]: Started Apache Ignite In-Memory
Computing Platform Service.
{noformat}
Is it possible to at least dump for which configs are nodes started if they
are?
Also, when node is stopped/crashed we could scratch a head forever before we
get an understanding from which config should we restart it again.
Very awkward, IMO.
> Apache Ignite 2.5 RPM and DEB packages
> --
>
> Key: IGNITE-7108
> URL: https://issues.apache.org/jira/browse/IGNITE-7108
> Project: Ignite
> Issue Type: New Feature
> Components: binary
>Reporter: Peter Ivanov
>Assignee: Peter Ivanov
>Priority: Critical
> Labels: important
> Fix For: 2.5
>
>
> # (/) Update RPM build process to unify with DEB build.
> # (/) Prepare build of DEB package (using architecture and layout from RPM
> package).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-7108) Apache Ignite 2.5 RPM and DEB packages
[
https://issues.apache.org/jira/browse/IGNITE-7108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16448404#comment-16448404
]
Max Shonichev commented on IGNITE-7108:
---
Same goes for update scenario. As we don't have rolling upgrade in the apache
ignite, IMO, we should stop running nodes but do not restart them automatically
after upgrade.
in case if some nodes of old version are currently running, print banner
{noformat}
===
WARNING: All local running Apache Ignite nodes will be stopped.
===
{noformat}
and also, no matter if nodes are running or not, print a banner with text:
{noformat}
===
WARNING: To update Apache Ignite cluster you must update all cluster nodes
before starting grid.
===
{noformat}
> Apache Ignite 2.5 RPM and DEB packages
> --
>
> Key: IGNITE-7108
> URL: https://issues.apache.org/jira/browse/IGNITE-7108
> Project: Ignite
> Issue Type: New Feature
> Components: binary
>Reporter: Peter Ivanov
>Assignee: Peter Ivanov
>Priority: Critical
> Labels: important
> Fix For: 2.5
>
>
> # (/) Update RPM build process to unify with DEB build.
> # (/) Prepare build of DEB package (using architecture and layout from RPM
> package).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-7108) Apache Ignite 2.5 RPM and DEB packages
[
https://issues.apache.org/jira/browse/IGNITE-7108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16448191#comment-16448191
]
Max Shonichev edited comment on IGNITE-7108 at 4/23/18 2:11 PM:
when user uninstalls package, the running service does not stop
{noformat}
yum remove apache-ignite
Loaded plugins: fastestmirror, ovl
Resolving Dependencies
--> Running transaction check
---> Package apache-ignite.noarch 0:2.5.0-1 will be erased
--> Finished Dependency Resolution
Dependencies Resolved
===
PackageArch
Version
Repository Size
===
Removing:
apache-ignite noarch
2.5.0-1
installed 277 M
Transaction Summary
===
Remove 1 Package
Installed size: 277 M
Is this ok [y/N]: y
Downloading packages:
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
Warning: RPMDB altered outside of yum.
Erasing: apache-ignite-2.5.0-1.noarch
1/1
userdel: user ignite is currently used by process 57
removed '/var/run/apache-ignite/default-config.xml.pid'
removed directory: '/var/run/apache-ignite'
Verifying : apache-ignite-2.5.0-1.noarch
1/1
Removed:
apache-ignite.noarch 0:2.5.0-1
Complete!
[root@973e6de20f40 /]# ps -AF
UIDPID PPID CSZ RSS PSR STIME TTY TIME CMD
root 1 0 0 10702 4640 6 13:10 ?00:00:00 /usr/sbin/init
root18 1 0 9211 7212 1 13:10 ?00:00:00
/usr/lib/systemd/systemd-journald
root20 0 0 2946 3000 0 13:10 ?00:00:00 bash
ignite 57 1 0 3238 2980 4 13:14 ?00:00:00 /bin/bash
/usr/share/apache-ignite/bin/ignite.sh /etc/apache-ignite/default-config.xml
ignite 17157 1 1774292 323388 2 13:14 ? 00:00:39 /usr/bin/java
-Xms1g -Xmx1g -server -XX:+AggressiveOpts -XX:MaxMetaspaceSize=256m
-DIGNITE_QUIET=true -DIGNITE_SUCCESS_FILE=/usr/share/apache-ignit
root 55320 0 11864 3288 5 14:03 ?00:00:00 ps -AF
{noformat}
also, user ignite was not deleted
was (Author: mshonichev):
when user uninstalls package, the running service does not stop
{noformat}
yum remove apache-ignite
Loaded plugins: fastestmirror, ovl
Resolving Dependencies
--> Running transaction check
---> Package apache-ignite.noarch 0:2.5.0-1 will be erased
--> Finished Dependency Resolution
Dependencies Resolved
===
PackageArch
Version
Repository Size
===
Removing:
apache-ignite noarch
2.5.0-1
installed 277 M
Transaction Summary
===
Remove 1 Package
[jira] [Commented] (IGNITE-7108) Apache Ignite 2.5 RPM and DEB packages
[
https://issues.apache.org/jira/browse/IGNITE-7108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16448191#comment-16448191
]
Max Shonichev commented on IGNITE-7108:
---
when user uninstalls package, the running service does not stop
{noformat}
yum remove apache-ignite
Loaded plugins: fastestmirror, ovl
Resolving Dependencies
--> Running transaction check
---> Package apache-ignite.noarch 0:2.5.0-1 will be erased
--> Finished Dependency Resolution
Dependencies Resolved
===
PackageArch
Version
Repository Size
===
Removing:
apache-ignite noarch
2.5.0-1
installed 277 M
Transaction Summary
===
Remove 1 Package
Installed size: 277 M
Is this ok [y/N]: y
Downloading packages:
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
Warning: RPMDB altered outside of yum.
Erasing: apache-ignite-2.5.0-1.noarch
1/1
userdel: user ignite is currently used by process 57
removed '/var/run/apache-ignite/default-config.xml.pid'
removed directory: '/var/run/apache-ignite'
Verifying : apache-ignite-2.5.0-1.noarch
1/1
Removed:
apache-ignite.noarch 0:2.5.0-1
Complete!
[root@973e6de20f40 /]# ps -AF
UIDPID PPID CSZ RSS PSR STIME TTY TIME CMD
root 1 0 0 10702 4640 6 13:10 ?00:00:00 /usr/sbin/init
root18 1 0 9211 7212 1 13:10 ?00:00:00
/usr/lib/systemd/systemd-journald
root20 0 0 2946 3000 0 13:10 ?00:00:00 bash
ignite 57 1 0 3238 2980 4 13:14 ?00:00:00 /bin/bash
/usr/share/apache-ignite/bin/ignite.sh /etc/apache-ignite/default-config.xml
ignite 17157 1 1774292 323388 2 13:14 ? 00:00:39 /usr/bin/java
-Xms1g -Xmx1g -server -XX:+AggressiveOpts -XX:MaxMetaspaceSize=256m
-DIGNITE_QUIET=true -DIGNITE_SUCCESS_FILE=/usr/share/apache-ignit
root 55320 0 11864 3288 5 14:03 ?00:00:00 ps -AF
{noformat}
> Apache Ignite 2.5 RPM and DEB packages
> --
>
> Key: IGNITE-7108
> URL: https://issues.apache.org/jira/browse/IGNITE-7108
> Project: Ignite
> Issue Type: New Feature
> Components: binary
>Reporter: Peter Ivanov
>Assignee: Peter Ivanov
>Priority: Critical
> Labels: important
> Fix For: 2.5
>
>
> # (/) Update RPM build process to unify with DEB build.
> # (/) Prepare build of DEB package (using architecture and layout from RPM
> package).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-7108) Apache Ignite 2.5 RPM and DEB packages
[
https://issues.apache.org/jira/browse/IGNITE-7108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16445760#comment-16445760
]
Max Shonichev edited comment on IGNITE-7108 at 4/20/18 2:01 PM:
building ignite from sources with instructions from DEVNOTES.txt
{noformat}
JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64/ mvn clean install
-Pall-java,all-scala,licenses -DskipTests
JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64/ mvn initialize -Prelease
{noformat}
results in `apache-ignite-fabric-2.5.0-SNAPSHOT-bin.zip` in `target/bin`
directory.
however, moving this file around to `packaging` and running
{noformat}
./package.sh --rpm
{noformat}
again leads to 404 error.
renaming archive `apache-ignite-fabric-2.5.0-SNAPSHOT-bin.zip` to
`apache-ignite-fabric-2.5.0-bin.zip` and running
{noformat}
./package.sh --rpm
{noformat}
leads to
{noformat}
mkdir: created directory '/tmp/tmp.XVNElrwoAJ/BUILD'
mkdir: created directory '/tmp/tmp.XVNElrwoAJ/RPMS'
mkdir: created directory '/tmp/tmp.XVNElrwoAJ/SOURCES'
mkdir: created directory '/tmp/tmp.XVNElrwoAJ/SPECS'
mkdir: created directory '/tmp/tmp.XVNElrwoAJ/SRPMS'
'apache-ignite-fabric-2.5.0-bin.zip' ->
'/tmp/tmp.XVNElrwoAJ/SOURCES/apache-ignite-fabric-2.5.0-bin.zip'
'rpm/name.service' -> '/tmp/tmp.XVNElrwoAJ/SOURCES/name.service'
'rpm/service.sh' -> '/tmp/tmp.XVNElrwoAJ/SOURCES/service.sh'
'rpm/apache-ignite.spec' -> '/tmp/tmp.XVNElrwoAJ/SPECS/apache-ignite.spec'
Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.lgqIhD
+ umask 022
+ cd /tmp/tmp.XVNElrwoAJ/BUILD
+ cd /tmp/tmp.XVNElrwoAJ/BUILD
+ rm -rf apache-ignite-fabric-2.5.0-bin
+ /usr/bin/unzip -qq
/tmp/tmp.XVNElrwoAJ/SOURCES/apache-ignite-fabric-2.5.0-bin.zip
+ STATUS=0
+ [ 0 -ne 0 ]
+ cd apache-ignite-fabric-2.5.0-bin
/var/tmp/rpm-tmp.lgqIhD: 39: cd: can't cd to apache-ignite-fabric-2.5.0-bin
error: Bad exit status from /var/tmp/rpm-tmp.lgqIhD (%prep)
RPM build errors:
Bad exit status from /var/tmp/rpm-tmp.lgqIhD (%prep)
Removing temporary work directories: /tmp/tmp.XVNElrwoAJ
=== Run time: 0h:00m:03s ===
{noformat}
was (Author: mshonichev):
building ignite from sources with
{noformat}
JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64/ mvn clean install
-Pall-java,all-scala,licenses -DskipTests
JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64/ mvn initialize -Prelease
{noformat}
results in `apache-ignite-fabric-2.5.0-SNAPSHOT-bin.zip` in `target/bin`
directory.
however, moving this file around to `packaging` and running
{noformat}
./package.sh --rpm
{noformat}
again leads to 404 error.
renaming archive `apache-ignite-fabric-2.5.0-SNAPSHOT-bin.zip` to
`apache-ignite-fabric-2.5.0-bin.zip` and running
{noformat}
./package.sh --rpm
{noformat}
leads to
{noformat}
mkdir: created directory '/tmp/tmp.XVNElrwoAJ/BUILD'
mkdir: created directory '/tmp/tmp.XVNElrwoAJ/RPMS'
mkdir: created directory '/tmp/tmp.XVNElrwoAJ/SOURCES'
mkdir: created directory '/tmp/tmp.XVNElrwoAJ/SPECS'
mkdir: created directory '/tmp/tmp.XVNElrwoAJ/SRPMS'
'apache-ignite-fabric-2.5.0-bin.zip' ->
'/tmp/tmp.XVNElrwoAJ/SOURCES/apache-ignite-fabric-2.5.0-bin.zip'
'rpm/name.service' -> '/tmp/tmp.XVNElrwoAJ/SOURCES/name.service'
'rpm/service.sh' -> '/tmp/tmp.XVNElrwoAJ/SOURCES/service.sh'
'rpm/apache-ignite.spec' -> '/tmp/tmp.XVNElrwoAJ/SPECS/apache-ignite.spec'
Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.lgqIhD
+ umask 022
+ cd /tmp/tmp.XVNElrwoAJ/BUILD
+ cd /tmp/tmp.XVNElrwoAJ/BUILD
+ rm -rf apache-ignite-fabric-2.5.0-bin
+ /usr/bin/unzip -qq
/tmp/tmp.XVNElrwoAJ/SOURCES/apache-ignite-fabric-2.5.0-bin.zip
+ STATUS=0
+ [ 0 -ne 0 ]
+ cd apache-ignite-fabric-2.5.0-bin
/var/tmp/rpm-tmp.lgqIhD: 39: cd: can't cd to apache-ignite-fabric-2.5.0-bin
error: Bad exit status from /var/tmp/rpm-tmp.lgqIhD (%prep)
RPM build errors:
Bad exit status from /var/tmp/rpm-tmp.lgqIhD (%prep)
Removing temporary work directories: /tmp/tmp.XVNElrwoAJ
=== Run time: 0h:00m:03s ===
{noformat}
> Apache Ignite 2.5 RPM and DEB packages
> --
>
> Key: IGNITE-7108
> URL: https://issues.apache.org/jira/browse/IGNITE-7108
> Project: Ignite
> Issue Type: New Feature
> Components: binary
>Reporter: Peter Ivanov
>Assignee: Peter Ivanov
>Priority: Critical
> Labels: important
> Fix For: 2.5
>
>
> # (/) Update RPM build process to unify with DEB build.
> # (/) Prepare build of DEB package (using architecture and layout from RPM
> package).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-7108) Apache Ignite 2.5 RPM and DEB packages
[
https://issues.apache.org/jira/browse/IGNITE-7108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16445760#comment-16445760
]
Max Shonichev commented on IGNITE-7108:
---
building ignite from sources with
{noformat}
JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64/ mvn clean install
-Pall-java,all-scala,licenses -DskipTests
JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64/ mvn initialize -Prelease
{noformat}
results in `apache-ignite-fabric-2.5.0-SNAPSHOT-bin.zip` in `target/bin`
directory.
however, moving this file around to `packaging` and running
{noformat}
./package.sh --rpm
{noformat}
again leads to 404 error.
renaming archive `apache-ignite-fabric-2.5.0-SNAPSHOT-bin.zip` to
`apache-ignite-fabric-2.5.0-bin.zip` and running
{noformat}
./package.sh --rpm
{noformat}
leads to
{noformat}
mkdir: created directory '/tmp/tmp.XVNElrwoAJ/BUILD'
mkdir: created directory '/tmp/tmp.XVNElrwoAJ/RPMS'
mkdir: created directory '/tmp/tmp.XVNElrwoAJ/SOURCES'
mkdir: created directory '/tmp/tmp.XVNElrwoAJ/SPECS'
mkdir: created directory '/tmp/tmp.XVNElrwoAJ/SRPMS'
'apache-ignite-fabric-2.5.0-bin.zip' ->
'/tmp/tmp.XVNElrwoAJ/SOURCES/apache-ignite-fabric-2.5.0-bin.zip'
'rpm/name.service' -> '/tmp/tmp.XVNElrwoAJ/SOURCES/name.service'
'rpm/service.sh' -> '/tmp/tmp.XVNElrwoAJ/SOURCES/service.sh'
'rpm/apache-ignite.spec' -> '/tmp/tmp.XVNElrwoAJ/SPECS/apache-ignite.spec'
Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.lgqIhD
+ umask 022
+ cd /tmp/tmp.XVNElrwoAJ/BUILD
+ cd /tmp/tmp.XVNElrwoAJ/BUILD
+ rm -rf apache-ignite-fabric-2.5.0-bin
+ /usr/bin/unzip -qq
/tmp/tmp.XVNElrwoAJ/SOURCES/apache-ignite-fabric-2.5.0-bin.zip
+ STATUS=0
+ [ 0 -ne 0 ]
+ cd apache-ignite-fabric-2.5.0-bin
/var/tmp/rpm-tmp.lgqIhD: 39: cd: can't cd to apache-ignite-fabric-2.5.0-bin
error: Bad exit status from /var/tmp/rpm-tmp.lgqIhD (%prep)
RPM build errors:
Bad exit status from /var/tmp/rpm-tmp.lgqIhD (%prep)
Removing temporary work directories: /tmp/tmp.XVNElrwoAJ
=== Run time: 0h:00m:03s ===
{noformat}
> Apache Ignite 2.5 RPM and DEB packages
> --
>
> Key: IGNITE-7108
> URL: https://issues.apache.org/jira/browse/IGNITE-7108
> Project: Ignite
> Issue Type: New Feature
> Components: binary
>Reporter: Peter Ivanov
>Assignee: Peter Ivanov
>Priority: Critical
> Labels: important
> Fix For: 2.5
>
>
> # (/) Update RPM build process to unify with DEB build.
> # (/) Prepare build of DEB package (using architecture and layout from RPM
> package).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-7108) Apache Ignite 2.5 RPM and DEB packages
[
https://issues.apache.org/jira/browse/IGNITE-7108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16445732#comment-16445732
]
Max Shonichev edited comment on IGNITE-7108 at 4/20/18 1:37 PM:
running
{noformat}
./package.sh --rpm
{noformat}
leads to:
{noformat}
mkdir: created directory '/tmp/tmp.EHS5qfo623/BUILD'
mkdir: created directory '/tmp/tmp.EHS5qfo623/RPMS'
mkdir: created directory '/tmp/tmp.EHS5qfo623/SOURCES'
mkdir: created directory '/tmp/tmp.EHS5qfo623/SPECS'
mkdir: created directory '/tmp/tmp.EHS5qfo623/SRPMS'
'apache-ignite-fabric-2.5.0-bin.zip' ->
'/tmp/tmp.EHS5qfo623/SOURCES/apache-ignite-fabric-2.5.0-bin.zip'
'rpm/name.service' -> '/tmp/tmp.EHS5qfo623/SOURCES/name.service'
'rpm/service.sh' -> '/tmp/tmp.EHS5qfo623/SOURCES/service.sh'
'rpm/apache-ignite.spec' -> '/tmp/tmp.EHS5qfo623/SPECS/apache-ignite.spec'
Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.XkGvkv
+ umask 022
+ cd /tmp/tmp.EHS5qfo623/BUILD
+ cd /tmp/tmp.EHS5qfo623/BUILD
+ rm -rf apache-ignite-fabric-2.5.0-bin
+ /bin/tar -xf /tmp/tmp.EHS5qfo623/SOURCES/apache-ignite-fabric-2.5.0-bin.zip
/bin/tar: This does not look like a tar archive
/bin/tar: Exiting with failure status due to previous errors
error: Bad exit status from /var/tmp/rpm-tmp.XkGvkv (%prep)
RPM build errors:
Bad exit status from /var/tmp/rpm-tmp.XkGvkv (%prep)
Removing temporary work directories: /tmp/tmp.EHS5qfo623
=== Run time: 0h:00m:00s ===
{noformat}
due to file apache-ignite-fabric-2.5.0-bin.zip created even in case of 404
error from site with following contents:
{noformat}
404 Not Found
Not Found
The requested URL /dist/ignite/2.5.0/apache-ignite-fabric-2.5.0-bin.zip was
not found on this server.
{noformat}
was (Author: mshonichev):
running
{noformat}
./package.sh --rpm
{noformat}
twice, leads to:
{noformat}
mkdir: created directory '/tmp/tmp.EHS5qfo623/BUILD'
mkdir: created directory '/tmp/tmp.EHS5qfo623/RPMS'
mkdir: created directory '/tmp/tmp.EHS5qfo623/SOURCES'
mkdir: created directory '/tmp/tmp.EHS5qfo623/SPECS'
mkdir: created directory '/tmp/tmp.EHS5qfo623/SRPMS'
'apache-ignite-fabric-2.5.0-bin.zip' ->
'/tmp/tmp.EHS5qfo623/SOURCES/apache-ignite-fabric-2.5.0-bin.zip'
'rpm/name.service' -> '/tmp/tmp.EHS5qfo623/SOURCES/name.service'
'rpm/service.sh' -> '/tmp/tmp.EHS5qfo623/SOURCES/service.sh'
'rpm/apache-ignite.spec' -> '/tmp/tmp.EHS5qfo623/SPECS/apache-ignite.spec'
Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.XkGvkv
+ umask 022
+ cd /tmp/tmp.EHS5qfo623/BUILD
+ cd /tmp/tmp.EHS5qfo623/BUILD
+ rm -rf apache-ignite-fabric-2.5.0-bin
+ /bin/tar -xf /tmp/tmp.EHS5qfo623/SOURCES/apache-ignite-fabric-2.5.0-bin.zip
/bin/tar: This does not look like a tar archive
/bin/tar: Exiting with failure status due to previous errors
error: Bad exit status from /var/tmp/rpm-tmp.XkGvkv (%prep)
RPM build errors:
Bad exit status from /var/tmp/rpm-tmp.XkGvkv (%prep)
Removing temporary work directories: /tmp/tmp.EHS5qfo623
=== Run time: 0h:00m:00s ===
{noformat}
due to file apache-ignite-fabric-2.5.0-bin.zip created even in case of 404
error from site with following contents:
{noformat}
404 Not Found
Not Found
The requested URL /dist/ignite/2.5.0/apache-ignite-fabric-2.5.0-bin.zip was
not found on this server.
{noformat}
> Apache Ignite 2.5 RPM and DEB packages
> --
>
> Key: IGNITE-7108
> URL: https://issues.apache.org/jira/browse/IGNITE-7108
> Project: Ignite
> Issue Type: New Feature
> Components: binary
>Reporter: Peter Ivanov
>Assignee: Peter Ivanov
>Priority: Critical
> Labels: important
> Fix For: 2.5
>
>
> # (/) Update RPM build process to unify with DEB build.
> # (/) Prepare build of DEB package (using architecture and layout from RPM
> package).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-7108) Apache Ignite 2.5 RPM and DEB packages
[
https://issues.apache.org/jira/browse/IGNITE-7108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16445732#comment-16445732
]
Max Shonichev commented on IGNITE-7108:
---
running
{noformat}
./package.sh --rpm
{noformat}
twice, leads to:
{noformat}
mkdir: created directory '/tmp/tmp.EHS5qfo623/BUILD'
mkdir: created directory '/tmp/tmp.EHS5qfo623/RPMS'
mkdir: created directory '/tmp/tmp.EHS5qfo623/SOURCES'
mkdir: created directory '/tmp/tmp.EHS5qfo623/SPECS'
mkdir: created directory '/tmp/tmp.EHS5qfo623/SRPMS'
'apache-ignite-fabric-2.5.0-bin.zip' ->
'/tmp/tmp.EHS5qfo623/SOURCES/apache-ignite-fabric-2.5.0-bin.zip'
'rpm/name.service' -> '/tmp/tmp.EHS5qfo623/SOURCES/name.service'
'rpm/service.sh' -> '/tmp/tmp.EHS5qfo623/SOURCES/service.sh'
'rpm/apache-ignite.spec' -> '/tmp/tmp.EHS5qfo623/SPECS/apache-ignite.spec'
Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.XkGvkv
+ umask 022
+ cd /tmp/tmp.EHS5qfo623/BUILD
+ cd /tmp/tmp.EHS5qfo623/BUILD
+ rm -rf apache-ignite-fabric-2.5.0-bin
+ /bin/tar -xf /tmp/tmp.EHS5qfo623/SOURCES/apache-ignite-fabric-2.5.0-bin.zip
/bin/tar: This does not look like a tar archive
/bin/tar: Exiting with failure status due to previous errors
error: Bad exit status from /var/tmp/rpm-tmp.XkGvkv (%prep)
RPM build errors:
Bad exit status from /var/tmp/rpm-tmp.XkGvkv (%prep)
Removing temporary work directories: /tmp/tmp.EHS5qfo623
=== Run time: 0h:00m:00s ===
{noformat}
due to file apache-ignite-fabric-2.5.0-bin.zip created even in case of 404
error from site with following contents:
{noformat}
404 Not Found
Not Found
The requested URL /dist/ignite/2.5.0/apache-ignite-fabric-2.5.0-bin.zip was
not found on this server.
{noformat}
> Apache Ignite 2.5 RPM and DEB packages
> --
>
> Key: IGNITE-7108
> URL: https://issues.apache.org/jira/browse/IGNITE-7108
> Project: Ignite
> Issue Type: New Feature
> Components: binary
>Reporter: Peter Ivanov
>Assignee: Peter Ivanov
>Priority: Critical
> Labels: important
> Fix For: 2.5
>
>
> # (/) Update RPM build process to unify with DEB build.
> # (/) Prepare build of DEB package (using architecture and layout from RPM
> package).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-7108) Apache Ignite 2.5 RPM and DEB packages
[
https://issues.apache.org/jira/browse/IGNITE-7108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16445685#comment-16445685
]
Max Shonichev edited comment on IGNITE-7108 at 4/20/18 1:17 PM:
would you please add {noformat}-f (--force) {noformat} option to package.sh so
it would pass proper arguments to yum/apt it order to run unattented.
was (Author: mshonichev):
would you please add {noformat}-f (--force) {noformat} option to package.sh so
it could be run unattented, meaning that it should pass proper arguments to
yum/apt.
> Apache Ignite 2.5 RPM and DEB packages
> --
>
> Key: IGNITE-7108
> URL: https://issues.apache.org/jira/browse/IGNITE-7108
> Project: Ignite
> Issue Type: New Feature
> Components: binary
>Reporter: Peter Ivanov
>Assignee: Peter Ivanov
>Priority: Critical
> Labels: important
> Fix For: 2.5
>
>
> # (/) Update RPM build process to unify with DEB build.
> # (/) Prepare build of DEB package (using architecture and layout from RPM
> package).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-7108) Apache Ignite 2.5 RPM and DEB packages
[
https://issues.apache.org/jira/browse/IGNITE-7108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16445685#comment-16445685
]
Max Shonichev edited comment on IGNITE-7108 at 4/20/18 1:03 PM:
would you please add {noformat}-f (--force) {noformat} option to package.sh so
it could be run unattented, meaning that it should pass proper arguments to
yum/apt.
was (Author: mshonichev):
would you please add -f (--force) option to package.sh so it could be run
unattented.
> Apache Ignite 2.5 RPM and DEB packages
> --
>
> Key: IGNITE-7108
> URL: https://issues.apache.org/jira/browse/IGNITE-7108
> Project: Ignite
> Issue Type: New Feature
> Components: binary
>Reporter: Peter Ivanov
>Assignee: Peter Ivanov
>Priority: Critical
> Labels: important
> Fix For: 2.5
>
>
> # (/) Update RPM build process to unify with DEB build.
> # (/) Prepare build of DEB package (using architecture and layout from RPM
> package).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-7108) Apache Ignite 2.5 RPM and DEB packages
[ https://issues.apache.org/jira/browse/IGNITE-7108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16445685#comment-16445685 ] Max Shonichev commented on IGNITE-7108: --- would you please add -f (--force) option to package.sh so it could be run unattented. > Apache Ignite 2.5 RPM and DEB packages > -- > > Key: IGNITE-7108 > URL: https://issues.apache.org/jira/browse/IGNITE-7108 > Project: Ignite > Issue Type: New Feature > Components: binary >Reporter: Peter Ivanov >Assignee: Peter Ivanov >Priority: Critical > Labels: important > Fix For: 2.5 > > > # (/) Update RPM build process to unify with DEB build. > # (/) Prepare build of DEB package (using architecture and layout from RPM > package). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-7108) Apache Ignite 2.5 RPM and DEB packages
[
https://issues.apache.org/jira/browse/IGNITE-7108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16445672#comment-16445672
]
Max Shonichev edited comment on IGNITE-7108 at 4/20/18 12:48 PM:
-
{noformat}
# docker run -it -v $(readlink -f incubator-ignite):/mnt ubuntu bash
# apt-get update
# cd /mnt/packaging
# ./package.sh --rpm
{noformat}
fails with
{noformat}
[ERROR] Can't find | get Apache Ignite's binary archive
Removing temporary work directories:
=== Run time: 0h:00m:48s ===
{noformat}
would be nice to dump what exactly binary archive we could not find
was (Author: mshonichev):
{noformat}
# docker run -it -v $(readlink -f incubator-ignite):/mnt ubuntu bash
# apt-get update
# cd /mnt/packaging
# ./package.sh --rpm
{noformat}
fails with
{noformat}
[ERROR] Can't find | get Apache Ignite's binary archive
Removing temporary work directories:
=== Run time: 0h:00m:48s ===
{noformat}
> Apache Ignite 2.5 RPM and DEB packages
> --
>
> Key: IGNITE-7108
> URL: https://issues.apache.org/jira/browse/IGNITE-7108
> Project: Ignite
> Issue Type: New Feature
> Components: binary
>Reporter: Peter Ivanov
>Assignee: Peter Ivanov
>Priority: Critical
> Labels: important
> Fix For: 2.5
>
>
> # (/) Update RPM build process to unify with DEB build.
> # (/) Prepare build of DEB package (using architecture and layout from RPM
> package).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-7108) Apache Ignite 2.5 RPM and DEB packages
[
https://issues.apache.org/jira/browse/IGNITE-7108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16445672#comment-16445672
]
Max Shonichev edited comment on IGNITE-7108 at 4/20/18 12:47 PM:
-
{noformat}
# docker run -it -v $(readlink -f incubator-ignite):/mnt ubuntu bash
# apt-get update
# cd /mnt/packaging
# ./package.sh --rpm
{noformat}
fails with
{noformat}
[ERROR] Can't find | get Apache Ignite's binary archive
Removing temporary work directories:
=== Run time: 0h:00m:48s ===
{noformat}
was (Author: mshonichev):
{noformat}
# docker run -it -v $(readlink -f incubator-ignite):/mnt ubuntu bash
# apt-get update
# cd /mnt/packaging
# ./package.sh --rpm
{noformat}
> Apache Ignite 2.5 RPM and DEB packages
> --
>
> Key: IGNITE-7108
> URL: https://issues.apache.org/jira/browse/IGNITE-7108
> Project: Ignite
> Issue Type: New Feature
> Components: binary
>Reporter: Peter Ivanov
>Assignee: Peter Ivanov
>Priority: Critical
> Labels: important
> Fix For: 2.5
>
>
> # (/) Update RPM build process to unify with DEB build.
> # (/) Prepare build of DEB package (using architecture and layout from RPM
> package).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-7108) Apache Ignite 2.5 RPM and DEB packages
[
https://issues.apache.org/jira/browse/IGNITE-7108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16445672#comment-16445672
]
Max Shonichev edited comment on IGNITE-7108 at 4/20/18 12:43 PM:
-
{noformat}
# docker run -it -v $(readlink -f incubator-ignite):/mnt ubuntu bash
# apt-get update
# cd /mnt/packaging
# ./package.sh --rpm
{noformat}
was (Author: mshonichev):
{noformat}
# docker run -it -v $(readlink -f incubator-ignite):/mnt ubuntu bash
# cd /mnt/packaging
# ./package.sh --rpm
{noformat}
leads to
{noformat}
[INFO] Software installation required root privileges
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Unable to locate package unzip
E: Unable to locate package curl
E: Unable to locate package alien
E: Unable to locate package gcc
E: Unable to locate package rpm
Removing temporary work directories:
=== Run time: 0h:00m:00s ===
{noformat}
> Apache Ignite 2.5 RPM and DEB packages
> --
>
> Key: IGNITE-7108
> URL: https://issues.apache.org/jira/browse/IGNITE-7108
> Project: Ignite
> Issue Type: New Feature
> Components: binary
>Reporter: Peter Ivanov
>Assignee: Peter Ivanov
>Priority: Critical
> Labels: important
> Fix For: 2.5
>
>
> # (/) Update RPM build process to unify with DEB build.
> # (/) Prepare build of DEB package (using architecture and layout from RPM
> package).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-7108) Apache Ignite 2.5 RPM and DEB packages
[
https://issues.apache.org/jira/browse/IGNITE-7108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16445672#comment-16445672
]
Max Shonichev commented on IGNITE-7108:
---
{noformat}
# docker run -it -v $(readlink -f incubator-ignite):/mnt ubuntu bash
# cd /mnt/packaging
# ./package.sh --rpm
{noformat}
leads to
{noformat}
[INFO] Software installation required root privileges
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Unable to locate package unzip
E: Unable to locate package curl
E: Unable to locate package alien
E: Unable to locate package gcc
E: Unable to locate package rpm
Removing temporary work directories:
=== Run time: 0h:00m:00s ===
{noformat}
> Apache Ignite 2.5 RPM and DEB packages
> --
>
> Key: IGNITE-7108
> URL: https://issues.apache.org/jira/browse/IGNITE-7108
> Project: Ignite
> Issue Type: New Feature
> Components: binary
>Reporter: Peter Ivanov
>Assignee: Peter Ivanov
>Priority: Critical
> Labels: important
> Fix For: 2.5
>
>
> # (/) Update RPM build process to unify with DEB build.
> # (/) Prepare build of DEB package (using architecture and layout from RPM
> package).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8078) Add new metrics for data storage
[
https://issues.apache.org/jira/browse/IGNITE-8078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16442271#comment-16442271
]
Max Shonichev commented on IGNITE-8078:
---
[~dmagda] in current implementation, enabling metrics per-cache, instead of
per-cachegroup, when number of caches and partitions is high (4k/32k), simply
brings grid down, so IMO we really should move getRebalancingPartitionsCount()
out of CacheMetrics, because otherwise it is not suitable for production at all.
> Add new metrics for data storage
>
>
> Key: IGNITE-8078
> URL: https://issues.apache.org/jira/browse/IGNITE-8078
> Project: Ignite
> Issue Type: New Feature
>Reporter: Dmitriy Govorukhin
>Assignee: Dmitriy Govorukhin
>Priority: Major
> Labels: iep-6
> Fix For: 2.5
>
>
> 1. Add new metrics for data storage and cache group.
> {code}
> class CacheGroupMetricsMXBean{
> /** CacheGroup type. PARTITIONED, REPLICATED, LOCAL.*/
> String getType();
> /** Partitions currently assigned to the local node in this cache group. */
> int[] getPartitions();
> }
> {code}
> {code}
> class DataRegionMXBean{
> /** Total offheap size in bytes. */
> long getOffHeapSize();
> /** Total used offheap size in bytes for all data regions. */
> long getOffheapUsedSize();
> /** The number of read pages from last restart. */
> long getPagesRead();
> /** The number of writen pages from last restart. */
> long getPagesWriten();
> /** The number of replaced pages from last restart . */
> long getPagesReplaced();
> /** Total dirty pages for the next checkpoint. */
> long getDirtyPages();
> }
> {code}
> {code}
> class DataStorageMXbean{
> /** Total offheap size in bytes. */
> long getOffHeapSize();
> /** Total used offheap size in bytes for all data regions. */
> long getOffheapUsedSize();
> /** The number of read pages from last restart. */
> long getPagesRead();
> /** The number of writen pages from last restart. */
> long getPagesWriten();
> /** The number of replaced pages from last restart. */
> long getPagesReplaced();
> /** Total checkpoint time from last restart. */
> long getCheckpointTotalTime();
> /** Total dirty pages for the next checkpoint. */
> long getDirtyPages();
> /** Total size in bytes for storage wal files. */
> long getWalTotalSize();
> /** Time of the last WAL segment rollover. */
> long getWalLastRollOverTime();
> }
> {code}
> {code}
> class IgniteMxBean {
> /** Returns string containing Node ID, Consistent ID, Node Order */
> String getCurrentCoordinator();
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-8278) Nightly built package does not run
Max Shonichev created IGNITE-8278:
-
Summary: Nightly built package does not run
Key: IGNITE-8278
URL: https://issues.apache.org/jira/browse/IGNITE-8278
Project: Ignite
Issue Type: Bug
Reporter: Max Shonichev
Trying to run build from
http://172.25.1.150:8111/viewLog.html?buildId=1209266=Releases_NightlyRelease_RunApacheIgniteNightlyRelease=artifacts
results in error:
{noformat}
Exception in thread "main" java.lang.ExceptionInInitializerError
at
org.apache.ignite.startup.cmdline.CommandLineStartup.(CommandLineStartup.java:99)
Caused by: java.lang.IllegalStateException: Failed to parse version:
2.5.0.20180415-0
at
org.apache.ignite.lang.IgniteProductVersion.fromString(IgniteProductVersion.java:314)
at
org.apache.ignite.internal.IgniteVersionUtils.(IgniteVersionUtils.java:71)
{noformat}
Possibly this is due to empty build timestamp in ignite.properties.
{noformat}
ignite.version=2.5.0.20180415
ignite.build=0
ignite.revision=DEV
ignite.rel.date=15042018
ignite.update.status.params=ver=2.5.0.20180415=apache-ignite
ignite.update.notifier.enabled.by.default=true
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-7821) Unify and improve Apache Ignite and Web Console Dockerfiles
[ https://issues.apache.org/jira/browse/IGNITE-7821?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16439310#comment-16439310 ] Max Shonichev edited comment on IGNITE-7821 at 4/16/18 11:38 AM: - Overall, looks good, just add unpack step to the instruction. was (Author: mshonichev): Overall, looks good > Unify and improve Apache Ignite and Web Console Dockerfiles > --- > > Key: IGNITE-7821 > URL: https://issues.apache.org/jira/browse/IGNITE-7821 > Project: Ignite > Issue Type: Improvement >Reporter: Peter Ivanov >Assignee: Peter Ivanov >Priority: Critical > Fix For: 2.5 > > > # Unify approach to docker build -- add instructions about how to build > specific docker images from binaries . > # Change Apache Ignite's Dockerfile to get binaries from local build. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
