[jira] [Comment Edited] (IGNITE-8618) Support Java 10
[ https://issues.apache.org/jira/browse/IGNITE-8618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16517786#comment-16517786 ] José Andrés Peña Villalobos edited comment on IGNITE-8618 at 6/20/18 4:44 AM: -- Melan Jayasinghage therefore just commenting above lines will hack into get ignite to run on Java 10 platform? I'm going to try UPDATE: Yeah it bootstraps fine... was (Author: jose2883cr): Melan Jayasinghage therefore just commenting above lines will hack into get ignite to run on Java 10 platform? I'm going to try > Support Java 10 > --- > > Key: IGNITE-8618 > URL: https://issues.apache.org/jira/browse/IGNITE-8618 > Project: Ignite > Issue Type: Task >Affects Versions: 2.4 >Reporter: Anghel Botos >Priority: Major > > Please make required changes so that Ignite runs on Java 10. > The blocking issue I encontered is related to the usage of Unsafe: > Caused by: java.lang.RuntimeException: jdk.internal.misc.JavaNioAccess class > is unavailable. > at > org.apache.ignite.internal.util.GridUnsafe.javaNioAccessObject(GridUnsafe.java:1459) > at org.apache.ignite.internal.util.GridUnsafe.(GridUnsafe.java:118) > ... 30 more > Caused by: java.lang.IllegalAccessException: class > org.apache.ignite.internal.util.GridUnsafe cannot access class > jdk.internal.misc.SharedSecrets (in module java.base) because module > java.base does not export jdk.internal.misc to unnamed module @754ba872 > at > java.base/jdk.internal.reflect.Reflection.newIllegalAccessException(Reflection.java:360) > at > java.base/java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:589) > at java.base/java.lang.reflect.Method.invoke(Method.java:556) > at > org.apache.ignite.internal.util.GridUnsafe.javaNioAccessObject(GridUnsafe.java:1456) > ... 31 more > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-8618) Support Java 10
[ https://issues.apache.org/jira/browse/IGNITE-8618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16517786#comment-16517786 ] José Andrés Peña Villalobos edited comment on IGNITE-8618 at 6/20/18 4:25 AM: -- Melan Jayasinghage therefore just commenting above lines will hack into get ignite to run on Java 10 platform? I'm going to try was (Author: jose2883cr): Melan Jayasinghage therefore just commenting above lines will hack into get ignite to run on Java 10 platform? I'm going to try > Support Java 10 > --- > > Key: IGNITE-8618 > URL: https://issues.apache.org/jira/browse/IGNITE-8618 > Project: Ignite > Issue Type: Task >Affects Versions: 2.4 >Reporter: Anghel Botos >Priority: Major > > Please make required changes so that Ignite runs on Java 10. > The blocking issue I encontered is related to the usage of Unsafe: > Caused by: java.lang.RuntimeException: jdk.internal.misc.JavaNioAccess class > is unavailable. > at > org.apache.ignite.internal.util.GridUnsafe.javaNioAccessObject(GridUnsafe.java:1459) > at org.apache.ignite.internal.util.GridUnsafe.(GridUnsafe.java:118) > ... 30 more > Caused by: java.lang.IllegalAccessException: class > org.apache.ignite.internal.util.GridUnsafe cannot access class > jdk.internal.misc.SharedSecrets (in module java.base) because module > java.base does not export jdk.internal.misc to unnamed module @754ba872 > at > java.base/jdk.internal.reflect.Reflection.newIllegalAccessException(Reflection.java:360) > at > java.base/java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:589) > at java.base/java.lang.reflect.Method.invoke(Method.java:556) > at > org.apache.ignite.internal.util.GridUnsafe.javaNioAccessObject(GridUnsafe.java:1456) > ... 31 more > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-8618) Support Java 10
[ https://issues.apache.org/jira/browse/IGNITE-8618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16517786#comment-16517786 ] José Andrés Peña Villalobos edited comment on IGNITE-8618 at 6/20/18 4:25 AM: -- Melan Jayasinghage therefore just commenting above lines will hack into get ignite to run on Java 10 platform? I'm going to try was (Author: jose2883cr): Melan Jayasinghage therefore just commenting above lines will hack into get ignite to run on Java 10 platform? > Support Java 10 > --- > > Key: IGNITE-8618 > URL: https://issues.apache.org/jira/browse/IGNITE-8618 > Project: Ignite > Issue Type: Task >Affects Versions: 2.4 >Reporter: Anghel Botos >Priority: Major > > Please make required changes so that Ignite runs on Java 10. > The blocking issue I encontered is related to the usage of Unsafe: > Caused by: java.lang.RuntimeException: jdk.internal.misc.JavaNioAccess class > is unavailable. > at > org.apache.ignite.internal.util.GridUnsafe.javaNioAccessObject(GridUnsafe.java:1459) > at org.apache.ignite.internal.util.GridUnsafe.(GridUnsafe.java:118) > ... 30 more > Caused by: java.lang.IllegalAccessException: class > org.apache.ignite.internal.util.GridUnsafe cannot access class > jdk.internal.misc.SharedSecrets (in module java.base) because module > java.base does not export jdk.internal.misc to unnamed module @754ba872 > at > java.base/jdk.internal.reflect.Reflection.newIllegalAccessException(Reflection.java:360) > at > java.base/java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:589) > at java.base/java.lang.reflect.Method.invoke(Method.java:556) > at > org.apache.ignite.internal.util.GridUnsafe.javaNioAccessObject(GridUnsafe.java:1456) > ... 31 more > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8618) Support Java 10
[ https://issues.apache.org/jira/browse/IGNITE-8618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16517786#comment-16517786 ] José Andrés Peña Villalobos commented on IGNITE-8618: - Melan Jayasinghage therefore just commenting above lines will hack into get ignite to run on Java 10 platform? > Support Java 10 > --- > > Key: IGNITE-8618 > URL: https://issues.apache.org/jira/browse/IGNITE-8618 > Project: Ignite > Issue Type: Task >Affects Versions: 2.4 >Reporter: Anghel Botos >Priority: Major > > Please make required changes so that Ignite runs on Java 10. > The blocking issue I encontered is related to the usage of Unsafe: > Caused by: java.lang.RuntimeException: jdk.internal.misc.JavaNioAccess class > is unavailable. > at > org.apache.ignite.internal.util.GridUnsafe.javaNioAccessObject(GridUnsafe.java:1459) > at org.apache.ignite.internal.util.GridUnsafe.(GridUnsafe.java:118) > ... 30 more > Caused by: java.lang.IllegalAccessException: class > org.apache.ignite.internal.util.GridUnsafe cannot access class > jdk.internal.misc.SharedSecrets (in module java.base) because module > java.base does not export jdk.internal.misc to unnamed module @754ba872 > at > java.base/jdk.internal.reflect.Reflection.newIllegalAccessException(Reflection.java:360) > at > java.base/java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:589) > at java.base/java.lang.reflect.Method.invoke(Method.java:556) > at > org.apache.ignite.internal.util.GridUnsafe.javaNioAccessObject(GridUnsafe.java:1456) > ... 31 more > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8618) Support Java 10
[
https://issues.apache.org/jira/browse/IGNITE-8618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16517727#comment-16517727
]
Melan Jayasinghage commented on IGNITE-8618:
[~jose2883cr] I believe ignite having compatibility with Java 10, but prechecks
on bin/ignite.sh, bin/include/functions.sh prevents us to running it on Java 10
and modifying them should work, I've tested this on Linux environment (yes,
it's shows same warning on both Java 9 and 10 )
bin/ignite.sh - line 154-161
{code:java}
${JAVA_HOME}/bin/java -version 2>&1 | grep -qE 'java version "(9|10).*"' && {
JVM_OPTS="--add-exports java.base/jdk.internal.misc=ALL-UNNAMED \
--add-exports java.base/sun.nio.ch=ALL-UNNAMED \
--add-exports java.management/com.sun.jmx.mbeanserver=ALL-UNNAMED \
--add-exports jdk.internal.jvmstat/sun.jvmstat.monitor=ALL-UNNAMED \
--add-modules java.xml.bind \
${JVM_OPTS}"
} || true
{code}
bin/include/functions.sh - line 61 - 72
{code:java}
"$JAVA" -version 2>&1 | grep -qE 'version "(1.8.*|9.*|10.*)"' || {
echo "$0, ERROR:"
echo "The version of JAVA installed in JAVA_HOME=$JAVA_HOME is
incorrect."
echo "Please point JAVA_HOME variable to installation of JDK 1.8, JDK 9
or JDK 10."
echo "You can also download latest JDK at http://java.com/download;
exit 1
}
{code}
> Support Java 10
> ---
>
> Key: IGNITE-8618
> URL: https://issues.apache.org/jira/browse/IGNITE-8618
> Project: Ignite
> Issue Type: Task
>Affects Versions: 2.4
>Reporter: Anghel Botos
>Priority: Major
>
> Please make required changes so that Ignite runs on Java 10.
> The blocking issue I encontered is related to the usage of Unsafe:
> Caused by: java.lang.RuntimeException: jdk.internal.misc.JavaNioAccess class
> is unavailable.
> at
> org.apache.ignite.internal.util.GridUnsafe.javaNioAccessObject(GridUnsafe.java:1459)
> at org.apache.ignite.internal.util.GridUnsafe.(GridUnsafe.java:118)
> ... 30 more
> Caused by: java.lang.IllegalAccessException: class
> org.apache.ignite.internal.util.GridUnsafe cannot access class
> jdk.internal.misc.SharedSecrets (in module java.base) because module
> java.base does not export jdk.internal.misc to unnamed module @754ba872
> at
> java.base/jdk.internal.reflect.Reflection.newIllegalAccessException(Reflection.java:360)
> at
> java.base/java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:589)
> at java.base/java.lang.reflect.Method.invoke(Method.java:556)
> at
> org.apache.ignite.internal.util.GridUnsafe.javaNioAccessObject(GridUnsafe.java:1456)
> ... 31 more
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8617) Node Discovery Using AWS Application ELB
[ https://issues.apache.org/jira/browse/IGNITE-8617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16517636#comment-16517636 ] Denis Magda commented on IGNITE-8617: - [~dpavlov], could you help with the review? I'm pretty busy this week and throughout the beginning of the next one. > Node Discovery Using AWS Application ELB > > > Key: IGNITE-8617 > URL: https://issues.apache.org/jira/browse/IGNITE-8617 > Project: Ignite > Issue Type: New Feature > Components: aws >Reporter: Uday Kale >Priority: Major > > Support for Node discovery using AWS Application ELB. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-8617) Node Discovery Using AWS Application ELB
[ https://issues.apache.org/jira/browse/IGNITE-8617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda reassigned IGNITE-8617: --- Assignee: Dmitriy Pavlov > Node Discovery Using AWS Application ELB > > > Key: IGNITE-8617 > URL: https://issues.apache.org/jira/browse/IGNITE-8617 > Project: Ignite > Issue Type: New Feature > Components: aws >Reporter: Uday Kale >Assignee: Dmitriy Pavlov >Priority: Major > > Support for Node discovery using AWS Application ELB. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-8618) Support Java 10
[ https://issues.apache.org/jira/browse/IGNITE-8618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16517626#comment-16517626 ] José Andrés Peña Villalobos edited comment on IGNITE-8618 at 6/19/18 11:25 PM: --- I created an question in stackoverflow about the support of Java 10 by Ignite not sure if this was already addressed: [https://stackoverflow.com/questions/50938116/apache-ignite-2-5-0-java-10-compatibility-on-mac] I have setup my *JAVA_HOME* environment variable by *$HOME/.profile* this way: *export JAVA_HOME="$(/usr/libexec/java_home)"* Downloaded the release *apache-ignite-fabric-2.5.0-bin.zip* Checking environment: josepens-mbp:bin josepen$ echo $JAVA_HOME */Library/Java/JavaVirtualMachines/jdk-10.0.1.jdk/Contents/Home* josepens-mbp:bin josepen$ $JAVA_HOME/bin/java --version *java 10.0.1 2018-04-17* *Java(TM) SE Runtime Environment 18.3 (build 10.0.1+10)* *Java HotSpot(TM) 64-Bit Server VM 18.3 (build 10.0.1+10, mixed mode)* Everything seems fine, however when running bin/.ignite.sh get the following error: josepens-mbp:bin josepen$ ./ignite.sh *./ignite.sh, ERROR: The version of JAVA installed in JAVA_HOME=/Library/Java/JavaVirtualMachines/jdk-10.0.1.jdk/Contents/Home is incorrect. Please point JAVA_HOME variable to installation of JDK 1.8 or JDK 9.* *You can also download latest JDK at [http://java.com/download]* Is Ignite compatible with Java 10? Thanks. was (Author: jose2883cr): I created an question in stackoverflow about the support of Java 10 by Ignite not sure if this was already addressed: [https://stackoverflow.com/questions/50938116/apache-ignite-2-5-0-java-10-compatibility-on-mac] I have setup my *JAVA_HOME* environment variable by *$HOME/.profile* this way: *export JAVA_HOME="$(/usr/libexec/java_home)"* Downloaded the release *apache-ignite-fabric-2.5.0-bin.zip* Checking environment: josepens-mbp:bin josepen$ echo $JAVA_HOME */Library/Java/JavaVirtualMachines/jdk-10.0.1.jdk/Contents/Home* josepens-mbp:bin josepen$ $JAVA_HOME/bin/java --version *java 10.0.1 2018-04-17* *Java(TM) SE Runtime Environment 18.3 (build 10.0.1+10)* *Java HotSpot(TM) 64-Bit Server VM 18.3 (build 10.0.1+10, mixed mode)* Everything seems fine, however when running bin/.ignite.sh get the following error: josepens-mbp:bin josepen$ ./ignite.sh *./ignite.sh, ERROR: The version of JAVA installed in JAVA_HOME=/Library/Java/JavaVirtualMachines/jdk-10.0.1.jdk/Contents/Home is incorrect. Please point JAVA_HOME variable to installation of JDK 1.8 or JDK 9.* *You can also download latest JDK at [http://java.com/download]* Is Ignite compatible with Java 10? Thanks. > Support Java 10 > --- > > Key: IGNITE-8618 > URL: https://issues.apache.org/jira/browse/IGNITE-8618 > Project: Ignite > Issue Type: Task >Affects Versions: 2.4 >Reporter: Anghel Botos >Priority: Major > > Please make required changes so that Ignite runs on Java 10. > The blocking issue I encontered is related to the usage of Unsafe: > Caused by: java.lang.RuntimeException: jdk.internal.misc.JavaNioAccess class > is unavailable. > at > org.apache.ignite.internal.util.GridUnsafe.javaNioAccessObject(GridUnsafe.java:1459) > at org.apache.ignite.internal.util.GridUnsafe.(GridUnsafe.java:118) > ... 30 more > Caused by: java.lang.IllegalAccessException: class > org.apache.ignite.internal.util.GridUnsafe cannot access class > jdk.internal.misc.SharedSecrets (in module java.base) because module > java.base does not export jdk.internal.misc to unnamed module @754ba872 > at > java.base/jdk.internal.reflect.Reflection.newIllegalAccessException(Reflection.java:360) > at > java.base/java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:589) > at java.base/java.lang.reflect.Method.invoke(Method.java:556) > at > org.apache.ignite.internal.util.GridUnsafe.javaNioAccessObject(GridUnsafe.java:1456) > ... 31 more > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-8618) Support Java 10
[ https://issues.apache.org/jira/browse/IGNITE-8618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16517626#comment-16517626 ] José Andrés Peña Villalobos edited comment on IGNITE-8618 at 6/19/18 11:24 PM: --- I created an question in stackoverflow about the support of Java 10 by Ignite not sure if this was already addressed: [https://stackoverflow.com/questions/50938116/apache-ignite-2-5-0-java-10-compatibility-on-mac] I have setup my *JAVA_HOME* environment variable by *$HOME/.profile* this way: *export JAVA_HOME="$(/usr/libexec/java_home)"* Downloaded the release *apache-ignite-fabric-2.5.0-bin.zip* Checking environment: josepens-mbp:bin josepen$ echo $JAVA_HOME */Library/Java/JavaVirtualMachines/jdk-10.0.1.jdk/Contents/Home* josepens-mbp:bin josepen$ $JAVA_HOME/bin/java --version *java 10.0.1 2018-04-17* *Java(TM) SE Runtime Environment 18.3 (build 10.0.1+10)* *Java HotSpot(TM) 64-Bit Server VM 18.3 (build 10.0.1+10, mixed mode)* Everything seems fine, however when running bin/.ignite.sh get the following error: josepens-mbp:bin josepen$ ./ignite.sh *./ignite.sh, ERROR: The version of JAVA installed in JAVA_HOME=/Library/Java/JavaVirtualMachines/jdk-10.0.1.jdk/Contents/Home is incorrect. Please point JAVA_HOME variable to installation of JDK 1.8 or JDK 9.* *You can also download latest JDK at [http://java.com/download]* Is Ignite compatible with Java 10? Thanks. was (Author: jose2883cr): I created an question in stackoverflow about the support of Java 10 by Ignite not sure if this was already addressed: [https://stackoverflow.com/questions/50938116/apache-ignite-2-5-0-java-10-compatibility-on-mac] 0down vote [favorite|https://stackoverflow.com/questions/50938116/apache-ignite-2-5-0-java-10-compatibility-on-mac] I have setup my *JAVA_HOME* environment variable by *$HOME/.profile* this way: *export JAVA_HOME="$(/usr/libexec/java_home)"* Downloaded the release *apache-ignite-fabric-2.5.0-bin.zip* Checking environment: josepens-mbp:bin josepen$ echo $JAVA_HOME */Library/Java/JavaVirtualMachines/jdk-10.0.1.jdk/Contents/Home* josepens-mbp:bin josepen$ $JAVA_HOME/bin/java --version *java 10.0.1 2018-04-17* *Java(TM) SE Runtime Environment 18.3 (build 10.0.1+10)* *Java HotSpot(TM) 64-Bit Server VM 18.3 (build 10.0.1+10, mixed mode)* Everything seems fine, however when running bin/.ignite.sh get the following error: josepens-mbp:bin josepen$ ./ignite.sh *./ignite.sh, ERROR: The version of JAVA installed in JAVA_HOME=/Library/Java/JavaVirtualMachines/jdk-10.0.1.jdk/Contents/Home is incorrect. Please point JAVA_HOME variable to installation of JDK 1.8 or JDK 9.* *You can also download latest JDK at [http://java.com/download]* Is Ignite compatible with Java 10? Thanks. > Support Java 10 > --- > > Key: IGNITE-8618 > URL: https://issues.apache.org/jira/browse/IGNITE-8618 > Project: Ignite > Issue Type: Task >Affects Versions: 2.4 >Reporter: Anghel Botos >Priority: Major > > Please make required changes so that Ignite runs on Java 10. > The blocking issue I encontered is related to the usage of Unsafe: > Caused by: java.lang.RuntimeException: jdk.internal.misc.JavaNioAccess class > is unavailable. > at > org.apache.ignite.internal.util.GridUnsafe.javaNioAccessObject(GridUnsafe.java:1459) > at org.apache.ignite.internal.util.GridUnsafe.(GridUnsafe.java:118) > ... 30 more > Caused by: java.lang.IllegalAccessException: class > org.apache.ignite.internal.util.GridUnsafe cannot access class > jdk.internal.misc.SharedSecrets (in module java.base) because module > java.base does not export jdk.internal.misc to unnamed module @754ba872 > at > java.base/jdk.internal.reflect.Reflection.newIllegalAccessException(Reflection.java:360) > at > java.base/java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:589) > at java.base/java.lang.reflect.Method.invoke(Method.java:556) > at > org.apache.ignite.internal.util.GridUnsafe.javaNioAccessObject(GridUnsafe.java:1456) > ... 31 more > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8618) Support Java 10
[ https://issues.apache.org/jira/browse/IGNITE-8618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16517626#comment-16517626 ] José Andrés Peña Villalobos commented on IGNITE-8618: - I created an question in stackoverflow about the support of Java 10 by Ignite not sure if this was already addressed: [https://stackoverflow.com/questions/50938116/apache-ignite-2-5-0-java-10-compatibility-on-mac] 0down vote [favorite|https://stackoverflow.com/questions/50938116/apache-ignite-2-5-0-java-10-compatibility-on-mac] I have setup my *JAVA_HOME* environment variable by *$HOME/.profile* this way: *export JAVA_HOME="$(/usr/libexec/java_home)"* Downloaded the release *apache-ignite-fabric-2.5.0-bin.zip* Checking environment: josepens-mbp:bin josepen$ echo $JAVA_HOME */Library/Java/JavaVirtualMachines/jdk-10.0.1.jdk/Contents/Home* josepens-mbp:bin josepen$ $JAVA_HOME/bin/java --version *java 10.0.1 2018-04-17* *Java(TM) SE Runtime Environment 18.3 (build 10.0.1+10)* *Java HotSpot(TM) 64-Bit Server VM 18.3 (build 10.0.1+10, mixed mode)* Everything seems fine, however when running bin/.ignite.sh get the following error: josepens-mbp:bin josepen$ ./ignite.sh *./ignite.sh, ERROR: The version of JAVA installed in JAVA_HOME=/Library/Java/JavaVirtualMachines/jdk-10.0.1.jdk/Contents/Home is incorrect. Please point JAVA_HOME variable to installation of JDK 1.8 or JDK 9.* *You can also download latest JDK at [http://java.com/download]* Is Ignite compatible with Java 10? Thanks. > Support Java 10 > --- > > Key: IGNITE-8618 > URL: https://issues.apache.org/jira/browse/IGNITE-8618 > Project: Ignite > Issue Type: Task >Affects Versions: 2.4 >Reporter: Anghel Botos >Priority: Major > > Please make required changes so that Ignite runs on Java 10. > The blocking issue I encontered is related to the usage of Unsafe: > Caused by: java.lang.RuntimeException: jdk.internal.misc.JavaNioAccess class > is unavailable. > at > org.apache.ignite.internal.util.GridUnsafe.javaNioAccessObject(GridUnsafe.java:1459) > at org.apache.ignite.internal.util.GridUnsafe.(GridUnsafe.java:118) > ... 30 more > Caused by: java.lang.IllegalAccessException: class > org.apache.ignite.internal.util.GridUnsafe cannot access class > jdk.internal.misc.SharedSecrets (in module java.base) because module > java.base does not export jdk.internal.misc to unnamed module @754ba872 > at > java.base/jdk.internal.reflect.Reflection.newIllegalAccessException(Reflection.java:360) > at > java.base/java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:589) > at java.base/java.lang.reflect.Method.invoke(Method.java:556) > at > org.apache.ignite.internal.util.GridUnsafe.javaNioAccessObject(GridUnsafe.java:1456) > ... 31 more > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-1260) S3 IP finder should have an option to use a subfolder instead of bucket root
[ https://issues.apache.org/jira/browse/IGNITE-1260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16517613#comment-16517613 ] Denis Magda commented on IGNITE-1260: - [~uday], have you updated the pull-request? When I click on the link of the one at the top of the discussion I see 12 days old changes. > S3 IP finder should have an option to use a subfolder instead of bucket root > > > Key: IGNITE-1260 > URL: https://issues.apache.org/jira/browse/IGNITE-1260 > Project: Ignite > Issue Type: Improvement > Components: general >Affects Versions: 1.1.4 >Reporter: Valentin Kulichenko >Priority: Minor > Labels: newbie, usability, user-request > > Current implementation forces user to use the bucket root which is not always > possible. Need to provide a configuration parameter that allows to provide a > path in addition to the bucket name. > Corresponding user@ thread: > http://apache-ignite-users.70518.x6.nabble.com/AWS-Integration-td495.html -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8808) Improve control.sh --tx command to show local and remote transactions.
[ https://issues.apache.org/jira/browse/IGNITE-8808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16517333#comment-16517333 ] ASF GitHub Bot commented on IGNITE-8808: Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/4209 > Improve control.sh --tx command to show local and remote transactions. > -- > > Key: IGNITE-8808 > URL: https://issues.apache.org/jira/browse/IGNITE-8808 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.5 >Reporter: Alexei Scherbakov >Assignee: Alexei Scherbakov >Priority: Major > Fix For: 2.6 > > > Currently --tx option for control.sh shows only transactions found on > near(initiating) nodes. > Due to various issues it's possible to have corresponding dht local and > remote transaction without near part. > Such transactions must be visible to utility. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-8699) ZookeeperDiscoverySpiTest#testDisconnectOnServersLeft flaky fails (rarely)
[
https://issues.apache.org/jira/browse/IGNITE-8699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16517297#comment-16517297
]
Vitaliy Biryukov edited comment on IGNITE-8699 at 6/19/18 4:48 PM:
---
Hi, [~sergey-chugunov] Please take a look.
This test falls for two reasons:
1) If node fail event occurs before local join, *DiscoveryWorker* hangs.
2) If all servers left cluster oldest client notifies all clients. Oldest
client receives events data and adds *ZkNoServersMessage*. If new events are
added at this time, the events data version will change and cause
*BadVersionException*.
was (Author: vitaliyb):
Hi, [~sergey-chugunov] Please take a look.
This test falls for two reasons:
1) If node fail event occurs before local join, DiscoveryWorker hangs.
2) If all servers left cluster oldest client notifies all clients. Oldest
client receives events data and adds *ZkNoServersMessage*. If new events are
added at this time, the events data version will change and cause
BadVersionException.
> ZookeeperDiscoverySpiTest#testDisconnectOnServersLeft flaky fails (rarely)
> --
>
> Key: IGNITE-8699
> URL: https://issues.apache.org/jira/browse/IGNITE-8699
> Project: Ignite
> Issue Type: Bug
>Reporter: Vitaliy Biryukov
>Assignee: Vitaliy Biryukov
>Priority: Major
> Labels: MakeTeamcityGreenAgain
>
> *Affected tests:*
> testDisconnectOnServersLeft_1
> testDisconnectOnServersLeft_2
> testDisconnectOnServersLeft_3
> testDisconnectOnServersLeft_4
> testDisconnectOnServersLeft_5
> {noformat}
> junit.framework.AssertionFailedError: Failed to wait for disconnect/reconnect
> event.
> at junit.framework.Assert.fail(Assert.java:57)
> at junit.framework.TestCase.fail(TestCase.java:227)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.waitReconnectEvent(ZookeeperDiscoverySpiTest.java:4685)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.disconnectOnServersLeft(ZookeeperDiscoverySpiTest.java:3541)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.testDisconnectOnServersLeft_4(ZookeeperDiscoverySpiTest.java:3476)
> 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 junit.framework.TestCase.runTest(TestCase.java:176)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2086)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:140)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:2001)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-8808) Improve control.sh --tx command to show local and remote transactions.
[ https://issues.apache.org/jira/browse/IGNITE-8808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16517294#comment-16517294 ] Alexei Scherbakov edited comment on IGNITE-8808 at 6/19/18 4:48 PM: Conflicts has appeared after merging of new tickets related to utility. Fixed. was (Author: ascherbakov): Conflicts do appear after merging of new tickets related to utility. Fixed. > Improve control.sh --tx command to show local and remote transactions. > -- > > Key: IGNITE-8808 > URL: https://issues.apache.org/jira/browse/IGNITE-8808 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.5 >Reporter: Alexei Scherbakov >Assignee: Alexei Scherbakov >Priority: Major > Fix For: 2.6 > > > Currently --tx option for control.sh shows only transactions found on > near(initiating) nodes. > Due to various issues it's possible to have corresponding dht local and > remote transaction without near part. > Such transactions must be visible to utility. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8808) Improve control.sh --tx command to show local and remote transactions.
[ https://issues.apache.org/jira/browse/IGNITE-8808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16517294#comment-16517294 ] Alexei Scherbakov commented on IGNITE-8808: --- Conflicts do appear after merging of new tickets related to utility. Fixed. > Improve control.sh --tx command to show local and remote transactions. > -- > > Key: IGNITE-8808 > URL: https://issues.apache.org/jira/browse/IGNITE-8808 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.5 >Reporter: Alexei Scherbakov >Assignee: Alexei Scherbakov >Priority: Major > Fix For: 2.6 > > > Currently --tx option for control.sh shows only transactions found on > near(initiating) nodes. > Due to various issues it's possible to have corresponding dht local and > remote transaction without near part. > Such transactions must be visible to utility. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8834) SqlQuery not throwing exception after partition loss events
[
https://issues.apache.org/jira/browse/IGNITE-8834?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton Kurbanov updated IGNITE-8834:
---
Affects Version/s: 2.5
> SqlQuery not throwing exception after partition loss events
> ---
>
> Key: IGNITE-8834
> URL: https://issues.apache.org/jira/browse/IGNITE-8834
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.4, 2.5
>Reporter: Anton Kurbanov
>Priority: Major
>
>
> Precondition: 3 server nodes, client listening for partition loss events,
> partitioned cache with backups = 1, partition loss policy = READ_ONLY_SAFE,
> stream some data. Kill 2 nodes, call:
> {code:java}
> SqlQuery query = new SqlQuery<>(Integer.class, "where
> _key>0");
> query.setLocal(false);
> List> list = cache.query(query).getAll();
> {code}
> Cache configuration:
> {code:java}
> public IgniteConfiguration getCfg() {
> IgniteConfiguration cfg = new IgniteConfiguration();
> cfg.setConsistentId(cfg.getIgniteInstanceName());
> cfg.setIncludeEventTypes(EventType.EVT_CACHE_REBALANCE_PART_DATA_LOST);
> TcpDiscoverySpi discovery = new TcpDiscoverySpi();
> TcpDiscoveryVmIpFinder finder = new TcpDiscoveryVmIpFinder();
> finder.setAddresses(Arrays.asList("127.0.0.1:47500..47509"));
> discovery.setIpFinder(finder);
> cfg.setDiscoverySpi(discovery);
> QueryEntity queryEntity = new QueryEntity();
> queryEntity.setKeyType(Integer.class.getName());
> queryEntity.setValueType(Integer.class.getName());
> cfg.setCacheConfiguration(new CacheConfiguration(CACHE)
> .setCacheMode(CacheMode.PARTITIONED)
> .setBackups(1)
> .setAffinity(new RendezvousAffinityFunction())
> .setWriteSynchronizationMode(CacheWriteSynchronizationMode.FULL_SYNC)
> .setPartitionLossPolicy(PartitionLossPolicy.READ_ONLY_SAFE)
> .setQueryEntities(Collections.singletonList(queryEntity)));
> DataStorageConfiguration storageCfg = new DataStorageConfiguration();
>
> storageCfg.getDefaultDataRegionConfiguration().setPersistenceEnabled(true);
> cfg.setDataStorageConfiguration(storageCfg);
> return cfg;
> }
> {code}
> Query is expected to fail, but succeeds and returns entries from partitions
> that are alive.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-8699) ZookeeperDiscoverySpiTest#testDisconnectOnServersLeft flaky fails (rarely)
[
https://issues.apache.org/jira/browse/IGNITE-8699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vitaliy Biryukov updated IGNITE-8699:
-
Description:
*Affected tests:*
testDisconnectOnServersLeft_1
testDisconnectOnServersLeft_2
testDisconnectOnServersLeft_3
testDisconnectOnServersLeft_4
testDisconnectOnServersLeft_5
{noformat}
junit.framework.AssertionFailedError: Failed to wait for disconnect/reconnect
event.
at junit.framework.Assert.fail(Assert.java:57)
at junit.framework.TestCase.fail(TestCase.java:227)
at
org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.waitReconnectEvent(ZookeeperDiscoverySpiTest.java:4685)
at
org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.disconnectOnServersLeft(ZookeeperDiscoverySpiTest.java:3541)
at
org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.testDisconnectOnServersLeft_4(ZookeeperDiscoverySpiTest.java:3476)
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 junit.framework.TestCase.runTest(TestCase.java:176)
at
org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2086)
at
org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:140)
at
org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:2001)
at java.lang.Thread.run(Thread.java:748)
{noformat}
was:
*Affected tests:*
testDisconnectOnServersLeft_1
testDisconnectOnServersLeft_2
testDisconnectOnServersLeft_3
testDisconnectOnServersLeft_4
testDisconnectOnServersLeft_5
*Causes:*
* Sometimes client nodes don't have time to join the topology.
* Sometimes starts communication failure resolver and wait for server nodes.
> ZookeeperDiscoverySpiTest#testDisconnectOnServersLeft flaky fails (rarely)
> --
>
> Key: IGNITE-8699
> URL: https://issues.apache.org/jira/browse/IGNITE-8699
> Project: Ignite
> Issue Type: Bug
>Reporter: Vitaliy Biryukov
>Assignee: Vitaliy Biryukov
>Priority: Major
> Labels: MakeTeamcityGreenAgain
>
> *Affected tests:*
> testDisconnectOnServersLeft_1
> testDisconnectOnServersLeft_2
> testDisconnectOnServersLeft_3
> testDisconnectOnServersLeft_4
> testDisconnectOnServersLeft_5
> {noformat}
> junit.framework.AssertionFailedError: Failed to wait for disconnect/reconnect
> event.
> at junit.framework.Assert.fail(Assert.java:57)
> at junit.framework.TestCase.fail(TestCase.java:227)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.waitReconnectEvent(ZookeeperDiscoverySpiTest.java:4685)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.disconnectOnServersLeft(ZookeeperDiscoverySpiTest.java:3541)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.testDisconnectOnServersLeft_4(ZookeeperDiscoverySpiTest.java:3476)
> 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 junit.framework.TestCase.runTest(TestCase.java:176)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2086)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:140)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:2001)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8808) Improve control.sh --tx command to show local and remote transactions.
[ https://issues.apache.org/jira/browse/IGNITE-8808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16517258#comment-16517258 ] Ivan Rakov commented on IGNITE-8808: Please resolve conflicts between PR branch and master. > Improve control.sh --tx command to show local and remote transactions. > -- > > Key: IGNITE-8808 > URL: https://issues.apache.org/jira/browse/IGNITE-8808 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.5 >Reporter: Alexei Scherbakov >Assignee: Alexei Scherbakov >Priority: Major > Fix For: 2.6 > > > Currently --tx option for control.sh shows only transactions found on > near(initiating) nodes. > Due to various issues it's possible to have corresponding dht local and > remote transaction without near part. > Such transactions must be visible to utility. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8554) Cache metrics: expose metrics with rebalance info about keys
[ https://issues.apache.org/jira/browse/IGNITE-8554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16517229#comment-16517229 ] ASF GitHub Bot commented on IGNITE-8554: Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/4094 > Cache metrics: expose metrics with rebalance info about keys > > > Key: IGNITE-8554 > URL: https://issues.apache.org/jira/browse/IGNITE-8554 > Project: Ignite > Issue Type: Improvement > Components: cache >Reporter: Alexey Kuznetsov >Assignee: Ilya Lantukh >Priority: Major > Fix For: 2.6 > > > In order to show info about rebalance progress we need to expose > estimatedRebalancingKeys and rebalancedKeys metrics. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8554) Cache metrics: expose metrics with rebalance info about keys
[ https://issues.apache.org/jira/browse/IGNITE-8554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16517227#comment-16517227 ] Ivan Rakov commented on IGNITE-8554: Merged to master. > Cache metrics: expose metrics with rebalance info about keys > > > Key: IGNITE-8554 > URL: https://issues.apache.org/jira/browse/IGNITE-8554 > Project: Ignite > Issue Type: Improvement > Components: cache >Reporter: Alexey Kuznetsov >Assignee: Ilya Lantukh >Priority: Major > Fix For: 2.6 > > > In order to show info about rebalance progress we need to expose > estimatedRebalancingKeys and rebalancedKeys metrics. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8820) Add ability to accept changing txTimeoutOnPartitionMapExchange while waiting for pending transactions.
[
https://issues.apache.org/jira/browse/IGNITE-8820?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16517212#comment-16517212
]
Alexei Scherbakov commented on IGNITE-8820:
---
[~ivandasch],
My comments:
1. Your code doesn't handle a case then timeout was enabled (>0) and after that
was disabled (=0).
Also readability is not good.
I suggest the following code:
{code}
boolean rolledBack = false;
long waitTimeout = 2 * cfg.getNetworkTimeout();
while (true) {
try {
partReleaseFut.get(waitTimeout, TimeUnit.MILLISECONDS);
break;
}
catch (IgniteFutureTimeoutCheckedException ignored) {
// Print pending transactions and locks that might have led to
hang.
if (nextDumpTime <= U.currentTimeMillis()) {
dumpPendingObjects(partReleaseFut);
nextDumpTime = U.currentTimeMillis() +
nextDumpTimeout(dumpCnt++, waitTimeout);
}
long curTimeout =
cfg.getTransactionConfiguration().getTxTimeoutOnPartitionMapExchange();
if (!rolledBack && curTimeout > 0 && U.currentTimeMillis() -
waitStart >= curTimeout) {
rolledBack = true;
cctx.tm().rollbackOnTopologyChange(initialVersion());
}
}
catch (IgniteCheckedException e) {
U.warn(log,"Unable to await partitions release future", e);
throw e;
}
}
{code}
2. You have added argument check to single method of TransactionConfiguration
and now it looks incomplete.
Please add argument checks to all setters or remove it at all. In fact we
really do not need arg check for timeouts because we treat only values > 0 as
valid timeots.
> Add ability to accept changing txTimeoutOnPartitionMapExchange while waiting
> for pending transactions.
> --
>
> Key: IGNITE-8820
> URL: https://issues.apache.org/jira/browse/IGNITE-8820
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.5
>Reporter: Ivan Daschinskiy
>Assignee: Ivan Daschinskiy
>Priority: Minor
> Fix For: 2.6
>
>
> Currently, if ExchangeFuture waits whith old value of
> txTimeoutOnPartitionMapExchange, new value is not accepted until next
> exchange starts. Sometimes it's very usefull (while timeout is too long and
> must be shorter applied immediatelly)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8798) Move transaction recovery logging to INFO level
[
https://issues.apache.org/jira/browse/IGNITE-8798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16517210#comment-16517210
]
Ivan Rakov commented on IGNITE-8798:
Thanks for your contribution! Merged to master.
> Move transaction recovery logging to INFO level
> ---
>
> Key: IGNITE-8798
> URL: https://issues.apache.org/jira/browse/IGNITE-8798
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexey Goncharuk
>Assignee: Evgenii Zagumennov
>Priority: Major
> Fix For: 2.6
>
>
> Currently we log transaction recovery state changes to {{DEBUG}}, however,
> this information is critically important for production deployment and
> incident analysis. I suggest to move corresponding logging
> ({{GridCacheTxRecoveryFuture}} and surrounding code) to {{INFO}} level.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8768) JVM crash in PDS1 suite in master branch
[ https://issues.apache.org/jira/browse/IGNITE-8768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16517178#comment-16517178 ] ASF GitHub Bot commented on IGNITE-8768: GitHub user Jokser opened a pull request: https://github.com/apache/ignite/pull/4227 IGNITE-8768 Implemented eviction stopping to prevent possible JVM crush You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-8768 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4227.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #4227 commit 2cb2cf9c1053a28f636b94936a685344fa29e1b5 Author: Pavel Kovalenko Date: 2018-06-18T15:55:56Z IGNITE-8768 WIP commit 17d33eb98490e5a714f88e295b89ac79dddbee43 Author: Pavel Kovalenko Date: 2018-06-19T14:26:23Z IGNITE-8768 Implemented eviction stop during cache group stopping. Reworked evictor class. commit 5a3e74a9b4a2bf93c865c4eeb94cf914d2da69e2 Author: Pavel Kovalenko Date: 2018-06-19T14:37:34Z IGNITE-8768 Complete eviction future before log error. > JVM crash in PDS1 suite in master branch > > > Key: IGNITE-8768 > URL: https://issues.apache.org/jira/browse/IGNITE-8768 > Project: Ignite > Issue Type: Bug > Components: persistence >Reporter: Sergey Chugunov >Priority: Blocker > Labels: MakeTeamcityGreenAgain > Fix For: 2.6 > > > JVM crash in latest build: [TC > link|https://ci.ignite.apache.org/viewLog.html?buildId=1372456=buildResultsDiv=IgniteTests24Java8_Pds1] > It is the first crash is latest 15 builds: [TC > link|https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_Pds1_IgniteTests24Java8=%3Cdefault%3E=buildTypeStatusDiv] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-8836) NullPointerException during Ignition.start prevents JVM shutdown
[ https://issues.apache.org/jira/browse/IGNITE-8836?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Kurbanov reassigned IGNITE-8836: -- Assignee: Anton Kurbanov > NullPointerException during Ignition.start prevents JVM shutdown > > > Key: IGNITE-8836 > URL: https://issues.apache.org/jira/browse/IGNITE-8836 > Project: Ignite > Issue Type: Bug >Reporter: Anton Kurbanov >Assignee: Anton Kurbanov >Priority: Major > Fix For: 1.9 > > > The exception like below leaves node in stopping state forever: > java.lang.NullPointerException: null > at > java.util.concurrent.ConcurrentLinkedQueue.checkNotNull(ConcurrentLinkedQueue.java:914) > at > java.util.concurrent.ConcurrentLinkedQueue.offer(ConcurrentLinkedQueue.java:327) > at > java.util.concurrent.ConcurrentLinkedQueue.add(ConcurrentLinkedQueue.java:297) > at > org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicUpdateResponse.addFailedKey(GridNearAtomicUpdateResponse.java:347) > at > org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicSingleUpdateFuture.addFailedKeys(GridDhtAtomicSingleUpdateFuture.java:166) > at > org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicAbstractUpdateFuture.onDone(GridDhtAtomicAbstractUpdateFuture.java:446) > at > org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicAbstractUpdateFuture.onDone(GridDhtAtomicAbstractUpdateFuture.java:56) > at > org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:345) > at > org.apache.ignite.internal.processors.cache.GridCacheMvccManager.cancelClientFutures(GridCacheMvccManager.java:388) > at > org.apache.ignite.internal.processors.cache.GridCacheMvccManager.onStop(GridCacheMvccManager.java:370) > at > org.apache.ignite.internal.processors.cache.GridCacheProcessor.onKernalStop(GridCacheProcessor.java:956) > at org.apache.ignite.internal.IgniteKernal.stop0(IgniteKernal.java:2095) > at org.apache.ignite.internal.IgniteKernal.stop(IgniteKernal.java:2041) > at > org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop0(IgnitionEx.java:2397) > at > org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop(IgnitionEx.java:2360) > at > org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance$2.run(IgnitionEx.java:1871) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8836) NullPointerException during Ignition.start prevents JVM shutdown
Anton Kurbanov created IGNITE-8836: -- Summary: NullPointerException during Ignition.start prevents JVM shutdown Key: IGNITE-8836 URL: https://issues.apache.org/jira/browse/IGNITE-8836 Project: Ignite Issue Type: Bug Reporter: Anton Kurbanov Fix For: 1.9 The exception like below leaves node in stopping state forever: java.lang.NullPointerException: null at java.util.concurrent.ConcurrentLinkedQueue.checkNotNull(ConcurrentLinkedQueue.java:914) at java.util.concurrent.ConcurrentLinkedQueue.offer(ConcurrentLinkedQueue.java:327) at java.util.concurrent.ConcurrentLinkedQueue.add(ConcurrentLinkedQueue.java:297) at org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicUpdateResponse.addFailedKey(GridNearAtomicUpdateResponse.java:347) at org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicSingleUpdateFuture.addFailedKeys(GridDhtAtomicSingleUpdateFuture.java:166) at org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicAbstractUpdateFuture.onDone(GridDhtAtomicAbstractUpdateFuture.java:446) at org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicAbstractUpdateFuture.onDone(GridDhtAtomicAbstractUpdateFuture.java:56) at org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:345) at org.apache.ignite.internal.processors.cache.GridCacheMvccManager.cancelClientFutures(GridCacheMvccManager.java:388) at org.apache.ignite.internal.processors.cache.GridCacheMvccManager.onStop(GridCacheMvccManager.java:370) at org.apache.ignite.internal.processors.cache.GridCacheProcessor.onKernalStop(GridCacheProcessor.java:956) at org.apache.ignite.internal.IgniteKernal.stop0(IgniteKernal.java:2095) at org.apache.ignite.internal.IgniteKernal.stop(IgniteKernal.java:2041) at org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop0(IgnitionEx.java:2397) at org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop(IgnitionEx.java:2360) at org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance$2.run(IgnitionEx.java:1871) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-1094) Ignite.createCache(CacheConfiguration) hangs if some exception occurs during cache initialization
[ https://issues.apache.org/jira/browse/IGNITE-1094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16517153#comment-16517153 ] Ilya Lantukh edited comment on IGNITE-1094 at 6/19/18 2:22 PM: --- Hi [~slava.koptilin], Thanks for contribution! I've reviewed your changes here: https://reviews.ignite.apache.org/ignite/review/IGNT-CR-652. Your solution looks good in general, but there are a few things that concern me. was (Author: ilantukh): [~slava.koptilin], I've reviewed your changes here: https://reviews.ignite.apache.org/ignite/review/IGNT-CR-652. > Ignite.createCache(CacheConfiguration) hangs if some exception occurs during > cache initialization > - > > Key: IGNITE-1094 > URL: https://issues.apache.org/jira/browse/IGNITE-1094 > Project: Ignite > Issue Type: Bug > Components: cache >Reporter: Sergey Evdokimov >Assignee: Vyacheslav Koptilin >Priority: Major > Labels: Muted_test > Fix For: 2.6 > > > User can pass broken configuration, for example, store factory that throws > exception from create() method. I created test to demonstrate the problem. > See IgniteDynamicCacheStartSelfTest#testBrokenStoreFactory in 'ignite-1094' > branch -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-1094) Ignite.createCache(CacheConfiguration) hangs if some exception occurs during cache initialization
[ https://issues.apache.org/jira/browse/IGNITE-1094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16517153#comment-16517153 ] Ilya Lantukh edited comment on IGNITE-1094 at 6/19/18 2:22 PM: --- Hi [~slava.koptilin], Thanks for contribution! I've reviewed your changes here: https://reviews.ignite.apache.org/ignite/review/IGNT-CR-652. Your solution looks good in general, but there are a few things that concern me. was (Author: ilantukh): Hi [~slava.koptilin], Thanks for contribution! I've reviewed your changes here: https://reviews.ignite.apache.org/ignite/review/IGNT-CR-652. Your solution looks good in general, but there are a few things that concern me. > Ignite.createCache(CacheConfiguration) hangs if some exception occurs during > cache initialization > - > > Key: IGNITE-1094 > URL: https://issues.apache.org/jira/browse/IGNITE-1094 > Project: Ignite > Issue Type: Bug > Components: cache >Reporter: Sergey Evdokimov >Assignee: Vyacheslav Koptilin >Priority: Major > Labels: Muted_test > Fix For: 2.6 > > > User can pass broken configuration, for example, store factory that throws > exception from create() method. I created test to demonstrate the problem. > See IgniteDynamicCacheStartSelfTest#testBrokenStoreFactory in 'ignite-1094' > branch -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-1094) Ignite.createCache(CacheConfiguration) hangs if some exception occurs during cache initialization
[ https://issues.apache.org/jira/browse/IGNITE-1094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16517153#comment-16517153 ] Ilya Lantukh commented on IGNITE-1094: -- [~slava.koptilin], I've reviewed your changes here: https://reviews.ignite.apache.org/ignite/review/IGNT-CR-652. > Ignite.createCache(CacheConfiguration) hangs if some exception occurs during > cache initialization > - > > Key: IGNITE-1094 > URL: https://issues.apache.org/jira/browse/IGNITE-1094 > Project: Ignite > Issue Type: Bug > Components: cache >Reporter: Sergey Evdokimov >Assignee: Vyacheslav Koptilin >Priority: Major > Labels: Muted_test > Fix For: 2.6 > > > User can pass broken configuration, for example, store factory that throws > exception from create() method. I created test to demonstrate the problem. > See IgniteDynamicCacheStartSelfTest#testBrokenStoreFactory in 'ignite-1094' > branch -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8835) Do not skip distributed phase of 2-phase partition release if there are some caches to stop / modify
Pavel Kovalenko created IGNITE-8835: --- Summary: Do not skip distributed phase of 2-phase partition release if there are some caches to stop / modify Key: IGNITE-8835 URL: https://issues.apache.org/jira/browse/IGNITE-8835 Project: Ignite Issue Type: Bug Components: cache Affects Versions: 2.5 Reporter: Pavel Kovalenko Assignee: Pavel Kovalenko Fix For: 2.6 If we don't perform distributed 2-phase in case of cache stop, we can lost some transactional updates from primary to backup. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Deleted] (IGNITE-8825) Ignite - Configuration for IGFS
[ https://issues.apache.org/jira/browse/IGNITE-8825?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn deleted IGNITE-8825: --- > Ignite - Configuration for IGFS > > > Key: IGNITE-8825 > URL: https://issues.apache.org/jira/browse/IGNITE-8825 > Project: Ignite > Issue Type: Test >Reporter: Puviarasu >Priority: Trivial > > Default configuration not working for IGFS -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8834) SqlQuery not throwing exception after partition loss events
Anton Kurbanov created IGNITE-8834:
--
Summary: SqlQuery not throwing exception after partition loss
events
Key: IGNITE-8834
URL: https://issues.apache.org/jira/browse/IGNITE-8834
Project: Ignite
Issue Type: Bug
Components: sql
Affects Versions: 2.4
Reporter: Anton Kurbanov
Precondition: 3 server nodes, client listening for partition loss events,
partitioned cache with backups = 1, partition loss policy = READ_ONLY_SAFE,
stream some data. Kill 2 nodes, call:
{code:java}
SqlQuery query = new SqlQuery<>(Integer.class, "where
_key>0");
query.setLocal(false);
List> list = cache.query(query).getAll();
{code}
Cache configuration:
{code:java}
public IgniteConfiguration getCfg() {
IgniteConfiguration cfg = new IgniteConfiguration();
cfg.setConsistentId(cfg.getIgniteInstanceName());
cfg.setIncludeEventTypes(EventType.EVT_CACHE_REBALANCE_PART_DATA_LOST);
TcpDiscoverySpi discovery = new TcpDiscoverySpi();
TcpDiscoveryVmIpFinder finder = new TcpDiscoveryVmIpFinder();
finder.setAddresses(Arrays.asList("127.0.0.1:47500..47509"));
discovery.setIpFinder(finder);
cfg.setDiscoverySpi(discovery);
QueryEntity queryEntity = new QueryEntity();
queryEntity.setKeyType(Integer.class.getName());
queryEntity.setValueType(Integer.class.getName());
cfg.setCacheConfiguration(new CacheConfiguration(CACHE)
.setCacheMode(CacheMode.PARTITIONED)
.setBackups(1)
.setAffinity(new RendezvousAffinityFunction())
.setWriteSynchronizationMode(CacheWriteSynchronizationMode.FULL_SYNC)
.setPartitionLossPolicy(PartitionLossPolicy.READ_ONLY_SAFE)
.setQueryEntities(Collections.singletonList(queryEntity)));
DataStorageConfiguration storageCfg = new DataStorageConfiguration();
storageCfg.getDefaultDataRegionConfiguration().setPersistenceEnabled(true);
cfg.setDataStorageConfiguration(storageCfg);
return cfg;
}
{code}
Query is expected to fail, but succeeds and returns entries from partitions
that are alive.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-8833) IgniteCache.isLocalLocked method has unexpected behivior in case of several nodes started in one JVM in different threads
Andrey Aleksandrov created IGNITE-8833:
--
Summary: IgniteCache.isLocalLocked method has unexpected behivior
in case of several nodes started in one JVM in different threads
Key: IGNITE-8833
URL: https://issues.apache.org/jira/browse/IGNITE-8833
Project: Ignite
Issue Type: Bug
Components: cache, documentation
Affects Versions: 2.5
Reporter: Andrey Aleksandrov
Fix For: 2.6
Attachments: ThreadLockedTest.java
According to specification:
[https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/IgniteCache.html#isLocalLocked-K-boolean-]
Checks if specified key is locked.This is a local in-VM operation and does not
involve any network trips or access to persistent storage in any way.
Parameters:
{{key}} - Key to check.
{{byCurrThread}} - If {{true}} method will check that current thread owns a
lock on this key, other vise will check that any thread on any node owns a lock
on this key.
Returns:{{True}} if lock is owned by some node.
In the attached test we start one node in the main thread and another node from
the second thread. In second node we take a lock but in main thread
isLocalLocked shows that no thread held the lock.
However tryLock works ok. So the behavior of the isLocalLocked method should be
described in this case or fixed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8810) Create failoverSafe for ReentrantLock
[ https://issues.apache.org/jira/browse/IGNITE-8810?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16517038#comment-16517038 ] Jon Tricker commented on IGNITE-8810: - Created the attached CacheUnlockTest.java testing the same problem with cache locks. If the ‘remote’ node is explicitly closed this releases the lock as expected. This is different to the re-entrant lock case. However if the remote node goes out of scope, or crashes, without an explicit close(), it remains locked. See comments in code for more details. However this is all running on one machine (process?). Maybe things are different if the failing node is really a remote machine connected over the network. > Create failoverSafe for ReentrantLock > - > > Key: IGNITE-8810 > URL: https://issues.apache.org/jira/browse/IGNITE-8810 > Project: Ignite > Issue Type: Improvement >Reporter: Evgenii Zhuravlev >Priority: Major > Attachments: CacheUnlockTest.java, UnlockTest.java > > > Currently, it has the flag "failoverSafe", but it doesn't have any > implementation for it -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8810) Create failoverSafe for ReentrantLock
[ https://issues.apache.org/jira/browse/IGNITE-8810?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Tricker updated IGNITE-8810: Attachment: CacheUnlockTest.java > Create failoverSafe for ReentrantLock > - > > Key: IGNITE-8810 > URL: https://issues.apache.org/jira/browse/IGNITE-8810 > Project: Ignite > Issue Type: Improvement >Reporter: Evgenii Zhuravlev >Priority: Major > Attachments: CacheUnlockTest.java, UnlockTest.java > > > Currently, it has the flag "failoverSafe", but it doesn't have any > implementation for it -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-4939) Receive event before cache initialized
[
https://issues.apache.org/jira/browse/IGNITE-4939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16517032#comment-16517032
]
ASF GitHub Bot commented on IGNITE-4939:
GitHub user ezhuravl opened a pull request:
https://github.com/apache/ignite/pull/4226
IGNITE-4939 Receive event before cache initialized fix
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-4939
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/4226.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #4226
commit 704f0fda313f559b810da9278fc120916c80795e
Author: ezhuravl
Date: 2018-06-18T09:19:39Z
IGNITE-4939 Receive event before cache initialized fix
> Receive event before cache initialized
> --
>
> Key: IGNITE-4939
> URL: https://issues.apache.org/jira/browse/IGNITE-4939
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 1.9
>Reporter: Nikolay Tikhonov
>Assignee: Evgenii Zhuravlev
>Priority: Blocker
> Fix For: 2.7
>
>
> Receive event before cache initialized that leads to the following:
> {noformat}
> Exception in thread "sys-#755%Default%" java.lang.IllegalArgumentException:
> Cache is not configured: ignite-sys-cache
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.jcache(GridCacheProcessor.java:3343)
> at
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler.handleEvent(CacheContinuousQueryHandler.java:719)
> at
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler.notifyCallback0(CacheContinuousQueryHandler.java:691)
> at
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler.notifyCallback(CacheContinuousQueryHandler.java:650)
> at
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.processNotification(GridContinuousProcessor.java:1086)
> at
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.access$2000(GridContinuousProcessor.java:97)
> at
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor$8.onMessage(GridContinuousProcessor.java:741)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1082)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$1600(GridIoManager.java:102)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$GridCommunicationMessageSet.unwind(GridIoManager.java:2332)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.unwindMessageSet(GridIoManager.java:1042)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$1900(GridIoManager.java:102)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$6.run(GridIoManager.java:1011)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8769) JVM crash in Basic1 suite in master branch on TC
[ https://issues.apache.org/jira/browse/IGNITE-8769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16517026#comment-16517026 ] ASF GitHub Bot commented on IGNITE-8769: Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/4206 > JVM crash in Basic1 suite in master branch on TC > > > Key: IGNITE-8769 > URL: https://issues.apache.org/jira/browse/IGNITE-8769 > Project: Ignite > Issue Type: Bug >Reporter: Sergey Chugunov >Assignee: Dmitriy Sorokin >Priority: Blocker > Labels: MakeTeamcityGreenAgain > Fix For: 2.6 > > > Latest build with crash: [TC > link|https://ci.ignite.apache.org/viewLog.html?buildId=1373991=buildResultsDiv=IgniteTests24Java8_Basic1] > There is another crash in the history: [TC > link|https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_Basic1_IgniteTests24Java8=%3Cdefault%3E=buildTypeStatusDiv] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8827) Disable WAL during apply updates on recovery
[ https://issues.apache.org/jira/browse/IGNITE-8827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16517014#comment-16517014 ] ASF GitHub Bot commented on IGNITE-8827: GitHub user DmitriyGovorukhin opened a pull request: https://github.com/apache/ignite/pull/4225 IGNITE-8827 disable WAL logging You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-8827 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4225.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #4225 commit 2250a923330127b2819bf50b4faeb40764f01762 Author: Dmitriy Govorukhin Date: 2018-06-19T11:57:48Z IGNITE-8827 disable WAL logging > Disable WAL during apply updates on recovery > > > Key: IGNITE-8827 > URL: https://issues.apache.org/jira/browse/IGNITE-8827 > Project: Ignite > Issue Type: Bug >Reporter: Dmitriy Govorukhin >Assignee: Dmitriy Govorukhin >Priority: Major > Fix For: 2.6 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8832) Detecting hanging of coordinator during processing local partition maps messages
Sergey Chugunov created IGNITE-8832: --- Summary: Detecting hanging of coordinator during processing local partition maps messages Key: IGNITE-8832 URL: https://issues.apache.org/jira/browse/IGNITE-8832 Project: Ignite Issue Type: Improvement Components: general Reporter: Sergey Chugunov After coordinator gathered local partition maps from all other server nodes it should prepare full partition map and send it back. If for some reason (e.g. bug in code) coordinator fails to prepare full map it should detect this situation and shut down itself. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8830) Non-coordinator node unable to finish local exchange should detect it and stop
[ https://issues.apache.org/jira/browse/IGNITE-8830?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Chugunov updated IGNITE-8830: Remaining Estimate: 336h Original Estimate: 336h > Non-coordinator node unable to finish local exchange should detect it and stop > -- > > Key: IGNITE-8830 > URL: https://issues.apache.org/jira/browse/IGNITE-8830 > Project: Ignite > Issue Type: Improvement > Components: general >Reporter: Sergey Chugunov >Priority: Major > Original Estimate: 336h > Remaining Estimate: 336h > > At the final stage of Partition Map Exchange coordinator node sends full > partitions map to all other nodes. > If some node fails to apply this message and finish its local exchange it > won't be able to operate correctly. > To prevent this node should be able to check status of this exchange on > coordinator (by sending some diagnostic message). If the exchange has already > finished on coordinator, node should stop. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8825) Ignite - Configuration for IGFS
[ https://issues.apache.org/jira/browse/IGNITE-8825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16517010#comment-16517010 ] Puviarasu commented on IGNITE-8825: --- Hello @[~cos], As I do not have Admin access I am not able to delete this ticket. Kindly requesting you to delete this ticket. Thanks in Advance!!! > Ignite - Configuration for IGFS > > > Key: IGNITE-8825 > URL: https://issues.apache.org/jira/browse/IGNITE-8825 > Project: Ignite > Issue Type: Test >Reporter: Puviarasu >Priority: Trivial > > Default configuration not working for IGFS -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8808) Improve control.sh --tx command to show local and remote transactions.
[ https://issues.apache.org/jira/browse/IGNITE-8808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16517005#comment-16517005 ] Ilya Lantukh commented on IGNITE-8808: -- Looks good to me. > Improve control.sh --tx command to show local and remote transactions. > -- > > Key: IGNITE-8808 > URL: https://issues.apache.org/jira/browse/IGNITE-8808 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.5 >Reporter: Alexei Scherbakov >Assignee: Alexei Scherbakov >Priority: Major > Fix For: 2.6 > > > Currently --tx option for control.sh shows only transactions found on > near(initiating) nodes. > Due to various issues it's possible to have corresponding dht local and > remote transaction without near part. > Such transactions must be visible to utility. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8617) Node Discovery Using AWS Application ELB
[ https://issues.apache.org/jira/browse/IGNITE-8617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16517001#comment-16517001 ] Uday Kale commented on IGNITE-8617: --- [~dmagda] can you please review this? > Node Discovery Using AWS Application ELB > > > Key: IGNITE-8617 > URL: https://issues.apache.org/jira/browse/IGNITE-8617 > Project: Ignite > Issue Type: New Feature > Components: aws >Reporter: Uday Kale >Priority: Major > > Support for Node discovery using AWS Application ELB. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8831) MarshallerMappingFileStore: Incorrect locks on files
[ https://issues.apache.org/jira/browse/IGNITE-8831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16516998#comment-16516998 ] Alexey Stelmak commented on IGNITE-8831: PR: https://github.com/apache/ignite/pull/4224 > MarshallerMappingFileStore: Incorrect locks on files > > > Key: IGNITE-8831 > URL: https://issues.apache.org/jira/browse/IGNITE-8831 > Project: Ignite > Issue Type: Bug >Reporter: Alexey Stelmak >Assignee: Alexey Stelmak >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8828) Detecting and stopping unresponsive nodes during Partition Map Exchange
[ https://issues.apache.org/jira/browse/IGNITE-8828?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Chugunov updated IGNITE-8828: Remaining Estimate: 240h Original Estimate: 240h > Detecting and stopping unresponsive nodes during Partition Map Exchange > --- > > Key: IGNITE-8828 > URL: https://issues.apache.org/jira/browse/IGNITE-8828 > Project: Ignite > Issue Type: Improvement > Components: general >Reporter: Sergey Chugunov >Priority: Major > Original Estimate: 240h > Remaining Estimate: 240h > > During PME process coordinator (1) gathers local partition maps from all > nodes and (2) sends calculated full partition map back to all nodes in the > topology. > However if one or more nodes fail to send local information on step 1 for any > reason, PME process hangs blocking all operations. The only solution will be > to manually identify and stop nodes which failed to send info to coordinator. > This should be done by coordinator itself: in case it didn't receive in time > local partition maps from any nodes, it should check that stopping these > nodes won't lead to data loss and then stop them forcibly. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8828) Detecting and stopping unresponsive nodes during Partition Map Exchange
[ https://issues.apache.org/jira/browse/IGNITE-8828?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Chugunov updated IGNITE-8828: Remaining Estimate: 264h (was: 240h) Original Estimate: 264h (was: 240h) > Detecting and stopping unresponsive nodes during Partition Map Exchange > --- > > Key: IGNITE-8828 > URL: https://issues.apache.org/jira/browse/IGNITE-8828 > Project: Ignite > Issue Type: Improvement > Components: general >Reporter: Sergey Chugunov >Priority: Major > Original Estimate: 264h > Remaining Estimate: 264h > > During PME process coordinator (1) gathers local partition maps from all > nodes and (2) sends calculated full partition map back to all nodes in the > topology. > However if one or more nodes fail to send local information on step 1 for any > reason, PME process hangs blocking all operations. The only solution will be > to manually identify and stop nodes which failed to send info to coordinator. > This should be done by coordinator itself: in case it didn't receive in time > local partition maps from any nodes, it should check that stopping these > nodes won't lead to data loss and then stop them forcibly. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-8831) MarshallerMappingFileStore: Incorrect locks on files
[ https://issues.apache.org/jira/browse/IGNITE-8831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Stelmak reassigned IGNITE-8831: -- Assignee: Alexey Stelmak > MarshallerMappingFileStore: Incorrect locks on files > > > Key: IGNITE-8831 > URL: https://issues.apache.org/jira/browse/IGNITE-8831 > Project: Ignite > Issue Type: Bug >Reporter: Alexey Stelmak >Assignee: Alexey Stelmak >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8831) MarshallerMappingFileStore: Incorrect locks on files
Alexey Stelmak created IGNITE-8831: -- Summary: MarshallerMappingFileStore: Incorrect locks on files Key: IGNITE-8831 URL: https://issues.apache.org/jira/browse/IGNITE-8831 Project: Ignite Issue Type: Bug Reporter: Alexey Stelmak -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-8704) CacheManagerTest.getUnsafeTypedCacheRequest failed
[
https://issues.apache.org/jira/browse/IGNITE-8704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton Vinogradov resolved IGNITE-8704.
--
Resolution: Fixed
Thanks for contribution.
Merged to master.
Tests failed at Jcache 1.0 muted
- CacheManagerTest.getUnsafeTypedCacheRequest
> CacheManagerTest.getUnsafeTypedCacheRequest failed
> --
>
> Key: IGNITE-8704
> URL: https://issues.apache.org/jira/browse/IGNITE-8704
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Alexander Menshikov
>Assignee: Alexander Menshikov
>Priority: Major
> Labels: iep-21
> Fix For: 2.6
>
>
> In JCache 1.1 type safety guarantees on method
> {{CacheManager#getCache(String)}} was relaxed. So we can remove unnesesary
> checks. Please see the links for detailes.
> *It makes test {{CacheManagerTest#getUnsafeTypedCacheRequest}} fail in TCK
> 1.0.1.*
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-8830) Non-coordinator node unable to finish local exchange should detect it and stop
[ https://issues.apache.org/jira/browse/IGNITE-8830?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Chugunov updated IGNITE-8830: Component/s: general > Non-coordinator node unable to finish local exchange should detect it and stop > -- > > Key: IGNITE-8830 > URL: https://issues.apache.org/jira/browse/IGNITE-8830 > Project: Ignite > Issue Type: Improvement > Components: general >Reporter: Sergey Chugunov >Priority: Major > > At the final stage of Partition Map Exchange coordinator node sends full > partitions map to all other nodes. > If some node fails to apply this message and finish its local exchange it > won't be able to operate correctly. > To prevent this node should be able to check status of this exchange on > coordinator (by sending some diagnostic message). If the exchange has already > finished on coordinator, node should stop. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8828) Detecting and stopping unresponsive nodes during Partition Map Exchange
[ https://issues.apache.org/jira/browse/IGNITE-8828?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Chugunov updated IGNITE-8828: Component/s: general > Detecting and stopping unresponsive nodes during Partition Map Exchange > --- > > Key: IGNITE-8828 > URL: https://issues.apache.org/jira/browse/IGNITE-8828 > Project: Ignite > Issue Type: Improvement > Components: general >Reporter: Sergey Chugunov >Priority: Major > > During PME process coordinator (1) gathers local partition maps from all > nodes and (2) sends calculated full partition map back to all nodes in the > topology. > However if one or more nodes fail to send local information on step 1 for any > reason, PME process hangs blocking all operations. The only solution will be > to manually identify and stop nodes which failed to send info to coordinator. > This should be done by coordinator itself: in case it didn't receive in time > local partition maps from any nodes, it should check that stopping these > nodes won't lead to data loss and then stop them forcibly. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8830) Non-coordinator node unable to finish local exchange should detect it and stop
Sergey Chugunov created IGNITE-8830: --- Summary: Non-coordinator node unable to finish local exchange should detect it and stop Key: IGNITE-8830 URL: https://issues.apache.org/jira/browse/IGNITE-8830 Project: Ignite Issue Type: Improvement Reporter: Sergey Chugunov At the final stage of Partition Map Exchange coordinator node sends full partitions map to all other nodes. If some node fails to apply this message and finish its local exchange it won't be able to operate correctly. To prevent this node should be able to check status of this exchange on coordinator (by sending some diagnostic message). If the exchange has already finished on coordinator, node should stop. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8829) Some configuration properties of TcpCommunicationSpi does not annotated appropriately
Vladislav Pyatkov created IGNITE-8829:
-
Summary: Some configuration properties of TcpCommunicationSpi does
not annotated appropriately
Key: IGNITE-8829
URL: https://issues.apache.org/jira/browse/IGNITE-8829
Project: Ignite
Issue Type: Bug
Reporter: Vladislav Pyatkov
When I checked all properties of TcpCommunicationSpi, I have found an issue
with getting all configuration properties from code. Because a part of them not
be a configured property, but a part of a real SPI life.
I should was rid of these issues - all configurable properties must annotate as
{{IgniteSpiConfiguration}}, but it not done for each.
I have found at least two properties for which not be done:
{{connectionsPerNode}}
{{usePairedConnections}}
and one property which not appropriate contract (it have only setter, but not
getter):
{{addressResolver}}
Need to revised all properties CommunicationSpi and correct them.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-8556) Web Console: Improve Webpack DEV mode
[ https://issues.apache.org/jira/browse/IGNITE-8556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov updated IGNITE-8556: - Fix Version/s: (was: 2.6) 2.7 > Web Console: Improve Webpack DEV mode > - > > Key: IGNITE-8556 > URL: https://issues.apache.org/jira/browse/IGNITE-8556 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Alexey Kuznetsov >Assignee: Alexey Kuznetsov >Priority: Major > Fix For: 2.7 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8828) Detecting and stopping unresponsive nodes during Partition Map Exchange
Sergey Chugunov created IGNITE-8828: --- Summary: Detecting and stopping unresponsive nodes during Partition Map Exchange Key: IGNITE-8828 URL: https://issues.apache.org/jira/browse/IGNITE-8828 Project: Ignite Issue Type: Improvement Reporter: Sergey Chugunov During PME process coordinator (1) gathers local partition maps from all nodes and (2) sends calculated full partition map back to all nodes in the topology. However if one or more nodes fail to send local information on step 1 for any reason, PME process hangs blocking all operations. The only solution will be to manually identify and stop nodes which failed to send info to coordinator. This should be done by coordinator itself: in case it didn't receive in time local partition maps from any nodes, it should check that stopping these nodes won't lead to data loss and then stop them forcibly. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-8557) Web Console: Webpack add support for SVG images
[ https://issues.apache.org/jira/browse/IGNITE-8557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov reassigned IGNITE-8557: Assignee: Ilya Borisov (was: Alexey Kuznetsov) [~Klaster_1] Could you change webpack configs for this? > Web Console: Webpack add support for SVG images > --- > > Key: IGNITE-8557 > URL: https://issues.apache.org/jira/browse/IGNITE-8557 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Alexey Kuznetsov >Assignee: Ilya Borisov >Priority: Major > Fix For: 2.6 > > > In current implementation we forced to store images in special folder and > copy them via copy plugin. But as we are going towards Angular with > components it will be better to store images near components (as we do for > css). > Lets add such loader to Webpack -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8557) Web Console: Webpack add support for SVG images
[ https://issues.apache.org/jira/browse/IGNITE-8557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov updated IGNITE-8557: - Component/s: wizards > Web Console: Webpack add support for SVG images > --- > > Key: IGNITE-8557 > URL: https://issues.apache.org/jira/browse/IGNITE-8557 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Alexey Kuznetsov >Assignee: Alexey Kuznetsov >Priority: Major > Fix For: 2.6 > > > In current implementation we forced to store images in special folder and > copy them via copy plugin. But as we are going towards Angular with > components it will be better to store images near components (as we do for > css). > Lets add such loader to Webpack -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-8655) Web Console: Update to next version.
[ https://issues.apache.org/jira/browse/IGNITE-8655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16516935#comment-16516935 ] Alexey Kuznetsov edited comment on IGNITE-8655 at 6/19/18 11:06 AM: Merged to master 2.5 -> 2.6. was (Author: kuaw26): Merged to master. > Web Console: Update to next version. > > > Key: IGNITE-8655 > URL: https://issues.apache.org/jira/browse/IGNITE-8655 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Alexey Kuznetsov >Assignee: Alexey Kuznetsov >Priority: Major > Fix For: 2.6 > > > Ignite 2.5 was released. > We need update master to next version. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (IGNITE-8655) Web Console: Update to next version.
[ https://issues.apache.org/jira/browse/IGNITE-8655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov closed IGNITE-8655. > Web Console: Update to next version. > > > Key: IGNITE-8655 > URL: https://issues.apache.org/jira/browse/IGNITE-8655 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Alexey Kuznetsov >Assignee: Alexey Kuznetsov >Priority: Major > Fix For: 2.6 > > > Ignite 2.5 was released. > We need update master to next version. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-8655) Web Console: Update to next version.
[ https://issues.apache.org/jira/browse/IGNITE-8655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov resolved IGNITE-8655. -- Resolution: Fixed Merged to master. > Web Console: Update to next version. > > > Key: IGNITE-8655 > URL: https://issues.apache.org/jira/browse/IGNITE-8655 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Alexey Kuznetsov >Assignee: Alexey Kuznetsov >Priority: Major > Fix For: 2.6 > > > Ignite 2.5 was released. > We need update master to next version. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8704) CacheManagerTest.getUnsafeTypedCacheRequest failed
[
https://issues.apache.org/jira/browse/IGNITE-8704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Menshikov updated IGNITE-8704:
Description:
In JCache 1.1 type safety guarantees on method
{{CacheManager#getCache(String)}} was relaxed. So we can remove unnesesary
checks. Please see the links for detailes.
It makes test
was:
In JCache 1.1 type safety guarantees on method CacheManager#getCache(String)
was relaxed. So we can remove unnesesary checks. Please see the links for
detailes.
> CacheManagerTest.getUnsafeTypedCacheRequest failed
> --
>
> Key: IGNITE-8704
> URL: https://issues.apache.org/jira/browse/IGNITE-8704
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Alexander Menshikov
>Assignee: Alexander Menshikov
>Priority: Major
> Labels: iep-21
> Fix For: 2.6
>
>
> In JCache 1.1 type safety guarantees on method
> {{CacheManager#getCache(String)}} was relaxed. So we can remove unnesesary
> checks. Please see the links for detailes.
> It makes test
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-8704) CacheManagerTest.getUnsafeTypedCacheRequest failed
[
https://issues.apache.org/jira/browse/IGNITE-8704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Menshikov updated IGNITE-8704:
Description:
In JCache 1.1 type safety guarantees on method
{{CacheManager#getCache(String)}} was relaxed. So we can remove unnesesary
checks. Please see the links for detailes.
*It makes test {{CacheManagerTest#getUnsafeTypedCacheRequest}} fail in TCK
1.0.1.*
was:
In JCache 1.1 type safety guarantees on method
{{CacheManager#getCache(String)}} was relaxed. So we can remove unnesesary
checks. Please see the links for detailes.
It makes test
> CacheManagerTest.getUnsafeTypedCacheRequest failed
> --
>
> Key: IGNITE-8704
> URL: https://issues.apache.org/jira/browse/IGNITE-8704
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Alexander Menshikov
>Assignee: Alexander Menshikov
>Priority: Major
> Labels: iep-21
> Fix For: 2.6
>
>
> In JCache 1.1 type safety guarantees on method
> {{CacheManager#getCache(String)}} was relaxed. So we can remove unnesesary
> checks. Please see the links for detailes.
> *It makes test {{CacheManagerTest#getUnsafeTypedCacheRequest}} fail in TCK
> 1.0.1.*
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-8704) CacheManagerTest.getUnsafeTypedCacheRequest failed
[ https://issues.apache.org/jira/browse/IGNITE-8704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Menshikov updated IGNITE-8704: Description: In JCache 1.1 type safety guarantees on method CacheManager#getCache(String) was relaxed. So we can remove unnesesary checks. Please see the links for detailes. was:In JCache 1.1 type safety guarantees on method CacheManager#getCache(String) was relaxed. So we can remove unnesesary checks. Please see the links for detailes. > CacheManagerTest.getUnsafeTypedCacheRequest failed > -- > > Key: IGNITE-8704 > URL: https://issues.apache.org/jira/browse/IGNITE-8704 > Project: Ignite > Issue Type: Sub-task >Reporter: Alexander Menshikov >Assignee: Alexander Menshikov >Priority: Major > Labels: iep-21 > Fix For: 2.6 > > > In JCache 1.1 type safety guarantees on method CacheManager#getCache(String) > was relaxed. So we can remove unnesesary checks. Please see the links for > detailes. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8798) Move transaction recovery logging to INFO level
[
https://issues.apache.org/jira/browse/IGNITE-8798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16516907#comment-16516907
]
Ivan Rakov commented on IGNITE-8798:
Guys, I can't find a TC run for this change.
Let's wait for successful run before merging:
https://ci.ignite.apache.org/viewQueued.html?itemId=1404268
> Move transaction recovery logging to INFO level
> ---
>
> Key: IGNITE-8798
> URL: https://issues.apache.org/jira/browse/IGNITE-8798
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexey Goncharuk
>Assignee: Evgenii Zagumennov
>Priority: Major
>
> Currently we log transaction recovery state changes to {{DEBUG}}, however,
> this information is critically important for production deployment and
> incident analysis. I suggest to move corresponding logging
> ({{GridCacheTxRecoveryFuture}} and surrounding code) to {{INFO}} level.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (IGNITE-8708) CacheManagerTest.close_cachesEmpty failed
[
https://issues.apache.org/jira/browse/IGNITE-8708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton Vinogradov resolved IGNITE-8708.
--
Resolution: Fixed
Thanks for contribution.
Merged to master.
Tests failed at Jcache 1.0 muted
* CacheManagerTest.close_cachesEmpty
* CacheManagerManagementTest.testMultipleCacheManagers
> CacheManagerTest.close_cachesEmpty failed
> -
>
> Key: IGNITE-8708
> URL: https://issues.apache.org/jira/browse/IGNITE-8708
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Alexander Menshikov
>Assignee: Alexander Menshikov
>Priority: Major
> Labels: iep-21
> Fix For: 2.6
>
>
> Method {{CacheManager#getCacheNames()}} should throw
> {{IllegalStateException}} in case when {{CacheManager}} is closed. But in TCK
> 1.0.1 test {{CacheManagerTest.close_cachesEmpty}} expect empty list, which
> was incorrect according to spec.
> In TCK 1.1.0 test is fixed.
> It was known problem, please see comments in {{CacheManager#getCacheNames()}}
> on current master.
> *But we can't make this test pass in both versions of TCK.*
> Also, for the same reason
> {{CacheManagerManagementTest#testMultipleCacheManagers}} fails in
> {{#teadDown}} section.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-8708) CacheManagerTest.close_cachesEmpty failed
[
https://issues.apache.org/jira/browse/IGNITE-8708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Menshikov updated IGNITE-8708:
Description:
Method {{CacheManager#getCacheNames()}} should throw {{IllegalStateException}}
in case when {{CacheManager}} is closed. But in TCK 1.0.1 test
{{CacheManagerTest.close_cachesEmpty}} expect empty list, which was incorrect
according to spec.
In TCK 1.1.0 test is fixed.
It was known problem, please see comments in {{CacheManager#getCacheNames()}}
on current master.
*But we can't make this test pass in both versions of TCK.*
Also, for the same reason
{{CacheManagerManagementTest#testMultipleCacheManagers}} fails in {{#teadDown}}
section.
was:
Method {{CacheManager#getCacheNames()}} should throw {{IllegalStateException}}
in case when {{CacheManager}} is closed. But in TCK 1.0.1 test
{{CacheManagerTest.close_cachesEmpty}} expect empty list, which was incorrect
according to spec.
In TCK 1.1.0 test is fixed.
It was known problem, please see comments in {{CacheManager#getCacheNames()}}
on current master.
*But we can't make this test pass in both versions of TCK.*
> CacheManagerTest.close_cachesEmpty failed
> -
>
> Key: IGNITE-8708
> URL: https://issues.apache.org/jira/browse/IGNITE-8708
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Alexander Menshikov
>Assignee: Alexander Menshikov
>Priority: Major
> Labels: iep-21
> Fix For: 2.6
>
>
> Method {{CacheManager#getCacheNames()}} should throw
> {{IllegalStateException}} in case when {{CacheManager}} is closed. But in TCK
> 1.0.1 test {{CacheManagerTest.close_cachesEmpty}} expect empty list, which
> was incorrect according to spec.
> In TCK 1.1.0 test is fixed.
> It was known problem, please see comments in {{CacheManager#getCacheNames()}}
> on current master.
> *But we can't make this test pass in both versions of TCK.*
> Also, for the same reason
> {{CacheManagerManagementTest#testMultipleCacheManagers}} fails in
> {{#teadDown}} section.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-5632) Web Console: add some kind of agent management and administration.
[ https://issues.apache.org/jira/browse/IGNITE-5632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vica Abramova reassigned IGNITE-5632: - Assignee: Alexey Kuznetsov (was: Vica Abramova) > Web Console: add some kind of agent management and administration. > -- > > Key: IGNITE-5632 > URL: https://issues.apache.org/jira/browse/IGNITE-5632 > Project: Ignite > Issue Type: Task > Components: wizards >Reporter: Alexey Kuznetsov >Assignee: Alexey Kuznetsov >Priority: Major > Attachments: Connections.png > > > In admin mode we should see all connected agents and mange their tokens lists > (add / remove). > May by stop/restart/agent logs view will be also useful. > To implement: > Display list of connected agent with list of users(tokens) that configured > on them. This could be a master-detail table or tree-like control. > Actions to implement > 1. Add users(tokens) by selecting from list of users. Will be nice to support > adding several users at once. > 2. Remove users. Will be nice to support removing several users at once. > 3. Restart selected web agents. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-5632) Web Console: add some kind of agent management and administration.
[ https://issues.apache.org/jira/browse/IGNITE-5632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16516903#comment-16516903 ] Vica Abramova commented on IGNITE-5632: --- [~kuaw26], ready! > Web Console: add some kind of agent management and administration. > -- > > Key: IGNITE-5632 > URL: https://issues.apache.org/jira/browse/IGNITE-5632 > Project: Ignite > Issue Type: Task > Components: wizards >Reporter: Alexey Kuznetsov >Assignee: Alexey Kuznetsov >Priority: Major > Attachments: Connections.png > > > In admin mode we should see all connected agents and mange their tokens lists > (add / remove). > May by stop/restart/agent logs view will be also useful. > To implement: > Display list of connected agent with list of users(tokens) that configured > on them. This could be a master-detail table or tree-like control. > Actions to implement > 1. Add users(tokens) by selecting from list of users. Will be nice to support > adding several users at once. > 2. Remove users. Will be nice to support removing several users at once. > 3. Restart selected web agents. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-5632) Web Console: add some kind of agent management and administration.
[ https://issues.apache.org/jira/browse/IGNITE-5632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vica Abramova updated IGNITE-5632: -- Attachment: Connections.png > Web Console: add some kind of agent management and administration. > -- > > Key: IGNITE-5632 > URL: https://issues.apache.org/jira/browse/IGNITE-5632 > Project: Ignite > Issue Type: Task > Components: wizards >Reporter: Alexey Kuznetsov >Assignee: Vica Abramova >Priority: Major > Attachments: Connections.png > > > In admin mode we should see all connected agents and mange their tokens lists > (add / remove). > May by stop/restart/agent logs view will be also useful. > To implement: > Display list of connected agent with list of users(tokens) that configured > on them. This could be a master-detail table or tree-like control. > Actions to implement > 1. Add users(tokens) by selecting from list of users. Will be nice to support > adding several users at once. > 2. Remove users. Will be nice to support removing several users at once. > 3. Restart selected web agents. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-5632) Web Console: add some kind of agent management and administration.
[ https://issues.apache.org/jira/browse/IGNITE-5632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vica Abramova updated IGNITE-5632: -- Attachment: (was: Connections.png) > Web Console: add some kind of agent management and administration. > -- > > Key: IGNITE-5632 > URL: https://issues.apache.org/jira/browse/IGNITE-5632 > Project: Ignite > Issue Type: Task > Components: wizards >Reporter: Alexey Kuznetsov >Assignee: Vica Abramova >Priority: Major > > In admin mode we should see all connected agents and mange their tokens lists > (add / remove). > May by stop/restart/agent logs view will be also useful. > To implement: > Display list of connected agent with list of users(tokens) that configured > on them. This could be a master-detail table or tree-like control. > Actions to implement > 1. Add users(tokens) by selecting from list of users. Will be nice to support > adding several users at once. > 2. Remove users. Will be nice to support removing several users at once. > 3. Restart selected web agents. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8749) Exception for "no space left" situation should be propagated to FailureHandler
[ https://issues.apache.org/jira/browse/IGNITE-8749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16516886#comment-16516886 ] ASF GitHub Bot commented on IGNITE-8749: Github user x-kreator closed the pull request at: https://github.com/apache/ignite/pull/4220 > Exception for "no space left" situation should be propagated to FailureHandler > -- > > Key: IGNITE-8749 > URL: https://issues.apache.org/jira/browse/IGNITE-8749 > Project: Ignite > Issue Type: Improvement > Components: persistence >Reporter: Sergey Chugunov >Assignee: Dmitriy Sorokin >Priority: Major > Fix For: 2.6 > > > For now if "no space left" situation is detected in > FileWriteAheadLogManager#formatFile method and corresponding exception is > thrown the exception doesn't get propagated to FailureHandler and node > continues working. > As "no space left" is a critical situation, corresponding exception should be > propagated to handler to make necessary actions. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8749) Exception for "no space left" situation should be propagated to FailureHandler
[ https://issues.apache.org/jira/browse/IGNITE-8749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16516888#comment-16516888 ] ASF GitHub Bot commented on IGNITE-8749: Github user x-kreator closed the pull request at: https://github.com/apache/ignite/pull/4216 > Exception for "no space left" situation should be propagated to FailureHandler > -- > > Key: IGNITE-8749 > URL: https://issues.apache.org/jira/browse/IGNITE-8749 > Project: Ignite > Issue Type: Improvement > Components: persistence >Reporter: Sergey Chugunov >Assignee: Dmitriy Sorokin >Priority: Major > Fix For: 2.6 > > > For now if "no space left" situation is detected in > FileWriteAheadLogManager#formatFile method and corresponding exception is > thrown the exception doesn't get propagated to FailureHandler and node > continues working. > As "no space left" is a critical situation, corresponding exception should be > propagated to handler to make necessary actions. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8749) Exception for "no space left" situation should be propagated to FailureHandler
[ https://issues.apache.org/jira/browse/IGNITE-8749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16516873#comment-16516873 ] Ivan Rakov commented on IGNITE-8749: This fix seems to cause execution timeout of PDS 2 suite. Rollback commit: 29599901cd6bcd5a8aec003edc1538dbd66530af > Exception for "no space left" situation should be propagated to FailureHandler > -- > > Key: IGNITE-8749 > URL: https://issues.apache.org/jira/browse/IGNITE-8749 > Project: Ignite > Issue Type: Improvement > Components: persistence >Reporter: Sergey Chugunov >Assignee: Dmitriy Sorokin >Priority: Major > Fix For: 2.6 > > > For now if "no space left" situation is detected in > FileWriteAheadLogManager#formatFile method and corresponding exception is > thrown the exception doesn't get propagated to FailureHandler and node > continues working. > As "no space left" is a critical situation, corresponding exception should be > propagated to handler to make necessary actions. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Reopened] (IGNITE-8749) Exception for "no space left" situation should be propagated to FailureHandler
[ https://issues.apache.org/jira/browse/IGNITE-8749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Sorokin reopened IGNITE-8749: - PR 4200 causes PDS 2 suites execution timeouts, PR 4220 needed to apply. > Exception for "no space left" situation should be propagated to FailureHandler > -- > > Key: IGNITE-8749 > URL: https://issues.apache.org/jira/browse/IGNITE-8749 > Project: Ignite > Issue Type: Improvement > Components: persistence >Reporter: Sergey Chugunov >Assignee: Dmitriy Sorokin >Priority: Major > Fix For: 2.6 > > > For now if "no space left" situation is detected in > FileWriteAheadLogManager#formatFile method and corresponding exception is > thrown the exception doesn't get propagated to FailureHandler and node > continues working. > As "no space left" is a critical situation, corresponding exception should be > propagated to handler to make necessary actions. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8827) Disable WAL during apply updates on recovery
Dmitriy Govorukhin created IGNITE-8827: -- Summary: Disable WAL during apply updates on recovery Key: IGNITE-8827 URL: https://issues.apache.org/jira/browse/IGNITE-8827 Project: Ignite Issue Type: Bug Reporter: Dmitriy Govorukhin -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8827) Disable WAL during apply updates on recovery
[ https://issues.apache.org/jira/browse/IGNITE-8827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Govorukhin updated IGNITE-8827: --- Fix Version/s: 2.6 > Disable WAL during apply updates on recovery > > > Key: IGNITE-8827 > URL: https://issues.apache.org/jira/browse/IGNITE-8827 > Project: Ignite > Issue Type: Bug >Reporter: Dmitriy Govorukhin >Priority: Major > Fix For: 2.6 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-8827) Disable WAL during apply updates on recovery
[ https://issues.apache.org/jira/browse/IGNITE-8827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Govorukhin reassigned IGNITE-8827: -- Assignee: Dmitriy Govorukhin > Disable WAL during apply updates on recovery > > > Key: IGNITE-8827 > URL: https://issues.apache.org/jira/browse/IGNITE-8827 > Project: Ignite > Issue Type: Bug >Reporter: Dmitriy Govorukhin >Assignee: Dmitriy Govorukhin >Priority: Major > Fix For: 2.6 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-8826) Add missed licence to pom file
[ https://issues.apache.org/jira/browse/IGNITE-8826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Babak resolved IGNITE-8826. Resolution: Fixed added licence header to pom added apache licence file to licences folder Merged. > Add missed licence to pom file > -- > > Key: IGNITE-8826 > URL: https://issues.apache.org/jira/browse/IGNITE-8826 > Project: Ignite > Issue Type: Bug > Components: ml >Reporter: Yury Babak >Assignee: Yury Babak >Priority: Major > Fix For: 2.6 > > > Add missed licence to modules\tensorflow\pom.xml -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8826) Add missed licence to pom file
Yury Babak created IGNITE-8826: -- Summary: Add missed licence to pom file Key: IGNITE-8826 URL: https://issues.apache.org/jira/browse/IGNITE-8826 Project: Ignite Issue Type: Bug Components: ml Reporter: Yury Babak Assignee: Yury Babak Fix For: 2.6 Add missed licence to modules\tensorflow\pom.xml -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (IGNITE-8825) Ignite - Configuration for IGFS
[ https://issues.apache.org/jira/browse/IGNITE-8825?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Puviarasu closed IGNITE-8825. - > Ignite - Configuration for IGFS > > > Key: IGNITE-8825 > URL: https://issues.apache.org/jira/browse/IGNITE-8825 > Project: Ignite > Issue Type: Test >Reporter: Puviarasu >Priority: Trivial > > Default configuration not working for IGFS -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-8825) Ignite - Configuration for IGFS
[ https://issues.apache.org/jira/browse/IGNITE-8825?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Puviarasu resolved IGNITE-8825. --- Resolution: Invalid > Ignite - Configuration for IGFS > > > Key: IGNITE-8825 > URL: https://issues.apache.org/jira/browse/IGNITE-8825 > Project: Ignite > Issue Type: Test >Reporter: Puviarasu >Priority: Trivial > > Default configuration not working for IGFS -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8825) Ignite - Configuration for IGFS
Puviarasu created IGNITE-8825: - Summary: Ignite - Configuration for IGFS Key: IGNITE-8825 URL: https://issues.apache.org/jira/browse/IGNITE-8825 Project: Ignite Issue Type: Test Reporter: Puviarasu Default configuration not working for IGFS -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-8506) Visor CMD: Show consistent ID in node tables.
[ https://issues.apache.org/jira/browse/IGNITE-8506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov reassigned IGNITE-8506: Resolution: Fixed Assignee: Pavel Konstantinov (was: Alexey Kuznetsov) Merged to master. > Visor CMD: Show consistent ID in node tables. > - > > Key: IGNITE-8506 > URL: https://issues.apache.org/jira/browse/IGNITE-8506 > Project: Ignite > Issue Type: Bug > Components: visor >Reporter: Vasiliy Sisko >Assignee: Pavel Konstantinov >Priority: Major > Fix For: 2.7 > > Attachments: screenshot-1.png > > > Add for topology command. > Check other command and add on node tables if exist. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8808) Improve control.sh --tx command to show local and remote transactions.
[ https://issues.apache.org/jira/browse/IGNITE-8808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16516757#comment-16516757 ] Alexei Scherbakov commented on IGNITE-8808: --- [~agoncharuk], Please review. > Improve control.sh --tx command to show local and remote transactions. > -- > > Key: IGNITE-8808 > URL: https://issues.apache.org/jira/browse/IGNITE-8808 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.5 >Reporter: Alexei Scherbakov >Assignee: Alexei Scherbakov >Priority: Major > Fix For: 2.6 > > > Currently --tx option for control.sh shows only transactions found on > near(initiating) nodes. > Due to various issues it's possible to have corresponding dht local and > remote transaction without near part. > Such transactions must be visible to utility. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8620) Remove intOrder and loc keys from node info in control.sh --tx utility
[ https://issues.apache.org/jira/browse/IGNITE-8620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16516751#comment-16516751 ] Alexei Scherbakov commented on IGNITE-8620: --- Yes it should > Remove intOrder and loc keys from node info in control.sh --tx utility > -- > > Key: IGNITE-8620 > URL: https://issues.apache.org/jira/browse/IGNITE-8620 > Project: Ignite > Issue Type: Improvement >Reporter: Dmitry Sherstobitov >Assignee: Alexand Polyakov >Priority: Major > > For now this information displayed in control.sh utility for each node: > TcpDiscoveryNode [id=2ed402d5-b5a7-4ade-a77a-12c2feea95ec, > addrs=[0:0:0:0:0:0:0:1%lo, 127.0.0.1, 172.25.1.47], > sockAddrs=[/0:0:0:0:0:0:0:1%lo:0, /127.0.0.1:0, /172.25.1.47:0], discPort=0, > order=6, intOrder=6, lastExchangeTime=1526482701193, loc=false, > ver=2.5.1#20180510-sha1:ee417b82, isClient=true] > loc and intOrder values are internal information and there is not need to > display it > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8594) Make error messages in validate_indexes command report more informative
[
https://issues.apache.org/jira/browse/IGNITE-8594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16516749#comment-16516749
]
Vladislav Pyatkov commented on IGNITE-8594:
---
New TC pass
https://ci.ignite.apache.org/viewQueued.html?itemId=1403205=queuedBuildOverviewTab
> Make error messages in validate_indexes command report more informative
> ---
>
> Key: IGNITE-8594
> URL: https://issues.apache.org/jira/browse/IGNITE-8594
> Project: Ignite
> Issue Type: Improvement
>Reporter: Ivan Rakov
>Assignee: Vladislav Pyatkov
>Priority: Major
> Fix For: 2.6
>
>
> In case index is broken and contains links to missing items in data pages,
> validate_indexes command will show "Item not found" messages in report:
> {noformat}
> IndexValidationIssue [key=null, cacheName=cache_group_1_028,
> idxName=_key_PK], class java.lang.IllegalStateException: Item not found: 65
> IndexValidationIssue [key=null, cacheName=cache_group_1_028,
> idxName=_key_PK], class java.lang.IllegalStateException: Item not found: 15
> SQL Index [cache=cache_group_1_028, idx=LONG__VAL_IDX]
> ValidateIndexesPartitionResult [consistentId=node2, sqlIdxName=LONG__VAL_IDX]
> IndexValidationIssue [key=null, cacheName=cache_group_1_028,
> idxName=LONG__VAL_IDX], class java.lang.IllegalStateException: Item not
> found: 60
> IndexValidationIssue [key=null, cacheName=cache_group_1_028,
> idxName=LONG__VAL_IDX], class java.lang.IllegalStateException: Item not
> found: 65
> IndexValidationIssue [key=null, cacheName=cache_group_1_028,
> idxName=LONG__VAL_IDX], class java.lang.IllegalStateException: Item not
> found: 65
> IndexValidationIssue [key=null, cacheName=cache_group_1_028,
> idxName=LONG__VAL_IDX], class java.lang.IllegalStateException: Item not
> found: 15
> {noformat}
> It would be better to explain what is happening: key is present in SQL index,
> but is missing in corresponding data page.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-8506) Visor CMD: Show consistent ID in node tables.
[ https://issues.apache.org/jira/browse/IGNITE-8506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov updated IGNITE-8506: - Fix Version/s: 2.7 > Visor CMD: Show consistent ID in node tables. > - > > Key: IGNITE-8506 > URL: https://issues.apache.org/jira/browse/IGNITE-8506 > Project: Ignite > Issue Type: Bug > Components: visor >Reporter: Vasiliy Sisko >Assignee: Alexey Kuznetsov >Priority: Major > Fix For: 2.7 > > Attachments: screenshot-1.png > > > Add for topology command. > Check other command and add on node tables if exist. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8506) Visor CMD: Show consistent ID in node tables.
[ https://issues.apache.org/jira/browse/IGNITE-8506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov updated IGNITE-8506: - Component/s: visor > Visor CMD: Show consistent ID in node tables. > - > > Key: IGNITE-8506 > URL: https://issues.apache.org/jira/browse/IGNITE-8506 > Project: Ignite > Issue Type: Bug > Components: visor >Reporter: Vasiliy Sisko >Assignee: Alexey Kuznetsov >Priority: Major > Fix For: 2.7 > > Attachments: screenshot-1.png > > > Add for topology command. > Check other command and add on node tables if exist. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8362) Collect service deployment results asynchronously on coordinator
[ https://issues.apache.org/jira/browse/IGNITE-8362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Daradur updated IGNITE-8362: --- Fix Version/s: 2.7 > Collect service deployment results asynchronously on coordinator > > > Key: IGNITE-8362 > URL: https://issues.apache.org/jira/browse/IGNITE-8362 > Project: Ignite > Issue Type: Improvement > Components: managed services >Reporter: Denis Mekhanikov >Assignee: Vyacheslav Daradur >Priority: Major > Labels: iep-17 > Fix For: 2.7 > > > When service deployment discovery message is sent, assigned nodes should > start the deployment asynchronously outside the discovery thread. > Deployment results should be sent to the coordinator over communication. > Deployment should be considered finished once all deployment result are > collected. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8361) Use discovery messages for service deployment
[ https://issues.apache.org/jira/browse/IGNITE-8361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Daradur updated IGNITE-8361: --- Fix Version/s: 2.7 > Use discovery messages for service deployment > - > > Key: IGNITE-8361 > URL: https://issues.apache.org/jira/browse/IGNITE-8361 > Project: Ignite > Issue Type: Improvement > Components: managed services >Reporter: Denis Mekhanikov >Assignee: Vyacheslav Daradur >Priority: Major > Labels: iep-17 > Fix For: 2.7 > > > Service deployment should be based on discovery messages distribution. > The procedure is as follows: > # Deploying node sends a message with a service configuration. > # Coordinator calculates the assignments and sends them in another message. > # Nodes check, whether they are assigned to deploy any services, and do so, > if they are. > Utility cache won't be needed after these changes are made. All its mentions > should be removed from the code. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-3392) Propagate service deployment results from assigned nodes to initiator
[
https://issues.apache.org/jira/browse/IGNITE-3392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Daradur updated IGNITE-3392:
---
Fix Version/s: 2.7
> Propagate service deployment results from assigned nodes to initiator
> -
>
> Key: IGNITE-3392
> URL: https://issues.apache.org/jira/browse/IGNITE-3392
> Project: Ignite
> Issue Type: Improvement
> Components: managed services
>Affects Versions: 1.6
>Reporter: Valentin Kulichenko
>Assignee: Vyacheslav Daradur
>Priority: Major
> Labels: iep-17
> Fix For: 2.7
>
> Attachments: Test.java
>
>
> Test that demonstrates the issue is attached. If exception is thrown from the
> {{Service.init()}} method, it's only printed out on the server not propagated
> to the client. If client then tries to get the proxy, it goes to infinite
> loop.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8428) Web Console: Support connect to secured cluster
[ https://issues.apache.org/jira/browse/IGNITE-8428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16516707#comment-16516707 ] ASF GitHub Bot commented on IGNITE-8428: GitHub user akuznetsov-gridgain opened a pull request: https://github.com/apache/ignite/pull/4221 IGNITE-8428 Web Console: Implemented connection to secured cluster. You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-8428 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4221.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #4221 commit a70d0335e661bbfb69c68b8a38c10c289dab261f Author: Alexey Kuznetsov Date: 2018-06-19T04:47:03Z IGNITE-8428 Web Console: Implemented connection to secured cluster. commit ba452276d918fb258fa48b50b32303c47e19561c Author: Alexey Kuznetsov Date: 2018-06-19T06:29:06Z IGNITE-8428 Minor cleanup. > Web Console: Support connect to secured cluster > --- > > Key: IGNITE-8428 > URL: https://issues.apache.org/jira/browse/IGNITE-8428 > Project: Ignite > Issue Type: Bug > Components: wizards >Reporter: Alexey Kuznetsov >Priority: Major > > See: > https://stackoverflow.com/questions/50065120/how-to-add-security-to-run-ignite-web-console-in-k8s -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-1903) Cache configuration is serialized to nodes whether they require it or not
[
https://issues.apache.org/jira/browse/IGNITE-1903?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov reassigned IGNITE-1903:
---
Assignee: (was: Vladimir Ozerov)
> Cache configuration is serialized to nodes whether they require it or not
> -
>
> Key: IGNITE-1903
> URL: https://issues.apache.org/jira/browse/IGNITE-1903
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 1.5.0.final
>Reporter: Michael Griggs
>Priority: Major
> Labels: community, usability
> Fix For: 2.6
>
>
> See User discussion thread:
> http://apache-ignite-users.70518.x6.nabble.com/CacheStore-being-serialized-to-client-td1931.html
> Brief summary: When a grid client joins the grid (clientMode=true) it
> receives a message from the server node(s) on the grid that contains the
> serialized CacheStore implementation object. If the client does not have
> this class on its CLASSPATH (and there is no reason it should, as it is a
> client) then the de-serialization of this message will fail, causing this
> exception:
> {code}SEVERE: Failed to unmarshal discovery data for component: 1
> class org.apache.ignite.IgniteCheckedException: Failed to find class with
> given class loader for unmarshalling (make sure same versions of all classes
> are available on all nodes or enable peer-class-loading):
> sun.misc.Launcher$AppClassLoader@14dad5dc
> at
> org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal(JdkMarshaller.java:104)
>
> at
> org.apache.ignite.marshaller.AbstractMarshaller.unmarshal(AbstractMarshaller.java:67)
>
> at
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.onExchange(TcpDiscoverySpi.java:1529)
>
> at
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.processNodeAddFinishedMessage(ClientImpl.java:1317)
>
> at
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.processDiscoveryMessage(ClientImpl.java:1229)
>
> at
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.body(ClientImpl.java:1199)
>
> at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
> Caused by: java.lang.ClassNotFoundException:
> c.g.r.cachewrapper.ignite.CacheMissHandlerIgnite
> {code}
> where {{c.g.r.cachewrapper.ignite.CacheMissHandlerIgnite}} is the CacheStore
> implementation.
> The ostensible reason for the CacheStore serialization is so that clients of
> a TRANSACTIONAL cache can begin the transaction on the underlying store.
> The only current solution to this is to add the grid node's CacheStore
> implementation class definition to the CLASSPATH of the client. This creates
> an *undesirable coupling* between server and client.
> ---
> *UPDATE (copy-paste from comment below)*
> This is actually more generic issue. When a new node joins (client or
> server), all existing cache configurations (which include cache stores) are
> sent to this node. It then deserializes it during startup which can cause
> exceptions on clients or servers where cache is not supposed to be deployed
> as defined by node filter.
> As a solution we can do the following:
> * During discovery, send node filter and cache store factory in binary format
> along with the cache configuration, not as its parts.
> * On server, check node filter first and deserialize cache configuration and
> cache store only if it returns true. In case of error, STOP join process (now
> we just print exception in log and go on, which is very error-prone).
> * On client, do not deserialize cache configuration and cache store until
> user's code tries to actually use the cache (calls Ignite.cache. If cache is
> ATOMIC, never deserialize the cache store.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
