[jira] [Updated] (IGNITE-12879) Refactor test configuration of discovery messages interceptors.
[
https://issues.apache.org/jira/browse/IGNITE-12879?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Petrov updated IGNITE-12879:
Description:
It's needed to change DiscoveryHook class method naming to the following:
{code:java}
public void beforeDiscovery(DiscoverySpiCustomMessage msg)
public void afterDiscovery(DiscoverySpiCustomMessage msg)
{code}
It will help to clarify the purpose of the methods.
It's needed to add the ability to configure DiscoveryHook instance through
TestTcpDiscoverySpi for discovery messages interception. It helps to avoid
redefinition of the TestTcpDiscoverySpi and its reconfiguration. The current
approach is as follows:
{code:java}
TcpDiscoverySpi spi = new TestTcpDiscoverySpi() {
@Override public void setListener(@Nullable DiscoverySpiListener lsnr) {
super.setListener(DiscoverySpiListenerWrapper.wrap(lsnr,
discoveryHook));
}
};
spi.setIpFinder(((TcpDiscoverySpi)cfg.getDiscoverySpi()).getIpFinder());
{code}
was:
It's needed to change DiscoveryHook class method naming to the following:
{code:java}
public void beforeDiscovery(DiscoverySpiCustomMessage msg)
public void afterDiscovery(DiscoverySpiCustomMessage msg)
{code}
It will help to clarify the purpose of the methods.
It's needed to add the ability to configure multiple DiscoveryHook instances
through TestTcpDiscoverySpi for discovery messages interception. It helps to
avoid redefinition of the TestTcpDiscoverySpi and its reconfiguration. The
current approach is as follows:
{code:java}
TcpDiscoverySpi spi = new TestTcpDiscoverySpi() {
@Override public void setListener(@Nullable DiscoverySpiListener lsnr) {
super.setListener(DiscoverySpiListenerWrapper.wrap(lsnr,
discoveryHook));
}
};
spi.setIpFinder(((TcpDiscoverySpi)cfg.getDiscoverySpi()).getIpFinder());
{code}
> Refactor test configuration of discovery messages interceptors.
> ---
>
> Key: IGNITE-12879
> URL: https://issues.apache.org/jira/browse/IGNITE-12879
> Project: Ignite
> Issue Type: Improvement
>Reporter: Mikhail Petrov
>Assignee: Mikhail Petrov
>Priority: Minor
> Time Spent: 2h 50m
> Remaining Estimate: 0h
>
> It's needed to change DiscoveryHook class method naming to the following:
> {code:java}
> public void beforeDiscovery(DiscoverySpiCustomMessage msg)
> public void afterDiscovery(DiscoverySpiCustomMessage msg)
> {code}
> It will help to clarify the purpose of the methods.
> It's needed to add the ability to configure DiscoveryHook instance through
> TestTcpDiscoverySpi for discovery messages interception. It helps to avoid
> redefinition of the TestTcpDiscoverySpi and its reconfiguration. The current
> approach is as follows:
> {code:java}
> TcpDiscoverySpi spi = new TestTcpDiscoverySpi() {
> @Override public void setListener(@Nullable DiscoverySpiListener lsnr) {
> super.setListener(DiscoverySpiListenerWrapper.wrap(lsnr,
> discoveryHook));
> }
> };
> spi.setIpFinder(((TcpDiscoverySpi)cfg.getDiscoverySpi()).getIpFinder());
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12879) Refactor test configuration of discovery messages interceptors.
[
https://issues.apache.org/jira/browse/IGNITE-12879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17085443#comment-17085443
]
Ignite TC Bot commented on IGNITE-12879:
{panel:title=Branch: [pull/7647/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5228355buildTypeId=IgniteTests24Java8_RunAll]
> Refactor test configuration of discovery messages interceptors.
> ---
>
> Key: IGNITE-12879
> URL: https://issues.apache.org/jira/browse/IGNITE-12879
> Project: Ignite
> Issue Type: Improvement
>Reporter: Mikhail Petrov
>Assignee: Mikhail Petrov
>Priority: Minor
> Time Spent: 2h 50m
> Remaining Estimate: 0h
>
> It's needed to change DiscoveryHook class method naming to the following:
> {code:java}
> public void beforeDiscovery(DiscoverySpiCustomMessage msg)
> public void afterDiscovery(DiscoverySpiCustomMessage msg)
> {code}
> It will help to clarify the purpose of the methods.
> It's needed to add the ability to configure multiple DiscoveryHook instances
> through TestTcpDiscoverySpi for discovery messages interception. It helps to
> avoid redefinition of the TestTcpDiscoverySpi and its reconfiguration. The
> current approach is as follows:
> {code:java}
> TcpDiscoverySpi spi = new TestTcpDiscoverySpi() {
> @Override public void setListener(@Nullable DiscoverySpiListener lsnr) {
> super.setListener(DiscoverySpiListenerWrapper.wrap(lsnr,
> discoveryHook));
> }
> };
> spi.setIpFinder(((TcpDiscoverySpi)cfg.getDiscoverySpi()).getIpFinder());
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12853) ThinClient: Introduce Features for thin clients
[ https://issues.apache.org/jira/browse/IGNITE-12853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17085330#comment-17085330 ] Igor Sapego commented on IGNITE-12853: -- [~ptupitsyn], [~alex_pl], fixed comments. [~nizhikov] yes, I'd like to sees it in 2.8.1 > ThinClient: Introduce Features for thin clients > --- > > Key: IGNITE-12853 > URL: https://issues.apache.org/jira/browse/IGNITE-12853 > Project: Ignite > Issue Type: Bug > Components: thin client >Reporter: Igor Sapego >Assignee: Igor Sapego >Priority: Major > Fix For: 2.9 > > Time Spent: 2h 10m > Remaining Estimate: 0h > > As we have a lot of different thin clients now, maintained by different > people, the issues with our backward compatibility mechanism becomes more and > more prominent. > Currently, we use protocol versioning as the only approach to provide > backward compatibility. The main issue of this approach is that we can not > skip some change in protocol and implement i.e. protocol of version 1.5 > without implementation of 1.4. There are many cases when one may want to do > so: e.g. when feature provided in 1.4 is not relevant for a specific client, > or when protocol version 1.5 contains urgent fix or feature which is easy to > implement, but its blocked by not-so-urgent and hard-to-implement feature > introduced in 1.4. > So to fix this issue I propose to introduce another backward compatibility > mechanism. The idea is to send "supported features" mask by a client to a > server, which should be answered with the same mask by the server. The > resulting set of enabled features is acquired with a simple logical "AND" > operation on these two masks. > This change has many other positive effects: > 1. It improves readability and also potentially simplifies debugging. > 2. It gives users the ability to enable or disable features of thin clients > on both server and client as they desire. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12853) ThinClient: Introduce Features for thin clients
[ https://issues.apache.org/jira/browse/IGNITE-12853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Sapego updated IGNITE-12853: - Fix Version/s: (was: 2.8.1) 2.9 > ThinClient: Introduce Features for thin clients > --- > > Key: IGNITE-12853 > URL: https://issues.apache.org/jira/browse/IGNITE-12853 > Project: Ignite > Issue Type: Bug > Components: thin client >Reporter: Igor Sapego >Assignee: Igor Sapego >Priority: Major > Fix For: 2.9 > > Time Spent: 2h 10m > Remaining Estimate: 0h > > As we have a lot of different thin clients now, maintained by different > people, the issues with our backward compatibility mechanism becomes more and > more prominent. > Currently, we use protocol versioning as the only approach to provide > backward compatibility. The main issue of this approach is that we can not > skip some change in protocol and implement i.e. protocol of version 1.5 > without implementation of 1.4. There are many cases when one may want to do > so: e.g. when feature provided in 1.4 is not relevant for a specific client, > or when protocol version 1.5 contains urgent fix or feature which is easy to > implement, but its blocked by not-so-urgent and hard-to-implement feature > introduced in 1.4. > So to fix this issue I propose to introduce another backward compatibility > mechanism. The idea is to send "supported features" mask by a client to a > server, which should be answered with the same mask by the server. The > resulting set of enabled features is acquired with a simple logical "AND" > operation on these two masks. > This change has many other positive effects: > 1. It improves readability and also potentially simplifies debugging. > 2. It gives users the ability to enable or disable features of thin clients > on both server and client as they desire. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12853) ThinClient: Introduce Features for thin clients
[ https://issues.apache.org/jira/browse/IGNITE-12853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Sapego updated IGNITE-12853: - Fix Version/s: (was: 2.9) 2.8.1 > ThinClient: Introduce Features for thin clients > --- > > Key: IGNITE-12853 > URL: https://issues.apache.org/jira/browse/IGNITE-12853 > Project: Ignite > Issue Type: Bug > Components: thin client >Reporter: Igor Sapego >Assignee: Igor Sapego >Priority: Major > Fix For: 2.8.1 > > Time Spent: 2h 10m > Remaining Estimate: 0h > > As we have a lot of different thin clients now, maintained by different > people, the issues with our backward compatibility mechanism becomes more and > more prominent. > Currently, we use protocol versioning as the only approach to provide > backward compatibility. The main issue of this approach is that we can not > skip some change in protocol and implement i.e. protocol of version 1.5 > without implementation of 1.4. There are many cases when one may want to do > so: e.g. when feature provided in 1.4 is not relevant for a specific client, > or when protocol version 1.5 contains urgent fix or feature which is easy to > implement, but its blocked by not-so-urgent and hard-to-implement feature > introduced in 1.4. > So to fix this issue I propose to introduce another backward compatibility > mechanism. The idea is to send "supported features" mask by a client to a > server, which should be answered with the same mask by the server. The > resulting set of enabled features is acquired with a simple logical "AND" > operation on these two masks. > This change has many other positive effects: > 1. It improves readability and also potentially simplifies debugging. > 2. It gives users the ability to enable or disable features of thin clients > on both server and client as they desire. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12853) ThinClient: Introduce Features for thin clients
[ https://issues.apache.org/jira/browse/IGNITE-12853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17085287#comment-17085287 ] Aleksey Plekhanov commented on IGNITE-12853: [~isapego] I left some minor comments, but generally looks good to me. > ThinClient: Introduce Features for thin clients > --- > > Key: IGNITE-12853 > URL: https://issues.apache.org/jira/browse/IGNITE-12853 > Project: Ignite > Issue Type: Bug > Components: thin client >Reporter: Igor Sapego >Assignee: Igor Sapego >Priority: Major > Fix For: 2.9 > > Time Spent: 2h 10m > Remaining Estimate: 0h > > As we have a lot of different thin clients now, maintained by different > people, the issues with our backward compatibility mechanism becomes more and > more prominent. > Currently, we use protocol versioning as the only approach to provide > backward compatibility. The main issue of this approach is that we can not > skip some change in protocol and implement i.e. protocol of version 1.5 > without implementation of 1.4. There are many cases when one may want to do > so: e.g. when feature provided in 1.4 is not relevant for a specific client, > or when protocol version 1.5 contains urgent fix or feature which is easy to > implement, but its blocked by not-so-urgent and hard-to-implement feature > introduced in 1.4. > So to fix this issue I propose to introduce another backward compatibility > mechanism. The idea is to send "supported features" mask by a client to a > server, which should be answered with the same mask by the server. The > resulting set of enabled features is acquired with a simple logical "AND" > operation on these two masks. > This change has many other positive effects: > 1. It improves readability and also potentially simplifies debugging. > 2. It gives users the ability to enable or disable features of thin clients > on both server and client as they desire. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12637) IgniteSparkSession doesn't start the clients on really distributed cluster
[
https://issues.apache.org/jira/browse/IGNITE-12637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17085251#comment-17085251
]
Andrey Aleksandrov commented on IGNITE-12637:
-
2.7.6 contains Spark 2.3.0 inside. So I tested the same version. Environment
was several AWS instances.
> IgniteSparkSession doesn't start the clients on really distributed cluster
> --
>
> Key: IGNITE-12637
> URL: https://issues.apache.org/jira/browse/IGNITE-12637
> Project: Ignite
> Issue Type: Bug
> Components: spark
>Affects Versions: 2.7.6
>Reporter: Andrey Aleksandrov
>Assignee: Yaroslav Molochkov
>Priority: Critical
> Fix For: 2.9, 2.8.1
>
>
> Next code:
> IgniteSparkSession igniteSession = IgniteSparkSession.builder()
> .appName("Spark Ignite example")
> .igniteConfig(configPath)
> .getOrCreate();
> Throws:
> class org.apache.ignite.IgniteIllegalStateException: Ignite instance with
> provided name doesn't exist. Did you call Ignition.start(..) to start an
> Ignite instance? [name=grid]
> Client config was located in all Spark nodes at the same place.
> When I ran these tests on the same host with several local executors then it
> worked. But if executors were located on different hosts then it didn't.
> DataFrame API works fine with the same config.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-12637) IgniteSparkSession doesn't start the clients on really distributed cluster
[
https://issues.apache.org/jira/browse/IGNITE-12637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17085251#comment-17085251
]
Andrey Aleksandrov edited comment on IGNITE-12637 at 4/16/20, 8:45 PM:
---
[~nizhikov] 2.7.6 contains Spark 2.3.0 inside. So I tested the same version.
Environment was several AWS instances.
was (Author: aealeksandrov):
2.7.6 contains Spark 2.3.0 inside. So I tested the same version. Environment
was several AWS instances.
> IgniteSparkSession doesn't start the clients on really distributed cluster
> --
>
> Key: IGNITE-12637
> URL: https://issues.apache.org/jira/browse/IGNITE-12637
> Project: Ignite
> Issue Type: Bug
> Components: spark
>Affects Versions: 2.7.6
>Reporter: Andrey Aleksandrov
>Assignee: Yaroslav Molochkov
>Priority: Critical
> Fix For: 2.9, 2.8.1
>
>
> Next code:
> IgniteSparkSession igniteSession = IgniteSparkSession.builder()
> .appName("Spark Ignite example")
> .igniteConfig(configPath)
> .getOrCreate();
> Throws:
> class org.apache.ignite.IgniteIllegalStateException: Ignite instance with
> provided name doesn't exist. Did you call Ignition.start(..) to start an
> Ignite instance? [name=grid]
> Client config was located in all Spark nodes at the same place.
> When I ran these tests on the same host with several local executors then it
> worked. But if executors were located on different hosts then it didn't.
> DataFrame API works fine with the same config.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12827) OutOfMemory exception when calling grid service from .NET with user type array parameter
[
https://issues.apache.org/jira/browse/IGNITE-12827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17085168#comment-17085168
]
Ivan Daschinskiy commented on IGNITE-12827:
---
[~nizhikov] Could you please take a look over my PR?
> OutOfMemory exception when calling grid service from .NET with user type
> array parameter
>
>
> Key: IGNITE-12827
> URL: https://issues.apache.org/jira/browse/IGNITE-12827
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.8
>Reporter: Alexey Kukushkin
>Assignee: Ivan Daschinskiy
>Priority: Major
> Labels: sbcf
> Fix For: 2.8.1
>
> Attachments: ignite-12827-vs-2.8.patch
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Calling a grid service from .NET with a parameter of user type array leads to
> Java OutOfMemory exception.
> +*Reproducer*+:
> * Limit JVM heap with 128 MB.
> * Create a .NET or Java service with a parameter of type
> *array of* Parameter {
> Id: int,
> *array of* ParameterValue {
> PeriodId: int,
> Value: double?
> }
> }
> * Call service with an array of 200 Parameters
> +*Expected*+:
> 128 MB of heap must be enough to call Java or .NET service with 200
> Parameters.
>
> +*Actual*+:
> Java OutOfMemory exception on 21st Parameter
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12827) OutOfMemory exception when calling grid service from .NET with user type array parameter
[
https://issues.apache.org/jira/browse/IGNITE-12827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17085165#comment-17085165
]
Ignite TC Bot commented on IGNITE-12827:
{panel:title=Branch: [pull/7679/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5228231buildTypeId=IgniteTests24Java8_RunAll]
> OutOfMemory exception when calling grid service from .NET with user type
> array parameter
>
>
> Key: IGNITE-12827
> URL: https://issues.apache.org/jira/browse/IGNITE-12827
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.8
>Reporter: Alexey Kukushkin
>Assignee: Ivan Daschinskiy
>Priority: Major
> Labels: sbcf
> Fix For: 2.8.1
>
> Attachments: ignite-12827-vs-2.8.patch
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Calling a grid service from .NET with a parameter of user type array leads to
> Java OutOfMemory exception.
> +*Reproducer*+:
> * Limit JVM heap with 128 MB.
> * Create a .NET or Java service with a parameter of type
> *array of* Parameter {
> Id: int,
> *array of* ParameterValue {
> PeriodId: int,
> Value: double?
> }
> }
> * Call service with an array of 200 Parameters
> +*Expected*+:
> 128 MB of heap must be enough to call Java or .NET service with 200
> Parameters.
>
> +*Actual*+:
> Java OutOfMemory exception on 21st Parameter
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12905) QueryKeyValueIterable missing custom spliterator() implementation
[
https://issues.apache.org/jira/browse/IGNITE-12905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Johnny Galatikitis updated IGNITE-12905:
Description:
We are using apache ignite with reactor-core and since reactors upgrade from
3.2.12 to 3.3.3 {code:java}
org.apache.ignite.internal.processors.query.QueryKeyValueIterable.iterator
{code}
is called multiple times. It starts with:
1. calling iterable.spliterator().hasCharacteristics(Spliterator.SIZED), where
iterable is instanceof QueryKeyValueIterable
2. calls default implementation Spliterators.spliteratorUnknownSize(iterator(),
0)
3. which in turn calls ignite's QueryKeyValueIterable.iterator() call and that
"uses it up" for subsequent calls, i.e. throw IgniteException "Iterator is
already fetched or query was cancelled."
was:
We are using apache ignite with reactor-core and since reactors upgrade from
3.2.12 to 3.3.3 {code:java}
org.apache.ignite.internal.processors.query.QueryKeyValueIterable
{code}
is called multiple times. It starts with:
1. calling iterable.spliterator().hasCharacteristics(Spliterator.SIZED), where
iterable is instanceof QueryKeyValueIterable
2. calls default implementation Spliterators.spliteratorUnknownSize(iterator(),
0)
3. which in turn calls ignite's QueryKeyValueIterable.iterator() call and that
"uses it up" for subsequent calls, i.e. throw IgniteException "Iterator is
already fetched or query was cancelled."
> QueryKeyValueIterable missing custom spliterator() implementation
> -
>
> Key: IGNITE-12905
> URL: https://issues.apache.org/jira/browse/IGNITE-12905
> Project: Ignite
> Issue Type: Bug
> Components: cache, general
>Affects Versions: 2.8
> Environment: Windows 10
> JDK 1.8.0_172
> ignite-core 2.8.0
> reactor-core 3.3.3
>Reporter: Johnny Galatikitis
>Priority: Critical
> Fix For: 2.8.1
>
> Attachments:
> IGNITE-12905_-_add_QueryKeyValueSpliterator_and_corresponding_test.patch
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We are using apache ignite with reactor-core and since reactors upgrade from
> 3.2.12 to 3.3.3 {code:java}
> org.apache.ignite.internal.processors.query.QueryKeyValueIterable.iterator
> {code}
> is called multiple times. It starts with:
> 1. calling iterable.spliterator().hasCharacteristics(Spliterator.SIZED),
> where iterable is instanceof QueryKeyValueIterable
> 2. calls default implementation
> Spliterators.spliteratorUnknownSize(iterator(), 0)
> 3. which in turn calls ignite's QueryKeyValueIterable.iterator() call and
> that "uses it up" for subsequent calls, i.e. throw IgniteException "Iterator
> is already fetched or query was cancelled."
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12888) Add support for ConstantName to checkstyle rules
[ https://issues.apache.org/jira/browse/IGNITE-12888?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17085117#comment-17085117 ] Pavel Pereslegin commented on IGNITE-12888: --- [~mmuzaf] Personally, I am against such change. I believe that this rule should be discussed with other contributors before applying it. > Add support for ConstantName to checkstyle rules > > > Key: IGNITE-12888 > URL: https://issues.apache.org/jira/browse/IGNITE-12888 > Project: Ignite > Issue Type: Task >Reporter: Maxim Muzafarov >Assignee: Maxim Muzafarov >Priority: Major > Fix For: 2.9 > > Time Spent: 0.5h > Remaining Estimate: 0h > > Add a new rule to checkstyle according to Apache Ignite naming conventions. > > https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines#CodingGuidelines-Naming -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12908) Confusing check for presence of SqlViewExporterSpi class in classpath during initialization
[
https://issues.apache.org/jira/browse/IGNITE-12908?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey N. Gura updated IGNITE-12908:
Description: {{IgnitionEx.initializeDefaultSpi()}} method checks for
presence of {{SqlViewExporterSpi}} class in classpath whilst actual intention
is to check for presence of indexing in classpath. It could be done just using
{{IgniteComponentType.INDEXING.inClassPath()}} method. (was:
{{IgniteEx.initializeDefaultSpi()}} method checks for presence of
{{SqlViewExporterSpi}} class in classpath whilst actual intention is to check
for presence of indexing in classpath. It could be done just using
{{IgniteComponentType.INDEXING.inClassPath()}} method.)
> Confusing check for presence of SqlViewExporterSpi class in classpath during
> initialization
> ---
>
> Key: IGNITE-12908
> URL: https://issues.apache.org/jira/browse/IGNITE-12908
> Project: Ignite
> Issue Type: Improvement
>Reporter: Andrey N. Gura
>Priority: Minor
> Labels: IEP-35
>
> {{IgnitionEx.initializeDefaultSpi()}} method checks for presence of
> {{SqlViewExporterSpi}} class in classpath whilst actual intention is to check
> for presence of indexing in classpath. It could be done just using
> {{IgniteComponentType.INDEXING.inClassPath()}} method.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12908) Confusing check for presence of SqlViewExporterSpi class in classpath during initialization
[
https://issues.apache.org/jira/browse/IGNITE-12908?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey N. Gura updated IGNITE-12908:
Summary: Confusing check for presence of SqlViewExporterSpi class in
classpath during initialization (was: Confusding check for presence of
SqlViewExporterSpi class in classpath during initialization)
> Confusing check for presence of SqlViewExporterSpi class in classpath during
> initialization
> ---
>
> Key: IGNITE-12908
> URL: https://issues.apache.org/jira/browse/IGNITE-12908
> Project: Ignite
> Issue Type: Improvement
>Reporter: Andrey N. Gura
>Priority: Minor
> Labels: IEP-35
>
> {{IgniteEx.initializeDefaultSpi()}} method checks for presence of
> {{SqlViewExporterSpi}} class in classpath whilst actual intention is to check
> for presence of indexing in classpath. It could be done just using
> {{IgniteComponentType.INDEXING.inClassPath()}} method.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-12907) GridSystemViewManager is not thread safe
[
https://issues.apache.org/jira/browse/IGNITE-12907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov reassigned IGNITE-12907:
Assignee: Nikolay Izhikov
> GridSystemViewManager is not thread safe
>
>
> Key: IGNITE-12907
> URL: https://issues.apache.org/jira/browse/IGNITE-12907
> Project: Ignite
> Issue Type: Bug
>Reporter: Andrey N. Gura
>Assignee: Nikolay Izhikov
>Priority: Major
> Labels: IEP-35
>
> {{GridSystemViewManager}} is not thread safe because it allows to registers
> walkers using public {{registerWalker()}} that just adds walker to a
> {{HashMap}}.
> It seems the simplest solution here: make {{registerWalker()}} method private
> because it has usages only from {{GridSystemViewManager}} constructor.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-12908) Confusding check for presence of SqlViewExporterSpi class in classpath during initialization
Andrey N. Gura created IGNITE-12908:
---
Summary: Confusding check for presence of SqlViewExporterSpi class
in classpath during initialization
Key: IGNITE-12908
URL: https://issues.apache.org/jira/browse/IGNITE-12908
Project: Ignite
Issue Type: Improvement
Reporter: Andrey N. Gura
{{IgniteEx.initializeDefaultSpi()}} method checks for presence of
{{SqlViewExporterSpi}} class in classpath whilst actual intention is to check
for presence of indexing in classpath. It could be done just using
{{IgniteComponentType.INDEXING.inClassPath()}} method.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-8409) Ignite gets stuck on IgniteDataStreamer.addData when using Object with AffinityKeyMapped
[ https://issues.apache.org/jira/browse/IGNITE-8409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17085072#comment-17085072 ] Nikolay Izhikov commented on IGNITE-8409: - Moved to 2.9 Please, write a comment if you want to see the fix for this issue in 2.8.1 > Ignite gets stuck on IgniteDataStreamer.addData when using Object with > AffinityKeyMapped > > > Key: IGNITE-8409 > URL: https://issues.apache.org/jira/browse/IGNITE-8409 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.3 >Reporter: Andrey Aleksandrov >Priority: Critical > Fix For: 2.9 > > Attachments: ContextCpty.java, TradeKey.java, TradeKeyNew.java > > > This problem reproduces from time to time when we are streaming the data > (TradeKey.java) to Ignite sql cache. As AffinityKeyMapped we used the object > type (ContextCpty.java) > When we change AffinityKeyMapped type from object to long type > (TradeKeyNew.java) then problem disappears. > Investigation help to understand that we hang in BPlusTree.java class in next > method: > private Result putDown(final Put p, final long pageId, final long fwdId, > final int lvl) > In this method: > res = p.tryReplaceInner(pageId, page, fwdId, lvl); > if (res != RETRY) // Go down recursively. > res = putDown(p, p.pageId, p.fwdId, lvl - 1); > if (res == RETRY_ROOT || p.isFinished()) > return res; > if (res == RETRY) > checkInterrupted(); //WE ALWAYS GO TO THIS PLACE -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-8409) Ignite gets stuck on IgniteDataStreamer.addData when using Object with AffinityKeyMapped
[ https://issues.apache.org/jira/browse/IGNITE-8409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov updated IGNITE-8409: Fix Version/s: (was: 2.8.1) > Ignite gets stuck on IgniteDataStreamer.addData when using Object with > AffinityKeyMapped > > > Key: IGNITE-8409 > URL: https://issues.apache.org/jira/browse/IGNITE-8409 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.3 >Reporter: Andrey Aleksandrov >Priority: Critical > Fix For: 2.9 > > Attachments: ContextCpty.java, TradeKey.java, TradeKeyNew.java > > > This problem reproduces from time to time when we are streaming the data > (TradeKey.java) to Ignite sql cache. As AffinityKeyMapped we used the object > type (ContextCpty.java) > When we change AffinityKeyMapped type from object to long type > (TradeKeyNew.java) then problem disappears. > Investigation help to understand that we hang in BPlusTree.java class in next > method: > private Result putDown(final Put p, final long pageId, final long fwdId, > final int lvl) > In this method: > res = p.tryReplaceInner(pageId, page, fwdId, lvl); > if (res != RETRY) // Go down recursively. > res = putDown(p, p.pageId, p.fwdId, lvl - 1); > if (res == RETRY_ROOT || p.isFinished()) > return res; > if (res == RETRY) > checkInterrupted(); //WE ALWAYS GO TO THIS PLACE -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12852) Comma in field is not supported by COPY command
[ https://issues.apache.org/jira/browse/IGNITE-12852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17085066#comment-17085066 ] Nikolay Izhikov commented on IGNITE-12852: -- Hello [~rkondakov] Can you, please, take a look at this changes? > Comma in field is not supported by COPY command > --- > > Key: IGNITE-12852 > URL: https://issues.apache.org/jira/browse/IGNITE-12852 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.8 >Reporter: YuJue Li >Assignee: YuJue Li >Priority: Critical > Fix For: 2.8.1 > > Time Spent: 10m > Remaining Estimate: 0h > > CREATE TABLE test(a int,b varchar(100),c int,PRIMARY key(a)); > > a.csv: > 1,"a,b",2 > > COPY FROM '/data/a.csv' INTO test (a,b,c) FORMAT CSV; > > The copy command fails because there is a comma in the second field,but this > is a fully legal and compliant CSV format -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12905) QueryKeyValueIterable missing custom spliterator() implementation
[
https://issues.apache.org/jira/browse/IGNITE-12905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17085064#comment-17085064
]
Nikolay Izhikov commented on IGNITE-12905:
--
Hello, [~bleedah]
Thanks for the PR.
I will try to find a reviewer for it at the nearest time.
> QueryKeyValueIterable missing custom spliterator() implementation
> -
>
> Key: IGNITE-12905
> URL: https://issues.apache.org/jira/browse/IGNITE-12905
> Project: Ignite
> Issue Type: Bug
> Components: cache, general
>Affects Versions: 2.8
> Environment: Windows 10
> JDK 1.8.0_172
> ignite-core 2.8.0
> reactor-core 3.3.3
>Reporter: Johnny Galatikitis
>Priority: Critical
> Fix For: 2.8.1
>
> Attachments:
> IGNITE-12905_-_add_QueryKeyValueSpliterator_and_corresponding_test.patch
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We are using apache ignite with reactor-core and since reactors upgrade from
> 3.2.12 to 3.3.3 {code:java}
> org.apache.ignite.internal.processors.query.QueryKeyValueIterable
> {code}
> is called multiple times. It starts with:
> 1. calling iterable.spliterator().hasCharacteristics(Spliterator.SIZED),
> where iterable is instanceof QueryKeyValueIterable
> 2. calls default implementation
> Spliterators.spliteratorUnknownSize(iterator(), 0)
> 3. which in turn calls ignite's QueryKeyValueIterable.iterator() call and
> that "uses it up" for subsequent calls, i.e. throw IgniteException "Iterator
> is already fetched or query was cancelled."
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12801) Possible extra page release when throttling and checkpoint thread store its concurrently
[
https://issues.apache.org/jira/browse/IGNITE-12801?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov updated IGNITE-12801:
-
Fix Version/s: 2.8.1
> Possible extra page release when throttling and checkpoint thread store its
> concurrently
>
>
> Key: IGNITE-12801
> URL: https://issues.apache.org/jira/browse/IGNITE-12801
> Project: Ignite
> Issue Type: Bug
>Reporter: Anton Kalashnikov
>Assignee: Anton Kalashnikov
>Priority: Major
> Fix For: 2.8.1
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> * User thread acquire page on write release
> * Checkpoint thread sees that page was acquired
> * Throttling thread sees that page was acquired
> * Checkpoint thread saves page to disk and releases the page
> * Throttling thread understand that the page was already saved but
> nonetheless release this page again. - this is not ok.
> {noformat}
> java.lang.AssertionError: null
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.copyPageForCheckpoint(PageMemoryImpl.java:1181)
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.checkpointWritePage(PageMemoryImpl.java:1160)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$WriteCheckpointPages.writePages(GridCacheDatabaseSharedManager.java:4868)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$WriteCheckpointPages.run(GridCacheDatabaseSharedManager.java:4792)
> ... 3 common frames omitted
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12801) Possible extra page release when throttling and checkpoint thread store its concurrently
[
https://issues.apache.org/jira/browse/IGNITE-12801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17085060#comment-17085060
]
Nikolay Izhikov commented on IGNITE-12801:
--
Included to 2.8.1 scope.
> Possible extra page release when throttling and checkpoint thread store its
> concurrently
>
>
> Key: IGNITE-12801
> URL: https://issues.apache.org/jira/browse/IGNITE-12801
> Project: Ignite
> Issue Type: Bug
>Reporter: Anton Kalashnikov
>Assignee: Anton Kalashnikov
>Priority: Major
> Fix For: 2.8.1
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> * User thread acquire page on write release
> * Checkpoint thread sees that page was acquired
> * Throttling thread sees that page was acquired
> * Checkpoint thread saves page to disk and releases the page
> * Throttling thread understand that the page was already saved but
> nonetheless release this page again. - this is not ok.
> {noformat}
> java.lang.AssertionError: null
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.copyPageForCheckpoint(PageMemoryImpl.java:1181)
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.checkpointWritePage(PageMemoryImpl.java:1160)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$WriteCheckpointPages.writePages(GridCacheDatabaseSharedManager.java:4868)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$WriteCheckpointPages.run(GridCacheDatabaseSharedManager.java:4792)
> ... 3 common frames omitted
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-10782) javadoc description for ml.math.exceptions.preprocessing and ml.selection.scoring.evaluator
[ https://issues.apache.org/jira/browse/IGNITE-10782?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Zinoviev updated IGNITE-10782: - Fix Version/s: (was: 2.8.1) 2.9 > javadoc description for ml.math.exceptions.preprocessing and > ml.selection.scoring.evaluator > --- > > Key: IGNITE-10782 > URL: https://issues.apache.org/jira/browse/IGNITE-10782 > Project: Ignite > Issue Type: Bug > Components: documentation, ml >Reporter: Stepan Pilschikov >Assignee: Alexey Zinoviev >Priority: Critical > Fix For: 2.9 > > > Need to add modules description for > - org.apache.ignite.ml.math.exceptions.preprocessing > - org.apache.ignite.ml.selection.scoring.evaluator > Located in ignite/docs/overview-summary.html -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-9740) [ML] Remove IgniteThread wrapper from ml unit test EvaluatorTest (follow up to IGNITE-9711)
[
https://issues.apache.org/jira/browse/IGNITE-9740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17085054#comment-17085054
]
Alexey Zinoviev commented on IGNITE-9740:
-
All ML related bugs are not urgent and are not influence on users.
> [ML] Remove IgniteThread wrapper from ml unit test EvaluatorTest (follow up
> to IGNITE-9711)
> ---
>
> Key: IGNITE-9740
> URL: https://issues.apache.org/jira/browse/IGNITE-9740
> Project: Ignite
> Issue Type: Bug
> Components: ml
>Reporter: Oleg Ignatenko
>Assignee: Alexey Zinoviev
>Priority: Critical
> Fix For: 2.9
>
>
> [EvaluatorTest|https://github.com/apache/ignite/blob/master/modules/ml/src/test/java/org/apache/ignite/ml/selection/scoring/evaluator/EvaluatorTest.java]
> involves {{IgniteThread}} which is in fact not needed there and should be
> removed.
> {{IgniteThread}} usage is a remainder / copy-paste from older tests and
> examples that were using API requiring it. This API has been removed and
> there is no need for wrapping like that anymore. For the reference on how to
> perform suggested cleanup check changes made to ml examples per IGNITE-9711.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12096) Used memory metric does not contract when cache is emptied - FreeList REUSE_BUCKET is not accounted for
[
https://issues.apache.org/jira/browse/IGNITE-12096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17085052#comment-17085052
]
Nikolay Izhikov commented on IGNITE-12096:
--
Moved to 2.9
Please, write a comment if you want to see the fix for this issue in 2.8.1
> Used memory metric does not contract when cache is emptied - FreeList
> REUSE_BUCKET is not accounted for
> ---
>
> Key: IGNITE-12096
> URL: https://issues.apache.org/jira/browse/IGNITE-12096
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.7
>Reporter: Colin Cassidy
>Priority: Major
> Fix For: 2.9
>
>
> When using the Ignite metrics API to measure available memory, the usage
> figures appear to be accurate while memory is being consumed - but when
> memory is freed the metrics do not drop. They appear to report that memory
> has not been freed up, even though it has.
> A reliable estimate of memory consumption is very important for solutions
> that don't use native persistence - as this is the only controllable way of
> avoiding a critical OOM condition.
> Reproducer below. This affects Ignite 2.7+.
> {{public class MemoryTest2 { }}
> {{ private static final String CACHE_NAME = "cache"; }}
> {{ private static final String DEFAULT_MEMORY_REGION = "Default_Region";
> }}
> {{ private static final long MEM_SIZE = 100L * 1024 * 1024; }}
> {{ @Test }}
> {{ public void testOOM() throws InterruptedException { }}
> {{ try (Ignite ignite = startIgnite("IgniteMemoryMonitorTest1")) { }}
> {{ fillDataRegion(ignite); }}
> {{ CacheConfiguration cfg = new }}
> {{CacheConfiguration<>(CACHE_NAME); }}
> {{ cfg.setStatisticsEnabled(true); }}
> {{ IgniteCache cache = }}
> {{ignite.getOrCreateCache(cfg); }}
> {{ // Clear all entries from the cache to free up memory }}
> {{ memUsed(ignite); }}
> {{ cache.clear(); }}
> {{ cache.removeAll(); }}
> {{ cache.put("Key", "Value"); }}
> {{ memUsed(ignite); }}
> {{ cache.destroy(); }}
> {{ Thread.sleep(5000); }}
> {{ // Should now report close to 0% but reports 59% still }}
> {{ memUsed(ignite); }}
> {{ } }}
> {{ } }}
> {{ }}
> {{ private Ignite startIgnite(String instanceName) { }}
> {{ IgniteConfiguration cfg = new IgniteConfiguration(); }}
> {{ cfg.setIgniteInstanceName(instanceName); }}
> {{ cfg.setDataStorageConfiguration(createDataStorageConfiguration());
> }}
> {{ cfg.setFailureHandler(new NoOpFailureHandler()); }}
> {{ return Ignition.start(cfg); }}
> {{ } }}
> {{ private DataStorageConfiguration createDataStorageConfiguration() { }}
> {{ return new DataStorageConfiguration() }}
> {{ .setDefaultDataRegionConfiguration( }}
> {{ new DataRegionConfiguration() }}
> {{ .setName(DEFAULT_MEMORY_REGION) }}
> {{ .setInitialSize(MEM_SIZE) }}
> {{ .setMaxSize(MEM_SIZE) }}
> {{ .setMetricsEnabled(true)); }}
> {{ } }}
> {{ private void fillDataRegion(Ignite ignite) { }}
> {{ byte[] megabyte = new byte[1024 * 1024]; }}
> {{ IgniteCache cache = }}
> {{ ignite.getOrCreateCache(CACHE_NAME); }}
> {{ for (int i = 0; i < 50; i++) { }}
> {{ cache.put(i, megabyte); }}
> {{ memUsed(ignite); }}
> {{ } }}
> {{ } }}
> {{ private void memUsed(Ignite ignite) { }}
> {{ DataRegionConfiguration defaultDataRegionCfg = }}
> {{ignite.configuration() }}
> {{ .getDataStorageConfiguration() }}
> {{ .getDefaultDataRegionConfiguration(); }}
> {{ String regionName = defaultDataRegionCfg.getName(); }}
> {{ DataRegionMetrics metrics = ignite.dataRegionMetrics(regionName);
> }}
> {{ float usedMem = metrics.getPagesFillFactor() * }}
> {{metrics.getTotalAllocatedPages() * metrics.getPageSize(); }}
> {{ float pctUsed = 100 * usedMem / defaultDataRegionCfg.getMaxSize();
> }}
> {{ System.out.println("Memory used: " + pctUsed + "%"); }}
> {{ } }}
> {{} }}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12096) Used memory metric does not contract when cache is emptied - FreeList REUSE_BUCKET is not accounted for
[
https://issues.apache.org/jira/browse/IGNITE-12096?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov updated IGNITE-12096:
-
Fix Version/s: (was: 2.8.1)
> Used memory metric does not contract when cache is emptied - FreeList
> REUSE_BUCKET is not accounted for
> ---
>
> Key: IGNITE-12096
> URL: https://issues.apache.org/jira/browse/IGNITE-12096
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.7
>Reporter: Colin Cassidy
>Priority: Major
> Fix For: 2.9
>
>
> When using the Ignite metrics API to measure available memory, the usage
> figures appear to be accurate while memory is being consumed - but when
> memory is freed the metrics do not drop. They appear to report that memory
> has not been freed up, even though it has.
> A reliable estimate of memory consumption is very important for solutions
> that don't use native persistence - as this is the only controllable way of
> avoiding a critical OOM condition.
> Reproducer below. This affects Ignite 2.7+.
> {{public class MemoryTest2 { }}
> {{ private static final String CACHE_NAME = "cache"; }}
> {{ private static final String DEFAULT_MEMORY_REGION = "Default_Region";
> }}
> {{ private static final long MEM_SIZE = 100L * 1024 * 1024; }}
> {{ @Test }}
> {{ public void testOOM() throws InterruptedException { }}
> {{ try (Ignite ignite = startIgnite("IgniteMemoryMonitorTest1")) { }}
> {{ fillDataRegion(ignite); }}
> {{ CacheConfiguration cfg = new }}
> {{CacheConfiguration<>(CACHE_NAME); }}
> {{ cfg.setStatisticsEnabled(true); }}
> {{ IgniteCache cache = }}
> {{ignite.getOrCreateCache(cfg); }}
> {{ // Clear all entries from the cache to free up memory }}
> {{ memUsed(ignite); }}
> {{ cache.clear(); }}
> {{ cache.removeAll(); }}
> {{ cache.put("Key", "Value"); }}
> {{ memUsed(ignite); }}
> {{ cache.destroy(); }}
> {{ Thread.sleep(5000); }}
> {{ // Should now report close to 0% but reports 59% still }}
> {{ memUsed(ignite); }}
> {{ } }}
> {{ } }}
> {{ }}
> {{ private Ignite startIgnite(String instanceName) { }}
> {{ IgniteConfiguration cfg = new IgniteConfiguration(); }}
> {{ cfg.setIgniteInstanceName(instanceName); }}
> {{ cfg.setDataStorageConfiguration(createDataStorageConfiguration());
> }}
> {{ cfg.setFailureHandler(new NoOpFailureHandler()); }}
> {{ return Ignition.start(cfg); }}
> {{ } }}
> {{ private DataStorageConfiguration createDataStorageConfiguration() { }}
> {{ return new DataStorageConfiguration() }}
> {{ .setDefaultDataRegionConfiguration( }}
> {{ new DataRegionConfiguration() }}
> {{ .setName(DEFAULT_MEMORY_REGION) }}
> {{ .setInitialSize(MEM_SIZE) }}
> {{ .setMaxSize(MEM_SIZE) }}
> {{ .setMetricsEnabled(true)); }}
> {{ } }}
> {{ private void fillDataRegion(Ignite ignite) { }}
> {{ byte[] megabyte = new byte[1024 * 1024]; }}
> {{ IgniteCache cache = }}
> {{ ignite.getOrCreateCache(CACHE_NAME); }}
> {{ for (int i = 0; i < 50; i++) { }}
> {{ cache.put(i, megabyte); }}
> {{ memUsed(ignite); }}
> {{ } }}
> {{ } }}
> {{ private void memUsed(Ignite ignite) { }}
> {{ DataRegionConfiguration defaultDataRegionCfg = }}
> {{ignite.configuration() }}
> {{ .getDataStorageConfiguration() }}
> {{ .getDefaultDataRegionConfiguration(); }}
> {{ String regionName = defaultDataRegionCfg.getName(); }}
> {{ DataRegionMetrics metrics = ignite.dataRegionMetrics(regionName);
> }}
> {{ float usedMem = metrics.getPagesFillFactor() * }}
> {{metrics.getTotalAllocatedPages() * metrics.getPageSize(); }}
> {{ float pctUsed = 100 * usedMem / defaultDataRegionCfg.getMaxSize();
> }}
> {{ System.out.println("Memory used: " + pctUsed + "%"); }}
> {{ } }}
> {{} }}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12801) Possible extra page release when throttling and checkpoint thread store its concurrently
[
https://issues.apache.org/jira/browse/IGNITE-12801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17085050#comment-17085050
]
Stanilovsky Evgeny commented on IGNITE-12801:
-
[~akalashnikov] very important in 2.8.1 ticket, isn`t it ? a u plan to merge it
? [~nizhikov] appeal u too )!
> Possible extra page release when throttling and checkpoint thread store its
> concurrently
>
>
> Key: IGNITE-12801
> URL: https://issues.apache.org/jira/browse/IGNITE-12801
> Project: Ignite
> Issue Type: Bug
>Reporter: Anton Kalashnikov
>Assignee: Anton Kalashnikov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> * User thread acquire page on write release
> * Checkpoint thread sees that page was acquired
> * Throttling thread sees that page was acquired
> * Checkpoint thread saves page to disk and releases the page
> * Throttling thread understand that the page was already saved but
> nonetheless release this page again. - this is not ok.
> {noformat}
> java.lang.AssertionError: null
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.copyPageForCheckpoint(PageMemoryImpl.java:1181)
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.checkpointWritePage(PageMemoryImpl.java:1160)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$WriteCheckpointPages.writePages(GridCacheDatabaseSharedManager.java:4868)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$WriteCheckpointPages.run(GridCacheDatabaseSharedManager.java:4792)
> ... 3 common frames omitted
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12853) ThinClient: Introduce Features for thin clients
[ https://issues.apache.org/jira/browse/IGNITE-12853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov updated IGNITE-12853: - Fix Version/s: (was: 2.8.1) 2.9 > ThinClient: Introduce Features for thin clients > --- > > Key: IGNITE-12853 > URL: https://issues.apache.org/jira/browse/IGNITE-12853 > Project: Ignite > Issue Type: Bug > Components: thin client >Reporter: Igor Sapego >Assignee: Igor Sapego >Priority: Major > Fix For: 2.9 > > Time Spent: 1h 40m > Remaining Estimate: 0h > > As we have a lot of different thin clients now, maintained by different > people, the issues with our backward compatibility mechanism becomes more and > more prominent. > Currently, we use protocol versioning as the only approach to provide > backward compatibility. The main issue of this approach is that we can not > skip some change in protocol and implement i.e. protocol of version 1.5 > without implementation of 1.4. There are many cases when one may want to do > so: e.g. when feature provided in 1.4 is not relevant for a specific client, > or when protocol version 1.5 contains urgent fix or feature which is easy to > implement, but its blocked by not-so-urgent and hard-to-implement feature > introduced in 1.4. > So to fix this issue I propose to introduce another backward compatibility > mechanism. The idea is to send "supported features" mask by a client to a > server, which should be answered with the same mask by the server. The > resulting set of enabled features is acquired with a simple logical "AND" > operation on these two masks. > This change has many other positive effects: > 1. It improves readability and also potentially simplifies debugging. > 2. It gives users the ability to enable or disable features of thin clients > on both server and client as they desire. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12853) ThinClient: Introduce Features for thin clients
[ https://issues.apache.org/jira/browse/IGNITE-12853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17085048#comment-17085048 ] Nikolay Izhikov commented on IGNITE-12853: -- Moved to 2.9 Please, write a comment if you want to see the fix for this issue in 2.8.1 > ThinClient: Introduce Features for thin clients > --- > > Key: IGNITE-12853 > URL: https://issues.apache.org/jira/browse/IGNITE-12853 > Project: Ignite > Issue Type: Bug > Components: thin client >Reporter: Igor Sapego >Assignee: Igor Sapego >Priority: Major > Fix For: 2.9 > > Time Spent: 1h 40m > Remaining Estimate: 0h > > As we have a lot of different thin clients now, maintained by different > people, the issues with our backward compatibility mechanism becomes more and > more prominent. > Currently, we use protocol versioning as the only approach to provide > backward compatibility. The main issue of this approach is that we can not > skip some change in protocol and implement i.e. protocol of version 1.5 > without implementation of 1.4. There are many cases when one may want to do > so: e.g. when feature provided in 1.4 is not relevant for a specific client, > or when protocol version 1.5 contains urgent fix or feature which is easy to > implement, but its blocked by not-so-urgent and hard-to-implement feature > introduced in 1.4. > So to fix this issue I propose to introduce another backward compatibility > mechanism. The idea is to send "supported features" mask by a client to a > server, which should be answered with the same mask by the server. The > resulting set of enabled features is acquired with a simple logical "AND" > operation on these two masks. > This change has many other positive effects: > 1. It improves readability and also potentially simplifies debugging. > 2. It gives users the ability to enable or disable features of thin clients > on both server and client as they desire. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-8409) Ignite gets stuck on IgniteDataStreamer.addData when using Object with AffinityKeyMapped
[ https://issues.apache.org/jira/browse/IGNITE-8409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17085047#comment-17085047 ] Alexey Goncharuk commented on IGNITE-8409: -- [~nizhikov] no, removed myself from the assignees. > Ignite gets stuck on IgniteDataStreamer.addData when using Object with > AffinityKeyMapped > > > Key: IGNITE-8409 > URL: https://issues.apache.org/jira/browse/IGNITE-8409 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.3 >Reporter: Andrey Aleksandrov >Priority: Critical > Fix For: 2.9, 2.8.1 > > Attachments: ContextCpty.java, TradeKey.java, TradeKeyNew.java > > > This problem reproduces from time to time when we are streaming the data > (TradeKey.java) to Ignite sql cache. As AffinityKeyMapped we used the object > type (ContextCpty.java) > When we change AffinityKeyMapped type from object to long type > (TradeKeyNew.java) then problem disappears. > Investigation help to understand that we hang in BPlusTree.java class in next > method: > private Result putDown(final Put p, final long pageId, final long fwdId, > final int lvl) > In this method: > res = p.tryReplaceInner(pageId, page, fwdId, lvl); > if (res != RETRY) // Go down recursively. > res = putDown(p, p.pageId, p.fwdId, lvl - 1); > if (res == RETRY_ROOT || p.isFinished()) > return res; > if (res == RETRY) > checkInterrupted(); //WE ALWAYS GO TO THIS PLACE -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-8409) Ignite gets stuck on IgniteDataStreamer.addData when using Object with AffinityKeyMapped
[ https://issues.apache.org/jira/browse/IGNITE-8409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk reassigned IGNITE-8409: Assignee: (was: Alexey Goncharuk) > Ignite gets stuck on IgniteDataStreamer.addData when using Object with > AffinityKeyMapped > > > Key: IGNITE-8409 > URL: https://issues.apache.org/jira/browse/IGNITE-8409 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.3 >Reporter: Andrey Aleksandrov >Priority: Critical > Fix For: 2.9, 2.8.1 > > Attachments: ContextCpty.java, TradeKey.java, TradeKeyNew.java > > > This problem reproduces from time to time when we are streaming the data > (TradeKey.java) to Ignite sql cache. As AffinityKeyMapped we used the object > type (ContextCpty.java) > When we change AffinityKeyMapped type from object to long type > (TradeKeyNew.java) then problem disappears. > Investigation help to understand that we hang in BPlusTree.java class in next > method: > private Result putDown(final Put p, final long pageId, final long fwdId, > final int lvl) > In this method: > res = p.tryReplaceInner(pageId, page, fwdId, lvl); > if (res != RETRY) // Go down recursively. > res = putDown(p, p.pageId, p.fwdId, lvl - 1); > if (res == RETRY_ROOT || p.isFinished()) > return res; > if (res == RETRY) > checkInterrupted(); //WE ALWAYS GO TO THIS PLACE -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-9764) Node may hang on start if cluster state is in transition
[
https://issues.apache.org/jira/browse/IGNITE-9764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17085045#comment-17085045
]
Nikolay Izhikov commented on IGNITE-9764:
-
Moved to 2.9
Please, write a comment if you want to see the fix for this issue in 2.8.1
> Node may hang on start if cluster state is in transition
>
>
> Key: IGNITE-9764
> URL: https://issues.apache.org/jira/browse/IGNITE-9764
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexey Goncharuk
>Priority: Critical
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.9
>
>
> The following sequence of events may cause node hang on start
> Node starts, detects cluster state transition and waits for it to complete
> {code}
> "start-node-1" #11804 prio=5 os_prio=0 tid=0x7f9cc4022000 nid=0x1094
> waiting on condition [0x7f9ffc4c2000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:178)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:141)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1084)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2033)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1728)
> - locked <0x9467c890> (a
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1156)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:654)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:917)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:855)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:843)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:809)
> at
> org.apache.ignite.internal.processors.cache.IgniteClusterActivateDeactivateTest.lambda$testConcurrentJoinAndActivate$4(IgniteClusterActivateDeactivateTest.java:539)
> at
> org.apache.ignite.internal.processors.cache.IgniteClusterActivateDeactivateTest$$Lambda$99/295822519.call(Unknown
> Source)
> at
> org.apache.ignite.testframework.GridTestThread.run(GridTestThread.java:86)
> {code}
> Nio thread that is to process a message that would complete the exchange is
> attempting to create a session and get a local node ID
> {code}
> "grid-nio-worker-tcp-comm-3-#9833%cache.IgniteClusterActivateDeactivateTest3%"
> #11875 prio=5 os_prio=0 tid=0x7f9c8009e800 nid=0x10dc waiting on
> condition [0x7f9ff4d76000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for (a
> java.util.concurrent.CountDownLatch$Sync)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304)
> at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231)
> at
> org.apache.ignite.internal.util.IgniteUtils.await(IgniteUtils.java:7577)
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.getSpiContext(TcpCommunicationSpi.java:2266)
> at
> org.apache.ignite.spi.IgniteSpiAdapter.getLocalNode(IgniteSpiAdapter.java:156)
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.safeLocalNodeId(TcpCommunicationSpi.java:4006)
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.nodeIdMessage(TcpCommunicationSpi.java:3999)
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.access$300(TcpCommunicationSpi.java:271)
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi$2.onConnected(TcpCommunicationSpi.java:412)
> at
> org.apache.ignite.internal.util.nio.GridNioFilterChain$TailFilter.onSessionOpened(GridNioFilterChain.java:251)
> at
> org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedSessionOpened(GridNioFilterAdapter.java:88)
> at
> org.apache.ignite.internal.util.nio.GridNioCodecFilter.onSessionOpened(GridNioCodecFilter.java:67)
> at
[jira] [Updated] (IGNITE-9764) Node may hang on start if cluster state is in transition
[
https://issues.apache.org/jira/browse/IGNITE-9764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov updated IGNITE-9764:
Fix Version/s: (was: 2.8.1)
> Node may hang on start if cluster state is in transition
>
>
> Key: IGNITE-9764
> URL: https://issues.apache.org/jira/browse/IGNITE-9764
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexey Goncharuk
>Priority: Critical
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.9
>
>
> The following sequence of events may cause node hang on start
> Node starts, detects cluster state transition and waits for it to complete
> {code}
> "start-node-1" #11804 prio=5 os_prio=0 tid=0x7f9cc4022000 nid=0x1094
> waiting on condition [0x7f9ffc4c2000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:178)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:141)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1084)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2033)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1728)
> - locked <0x9467c890> (a
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1156)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:654)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:917)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:855)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:843)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:809)
> at
> org.apache.ignite.internal.processors.cache.IgniteClusterActivateDeactivateTest.lambda$testConcurrentJoinAndActivate$4(IgniteClusterActivateDeactivateTest.java:539)
> at
> org.apache.ignite.internal.processors.cache.IgniteClusterActivateDeactivateTest$$Lambda$99/295822519.call(Unknown
> Source)
> at
> org.apache.ignite.testframework.GridTestThread.run(GridTestThread.java:86)
> {code}
> Nio thread that is to process a message that would complete the exchange is
> attempting to create a session and get a local node ID
> {code}
> "grid-nio-worker-tcp-comm-3-#9833%cache.IgniteClusterActivateDeactivateTest3%"
> #11875 prio=5 os_prio=0 tid=0x7f9c8009e800 nid=0x10dc waiting on
> condition [0x7f9ff4d76000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for (a
> java.util.concurrent.CountDownLatch$Sync)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304)
> at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231)
> at
> org.apache.ignite.internal.util.IgniteUtils.await(IgniteUtils.java:7577)
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.getSpiContext(TcpCommunicationSpi.java:2266)
> at
> org.apache.ignite.spi.IgniteSpiAdapter.getLocalNode(IgniteSpiAdapter.java:156)
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.safeLocalNodeId(TcpCommunicationSpi.java:4006)
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.nodeIdMessage(TcpCommunicationSpi.java:3999)
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.access$300(TcpCommunicationSpi.java:271)
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi$2.onConnected(TcpCommunicationSpi.java:412)
> at
> org.apache.ignite.internal.util.nio.GridNioFilterChain$TailFilter.onSessionOpened(GridNioFilterChain.java:251)
> at
> org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedSessionOpened(GridNioFilterAdapter.java:88)
> at
> org.apache.ignite.internal.util.nio.GridNioCodecFilter.onSessionOpened(GridNioCodecFilter.java:67)
> at
>
[jira] [Commented] (IGNITE-11238) Possible hang on exchange
[
https://issues.apache.org/jira/browse/IGNITE-11238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17085044#comment-17085044
]
Nikolay Izhikov commented on IGNITE-11238:
--
Moved to 2.9
Please, write a comment if you want to see the fix for this issue in 2.8.1
> Possible hang on exchange
> -
>
> Key: IGNITE-11238
> URL: https://issues.apache.org/jira/browse/IGNITE-11238
> Project: Ignite
> Issue Type: Bug
> Components: general
>Reporter: Igor Seliverstov
>Priority: Critical
> Fix For: 2.9
>
>
> Currently we may hang on exchange for a while (two network timeouts) waiting
> for release a latch (see
> {{GridDhtPartitionsExchangeFuture#waitPartitionRelease releaseLatch}}) in
> case a processing topology version has not been added to discovery history
> yet but client acknowledge already received by coordinator:
> {code:java}
> [2019-02-06
> 17:43:17,009][ERROR][sys-#43%mvcc.CacheMvccPartitionedSqlCoordinatorFailoverTest0%][ExchangeLatchManager]
> Topology AffinityTopologyVersion [topVer=24, minorTopVer=0] not found in
> discovery history ; consider increasing IGNITE_DISCOVERY_HISTORY_SIZE
> property. Current value is -1
> class org.apache.ignite.IgniteException: Topology AffinityTopologyVersion
> [topVer=24, minorTopVer=0] not found in discovery history ; consider
> increasing IGNITE_DISCOVERY_HISTORY_SIZE property. Current value is -1
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.latch.ExchangeLatchManager.aliveNodesForTopologyVer(ExchangeLatchManager.java:260)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.latch.ExchangeLatchManager.getLatchCoordinator(ExchangeLatchManager.java:302)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.latch.ExchangeLatchManager.processAck(ExchangeLatchManager.java:351)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.latch.ExchangeLatchManager.lambda$new$0(ExchangeLatchManager.java:121)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1561)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1189)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:127)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$8.run(GridIoManager.java:1086)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> This way the received ack won't be processed, so, we will be waiting for
> retry:
> {code:java}
> // Try to resend ack.
> releaseLatch.countDown();
> {code}
> To solve the issue we need to test whether the version is present in
> discovery history and put it into a pending map if i isn't so (see
> {{ExchangeLatchManager#pendingAcks}})
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-11238) Possible hang on exchange
[
https://issues.apache.org/jira/browse/IGNITE-11238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov updated IGNITE-11238:
-
Fix Version/s: (was: 2.8.1)
> Possible hang on exchange
> -
>
> Key: IGNITE-11238
> URL: https://issues.apache.org/jira/browse/IGNITE-11238
> Project: Ignite
> Issue Type: Bug
> Components: general
>Reporter: Igor Seliverstov
>Priority: Critical
> Fix For: 2.9
>
>
> Currently we may hang on exchange for a while (two network timeouts) waiting
> for release a latch (see
> {{GridDhtPartitionsExchangeFuture#waitPartitionRelease releaseLatch}}) in
> case a processing topology version has not been added to discovery history
> yet but client acknowledge already received by coordinator:
> {code:java}
> [2019-02-06
> 17:43:17,009][ERROR][sys-#43%mvcc.CacheMvccPartitionedSqlCoordinatorFailoverTest0%][ExchangeLatchManager]
> Topology AffinityTopologyVersion [topVer=24, minorTopVer=0] not found in
> discovery history ; consider increasing IGNITE_DISCOVERY_HISTORY_SIZE
> property. Current value is -1
> class org.apache.ignite.IgniteException: Topology AffinityTopologyVersion
> [topVer=24, minorTopVer=0] not found in discovery history ; consider
> increasing IGNITE_DISCOVERY_HISTORY_SIZE property. Current value is -1
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.latch.ExchangeLatchManager.aliveNodesForTopologyVer(ExchangeLatchManager.java:260)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.latch.ExchangeLatchManager.getLatchCoordinator(ExchangeLatchManager.java:302)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.latch.ExchangeLatchManager.processAck(ExchangeLatchManager.java:351)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.latch.ExchangeLatchManager.lambda$new$0(ExchangeLatchManager.java:121)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1561)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1189)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:127)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$8.run(GridIoManager.java:1086)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> This way the received ack won't be processed, so, we will be waiting for
> retry:
> {code:java}
> // Try to resend ack.
> releaseLatch.countDown();
> {code}
> To solve the issue we need to test whether the version is present in
> discovery history and put it into a pending map if i isn't so (see
> {{ExchangeLatchManager#pendingAcks}})
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-10010) Node halted if second node was stopped, then cache destroyed, then second node returned
[
https://issues.apache.org/jira/browse/IGNITE-10010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17085040#comment-17085040
]
Nikolay Izhikov commented on IGNITE-10010:
--
Moved to 2.9
Please, write a comment if you want to see the fix for this issue in 2.8.1
> Node halted if second node was stopped, then cache destroyed, then second
> node returned
> ---
>
> Key: IGNITE-10010
> URL: https://issues.apache.org/jira/browse/IGNITE-10010
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.7
>Reporter: Sergey Kozlov
>Assignee: Alexey Goncharuk
>Priority: Critical
> Fix For: 2.9
>
> Attachments: PersistenceNodeRestartAfterCacheDropSelfTest.java,
> ignite-gridparitition-nullpointer.zip
>
>
> Partitions cache sizes1. Start 2 nodes with PDS
> 2. Activate cluster
> 3. Connect sqlline.
> 4. Create table {{create table t1(a int, b varchar, primary key(a)) with
> "ATOMICITY=TRANSACTIONAL_SNAPSHOT,backups=1";}}
> 5. Stop node 1
> 6. Drop table {{drop table t1;}}
> 7. Start node 1
> 8. Node 2 stopped by handler:
> {noformat}
> c:\Work\apache-ignite-2.7.0-SNAPSHOT-bin>bin\ignite.bat server.xml -v -J-DID=1
> Ignite Command Line Startup, ver. 2.7.0-SNAPSHOT#19700101-sha1:DEV
> 2018 Copyright(C) Apache Software Foundation
> [18:04:22,745][INFO][main][IgniteKernal]
> >>>__
> >>> / _/ ___/ |/ / _/_ __/ __/
> >>> _/ // (7 7// / / / / _/
> >>> /___/\___/_/|_/___/ /_/ /___/
> >>>
> >>> ver. 2.7.0-SNAPSHOT#19700101-sha1:DEV
> >>> 2018 Copyright(C) Apache Software Foundation
> >>>
> >>> Ignite documentation: http://ignite.apache.org
> [18:04:22,745][INFO][main][IgniteKernal] Config URL:
> file:/c:/Work/apache-ignite-2.7.0-SNAPSHOT-bin/server.xml
> [18:04:22,760][INFO][main][IgniteKernal] IgniteConfiguration
> [igniteInstanceName=null, pubPoolSize=8, svcPoolSize=8, cal
> lbackPoolSize=8, stripedPoolSize=8, sysPoolSize=8, mgmtPoolSize=4,
> igfsPoolSize=8, dataStreamerPoolSize=8, utilityCacheP
> oolSize=8, utilityCacheKeepAliveTime=6, p2pPoolSize=2, qryPoolSize=8,
> igniteHome=c:\Work\apache-ignite-2.7.0-SNAPSHO
> T-bin, igniteWorkDir=c:\Work\apache-ignite-2.7.0-SNAPSHOT-bin\work,
> mbeanSrv=com.sun.jmx.mbeanserver.JmxMBeanServer@6f94
> fa3e, nodeId=d02069db-6d0b-4a40-b185-1d95fa330853, marsh=BinaryMarshaller [],
> marshLocJobs=false, daemon=false, p2pEnabl
> ed=false, netTimeout=5000, sndRetryDelay=1000, sndRetryCnt=3,
> metricsHistSize=1, metricsUpdateFreq=2000, metricsExpT
> ime=9223372036854775807, discoSpi=TcpDiscoverySpi [addrRslvr=null,
> sockTimeout=0, ackTimeout=0, marsh=null, reconCnt=10,
> reconDelay=2000, maxAckTimeout=60, forceSrvMode=false,
> clientReconnectDisabled=false, internalLsnr=null], segPlc=ST
> OP, segResolveAttempts=2, waitForSegOnStart=true, allResolversPassReq=true,
> segChkFreq=1, commSpi=TcpCommunicationSp
> i [connectGate=null,
> connPlc=org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi$FirstConnectionPolicy@22ff4249,
> enableForcibleNodeKill=false, enableTroubleshootingLog=false, locAddr=null,
> locHost=null, locPort=47100, locPortRange=1
> 00, shmemPort=-1, directBuf=true, directSndBuf=false, idleConnTimeout=60,
> connTimeout=5000, maxConnTimeout=60, r
> econCnt=10, sockSndBuf=32768, sockRcvBuf=32768, msgQueueLimit=0,
> slowClientQueueLimit=0, nioSrvr=null, shmemSrv=null, us
> ePairedConnections=false, connectionsPerNode=1, tcpNoDelay=true,
> filterReachableAddresses=false, ackSndThreshold=32, una
> ckedMsgsBufSize=0, sockWriteTimeout=2000, boundTcpPort=-1,
> boundTcpShmemPort=-1, selectorsCnt=4, selectorSpins=0, addrRs
> lvr=null, ctxInitLatch=java.util.concurrent.CountDownLatch@2d1ef81a[Count =
> 1], stopping=false], evtSpi=org.apache.ignit
> e.spi.eventstorage.NoopEventStorageSpi@4c402120, colSpi=NoopCollisionSpi [],
> deploySpi=LocalDeploymentSpi [], indexingSp
> i=org.apache.ignite.spi.indexing.noop.NoopIndexingSpi@815b41f,
> addrRslvr=null, encryptionSpi=org.apache.ignite.spi.encry
> ption.noop.NoopEncryptionSpi@5542c4ed, clientMode=false,
> rebalanceThreadPoolSize=1, txCfg=TransactionConfiguration [txSe
> rEnabled=false, dfltIsolation=REPEATABLE_READ, dfltConcurrency=PESSIMISTIC,
> dfltTxTimeout=0, txTimeoutOnPartitionMapExch
> ange=0, pessimisticTxLogSize=0, pessimisticTxLogLinger=1,
> tmLookupClsName=null, txManagerFactory=null, useJtaSync=fa
> lse], cacheSanityCheckEnabled=true, discoStartupDelay=6,
> deployMode=SHARED, p2pMissedCacheSize=100, locHost=127.0.0.
> 1, timeSrvPortBase=31100, timeSrvPortRange=100,
> failureDetectionTimeout=1, sysWorkerBlockedTimeout=null, clientFailu
> reDetectionTimeout=3, metricsLogFreq=6, hadoopCfg=null,
> connectorCfg=ConnectorConfiguration [jettyPath=null, hos
>
[jira] [Updated] (IGNITE-10010) Node halted if second node was stopped, then cache destroyed, then second node returned
[
https://issues.apache.org/jira/browse/IGNITE-10010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov updated IGNITE-10010:
-
Fix Version/s: (was: 2.8.1)
> Node halted if second node was stopped, then cache destroyed, then second
> node returned
> ---
>
> Key: IGNITE-10010
> URL: https://issues.apache.org/jira/browse/IGNITE-10010
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.7
>Reporter: Sergey Kozlov
>Assignee: Alexey Goncharuk
>Priority: Critical
> Fix For: 2.9
>
> Attachments: PersistenceNodeRestartAfterCacheDropSelfTest.java,
> ignite-gridparitition-nullpointer.zip
>
>
> Partitions cache sizes1. Start 2 nodes with PDS
> 2. Activate cluster
> 3. Connect sqlline.
> 4. Create table {{create table t1(a int, b varchar, primary key(a)) with
> "ATOMICITY=TRANSACTIONAL_SNAPSHOT,backups=1";}}
> 5. Stop node 1
> 6. Drop table {{drop table t1;}}
> 7. Start node 1
> 8. Node 2 stopped by handler:
> {noformat}
> c:\Work\apache-ignite-2.7.0-SNAPSHOT-bin>bin\ignite.bat server.xml -v -J-DID=1
> Ignite Command Line Startup, ver. 2.7.0-SNAPSHOT#19700101-sha1:DEV
> 2018 Copyright(C) Apache Software Foundation
> [18:04:22,745][INFO][main][IgniteKernal]
> >>>__
> >>> / _/ ___/ |/ / _/_ __/ __/
> >>> _/ // (7 7// / / / / _/
> >>> /___/\___/_/|_/___/ /_/ /___/
> >>>
> >>> ver. 2.7.0-SNAPSHOT#19700101-sha1:DEV
> >>> 2018 Copyright(C) Apache Software Foundation
> >>>
> >>> Ignite documentation: http://ignite.apache.org
> [18:04:22,745][INFO][main][IgniteKernal] Config URL:
> file:/c:/Work/apache-ignite-2.7.0-SNAPSHOT-bin/server.xml
> [18:04:22,760][INFO][main][IgniteKernal] IgniteConfiguration
> [igniteInstanceName=null, pubPoolSize=8, svcPoolSize=8, cal
> lbackPoolSize=8, stripedPoolSize=8, sysPoolSize=8, mgmtPoolSize=4,
> igfsPoolSize=8, dataStreamerPoolSize=8, utilityCacheP
> oolSize=8, utilityCacheKeepAliveTime=6, p2pPoolSize=2, qryPoolSize=8,
> igniteHome=c:\Work\apache-ignite-2.7.0-SNAPSHO
> T-bin, igniteWorkDir=c:\Work\apache-ignite-2.7.0-SNAPSHOT-bin\work,
> mbeanSrv=com.sun.jmx.mbeanserver.JmxMBeanServer@6f94
> fa3e, nodeId=d02069db-6d0b-4a40-b185-1d95fa330853, marsh=BinaryMarshaller [],
> marshLocJobs=false, daemon=false, p2pEnabl
> ed=false, netTimeout=5000, sndRetryDelay=1000, sndRetryCnt=3,
> metricsHistSize=1, metricsUpdateFreq=2000, metricsExpT
> ime=9223372036854775807, discoSpi=TcpDiscoverySpi [addrRslvr=null,
> sockTimeout=0, ackTimeout=0, marsh=null, reconCnt=10,
> reconDelay=2000, maxAckTimeout=60, forceSrvMode=false,
> clientReconnectDisabled=false, internalLsnr=null], segPlc=ST
> OP, segResolveAttempts=2, waitForSegOnStart=true, allResolversPassReq=true,
> segChkFreq=1, commSpi=TcpCommunicationSp
> i [connectGate=null,
> connPlc=org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi$FirstConnectionPolicy@22ff4249,
> enableForcibleNodeKill=false, enableTroubleshootingLog=false, locAddr=null,
> locHost=null, locPort=47100, locPortRange=1
> 00, shmemPort=-1, directBuf=true, directSndBuf=false, idleConnTimeout=60,
> connTimeout=5000, maxConnTimeout=60, r
> econCnt=10, sockSndBuf=32768, sockRcvBuf=32768, msgQueueLimit=0,
> slowClientQueueLimit=0, nioSrvr=null, shmemSrv=null, us
> ePairedConnections=false, connectionsPerNode=1, tcpNoDelay=true,
> filterReachableAddresses=false, ackSndThreshold=32, una
> ckedMsgsBufSize=0, sockWriteTimeout=2000, boundTcpPort=-1,
> boundTcpShmemPort=-1, selectorsCnt=4, selectorSpins=0, addrRs
> lvr=null, ctxInitLatch=java.util.concurrent.CountDownLatch@2d1ef81a[Count =
> 1], stopping=false], evtSpi=org.apache.ignit
> e.spi.eventstorage.NoopEventStorageSpi@4c402120, colSpi=NoopCollisionSpi [],
> deploySpi=LocalDeploymentSpi [], indexingSp
> i=org.apache.ignite.spi.indexing.noop.NoopIndexingSpi@815b41f,
> addrRslvr=null, encryptionSpi=org.apache.ignite.spi.encry
> ption.noop.NoopEncryptionSpi@5542c4ed, clientMode=false,
> rebalanceThreadPoolSize=1, txCfg=TransactionConfiguration [txSe
> rEnabled=false, dfltIsolation=REPEATABLE_READ, dfltConcurrency=PESSIMISTIC,
> dfltTxTimeout=0, txTimeoutOnPartitionMapExch
> ange=0, pessimisticTxLogSize=0, pessimisticTxLogLinger=1,
> tmLookupClsName=null, txManagerFactory=null, useJtaSync=fa
> lse], cacheSanityCheckEnabled=true, discoStartupDelay=6,
> deployMode=SHARED, p2pMissedCacheSize=100, locHost=127.0.0.
> 1, timeSrvPortBase=31100, timeSrvPortRange=100,
> failureDetectionTimeout=1, sysWorkerBlockedTimeout=null, clientFailu
> reDetectionTimeout=3, metricsLogFreq=6, hadoopCfg=null,
> connectorCfg=ConnectorConfiguration [jettyPath=null, hos
> t=null, port=11211, noDelay=true, directBuf=false, sndBufSize=32768,
> rcvBufSize=32768,
[jira] [Updated] (IGNITE-9740) [ML] Remove IgniteThread wrapper from ml unit test EvaluatorTest (follow up to IGNITE-9711)
[
https://issues.apache.org/jira/browse/IGNITE-9740?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov updated IGNITE-9740:
Fix Version/s: (was: 2.8.1)
2.9
> [ML] Remove IgniteThread wrapper from ml unit test EvaluatorTest (follow up
> to IGNITE-9711)
> ---
>
> Key: IGNITE-9740
> URL: https://issues.apache.org/jira/browse/IGNITE-9740
> Project: Ignite
> Issue Type: Bug
> Components: ml
>Reporter: Oleg Ignatenko
>Assignee: Alexey Zinoviev
>Priority: Critical
> Fix For: 2.9
>
>
> [EvaluatorTest|https://github.com/apache/ignite/blob/master/modules/ml/src/test/java/org/apache/ignite/ml/selection/scoring/evaluator/EvaluatorTest.java]
> involves {{IgniteThread}} which is in fact not needed there and should be
> removed.
> {{IgniteThread}} usage is a remainder / copy-paste from older tests and
> examples that were using API requiring it. This API has been removed and
> there is no need for wrapping like that anymore. For the reference on how to
> perform suggested cleanup check changes made to ml examples per IGNITE-9711.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-9740) [ML] Remove IgniteThread wrapper from ml unit test EvaluatorTest (follow up to IGNITE-9711)
[
https://issues.apache.org/jira/browse/IGNITE-9740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17085035#comment-17085035
]
Nikolay Izhikov commented on IGNITE-9740:
-
Moved to 2.9
Please, write a comment if you want to see the fix for this issue in 2.8.1
> [ML] Remove IgniteThread wrapper from ml unit test EvaluatorTest (follow up
> to IGNITE-9711)
> ---
>
> Key: IGNITE-9740
> URL: https://issues.apache.org/jira/browse/IGNITE-9740
> Project: Ignite
> Issue Type: Bug
> Components: ml
>Reporter: Oleg Ignatenko
>Assignee: Alexey Zinoviev
>Priority: Critical
> Fix For: 2.8.1
>
>
> [EvaluatorTest|https://github.com/apache/ignite/blob/master/modules/ml/src/test/java/org/apache/ignite/ml/selection/scoring/evaluator/EvaluatorTest.java]
> involves {{IgniteThread}} which is in fact not needed there and should be
> removed.
> {{IgniteThread}} usage is a remainder / copy-paste from older tests and
> examples that were using API requiring it. This API has been removed and
> there is no need for wrapping like that anymore. For the reference on how to
> perform suggested cleanup check changes made to ml examples per IGNITE-9711.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (IGNITE-10011) Pages leak suspicion in PDS
[ https://issues.apache.org/jira/browse/IGNITE-10011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov resolved IGNITE-10011. -- Resolution: Invalid I'm closing this issue as "Invalid" based on [~agoncharuk] comment. Please, feel free to reopen it if issue still can be reproduced. > Pages leak suspicion in PDS > --- > > Key: IGNITE-10011 > URL: https://issues.apache.org/jira/browse/IGNITE-10011 > Project: Ignite > Issue Type: Bug > Components: persistence >Reporter: Ilya Kasnacheev >Priority: Critical > Labels: performance > Fix For: 2.9, 2.8.1 > > Attachments: Main.java > > Time Spent: 10m > Remaining Estimate: 0h > > See the attached Main which adds 500k records to 3 caches, then clears them, > rinse, repeat. > When ran with default settings, totalAllocatedSize will slowly double over > the course of a few hours and then continue to grow. > When ran with 2 FreeList buckets, it will double every time, 600M -> 1200M -> > 1800M -> etc. > See the userlist discussion -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12888) Add support for ConstantName to checkstyle rules
[ https://issues.apache.org/jira/browse/IGNITE-12888?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17085028#comment-17085028 ] Maxim Muzafarov commented on IGNITE-12888: -- [~xtern] You're right. We can't cover such cases by the checkstyle since static code analysis is not so smart. > Add support for ConstantName to checkstyle rules > > > Key: IGNITE-12888 > URL: https://issues.apache.org/jira/browse/IGNITE-12888 > Project: Ignite > Issue Type: Task >Reporter: Maxim Muzafarov >Assignee: Maxim Muzafarov >Priority: Major > Fix For: 2.9 > > Time Spent: 0.5h > Remaining Estimate: 0h > > Add a new rule to checkstyle according to Apache Ignite naming conventions. > > https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines#CodingGuidelines-Naming -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12759) Getting a SecurityContext from GridSecurityProcessor
[ https://issues.apache.org/jira/browse/IGNITE-12759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov updated IGNITE-12759: - Fix Version/s: 2.8.1 > Getting a SecurityContext from GridSecurityProcessor > > > Key: IGNITE-12759 > URL: https://issues.apache.org/jira/browse/IGNITE-12759 > Project: Ignite > Issue Type: Improvement > Components: security >Reporter: Denis Garus >Assignee: Denis Garus >Priority: Major > Labels: iep-41 > Fix For: 2.8.1 > > Time Spent: 2h > Remaining Estimate: 0h > > Extend the _GridSecurityProcessor_ interface by adding _securityContext(UUID > subjId)_ method and use this method to get the actual security context. > h4. Backward compatibility > The logic of getting security context for Ignite: > # Try to get a security context using _ClusterNode_ attributes (as it works > now); > # Get a security context through _GridSecurityProcessor_. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-10075) .NET: Avoid binary configurations of Ignite Java service params and result when calling it from Ignite.NET
[ https://issues.apache.org/jira/browse/IGNITE-10075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17085025#comment-17085025 ] Alexey Kukushkin commented on IGNITE-10075: --- [~zzzadruga], let me create a reproducer. Will add the reproducer to the ticket soon. > .NET: Avoid binary configurations of Ignite Java service params and result > when calling it from Ignite.NET > -- > > Key: IGNITE-10075 > URL: https://issues.apache.org/jira/browse/IGNITE-10075 > Project: Ignite > Issue Type: Improvement > Components: platforms >Affects Versions: 2.6 >Reporter: Alexey Kukushkin >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET, sbcf > Attachments: MyTest.cs, ignite-10075-vs-2.8.patch > > > Presently if there is an Ignite Java service taking parameters of complex > (composite) types and returning a result of complex type then all the complex > types must be explicitly specified in the binary configuration. > We need to enhance Ignite not to require binary configuration assuming that > we use the same type, package/namespace and field/property names on both the > .NET and Java sides (or provide a custom name mapper for relaxed naming > conventions). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-11302) idleConnectionTimeout TcpComm different on server and client (client default > server custom) lead to wait until client timeout on server side
[
https://issues.apache.org/jira/browse/IGNITE-11302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov updated IGNITE-11302:
-
Description:
Server config:
{code:xml}
Client config
{code}
Server wait until default idleConnectionTimeout (10 m) for client fail.
If both config with idleConnectionTimeout=1 s - ignite worked according to
config
was:
Server config:
Client config
Server wait until default idleConnectionTimeout (10 m) for client fail.
If both config with idleConnectionTimeout=1 s - ignite worked according to
config
> idleConnectionTimeout TcpComm different on server and client (client default
> > server custom) lead to wait until client timeout on server side
> --
>
> Key: IGNITE-11302
> URL: https://issues.apache.org/jira/browse/IGNITE-11302
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.5
>Reporter: ARomantsov
>Assignee: Dmitriy Sorokin
>Priority: Critical
> Fix For: 2.9
>
>
> Server config:
> {code:xml}
>
> class="org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi">
>
>
>
> Client config
>
> class="org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi">
>
>
> {code}
> Server wait until default idleConnectionTimeout (10 m) for client fail.
> If both config with idleConnectionTimeout=1 s - ignite worked according to
> config
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-11302) idleConnectionTimeout TcpComm different on server and client (client default > server custom) lead to wait until client timeout on server side
[ https://issues.apache.org/jira/browse/IGNITE-11302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17085024#comment-17085024 ] Nikolay Izhikov commented on IGNITE-11302: -- Moved to 2.9 Please, write a comment if you want to see the fix for this issue in 2.8.1 > idleConnectionTimeout TcpComm different on server and client (client default > > server custom) lead to wait until client timeout on server side > -- > > Key: IGNITE-11302 > URL: https://issues.apache.org/jira/browse/IGNITE-11302 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.5 >Reporter: ARomantsov >Assignee: Dmitriy Sorokin >Priority: Critical > Fix For: 2.9 > > > Server config: > > class="org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi"> > > > > Client config > > class="org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi"> > > > Server wait until default idleConnectionTimeout (10 m) for client fail. > If both config with idleConnectionTimeout=1 s - ignite worked according to > config -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-11302) idleConnectionTimeout TcpComm different on server and client (client default > server custom) lead to wait until client timeout on server side
[ https://issues.apache.org/jira/browse/IGNITE-11302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov updated IGNITE-11302: - Fix Version/s: (was: 2.8.1) > idleConnectionTimeout TcpComm different on server and client (client default > > server custom) lead to wait until client timeout on server side > -- > > Key: IGNITE-11302 > URL: https://issues.apache.org/jira/browse/IGNITE-11302 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.5 >Reporter: ARomantsov >Assignee: Dmitriy Sorokin >Priority: Critical > Fix For: 2.9 > > > Server config: > > class="org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi"> > > > > Client config > > class="org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi"> > > > Server wait until default idleConnectionTimeout (10 m) for client fail. > If both config with idleConnectionTimeout=1 s - ignite worked according to > config -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12637) IgniteSparkSession doesn't start the clients on really distributed cluster
[
https://issues.apache.org/jira/browse/IGNITE-12637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17085023#comment-17085023
]
Nikolay Izhikov commented on IGNITE-12637:
--
Hello. [~aealeksandrov]
What version of the Spark did you use?
> IgniteSparkSession doesn't start the clients on really distributed cluster
> --
>
> Key: IGNITE-12637
> URL: https://issues.apache.org/jira/browse/IGNITE-12637
> Project: Ignite
> Issue Type: Bug
> Components: spark
>Affects Versions: 2.7.6
>Reporter: Andrey Aleksandrov
>Assignee: Yaroslav Molochkov
>Priority: Critical
> Fix For: 2.9, 2.8.1
>
>
> Next code:
> IgniteSparkSession igniteSession = IgniteSparkSession.builder()
> .appName("Spark Ignite example")
> .igniteConfig(configPath)
> .getOrCreate();
> Throws:
> class org.apache.ignite.IgniteIllegalStateException: Ignite instance with
> provided name doesn't exist. Did you call Ignition.start(..) to start an
> Ignite instance? [name=grid]
> Client config was located in all Spark nodes at the same place.
> When I ran these tests on the same host with several local executors then it
> worked. But if executors were located on different hosts then it didn't.
> DataFrame API works fine with the same config.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12907) GridSystemViewManager is not thread safe
[
https://issues.apache.org/jira/browse/IGNITE-12907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey N. Gura updated IGNITE-12907:
Description:
{{GridSystemViewManager}} is not thread safe because it allows to registers
walkers using public {{registerWalker()}} that just adds walker to a
{{HashMap}}.
It seems the simplest solution here: make {{registerWalker()}} method private
because it has usages only from {{GridSystemViewManager}} constructor.
was:
{{GridSystemViewManager}} is not thread safe because it allows to registers
walkers using public {{registerWalker()}} that just adds walker to a
{{HashMap}}.
It seems that simplest solution here: make {{registerWalker()}} method private
because it has usages only from {{GridSystemViewManager}} constructor.
> GridSystemViewManager is not thread safe
>
>
> Key: IGNITE-12907
> URL: https://issues.apache.org/jira/browse/IGNITE-12907
> Project: Ignite
> Issue Type: Bug
>Reporter: Andrey N. Gura
>Priority: Major
> Labels: IEP-35
>
> {{GridSystemViewManager}} is not thread safe because it allows to registers
> walkers using public {{registerWalker()}} that just adds walker to a
> {{HashMap}}.
> It seems the simplest solution here: make {{registerWalker()}} method private
> because it has usages only from {{GridSystemViewManager}} constructor.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-12907) GridSystemViewManager is not thread safe
Andrey N. Gura created IGNITE-12907:
---
Summary: GridSystemViewManager is not thread safe
Key: IGNITE-12907
URL: https://issues.apache.org/jira/browse/IGNITE-12907
Project: Ignite
Issue Type: Bug
Reporter: Andrey N. Gura
{{GridSystemViewManager}} is not thread safe because it allows to registers
walkers using public {{registerWalker()}} that just adds walker to a
{{HashMap}}.
It seems that simplest solution here: make {{registerWalker()}} method private
because it has usages only from {{GridSystemViewManager}} constructor.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12033) Callbacks from striped pool due to async/await may hang cluster
[
https://issues.apache.org/jira/browse/IGNITE-12033?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17085011#comment-17085011
]
Nikolay Izhikov commented on IGNITE-12033:
--
Moved to 2.9
Please, write a comment if you want to see the fix for this issue in 2.8.1
> Callbacks from striped pool due to async/await may hang cluster
> ---
>
> Key: IGNITE-12033
> URL: https://issues.apache.org/jira/browse/IGNITE-12033
> Project: Ignite
> Issue Type: Bug
> Components: cache, platforms
>Affects Versions: 2.7.5
>Reporter: Ilya Kasnacheev
>Priority: Critical
> Fix For: 2.9
>
>
> Discussed on dev-list:
> http://apache-ignite-developers.2346864.n4.nabble.com/Re-EXTERNAL-Re-Replace-or-Put-after-PutAsync-causes-Ignite-to-hang-td42921.html
> *Must use the public pool for callbacks as the most obvious step.*
>
> http://apache-ignite-users.70518.x6.nabble.com/Replace-or-Put-after-PutAsync-causes-Ignite-to-hang-td27871.html#a28051
> There's a reproducer project. Long story short, .Net can invoke cache
> operations with future callbacks, which will be invoked from striped pool. If
> such callbacks are to use cache operations, those will be possibly sheduled
> to the same stripe and cause a deadlock.
> The code is very simple:
> {code}
> Console.WriteLine("PutAsync");
> await cache.PutAsync(1, "Test");
> Console.WriteLine("Replace");
> cache.Replace(1, "Testing"); // Hangs here
> Console.WriteLine("Wait");
> await Task.Delay(Timeout.Infinite);
> {code}
> async/await should absolutely not allow any client code to be run from
> stripes.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12033) Callbacks from striped pool due to async/await may hang cluster
[
https://issues.apache.org/jira/browse/IGNITE-12033?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov updated IGNITE-12033:
-
Fix Version/s: (was: 2.8.1)
> Callbacks from striped pool due to async/await may hang cluster
> ---
>
> Key: IGNITE-12033
> URL: https://issues.apache.org/jira/browse/IGNITE-12033
> Project: Ignite
> Issue Type: Bug
> Components: cache, platforms
>Affects Versions: 2.7.5
>Reporter: Ilya Kasnacheev
>Priority: Critical
> Fix For: 2.9
>
>
> Discussed on dev-list:
> http://apache-ignite-developers.2346864.n4.nabble.com/Re-EXTERNAL-Re-Replace-or-Put-after-PutAsync-causes-Ignite-to-hang-td42921.html
> *Must use the public pool for callbacks as the most obvious step.*
>
> http://apache-ignite-users.70518.x6.nabble.com/Replace-or-Put-after-PutAsync-causes-Ignite-to-hang-td27871.html#a28051
> There's a reproducer project. Long story short, .Net can invoke cache
> operations with future callbacks, which will be invoked from striped pool. If
> such callbacks are to use cache operations, those will be possibly sheduled
> to the same stripe and cause a deadlock.
> The code is very simple:
> {code}
> Console.WriteLine("PutAsync");
> await cache.PutAsync(1, "Test");
> Console.WriteLine("Replace");
> cache.Replace(1, "Testing"); // Hangs here
> Console.WriteLine("Wait");
> await Task.Delay(Timeout.Infinite);
> {code}
> async/await should absolutely not allow any client code to be run from
> stripes.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-10136) NPE in PartitionUpdateCountersMessage
[
https://issues.apache.org/jira/browse/IGNITE-10136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov updated IGNITE-10136:
-
Fix Version/s: (was: 2.8.1)
> NPE in PartitionUpdateCountersMessage
> -
>
> Key: IGNITE-10136
> URL: https://issues.apache.org/jira/browse/IGNITE-10136
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.7
>Reporter: Sergey Kozlov
>Assignee: Sergey Kozlov
>Priority: Critical
> Fix For: 2.9
>
>
> {noformat}
> [14:00:55,950][INFO][db-checkpoint-thread-#73][GridCacheDatabaseSharedManager]
> Checkpoint started [checkpointId=9d5398bc-896a-469c-8686-38e2afd517c1,
> startPtr=FileWALPointer [idx=0, fileOff=17828636, len=210609],
> checkpointLockWait=0ms, checkpointLockHoldTime=11ms,
> walCpRecordFsyncDuration=12ms, pages=636, reason='timeout']
> [14:00:56,029][INFO][db-checkpoint-thread-#73][GridCacheDatabaseSharedManager]
> Checkpoint finished [cpId=9d5398bc-896a-469c-8686-38e2afd517c1, pages=636,
> markPos=FileWALPointer [idx=0, fileOff=17828636, len=210609],
> walSegmentsCleared=0, walSegmentsCovered=[], markDuration=26ms,
> pagesWrite=21ms, fsync=58ms, total=105ms]
> [14:00:56,940][INFO][db-checkpoint-thread-#73][GridCacheDatabaseSharedManager]
> Checkpoint started [checkpointId=5f46c89e-ead8-4c87-adad-72a50c26bd7c,
> startPtr=FileWALPointer [idx=0, fileOff=20005440, len=210609],
> checkpointLockWait=0ms, checkpointLockHoldTime=8ms,
> walCpRecordFsyncDuration=5ms, pages=474, reason='timeout']
> [14:00:57,003][INFO][db-checkpoint-thread-#73][GridCacheDatabaseSharedManager]
> Checkpoint finished [cpId=5f46c89e-ead8-4c87-adad-72a50c26bd7c, pages=474,
> markPos=FileWALPointer [idx=0, fileOff=20005440, len=210609],
> walSegmentsCleared=0, walSegmentsCovered=[], markDuration=15ms,
> pagesWrite=10ms, fsync=53ms, total=78ms]
> [14:00:57,065][SEVERE][grid-nio-worker-tcp-comm-2-#42][GridDirectParser]
> Failed to read message [msg=GridIoMessage [plc=0, topic=null, topicOrd=-1,
> ordered=false, timeout=0, skipOnTimeout=false, msg=null],
> buf=java.nio.DirectByteBuffer[pos=792 lim=885 cap=32768],
> reader=RollingUpgradeMessageReader [state=StateItem
> [stream=DirectByteBufferStreamImplV2 [baseOff=140703933959040, arrOff=-1,
> tmpArrOff=0, valReadBytes=0, tmpArrBytes=0, msgTypeDone=true,
> msg=GridCacheIdMessage [cacheId=0]GridDistributedBaseMessage
> [ver=GridCacheVersion [topVer=152301622, order=1540821647376, nodeOrder=4],
> committedVers=null, rolledbackVers=null, cnt=0,
> super=]GridDistributedTxPrepareRequest [threadId=236,
> concurrency=PESSIMISTIC, isolation=REPEATABLE_READ, writeVer=GridCacheVersion
> [topVer=152301622, order=1540821647377, nodeOrder=4], timeout=0, reads=null,
> writes=ArrayList [], dhtVers=null, txSize=-1, plc=2, txState=null,
> flags=last, super=]GridDhtTxPrepareRequest
> [nearNodeId=3800f476-beb1-46b0-8a39-faa51c91831d,
> futId=f794020c661-cc8749ef-caa5-4f1e-9d89-4a9beff59798, miniId=1,
> topVer=AffinityTopologyVersion [topVer=5, minorTopVer=8],
> invalidateNearEntries={}, nearWrites=null, owned=null,
> nearXidVer=GridCacheVersion [topVer=152301622, order=1540821647374,
> nodeOrder=5], subjId=3800f476-beb1-46b0-8a39-faa51c91831d, taskNameHash=0,
> preloadKeys=null, mvccSnapshot=MvccSnapshotResponse [futId=1,
> crdVer=1540821617885, cntr=16, opCntr=1, txs=null, cleanupVer=15,
> tracking=0], skipCompletedVers=false, super=], mapIt=null, it=null,
> arrPos=-1, keyDone=false, readSize=-1, readItems=0, prim=0, primShift=0,
> uuidState=0, uuidMost=0, uuidLeast=0, uuidLocId=0, lastFinished=true],
> state=0, fieldCnt=7, readFieldCnt=0, curName=msg, typeRead=true,
> itemTypeRead=false, keyTypeRead=false, valTypeRead=false, curType=21,
> curItemType=null, curKeyType=null, curValType=null, readMsgCls=class
> o.a.i.i.managers.communication.GridIoMessage]StateItem
> [stream=DirectByteBufferStreamImplV2 [baseOff=140703933959040, arrOff=-1,
> tmpArrOff=0, valReadBytes=0, tmpArrBytes=0, msgTypeDone=true,
> msg=PartitionUpdateCountersMessage{cacheId=-553317389, size=0, cntrs=},
> mapIt=null, it=null, arrPos=-1, keyDone=false, readSize=1, readItems=0,
> prim=0, primShift=0, uuidState=0, uuidMost=0, uuidLeast=0, uuidLocId=0,
> lastFinished=true], state=0, fieldCnt=-1, readFieldCnt=0, curName=null,
> typeRead=false, itemTypeRead=false, keyTypeRead=false, valTypeRead=false,
> curType=0, curItemType=null, curKeyType=null, curValType=null,
> readMsgCls=null]StateItem [stream=DirectByteBufferStreamImplV2
> [baseOff=140703933959040, arrOff=-1, tmpArrOff=0, valReadBytes=0,
> tmpArrBytes=0, msgTypeDone=false, msg=null, mapIt=null, it=null, arrPos=-1,
> keyDone=false, readSize=-1, readItems=0, prim=0, primShift=0, uuidState=0,
> uuidMost=0, uuidLeast=0, uuidLocId=0, lastFinished=true], state=0,
> fieldCnt=-1,
[jira] [Commented] (IGNITE-10136) NPE in PartitionUpdateCountersMessage
[
https://issues.apache.org/jira/browse/IGNITE-10136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17085006#comment-17085006
]
Nikolay Izhikov commented on IGNITE-10136:
--
Moved to 2.9
Please, write a comment if you want to see the fix for this issue in 2.8.1
> NPE in PartitionUpdateCountersMessage
> -
>
> Key: IGNITE-10136
> URL: https://issues.apache.org/jira/browse/IGNITE-10136
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.7
>Reporter: Sergey Kozlov
>Assignee: Sergey Kozlov
>Priority: Critical
> Fix For: 2.9, 2.8.1
>
>
> {noformat}
> [14:00:55,950][INFO][db-checkpoint-thread-#73][GridCacheDatabaseSharedManager]
> Checkpoint started [checkpointId=9d5398bc-896a-469c-8686-38e2afd517c1,
> startPtr=FileWALPointer [idx=0, fileOff=17828636, len=210609],
> checkpointLockWait=0ms, checkpointLockHoldTime=11ms,
> walCpRecordFsyncDuration=12ms, pages=636, reason='timeout']
> [14:00:56,029][INFO][db-checkpoint-thread-#73][GridCacheDatabaseSharedManager]
> Checkpoint finished [cpId=9d5398bc-896a-469c-8686-38e2afd517c1, pages=636,
> markPos=FileWALPointer [idx=0, fileOff=17828636, len=210609],
> walSegmentsCleared=0, walSegmentsCovered=[], markDuration=26ms,
> pagesWrite=21ms, fsync=58ms, total=105ms]
> [14:00:56,940][INFO][db-checkpoint-thread-#73][GridCacheDatabaseSharedManager]
> Checkpoint started [checkpointId=5f46c89e-ead8-4c87-adad-72a50c26bd7c,
> startPtr=FileWALPointer [idx=0, fileOff=20005440, len=210609],
> checkpointLockWait=0ms, checkpointLockHoldTime=8ms,
> walCpRecordFsyncDuration=5ms, pages=474, reason='timeout']
> [14:00:57,003][INFO][db-checkpoint-thread-#73][GridCacheDatabaseSharedManager]
> Checkpoint finished [cpId=5f46c89e-ead8-4c87-adad-72a50c26bd7c, pages=474,
> markPos=FileWALPointer [idx=0, fileOff=20005440, len=210609],
> walSegmentsCleared=0, walSegmentsCovered=[], markDuration=15ms,
> pagesWrite=10ms, fsync=53ms, total=78ms]
> [14:00:57,065][SEVERE][grid-nio-worker-tcp-comm-2-#42][GridDirectParser]
> Failed to read message [msg=GridIoMessage [plc=0, topic=null, topicOrd=-1,
> ordered=false, timeout=0, skipOnTimeout=false, msg=null],
> buf=java.nio.DirectByteBuffer[pos=792 lim=885 cap=32768],
> reader=RollingUpgradeMessageReader [state=StateItem
> [stream=DirectByteBufferStreamImplV2 [baseOff=140703933959040, arrOff=-1,
> tmpArrOff=0, valReadBytes=0, tmpArrBytes=0, msgTypeDone=true,
> msg=GridCacheIdMessage [cacheId=0]GridDistributedBaseMessage
> [ver=GridCacheVersion [topVer=152301622, order=1540821647376, nodeOrder=4],
> committedVers=null, rolledbackVers=null, cnt=0,
> super=]GridDistributedTxPrepareRequest [threadId=236,
> concurrency=PESSIMISTIC, isolation=REPEATABLE_READ, writeVer=GridCacheVersion
> [topVer=152301622, order=1540821647377, nodeOrder=4], timeout=0, reads=null,
> writes=ArrayList [], dhtVers=null, txSize=-1, plc=2, txState=null,
> flags=last, super=]GridDhtTxPrepareRequest
> [nearNodeId=3800f476-beb1-46b0-8a39-faa51c91831d,
> futId=f794020c661-cc8749ef-caa5-4f1e-9d89-4a9beff59798, miniId=1,
> topVer=AffinityTopologyVersion [topVer=5, minorTopVer=8],
> invalidateNearEntries={}, nearWrites=null, owned=null,
> nearXidVer=GridCacheVersion [topVer=152301622, order=1540821647374,
> nodeOrder=5], subjId=3800f476-beb1-46b0-8a39-faa51c91831d, taskNameHash=0,
> preloadKeys=null, mvccSnapshot=MvccSnapshotResponse [futId=1,
> crdVer=1540821617885, cntr=16, opCntr=1, txs=null, cleanupVer=15,
> tracking=0], skipCompletedVers=false, super=], mapIt=null, it=null,
> arrPos=-1, keyDone=false, readSize=-1, readItems=0, prim=0, primShift=0,
> uuidState=0, uuidMost=0, uuidLeast=0, uuidLocId=0, lastFinished=true],
> state=0, fieldCnt=7, readFieldCnt=0, curName=msg, typeRead=true,
> itemTypeRead=false, keyTypeRead=false, valTypeRead=false, curType=21,
> curItemType=null, curKeyType=null, curValType=null, readMsgCls=class
> o.a.i.i.managers.communication.GridIoMessage]StateItem
> [stream=DirectByteBufferStreamImplV2 [baseOff=140703933959040, arrOff=-1,
> tmpArrOff=0, valReadBytes=0, tmpArrBytes=0, msgTypeDone=true,
> msg=PartitionUpdateCountersMessage{cacheId=-553317389, size=0, cntrs=},
> mapIt=null, it=null, arrPos=-1, keyDone=false, readSize=1, readItems=0,
> prim=0, primShift=0, uuidState=0, uuidMost=0, uuidLeast=0, uuidLocId=0,
> lastFinished=true], state=0, fieldCnt=-1, readFieldCnt=0, curName=null,
> typeRead=false, itemTypeRead=false, keyTypeRead=false, valTypeRead=false,
> curType=0, curItemType=null, curKeyType=null, curValType=null,
> readMsgCls=null]StateItem [stream=DirectByteBufferStreamImplV2
> [baseOff=140703933959040, arrOff=-1, tmpArrOff=0, valReadBytes=0,
> tmpArrBytes=0, msgTypeDone=false, msg=null, mapIt=null, it=null, arrPos=-1,
> keyDone=false, readSize=-1, readItems=0, prim=0,
[jira] [Resolved] (IGNITE-10313) Long exchange on deactivation process
[ https://issues.apache.org/jira/browse/IGNITE-10313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov resolved IGNITE-10313. -- Resolution: Incomplete Hello, [~ARomantsov] Can you, please, provide more details about this issue? Logs, configs, cluster topology For now, I'm closing this issue as incomplete. Please, feel free to reopen it. > Long exchange on deactivation process > - > > Key: IGNITE-10313 > URL: https://issues.apache.org/jira/browse/IGNITE-10313 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.7 > Environment: 16 host, 1 server node per host >Reporter: ARomantsov >Priority: Critical > Fix For: 2.9, 2.8.1 > > > Long exhange after start deactivation process - near to three minutes. > Probably in doesn't end, but control.sh return to control to console and I > stop cluster -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-10313) Long exchange on deactivation process
[ https://issues.apache.org/jira/browse/IGNITE-10313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov reassigned IGNITE-10313: Assignee: (was: Nikolay Izhikov) > Long exchange on deactivation process > - > > Key: IGNITE-10313 > URL: https://issues.apache.org/jira/browse/IGNITE-10313 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.7 > Environment: 16 host, 1 server node per host >Reporter: ARomantsov >Priority: Critical > Fix For: 2.9, 2.8.1 > > > Long exhange after start deactivation process - near to three minutes. > Probably in doesn't end, but control.sh return to control to console and I > stop cluster -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-10313) Long exchange on deactivation process
[ https://issues.apache.org/jira/browse/IGNITE-10313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov reassigned IGNITE-10313: Assignee: Nikolay Izhikov > Long exchange on deactivation process > - > > Key: IGNITE-10313 > URL: https://issues.apache.org/jira/browse/IGNITE-10313 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.7 > Environment: 16 host, 1 server node per host >Reporter: ARomantsov >Assignee: Nikolay Izhikov >Priority: Critical > Fix For: 2.9, 2.8.1 > > > Long exhange after start deactivation process - near to three minutes. > Probably in doesn't end, but control.sh return to control to console and I > stop cluster -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-8409) Ignite gets stuck on IgniteDataStreamer.addData when using Object with AffinityKeyMapped
[ https://issues.apache.org/jira/browse/IGNITE-8409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17084995#comment-17084995 ] Nikolay Izhikov commented on IGNITE-8409: - Hello, [~agoncharuk] Are you working on this issue? > Ignite gets stuck on IgniteDataStreamer.addData when using Object with > AffinityKeyMapped > > > Key: IGNITE-8409 > URL: https://issues.apache.org/jira/browse/IGNITE-8409 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.3 >Reporter: Andrey Aleksandrov >Assignee: Alexey Goncharuk >Priority: Critical > Fix For: 2.9, 2.8.1 > > Attachments: ContextCpty.java, TradeKey.java, TradeKeyNew.java > > > This problem reproduces from time to time when we are streaming the data > (TradeKey.java) to Ignite sql cache. As AffinityKeyMapped we used the object > type (ContextCpty.java) > When we change AffinityKeyMapped type from object to long type > (TradeKeyNew.java) then problem disappears. > Investigation help to understand that we hang in BPlusTree.java class in next > method: > private Result putDown(final Put p, final long pageId, final long fwdId, > final int lvl) > In this method: > res = p.tryReplaceInner(pageId, page, fwdId, lvl); > if (res != RETRY) // Go down recursively. > res = putDown(p, p.pageId, p.fwdId, lvl - 1); > if (res == RETRY_ROOT || p.isFinished()) > return res; > if (res == RETRY) > checkInterrupted(); //WE ALWAYS GO TO THIS PLACE -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12489) Error during purges by expiration: Unknown page type
[
https://issues.apache.org/jira/browse/IGNITE-12489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17084994#comment-17084994
]
Nikolay Izhikov commented on IGNITE-12489:
--
Hello, [~akalashnikov]
Are you working on this issue?
> Error during purges by expiration: Unknown page type
>
>
> Key: IGNITE-12489
> URL: https://issues.apache.org/jira/browse/IGNITE-12489
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.7, 2.7.6
>Reporter: Ruslan Kamashev
>Assignee: Anton Kalashnikov
>Priority: Blocker
> Fix For: 2.9, 2.8.1
>
>
> {{*logger*}}
> {code:java}
> org.apache.ignite.internal.processors.cache.GridCacheIoManager
> {code}
> {{*message*}}
> {code:java}
> Failed to process message [senderId=969d56ba-4b46-40cf-886e-ac445cf6a95d,
> messageType=class
> o.a.i.i.processors.cache.distributed.dht.atomic.GridDhtAtomicUpdateRequest]{code}
> {{*thread*}}
> {code:java}
> sys-stripe-19-#20{code}
> {{*trace*}}
> {code:java}
> java.lang.IllegalStateException: Unknown page type: 1 pageId: 00010303117d
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.io(BPlusTree.java:5058)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.access$200(BPlusTree.java:90)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$AbstractForwardCursor.nextPage(BPlusTree.java:5330)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$ForwardCursor.next(BPlusTree.java:5566)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.purgeExpiredInternal(GridCacheOffheapManager.java:2232)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.purgeExpired(GridCacheOffheapManager.java:2157)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager.expire(GridCacheOffheapManager.java:845)
> at
> org.apache.ignite.internal.processors.cache.GridCacheTtlManager.expire(GridCacheTtlManager.java:207)
> at
> org.apache.ignite.internal.processors.cache.GridCacheUtils.unwindEvicts(GridCacheUtils.java:888)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessageProcessed(GridCacheIoManager.java:1103)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1076)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:581)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:380)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:306)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:101)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:295)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1569)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1197)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:127)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1093)
> at
> org.apache.ignite.internal.util.StripedExecutor$Stripe.body(StripedExecutor.java:505)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> at java.lang.Thread.run(Thread.java:748)
> Dec 23, 2019 @ 18:28:28.457 {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12489) Error during purges by expiration: Unknown page type
[
https://issues.apache.org/jira/browse/IGNITE-12489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov updated IGNITE-12489:
-
Fix Version/s: 2.8.1
> Error during purges by expiration: Unknown page type
>
>
> Key: IGNITE-12489
> URL: https://issues.apache.org/jira/browse/IGNITE-12489
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.7, 2.7.6
>Reporter: Ruslan Kamashev
>Assignee: Anton Kalashnikov
>Priority: Blocker
> Fix For: 2.9, 2.8.1
>
>
> {{*logger*}}
> {code:java}
> org.apache.ignite.internal.processors.cache.GridCacheIoManager
> {code}
> {{*message*}}
> {code:java}
> Failed to process message [senderId=969d56ba-4b46-40cf-886e-ac445cf6a95d,
> messageType=class
> o.a.i.i.processors.cache.distributed.dht.atomic.GridDhtAtomicUpdateRequest]{code}
> {{*thread*}}
> {code:java}
> sys-stripe-19-#20{code}
> {{*trace*}}
> {code:java}
> java.lang.IllegalStateException: Unknown page type: 1 pageId: 00010303117d
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.io(BPlusTree.java:5058)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.access$200(BPlusTree.java:90)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$AbstractForwardCursor.nextPage(BPlusTree.java:5330)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$ForwardCursor.next(BPlusTree.java:5566)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.purgeExpiredInternal(GridCacheOffheapManager.java:2232)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.purgeExpired(GridCacheOffheapManager.java:2157)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager.expire(GridCacheOffheapManager.java:845)
> at
> org.apache.ignite.internal.processors.cache.GridCacheTtlManager.expire(GridCacheTtlManager.java:207)
> at
> org.apache.ignite.internal.processors.cache.GridCacheUtils.unwindEvicts(GridCacheUtils.java:888)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessageProcessed(GridCacheIoManager.java:1103)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1076)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:581)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:380)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:306)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:101)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:295)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1569)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1197)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:127)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1093)
> at
> org.apache.ignite.internal.util.StripedExecutor$Stripe.body(StripedExecutor.java:505)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> at java.lang.Thread.run(Thread.java:748)
> Dec 23, 2019 @ 18:28:28.457 {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12489) Error during purges by expiration: Unknown page type
[
https://issues.apache.org/jira/browse/IGNITE-12489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov updated IGNITE-12489:
-
Fix Version/s: (was: 2.8.1)
> Error during purges by expiration: Unknown page type
>
>
> Key: IGNITE-12489
> URL: https://issues.apache.org/jira/browse/IGNITE-12489
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.7, 2.7.6
>Reporter: Ruslan Kamashev
>Assignee: Anton Kalashnikov
>Priority: Blocker
> Fix For: 2.9
>
>
> {{*logger*}}
> {code:java}
> org.apache.ignite.internal.processors.cache.GridCacheIoManager
> {code}
> {{*message*}}
> {code:java}
> Failed to process message [senderId=969d56ba-4b46-40cf-886e-ac445cf6a95d,
> messageType=class
> o.a.i.i.processors.cache.distributed.dht.atomic.GridDhtAtomicUpdateRequest]{code}
> {{*thread*}}
> {code:java}
> sys-stripe-19-#20{code}
> {{*trace*}}
> {code:java}
> java.lang.IllegalStateException: Unknown page type: 1 pageId: 00010303117d
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.io(BPlusTree.java:5058)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.access$200(BPlusTree.java:90)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$AbstractForwardCursor.nextPage(BPlusTree.java:5330)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$ForwardCursor.next(BPlusTree.java:5566)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.purgeExpiredInternal(GridCacheOffheapManager.java:2232)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.purgeExpired(GridCacheOffheapManager.java:2157)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager.expire(GridCacheOffheapManager.java:845)
> at
> org.apache.ignite.internal.processors.cache.GridCacheTtlManager.expire(GridCacheTtlManager.java:207)
> at
> org.apache.ignite.internal.processors.cache.GridCacheUtils.unwindEvicts(GridCacheUtils.java:888)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessageProcessed(GridCacheIoManager.java:1103)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1076)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:581)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:380)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:306)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:101)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:295)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1569)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1197)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:127)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1093)
> at
> org.apache.ignite.internal.util.StripedExecutor$Stripe.body(StripedExecutor.java:505)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> at java.lang.Thread.run(Thread.java:748)
> Dec 23, 2019 @ 18:28:28.457 {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12795) Partially revert changes to atomic caches introduced in IGNITE-11797
[
https://issues.apache.org/jira/browse/IGNITE-12795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17084988#comment-17084988
]
Nikolay Izhikov commented on IGNITE-12795:
--
Hello, [~ascherbakov]
Can you provide a fix for this issue?
> Partially revert changes to atomic caches introduced in IGNITE-11797
>
>
> Key: IGNITE-12795
> URL: https://issues.apache.org/jira/browse/IGNITE-12795
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.8
>Reporter: Alexey Scherbakov
>Assignee: Alexey Scherbakov
>Priority: Blocker
> Fix For: 2.8.1
>
>
> These changes can trigger node failure during update on backup:
> Better fix for atomics is needed.
> {noformat}
> class org.apache.ignite.IgniteCheckedException: Failed to update the counter
> [newVal=173, curState=Counter [lwm=172, holes={173=Item [start=173,
> delta=1]}, maxApplied=174, hwm=173]]
> at
> org.apache.ignite.internal.processors.cache.PartitionUpdateCounterTrackingImpl.update(PartitionUpdateCounterTrackingImpl.java:152)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.updateCounter(IgniteCacheOffheapManagerImpl.java:1578)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.updateCounter(GridCacheOffheapManager.java:2198)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.topology.GridDhtLocalPartition.nextUpdateCounter(GridDhtLocalPartition.java:995)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheEntry.nextPartitionCounter(GridDhtCacheEntry.java:104)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry$AtomicCacheUpdateClosure.update(GridCacheMapEntry.java:6434)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry$AtomicCacheUpdateClosure.call(GridCacheMapEntry.java:6190)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry$AtomicCacheUpdateClosure.call(GridCacheMapEntry.java:5881)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Invoke.invokeClosure(BPlusTree.java:3995)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Invoke.access$5700(BPlusTree.java:3889)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.invokeDown(BPlusTree.java:2020)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.invoke(BPlusTree.java:1904)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.invoke0(IgniteCacheOffheapManagerImpl.java:1656)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.invoke(IgniteCacheOffheapManagerImpl.java:1639)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.invoke(GridCacheOffheapManager.java:2450)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.invoke(IgniteCacheOffheapManagerImpl.java:436)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.innerUpdate(GridCacheMapEntry.java:2311)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.processDhtAtomicUpdateRequest(GridDhtAtomicCache.java:3362)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.access$600(GridDhtAtomicCache.java:139)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$7.apply(GridDhtAtomicCache.java:311)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$7.apply(GridDhtAtomicCache.java:306)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1142)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:591)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:392)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:318)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:109)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:308)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1637)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1257)
> at
>
[jira] [Commented] (IGNITE-12489) Error during purges by expiration: Unknown page type
[
https://issues.apache.org/jira/browse/IGNITE-12489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17084987#comment-17084987
]
Maxim Muzafarov commented on IGNITE-12489:
--
Hello,
This issue still needs to be investigated and resolved.
Issues IGNITE-12593, IGNITE-12594 which is probably related to this issue
already in the 2.8 branch.
> Error during purges by expiration: Unknown page type
>
>
> Key: IGNITE-12489
> URL: https://issues.apache.org/jira/browse/IGNITE-12489
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.7, 2.7.6
>Reporter: Ruslan Kamashev
>Assignee: Anton Kalashnikov
>Priority: Blocker
> Fix For: 2.9, 2.8.1
>
>
> {{*logger*}}
> {code:java}
> org.apache.ignite.internal.processors.cache.GridCacheIoManager
> {code}
> {{*message*}}
> {code:java}
> Failed to process message [senderId=969d56ba-4b46-40cf-886e-ac445cf6a95d,
> messageType=class
> o.a.i.i.processors.cache.distributed.dht.atomic.GridDhtAtomicUpdateRequest]{code}
> {{*thread*}}
> {code:java}
> sys-stripe-19-#20{code}
> {{*trace*}}
> {code:java}
> java.lang.IllegalStateException: Unknown page type: 1 pageId: 00010303117d
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.io(BPlusTree.java:5058)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.access$200(BPlusTree.java:90)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$AbstractForwardCursor.nextPage(BPlusTree.java:5330)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$ForwardCursor.next(BPlusTree.java:5566)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.purgeExpiredInternal(GridCacheOffheapManager.java:2232)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.purgeExpired(GridCacheOffheapManager.java:2157)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager.expire(GridCacheOffheapManager.java:845)
> at
> org.apache.ignite.internal.processors.cache.GridCacheTtlManager.expire(GridCacheTtlManager.java:207)
> at
> org.apache.ignite.internal.processors.cache.GridCacheUtils.unwindEvicts(GridCacheUtils.java:888)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessageProcessed(GridCacheIoManager.java:1103)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1076)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:581)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:380)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:306)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:101)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:295)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1569)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1197)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:127)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1093)
> at
> org.apache.ignite.internal.util.StripedExecutor$Stripe.body(StripedExecutor.java:505)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> at java.lang.Thread.run(Thread.java:748)
> Dec 23, 2019 @ 18:28:28.457 {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12765) Slim binary release and docker image for Apache Ignite
[
https://issues.apache.org/jira/browse/IGNITE-12765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17084986#comment-17084986
]
Nikolay Izhikov commented on IGNITE-12765:
--
Moved to 2.9
Please, write a comment if you want to see the fix for this issue in 2.8.1
> Slim binary release and docker image for Apache Ignite
> --
>
> Key: IGNITE-12765
> URL: https://issues.apache.org/jira/browse/IGNITE-12765
> Project: Ignite
> Issue Type: Task
>Reporter: Maxim Muzafarov
>Priority: Blocker
> Fix For: 2.9
>
>
> 1. Prepare Apache Ignite "slim" distribution (example:
> https://github.com/apache/ignite/tree/ignite-slim)
> 2. Update configuration and check Apache Ignite RELEASE TeamCity Suite
> according to a new additional package distribution.
> See - discussion on dev-list
> http://apache-ignite-developers.2346864.n4.nabble.com/Slim-binary-release-and-docker-image-for-Apache-Ignite-td45110.html
> {code}
> libs:
> core/shmem/jcache
> ignite-indexing
> ignite-spring
> libs/optional:
> ignite-compress
> ignite-rest-http
> ignite-spring-data_2.2
> ignite-log4j2
> ignite-log4j
> ignite-slf4j
> ignite-opencensus
> ignite-kubernetes
> ignite-urideploy
> ignite-jta
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12398) Apache Ignite Cluster(Amazon S3 Based Discovery) Nodes getting down if we connect Ignite Visor Command Line Interface
[
https://issues.apache.org/jira/browse/IGNITE-12398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17084984#comment-17084984
]
Nikolay Izhikov commented on IGNITE-12398:
--
Moved to 2.9 release.
Please, write a comment if you want to see the fix in 2.8.1
> Apache Ignite Cluster(Amazon S3 Based Discovery) Nodes getting down if we
> connect Ignite Visor Command Line Interface
> -
>
> Key: IGNITE-12398
> URL: https://issues.apache.org/jira/browse/IGNITE-12398
> Project: Ignite
> Issue Type: Bug
> Components: aws, general, s3, visor
>Affects Versions: 2.7
> Environment: Production
>Reporter: Ravi Kumar Powli
>Assignee: Emmanouil Gkatziouras
>Priority: Blocker
> Fix For: 2.9
>
>
> We have Apache Ignite 3 node cluster setup with Amazon S3 Based Discovery. If
> we connect any one cluster node using Ignite Visor Command Line Interface it
> got hang and automatically cluster nodes(all the three nodes) are going down.
> Please find the below exception stacktrace.
> {noformat}
> [SEVERE][tcp-disco-msg-worker-#2%DataStoreIgniteCache%][] Critical system
> error detected. Will be handled accordingly to configured handler
> [hnd=NoOpFailureHandler [super=AbstractFailureHandler
> [ignoredFailureTypes=[SYSTEM_WORKER_BLOCKED]]], failureCtx=FailureContext
> [type=SYSTEM_WORKER_TERMINATION, err=java.lang.NullPointerException]]
> java.lang.NullPointerException
> at
> org.apache.ignite.spi.discovery.tcp.ipfinder.s3.TcpDiscoveryS3IpFinder.key(TcpDiscoveryS3IpFinder.java:247)
> at
> org.apache.ignite.spi.discovery.tcp.ipfinder.s3.TcpDiscoveryS3IpFinder.registerAddresses(TcpDiscoveryS3IpFinder.java:205)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processNodeAddFinishedMessage(ServerImpl.java:4616)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processNodeAddedMessage(ServerImpl.java:4232)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2816)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2611)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorker.body(ServerImpl.java:7188)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.body(ServerImpl.java:2700)
> at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorkerThread.body(ServerImpl.java:7119)
> at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
> [10:36:54,600][SEVERE][tcp-disco-msg-worker-#2%DataStoreIgniteCache%][]
> Critical system error detected. Will be handled accordingly to configured
> handler [hnd=NoOpFailureHandler [super=AbstractFailureHandler
> [ignoredFailureTypes=[SYSTEM_WORKER_BLOCKED]]], failureCtx=FailureContext
> [type=SYSTEM_WORKER_TERMINATION, err=class o.a.i.IgniteException: GridWorker
> [name=tcp-disco-msg-worker, igniteInstanceName=DataStoreIgniteCache,
> finished=true, heartbeatTs=1574332614423]]]
> class org.apache.ignite.IgniteException: GridWorker
> [name=tcp-disco-msg-worker, igniteInstanceName=DataStoreIgniteCache,
> finished=true, heartbeatTs=1574332614423]
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance$2.apply(IgnitionEx.java:1831)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance$2.apply(IgnitionEx.java:1826)
> at
> org.apache.ignite.internal.worker.WorkersRegistry.onStopped(WorkersRegistry.java:169)
> at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:153)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorkerThread.body(ServerImpl.java:7119)
> at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
> [10:36:59] Ignite node stopped OK [name=DataStoreIgniteCache,
> uptime=00:01:13.934]
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12765) Slim binary release and docker image for Apache Ignite
[
https://issues.apache.org/jira/browse/IGNITE-12765?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov updated IGNITE-12765:
-
Fix Version/s: (was: 2.8.1)
2.9
> Slim binary release and docker image for Apache Ignite
> --
>
> Key: IGNITE-12765
> URL: https://issues.apache.org/jira/browse/IGNITE-12765
> Project: Ignite
> Issue Type: Task
>Reporter: Maxim Muzafarov
>Priority: Blocker
> Fix For: 2.9
>
>
> 1. Prepare Apache Ignite "slim" distribution (example:
> https://github.com/apache/ignite/tree/ignite-slim)
> 2. Update configuration and check Apache Ignite RELEASE TeamCity Suite
> according to a new additional package distribution.
> See - discussion on dev-list
> http://apache-ignite-developers.2346864.n4.nabble.com/Slim-binary-release-and-docker-image-for-Apache-Ignite-td45110.html
> {code}
> libs:
> core/shmem/jcache
> ignite-indexing
> ignite-spring
> libs/optional:
> ignite-compress
> ignite-rest-http
> ignite-spring-data_2.2
> ignite-log4j2
> ignite-log4j
> ignite-slf4j
> ignite-opencensus
> ignite-kubernetes
> ignite-urideploy
> ignite-jta
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12398) Apache Ignite Cluster(Amazon S3 Based Discovery) Nodes getting down if we connect Ignite Visor Command Line Interface
[
https://issues.apache.org/jira/browse/IGNITE-12398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov updated IGNITE-12398:
-
Fix Version/s: (was: 2.8.1)
2.9
> Apache Ignite Cluster(Amazon S3 Based Discovery) Nodes getting down if we
> connect Ignite Visor Command Line Interface
> -
>
> Key: IGNITE-12398
> URL: https://issues.apache.org/jira/browse/IGNITE-12398
> Project: Ignite
> Issue Type: Bug
> Components: aws, general, s3, visor
>Affects Versions: 2.7
> Environment: Production
>Reporter: Ravi Kumar Powli
>Assignee: Emmanouil Gkatziouras
>Priority: Blocker
> Fix For: 2.9
>
>
> We have Apache Ignite 3 node cluster setup with Amazon S3 Based Discovery. If
> we connect any one cluster node using Ignite Visor Command Line Interface it
> got hang and automatically cluster nodes(all the three nodes) are going down.
> Please find the below exception stacktrace.
> {noformat}
> [SEVERE][tcp-disco-msg-worker-#2%DataStoreIgniteCache%][] Critical system
> error detected. Will be handled accordingly to configured handler
> [hnd=NoOpFailureHandler [super=AbstractFailureHandler
> [ignoredFailureTypes=[SYSTEM_WORKER_BLOCKED]]], failureCtx=FailureContext
> [type=SYSTEM_WORKER_TERMINATION, err=java.lang.NullPointerException]]
> java.lang.NullPointerException
> at
> org.apache.ignite.spi.discovery.tcp.ipfinder.s3.TcpDiscoveryS3IpFinder.key(TcpDiscoveryS3IpFinder.java:247)
> at
> org.apache.ignite.spi.discovery.tcp.ipfinder.s3.TcpDiscoveryS3IpFinder.registerAddresses(TcpDiscoveryS3IpFinder.java:205)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processNodeAddFinishedMessage(ServerImpl.java:4616)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processNodeAddedMessage(ServerImpl.java:4232)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2816)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2611)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorker.body(ServerImpl.java:7188)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.body(ServerImpl.java:2700)
> at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorkerThread.body(ServerImpl.java:7119)
> at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
> [10:36:54,600][SEVERE][tcp-disco-msg-worker-#2%DataStoreIgniteCache%][]
> Critical system error detected. Will be handled accordingly to configured
> handler [hnd=NoOpFailureHandler [super=AbstractFailureHandler
> [ignoredFailureTypes=[SYSTEM_WORKER_BLOCKED]]], failureCtx=FailureContext
> [type=SYSTEM_WORKER_TERMINATION, err=class o.a.i.IgniteException: GridWorker
> [name=tcp-disco-msg-worker, igniteInstanceName=DataStoreIgniteCache,
> finished=true, heartbeatTs=1574332614423]]]
> class org.apache.ignite.IgniteException: GridWorker
> [name=tcp-disco-msg-worker, igniteInstanceName=DataStoreIgniteCache,
> finished=true, heartbeatTs=1574332614423]
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance$2.apply(IgnitionEx.java:1831)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance$2.apply(IgnitionEx.java:1826)
> at
> org.apache.ignite.internal.worker.WorkersRegistry.onStopped(WorkersRegistry.java:169)
> at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:153)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorkerThread.body(ServerImpl.java:7119)
> at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
> [10:36:59] Ignite node stopped OK [name=DataStoreIgniteCache,
> uptime=00:01:13.934]
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12398) Apache Ignite Cluster(Amazon S3 Based Discovery) Nodes getting down if we connect Ignite Visor Command Line Interface
[
https://issues.apache.org/jira/browse/IGNITE-12398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov updated IGNITE-12398:
-
Description:
We have Apache Ignite 3 node cluster setup with Amazon S3 Based Discovery. If
we connect any one cluster node using Ignite Visor Command Line Interface it
got hang and automatically cluster nodes(all the three nodes) are going down.
Please find the below exception stacktrace.
{noformat}
[SEVERE][tcp-disco-msg-worker-#2%DataStoreIgniteCache%][] Critical system error
detected. Will be handled accordingly to configured handler
[hnd=NoOpFailureHandler [super=AbstractFailureHandler
[ignoredFailureTypes=[SYSTEM_WORKER_BLOCKED]]], failureCtx=FailureContext
[type=SYSTEM_WORKER_TERMINATION, err=java.lang.NullPointerException]]
java.lang.NullPointerException
at
org.apache.ignite.spi.discovery.tcp.ipfinder.s3.TcpDiscoveryS3IpFinder.key(TcpDiscoveryS3IpFinder.java:247)
at
org.apache.ignite.spi.discovery.tcp.ipfinder.s3.TcpDiscoveryS3IpFinder.registerAddresses(TcpDiscoveryS3IpFinder.java:205)
at
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processNodeAddFinishedMessage(ServerImpl.java:4616)
at
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processNodeAddedMessage(ServerImpl.java:4232)
at
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2816)
at
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2611)
at
org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorker.body(ServerImpl.java:7188)
at
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.body(ServerImpl.java:2700)
at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
at
org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorkerThread.body(ServerImpl.java:7119)
at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
[10:36:54,600][SEVERE][tcp-disco-msg-worker-#2%DataStoreIgniteCache%][]
Critical system error detected. Will be handled accordingly to configured
handler [hnd=NoOpFailureHandler [super=AbstractFailureHandler
[ignoredFailureTypes=[SYSTEM_WORKER_BLOCKED]]], failureCtx=FailureContext
[type=SYSTEM_WORKER_TERMINATION, err=class o.a.i.IgniteException: GridWorker
[name=tcp-disco-msg-worker, igniteInstanceName=DataStoreIgniteCache,
finished=true, heartbeatTs=1574332614423]]]
class org.apache.ignite.IgniteException: GridWorker [name=tcp-disco-msg-worker,
igniteInstanceName=DataStoreIgniteCache, finished=true,
heartbeatTs=1574332614423]
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance$2.apply(IgnitionEx.java:1831)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance$2.apply(IgnitionEx.java:1826)
at
org.apache.ignite.internal.worker.WorkersRegistry.onStopped(WorkersRegistry.java:169)
at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:153)
at
org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorkerThread.body(ServerImpl.java:7119)
at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
[10:36:59] Ignite node stopped OK [name=DataStoreIgniteCache,
uptime=00:01:13.934]
{noformat}
was:
We have Apache Ignite 3 node cluster setup with Amazon S3 Based Discovery. If
we connect any one cluster node using Ignite Visor Command Line Interface it
got hang and automatically cluster nodes(all the three nodes) are going down.
Please find the below exception stacktrace.
[SEVERE][tcp-disco-msg-worker-#2%DataStoreIgniteCache%][] Critical system error
detected. Will be handled accordingly to configured handler
[hnd=NoOpFailureHandler [super=AbstractFailureHandler
[ignoredFailureTypes=[SYSTEM_WORKER_BLOCKED]]], failureCtx=FailureContext
[type=SYSTEM_WORKER_TERMINATION, err=java.lang.NullPointerException]]
java.lang.NullPointerException
at
org.apache.ignite.spi.discovery.tcp.ipfinder.s3.TcpDiscoveryS3IpFinder.key(TcpDiscoveryS3IpFinder.java:247)
at
org.apache.ignite.spi.discovery.tcp.ipfinder.s3.TcpDiscoveryS3IpFinder.registerAddresses(TcpDiscoveryS3IpFinder.java:205)
at
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processNodeAddFinishedMessage(ServerImpl.java:4616)
at
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processNodeAddedMessage(ServerImpl.java:4232)
at
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2816)
at
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2611)
at
org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorker.body(ServerImpl.java:7188)
at
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.body(ServerImpl.java:2700)
at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
at
org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorkerThread.body(ServerImpl.java:7119)
at
[jira] [Commented] (IGNITE-12489) Error during purges by expiration: Unknown page type
[
https://issues.apache.org/jira/browse/IGNITE-12489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17084982#comment-17084982
]
Nikolay Izhikov commented on IGNITE-12489:
--
Hello, [~mmuzaf]
Can you, please, clarify, what commits have to be cherry-picked in 2.8.1 branch?
> Error during purges by expiration: Unknown page type
>
>
> Key: IGNITE-12489
> URL: https://issues.apache.org/jira/browse/IGNITE-12489
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.7, 2.7.6
>Reporter: Ruslan Kamashev
>Assignee: Anton Kalashnikov
>Priority: Blocker
> Fix For: 2.9, 2.8.1
>
>
> {{*logger*}}
> {code:java}
> org.apache.ignite.internal.processors.cache.GridCacheIoManager
> {code}
> {{*message*}}
> {code:java}
> Failed to process message [senderId=969d56ba-4b46-40cf-886e-ac445cf6a95d,
> messageType=class
> o.a.i.i.processors.cache.distributed.dht.atomic.GridDhtAtomicUpdateRequest]{code}
> {{*thread*}}
> {code:java}
> sys-stripe-19-#20{code}
> {{*trace*}}
> {code:java}
> java.lang.IllegalStateException: Unknown page type: 1 pageId: 00010303117d
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.io(BPlusTree.java:5058)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.access$200(BPlusTree.java:90)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$AbstractForwardCursor.nextPage(BPlusTree.java:5330)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$ForwardCursor.next(BPlusTree.java:5566)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.purgeExpiredInternal(GridCacheOffheapManager.java:2232)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.purgeExpired(GridCacheOffheapManager.java:2157)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager.expire(GridCacheOffheapManager.java:845)
> at
> org.apache.ignite.internal.processors.cache.GridCacheTtlManager.expire(GridCacheTtlManager.java:207)
> at
> org.apache.ignite.internal.processors.cache.GridCacheUtils.unwindEvicts(GridCacheUtils.java:888)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessageProcessed(GridCacheIoManager.java:1103)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1076)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:581)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:380)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:306)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:101)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:295)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1569)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1197)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:127)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1093)
> at
> org.apache.ignite.internal.util.StripedExecutor$Stripe.body(StripedExecutor.java:505)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> at java.lang.Thread.run(Thread.java:748)
> Dec 23, 2019 @ 18:28:28.457 {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12827) OutOfMemory exception when calling grid service from .NET with user type array parameter
[
https://issues.apache.org/jira/browse/IGNITE-12827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov updated IGNITE-12827:
-
Fix Version/s: 2.8.1
> OutOfMemory exception when calling grid service from .NET with user type
> array parameter
>
>
> Key: IGNITE-12827
> URL: https://issues.apache.org/jira/browse/IGNITE-12827
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.8
>Reporter: Alexey Kukushkin
>Assignee: Ivan Daschinskiy
>Priority: Major
> Labels: sbcf
> Fix For: 2.8.1
>
> Attachments: ignite-12827-vs-2.8.patch
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Calling a grid service from .NET with a parameter of user type array leads to
> Java OutOfMemory exception.
> +*Reproducer*+:
> * Limit JVM heap with 128 MB.
> * Create a .NET or Java service with a parameter of type
> *array of* Parameter {
> Id: int,
> *array of* ParameterValue {
> PeriodId: int,
> Value: double?
> }
> }
> * Call service with an array of 200 Parameters
> +*Expected*+:
> 128 MB of heap must be enough to call Java or .NET service with 200
> Parameters.
>
> +*Actual*+:
> Java OutOfMemory exception on 21st Parameter
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12880) IllegalArgumentException on activation of LogExporterSpi
[
https://issues.apache.org/jira/browse/IGNITE-12880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov updated IGNITE-12880:
-
Fix Version/s: 2.8.1
> IllegalArgumentException on activation of LogExporterSpi
>
>
> Key: IGNITE-12880
> URL: https://issues.apache.org/jira/browse/IGNITE-12880
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.8
>Reporter: Denis A. Magda
>Assignee: Nikolay Izhikov
>Priority: Major
> Fix For: 2.8.1
>
>
> I tried to enable `LogExporterSpi` and getting an error below. Running on
> jdk1.8.0_77.jdk and macOS Catalina. See a source file attached.
> {noformat}
> Apr 08, 2020 1:07:00 PM org.apache.ignite.logger.java.JavaLogger error
> SEVERE: Got exception while starting (will rollback startup routine).
> java.lang.IllegalArgumentException
> at
> java.util.concurrent.ScheduledThreadPoolExecutor.scheduleWithFixedDelay(ScheduledThreadPoolExecutor.java:589)
> at
> org.apache.ignite.internal.processors.metric.PushMetricsExporterAdapter.spiStart(PushMetricsExporterAdapter.java:56)
> at
> org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:297)
> at
> org.apache.ignite.internal.processors.metric.GridMetricManager.start(GridMetricManager.java:277)
> at
> org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:1960)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1171)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2038)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1703)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1117)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:637)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:563)
> at org.apache.ignite.Ignition.start(Ignition.java:321)
> at ServerNodeStartup.main(ServerNodeStartup.java:43)
> Apr 08, 2020 1:07:00 PM org.apache.ignite.logger.java.JavaLogger error
> SEVERE: Failed to stop component (ignoring): GridManagerAdapter
> [enabled=true, name=o.a.i.i.processors.metric.GridMetricManager]
> java.lang.NullPointerException
> at
> org.apache.ignite.internal.processors.metric.PushMetricsExporterAdapter.spiStop(PushMetricsExporterAdapter.java:71)
> at
> org.apache.ignite.internal.managers.GridManagerAdapter.stopSpi(GridManagerAdapter.java:330)
> at
> org.apache.ignite.internal.processors.metric.GridMetricManager.stop(GridMetricManager.java:314)
> at org.apache.ignite.internal.IgniteKernal.stop0(IgniteKernal.java:2627)
> at org.apache.ignite.internal.IgniteKernal.stop(IgniteKernal.java:2499)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1395)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2038)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1703)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1117)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:637)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:563)
> at org.apache.ignite.Ignition.start(Ignition.java:321)
> at ServerNodeStartup.main(ServerNodeStartup.java:43)
> [13:07:00] Ignite node stopped wih ERRORS [uptime=00:00:01.303]
> Exception in thread "main" class org.apache.ignite.IgniteException: null
> at
> org.apache.ignite.internal.util.IgniteUtils.convertException(IgniteUtils.java:1067)
> at org.apache.ignite.Ignition.start(Ignition.java:324)
> at ServerNodeStartup.main(ServerNodeStartup.java:43)
> Caused by: class org.apache.ignite.IgniteCheckedException: null
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1402)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2038)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1703)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1117)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:637)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:563)
> at org.apache.ignite.Ignition.start(Ignition.java:321)
> ... 1 more
> Caused by: java.lang.IllegalArgumentException
> at
> java.util.concurrent.ScheduledThreadPoolExecutor.scheduleWithFixedDelay(ScheduledThreadPoolExecutor.java:589)
> at
> org.apache.ignite.internal.processors.metric.PushMetricsExporterAdapter.spiStart(PushMetricsExporterAdapter.java:56)
> at
>
[jira] [Commented] (IGNITE-4380) Cache invoke calls can be lost
[
https://issues.apache.org/jira/browse/IGNITE-4380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17084967#comment-17084967
]
Nikolay Izhikov commented on IGNITE-4380:
-
The issue excluded from the 2.8.1 scope.
If some is interested to get fix for this issue in 2.8.1, please, write the
comment.
> Cache invoke calls can be lost
> --
>
> Key: IGNITE-4380
> URL: https://issues.apache.org/jira/browse/IGNITE-4380
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.0
>Reporter: Semen Boikov
>Priority: Critical
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.9
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> * Recently added test
> GridCacheAbstractFullApiSelfTest.testInvokeAllMultithreaded fails on TC in
> various configurations with transactional cache.
> Example of failure
> GridCacheReplicatedOffHeapTieredMultiNodeFullApiSelfTest.testInvokeAllMultithreaded:
> {noformat}
> junit.framework.AssertionFailedError: expected:<2> but was:<10868>
> at junit.framework.Assert.fail(Assert.java:57)
> at junit.framework.Assert.failNotEquals(Assert.java:329)
> at junit.framework.Assert.assertEquals(Assert.java:78)
> at junit.framework.Assert.assertEquals(Assert.java:234)
> at junit.framework.Assert.assertEquals(Assert.java:241)
> at junit.framework.TestCase.assertEquals(TestCase.java:409)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAbstractFullApiSelfTest.testInvokeAllMultithreaded(GridCacheAbstractFullApiSelfTest.java:342)
> at sun.reflect.GeneratedMethodAccessor96.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:1803)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:118)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$4.run(GridAbstractTest.java:1718)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-4380) Cache invoke calls can be lost
[
https://issues.apache.org/jira/browse/IGNITE-4380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov updated IGNITE-4380:
Fix Version/s: (was: 2.8.1)
> Cache invoke calls can be lost
> --
>
> Key: IGNITE-4380
> URL: https://issues.apache.org/jira/browse/IGNITE-4380
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.0
>Reporter: Semen Boikov
>Priority: Critical
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.9
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> * Recently added test
> GridCacheAbstractFullApiSelfTest.testInvokeAllMultithreaded fails on TC in
> various configurations with transactional cache.
> Example of failure
> GridCacheReplicatedOffHeapTieredMultiNodeFullApiSelfTest.testInvokeAllMultithreaded:
> {noformat}
> junit.framework.AssertionFailedError: expected:<2> but was:<10868>
> at junit.framework.Assert.fail(Assert.java:57)
> at junit.framework.Assert.failNotEquals(Assert.java:329)
> at junit.framework.Assert.assertEquals(Assert.java:78)
> at junit.framework.Assert.assertEquals(Assert.java:234)
> at junit.framework.Assert.assertEquals(Assert.java:241)
> at junit.framework.TestCase.assertEquals(TestCase.java:409)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAbstractFullApiSelfTest.testInvokeAllMultithreaded(GridCacheAbstractFullApiSelfTest.java:342)
> at sun.reflect.GeneratedMethodAccessor96.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:1803)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:118)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$4.run(GridAbstractTest.java:1718)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12772) JmxMetricExporterSpi uses log method which must not be used in production code
[
https://issues.apache.org/jira/browse/IGNITE-12772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17084962#comment-17084962
]
Nikolay Izhikov commented on IGNITE-12772:
--
Merged to master.
[~YAMolochkov] Thanks for the contribution.
> JmxMetricExporterSpi uses log method which must not be used in production code
> --
>
> Key: IGNITE-12772
> URL: https://issues.apache.org/jira/browse/IGNITE-12772
> Project: Ignite
> Issue Type: Bug
>Reporter: Andrey N. Gura
>Assignee: Yaroslav Molochkov
>Priority: Minor
> Labels: IEP-35
> Fix For: 2.8.1
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {{JmxMetricExporterSpi.register()}} method uses {{IgniteUtils.debug()}}
> method that log on {{INFO}} level instead of {{DEBUG}} because it needs only
> for debug purposes. Should be replaced by explicit {{log.debug()}} invocation.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-12888) Add support for ConstantName to checkstyle rules
[
https://issues.apache.org/jira/browse/IGNITE-12888?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17084960#comment-17084960
]
Pavel Pereslegin edited comment on IGNITE-12888 at 4/16/20, 3:07 PM:
-
[~mmuzaf],
I think this rule may violate the Ignite coding convention:
"_{color:#172b4d}Constants ({color}*final*{color:#172b4d} class attributes that
have *constant semantic* and *not just made final* *because* of inner class
access or *performance considerations*) should all be upper-case.{color}_"
I'm pretty sure that this checkstyle rule cannot take into account the
semantics of using each of the "static final" field. Right?
was (Author: xtern):
[~mmuzaf],
I think this rule may violate the Ignite coding convention:
"_{color:#172b4d}Constants ({color}*final*{color:#172b4d} class attributes that
have *constant semantic* and *not just made final* *because* of inner class
access or *performance considerations*) should all be upper-case.{color}_"
I'm pretty sure that this checkstyle rule cannot take into account the
semantics of using each "static final" field. Right?
> Add support for ConstantName to checkstyle rules
>
>
> Key: IGNITE-12888
> URL: https://issues.apache.org/jira/browse/IGNITE-12888
> Project: Ignite
> Issue Type: Task
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Major
> Fix For: 2.9
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Add a new rule to checkstyle according to Apache Ignite naming conventions.
>
> https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines#CodingGuidelines-Naming
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-12888) Add support for ConstantName to checkstyle rules
[
https://issues.apache.org/jira/browse/IGNITE-12888?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17084960#comment-17084960
]
Pavel Pereslegin edited comment on IGNITE-12888 at 4/16/20, 3:07 PM:
-
[~mmuzaf],
I think this rule may violate the Ignite coding convention:
"_{color:#172b4d}Constants ({color}*final*{color:#172b4d} class attributes that
have *constant semantic* and *not just made final* *because* of inner class
access or *performance considerations*) should all be upper-case.{color}_"
I'm pretty sure that this checkstyle rule cannot take into account the
semantics of using each "static final" field. Right?
was (Author: xtern):
[~mmuzaf],
I think this rule may violate the Ignite coding convention:
"_{color:#172b4d}Constants ({color}*final*{color:#172b4d} class attributes that
have *constant semantic* and *not just made final* *because* of inner class
access or *performance considerations*) should all be upper-case.{color}_"
I'm pretty sure that this rule cannot take into account the semantics of using
each "static final" field. Right?
> Add support for ConstantName to checkstyle rules
>
>
> Key: IGNITE-12888
> URL: https://issues.apache.org/jira/browse/IGNITE-12888
> Project: Ignite
> Issue Type: Task
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Major
> Fix For: 2.9
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Add a new rule to checkstyle according to Apache Ignite naming conventions.
>
> https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines#CodingGuidelines-Naming
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12888) Add support for ConstantName to checkstyle rules
[
https://issues.apache.org/jira/browse/IGNITE-12888?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17084960#comment-17084960
]
Pavel Pereslegin commented on IGNITE-12888:
---
[~mmuzaf],
I think this rule may violate the Ignite coding convention:
"_{color:#172b4d}Constants ({color}*final*{color:#172b4d} class attributes that
have *constant semantic* and *not just made final* *because* of inner class
access or *performance considerations*) should all be upper-case.{color}_"
I'm pretty sure that this rule cannot take into account the semantics of using
each "static final" field. Right?
> Add support for ConstantName to checkstyle rules
>
>
> Key: IGNITE-12888
> URL: https://issues.apache.org/jira/browse/IGNITE-12888
> Project: Ignite
> Issue Type: Task
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Major
> Fix For: 2.9
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Add a new rule to checkstyle according to Apache Ignite naming conventions.
>
> https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines#CodingGuidelines-Naming
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12905) QueryKeyValueIterable missing custom spliterator() implementation
[
https://issues.apache.org/jira/browse/IGNITE-12905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17084946#comment-17084946
]
Johnny Galatikitis commented on IGNITE-12905:
-
[~vozerov] Found the task that implemented QueryKeyValueIterable and
devozerov's username on jira. Could you help me with a review?
> QueryKeyValueIterable missing custom spliterator() implementation
> -
>
> Key: IGNITE-12905
> URL: https://issues.apache.org/jira/browse/IGNITE-12905
> Project: Ignite
> Issue Type: Bug
> Components: cache, general
>Affects Versions: 2.8
> Environment: Windows 10
> JDK 1.8.0_172
> ignite-core 2.8.0
> reactor-core 3.3.3
>Reporter: Johnny Galatikitis
>Priority: Critical
> Fix For: 2.8.1
>
> Attachments:
> IGNITE-12905_-_add_QueryKeyValueSpliterator_and_corresponding_test.patch
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We are using apache ignite with reactor-core and since reactors upgrade from
> 3.2.12 to 3.3.3 {code:java}
> org.apache.ignite.internal.processors.query.QueryKeyValueIterable
> {code}
> is called multiple times. It starts with:
> 1. calling iterable.spliterator().hasCharacteristics(Spliterator.SIZED),
> where iterable is instanceof QueryKeyValueIterable
> 2. calls default implementation
> Spliterators.spliteratorUnknownSize(iterator(), 0)
> 3. which in turn calls ignite's QueryKeyValueIterable.iterator() call and
> that "uses it up" for subsequent calls, i.e. throw IgniteException "Iterator
> is already fetched or query was cancelled."
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12827) OutOfMemory exception when calling grid service from .NET with user type array parameter
[
https://issues.apache.org/jira/browse/IGNITE-12827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17084945#comment-17084945
]
Ivan Daschinskiy commented on IGNITE-12827:
---
[~NSAmelchev] Thanks a lot!
> OutOfMemory exception when calling grid service from .NET with user type
> array parameter
>
>
> Key: IGNITE-12827
> URL: https://issues.apache.org/jira/browse/IGNITE-12827
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.8
>Reporter: Alexey Kukushkin
>Assignee: Ivan Daschinskiy
>Priority: Major
> Labels: sbcf
> Attachments: ignite-12827-vs-2.8.patch
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Calling a grid service from .NET with a parameter of user type array leads to
> Java OutOfMemory exception.
> +*Reproducer*+:
> * Limit JVM heap with 128 MB.
> * Create a .NET or Java service with a parameter of type
> *array of* Parameter {
> Id: int,
> *array of* ParameterValue {
> PeriodId: int,
> Value: double?
> }
> }
> * Call service with an array of 200 Parameters
> +*Expected*+:
> 128 MB of heap must be enough to call Java or .NET service with 200
> Parameters.
>
> +*Actual*+:
> Java OutOfMemory exception on 21st Parameter
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12905) QueryKeyValueIterable missing custom spliterator() implementation
[
https://issues.apache.org/jira/browse/IGNITE-12905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Johnny Galatikitis updated IGNITE-12905:
Priority: Critical (was: Major)
> QueryKeyValueIterable missing custom spliterator() implementation
> -
>
> Key: IGNITE-12905
> URL: https://issues.apache.org/jira/browse/IGNITE-12905
> Project: Ignite
> Issue Type: Bug
> Components: cache, general
>Affects Versions: 2.8
> Environment: Windows 10
> JDK 1.8.0_172
> ignite-core 2.8.0
> reactor-core 3.3.3
>Reporter: Johnny Galatikitis
>Priority: Critical
> Fix For: 2.8.1
>
> Attachments:
> IGNITE-12905_-_add_QueryKeyValueSpliterator_and_corresponding_test.patch
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We are using apache ignite with reactor-core and since reactors upgrade from
> 3.2.12 to 3.3.3 {code:java}
> org.apache.ignite.internal.processors.query.QueryKeyValueIterable
> {code}
> is called multiple times. It starts with:
> 1. calling iterable.spliterator().hasCharacteristics(Spliterator.SIZED),
> where iterable is instanceof QueryKeyValueIterable
> 2. calls default implementation
> Spliterators.spliteratorUnknownSize(iterator(), 0)
> 3. which in turn calls ignite's QueryKeyValueIterable.iterator() call and
> that "uses it up" for subsequent calls, i.e. throw IgniteException "Iterator
> is already fetched or query was cancelled."
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-10075) .NET: Avoid binary configurations of Ignite Java service params and result when calling it from Ignite.NET
[ https://issues.apache.org/jira/browse/IGNITE-10075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17084934#comment-17084934 ] Nikolai Kulagin commented on IGNITE-10075: -- [~kukushal], I checked this version. I created Java service with complex type and created complex type on .NET with an equal namespace. And this solution worked without a patch. If java package and .NET namespace were different, I got the error. > .NET: Avoid binary configurations of Ignite Java service params and result > when calling it from Ignite.NET > -- > > Key: IGNITE-10075 > URL: https://issues.apache.org/jira/browse/IGNITE-10075 > Project: Ignite > Issue Type: Improvement > Components: platforms >Affects Versions: 2.6 >Reporter: Alexey Kukushkin >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET, sbcf > Attachments: MyTest.cs, ignite-10075-vs-2.8.patch > > > Presently if there is an Ignite Java service taking parameters of complex > (composite) types and returning a result of complex type then all the complex > types must be explicitly specified in the binary configuration. > We need to enhance Ignite not to require binary configuration assuming that > we use the same type, package/namespace and field/property names on both the > .NET and Java sides (or provide a custom name mapper for relaxed naming > conventions). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-12905) QueryKeyValueIterable missing custom spliterator() implementation
[
https://issues.apache.org/jira/browse/IGNITE-12905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17084913#comment-17084913
]
Johnny Galatikitis edited comment on IGNITE-12905 at 4/16/20, 2:47 PM:
---
Added a test case that tests this exact scenario and should fail before
applying this PR/patch:
{code:java}org.apache.ignite.internal.IgniteClientReconnectContinuousProcessorTest#testCacheContinuousQuerySpliteratorMultipleCalls{code}
was (Author: bleedah):
Added a test case that tests this exact scenario and should fail before
applying this PR:
{code:java}org.apache.ignite.internal.IgniteClientReconnectContinuousProcessorTest#testCacheContinuousQuerySpliteratorMultipleCalls{code}
> QueryKeyValueIterable missing custom spliterator() implementation
> -
>
> Key: IGNITE-12905
> URL: https://issues.apache.org/jira/browse/IGNITE-12905
> Project: Ignite
> Issue Type: Bug
> Components: cache, general
>Affects Versions: 2.8
> Environment: Windows 10
> JDK 1.8.0_172
> ignite-core 2.8.0
> reactor-core 3.3.3
>Reporter: Johnny Galatikitis
>Priority: Major
> Fix For: 2.8.1
>
> Attachments:
> IGNITE-12905_-_add_QueryKeyValueSpliterator_and_corresponding_test.patch
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We are using apache ignite with reactor-core and since reactors upgrade from
> 3.2.12 to 3.3.3 {code:java}
> org.apache.ignite.internal.processors.query.QueryKeyValueIterable
> {code}
> is called multiple times. It starts with:
> 1. calling iterable.spliterator().hasCharacteristics(Spliterator.SIZED),
> where iterable is instanceof QueryKeyValueIterable
> 2. calls default implementation
> Spliterators.spliteratorUnknownSize(iterator(), 0)
> 3. which in turn calls ignite's QueryKeyValueIterable.iterator() call and
> that "uses it up" for subsequent calls, i.e. throw IgniteException "Iterator
> is already fetched or query was cancelled."
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-12905) QueryKeyValueIterable missing custom spliterator() implementation
[
https://issues.apache.org/jira/browse/IGNITE-12905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17084925#comment-17084925
]
Johnny Galatikitis edited comment on IGNITE-12905 at 4/16/20, 2:46 PM:
---
Not directly related, but - I tried to register at
https://reviews.ignite.apache.org/ but it returned 502 Bad Gateway.
The closest I could get to finding the right reviewer is git username devozerov.
was (Author: bleedah):
Not directly related, but - I tried to register at
https://reviews.ignite.apache.org/ but it returned 502 Bad Gateway.
> QueryKeyValueIterable missing custom spliterator() implementation
> -
>
> Key: IGNITE-12905
> URL: https://issues.apache.org/jira/browse/IGNITE-12905
> Project: Ignite
> Issue Type: Bug
> Components: cache, general
>Affects Versions: 2.8
> Environment: Windows 10
> JDK 1.8.0_172
> ignite-core 2.8.0
> reactor-core 3.3.3
>Reporter: Johnny Galatikitis
>Priority: Major
> Fix For: 2.8.1
>
> Attachments:
> IGNITE-12905_-_add_QueryKeyValueSpliterator_and_corresponding_test.patch
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We are using apache ignite with reactor-core and since reactors upgrade from
> 3.2.12 to 3.3.3 {code:java}
> org.apache.ignite.internal.processors.query.QueryKeyValueIterable
> {code}
> is called multiple times. It starts with:
> 1. calling iterable.spliterator().hasCharacteristics(Spliterator.SIZED),
> where iterable is instanceof QueryKeyValueIterable
> 2. calls default implementation
> Spliterators.spliteratorUnknownSize(iterator(), 0)
> 3. which in turn calls ignite's QueryKeyValueIterable.iterator() call and
> that "uses it up" for subsequent calls, i.e. throw IgniteException "Iterator
> is already fetched or query was cancelled."
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12827) OutOfMemory exception when calling grid service from .NET with user type array parameter
[
https://issues.apache.org/jira/browse/IGNITE-12827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17084930#comment-17084930
]
Amelchev Nikita commented on IGNITE-12827:
--
[~ivandasch], LGTM
> OutOfMemory exception when calling grid service from .NET with user type
> array parameter
>
>
> Key: IGNITE-12827
> URL: https://issues.apache.org/jira/browse/IGNITE-12827
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.8
>Reporter: Alexey Kukushkin
>Assignee: Ivan Daschinskiy
>Priority: Major
> Labels: sbcf
> Attachments: ignite-12827-vs-2.8.patch
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Calling a grid service from .NET with a parameter of user type array leads to
> Java OutOfMemory exception.
> +*Reproducer*+:
> * Limit JVM heap with 128 MB.
> * Create a .NET or Java service with a parameter of type
> *array of* Parameter {
> Id: int,
> *array of* ParameterValue {
> PeriodId: int,
> Value: double?
> }
> }
> * Call service with an array of 200 Parameters
> +*Expected*+:
> 128 MB of heap must be enough to call Java or .NET service with 200
> Parameters.
>
> +*Actual*+:
> Java OutOfMemory exception on 21st Parameter
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12905) QueryKeyValueIterable missing custom spliterator() implementation
[
https://issues.apache.org/jira/browse/IGNITE-12905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17084925#comment-17084925
]
Johnny Galatikitis commented on IGNITE-12905:
-
Not directly related, but - I tried to register at
https://reviews.ignite.apache.org/ but it returned 502 Bad Gateway.
> QueryKeyValueIterable missing custom spliterator() implementation
> -
>
> Key: IGNITE-12905
> URL: https://issues.apache.org/jira/browse/IGNITE-12905
> Project: Ignite
> Issue Type: Bug
> Components: cache, general
>Affects Versions: 2.8
> Environment: Windows 10
> JDK 1.8.0_172
> ignite-core 2.8.0
> reactor-core 3.3.3
>Reporter: Johnny Galatikitis
>Priority: Major
> Fix For: 2.8.1
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We are using apache ignite with reactor-core and since reactors upgrade from
> 3.2.12 to 3.3.3 {code:java}
> org.apache.ignite.internal.processors.query.QueryKeyValueIterable
> {code}
> is called multiple times. It starts with:
> 1. calling iterable.spliterator().hasCharacteristics(Spliterator.SIZED),
> where iterable is instanceof QueryKeyValueIterable
> 2. calls default implementation
> Spliterators.spliteratorUnknownSize(iterator(), 0)
> 3. which in turn calls ignite's QueryKeyValueIterable.iterator() call and
> that "uses it up" for subsequent calls, i.e. throw IgniteException "Iterator
> is already fetched or query was cancelled."
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-12905) QueryKeyValueIterable missing custom spliterator() implementation
[
https://issues.apache.org/jira/browse/IGNITE-12905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17084913#comment-17084913
]
Johnny Galatikitis edited comment on IGNITE-12905 at 4/16/20, 2:33 PM:
---
Added a test case that tests this exact scenario and should fail before
applying this PR:
{code:java}org.apache.ignite.internal.IgniteClientReconnectContinuousProcessorTest#testCacheContinuousQuerySpliteratorMultipleCalls{code}
was (Author: bleedah):
Added a test case that tests this exact scenario:
{code:java}org.apache.ignite.internal.IgniteClientReconnectContinuousProcessorTest#testCacheContinuousQuerySpliteratorMultipleCalls{code}
> QueryKeyValueIterable missing custom spliterator() implementation
> -
>
> Key: IGNITE-12905
> URL: https://issues.apache.org/jira/browse/IGNITE-12905
> Project: Ignite
> Issue Type: Bug
> Components: cache, general
>Affects Versions: 2.8
> Environment: Windows 10
> JDK 1.8.0_172
> ignite-core 2.8.0
> reactor-core 3.3.3
>Reporter: Johnny Galatikitis
>Priority: Major
> Fix For: 2.8.1
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We are using apache ignite with reactor-core and since reactors upgrade from
> 3.2.12 to 3.3.3 {code:java}
> org.apache.ignite.internal.processors.query.QueryKeyValueIterable
> {code}
> is called multiple times. It starts with:
> 1. calling iterable.spliterator().hasCharacteristics(Spliterator.SIZED),
> where iterable is instanceof QueryKeyValueIterable
> 2. calls default implementation
> Spliterators.spliteratorUnknownSize(iterator(), 0)
> 3. which in turn calls ignite's QueryKeyValueIterable.iterator() call and
> that "uses it up" for subsequent calls, i.e. throw IgniteException "Iterator
> is already fetched or query was cancelled."
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12905) QueryKeyValueIterable missing custom spliterator() implementation
[
https://issues.apache.org/jira/browse/IGNITE-12905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17084913#comment-17084913
]
Johnny Galatikitis commented on IGNITE-12905:
-
Added a test case that tests this exact scenario:
{code:java}org.apache.ignite.internal.IgniteClientReconnectContinuousProcessorTest#testCacheContinuousQuerySpliteratorMultipleCalls{code}
> QueryKeyValueIterable missing custom spliterator() implementation
> -
>
> Key: IGNITE-12905
> URL: https://issues.apache.org/jira/browse/IGNITE-12905
> Project: Ignite
> Issue Type: Bug
> Components: cache, general
>Affects Versions: 2.8
> Environment: Windows 10
> JDK 1.8.0_172
> ignite-core 2.8.0
> reactor-core 3.3.3
>Reporter: Johnny Galatikitis
>Priority: Major
> Fix For: 2.8.1
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We are using apache ignite with reactor-core and since reactors upgrade from
> 3.2.12 to 3.3.3 {code:java}
> org.apache.ignite.internal.processors.query.QueryKeyValueIterable
> {code}
> is called multiple times. It starts with:
> 1. calling iterable.spliterator().hasCharacteristics(Spliterator.SIZED),
> where iterable is instanceof QueryKeyValueIterable
> 2. calls default implementation
> Spliterators.spliteratorUnknownSize(iterator(), 0)
> 3. which in turn calls ignite's QueryKeyValueIterable.iterator() call and
> that "uses it up" for subsequent calls, i.e. throw IgniteException "Iterator
> is already fetched or query was cancelled."
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12905) QueryKeyValueIterable missing custom spliterator() implementation
[
https://issues.apache.org/jira/browse/IGNITE-12905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Johnny Galatikitis updated IGNITE-12905:
Description:
We are using apache ignite with reactor-core and since reactors upgrade from
3.2.12 to 3.3.3 {code:java}
org.apache.ignite.internal.processors.query.QueryKeyValueIterable
{code}
is called multiple times. It starts with:
1. calling iterable.spliterator().hasCharacteristics(Spliterator.SIZED), where
iterable is instanceof QueryKeyValueIterable
2. calls default implementation Spliterators.spliteratorUnknownSize(iterator(),
0)
3. which in turn calls ignite's QueryKeyValueIterable.iterator() call and that
"uses it up" for subsequent calls, i.e. throw IgniteException "Iterator is
already fetched or query was cancelled."
was:
We are using apache ignite with reactor-core and since reactors upgrade from
3.2.12 to 3.3.3 {code:java}
org.apache.ignite.internal.processors.cache.QueryCursorImpl.iterator
{code}
is called multiple times. It starts with:
1. calling iterable.spliterator().hasCharacteristics(Spliterator.SIZED), where
iterable is instanceof QueryKeyValueIterable
2. calls default implementation Spliterators.spliteratorUnknownSize(iterator(),
0)
3. which in turn calls ignite's QueryKeyValueIterable.iterator() call and that
"uses it up" for subsequent calls, i.e. throw IgniteException "Iterator is
already fetched or query was cancelled."
> QueryKeyValueIterable missing custom spliterator() implementation
> -
>
> Key: IGNITE-12905
> URL: https://issues.apache.org/jira/browse/IGNITE-12905
> Project: Ignite
> Issue Type: Bug
> Components: cache, general
>Affects Versions: 2.8
> Environment: Windows 10
> JDK 1.8.0_172
> ignite-core 2.8.0
> reactor-core 3.3.3
>Reporter: Johnny Galatikitis
>Priority: Major
> Fix For: 2.8.1
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We are using apache ignite with reactor-core and since reactors upgrade from
> 3.2.12 to 3.3.3 {code:java}
> org.apache.ignite.internal.processors.query.QueryKeyValueIterable
> {code}
> is called multiple times. It starts with:
> 1. calling iterable.spliterator().hasCharacteristics(Spliterator.SIZED),
> where iterable is instanceof QueryKeyValueIterable
> 2. calls default implementation
> Spliterators.spliteratorUnknownSize(iterator(), 0)
> 3. which in turn calls ignite's QueryKeyValueIterable.iterator() call and
> that "uses it up" for subsequent calls, i.e. throw IgniteException "Iterator
> is already fetched or query was cancelled."
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12905) QueryKeyValueIterable missing custom spliterator() implementation
[
https://issues.apache.org/jira/browse/IGNITE-12905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Johnny Galatikitis updated IGNITE-12905:
Description:
We are using apache ignite with reactor-core and since reactors upgrade from
3.2.12 to 3.3.3 {code:java}
org.apache.ignite.internal.processors.cache.QueryCursorImpl.iterator
{code}
is called multiple times. It starts with:
1. calling iterable.spliterator().hasCharacteristics(Spliterator.SIZED), where
iterable is instanceof QueryKeyValueIterable
2. calls default implementation Spliterators.spliteratorUnknownSize(iterator(),
0)
3. which in turn calls ignite's QueryKeyValueIterable.iterator() call and that
"uses it up" for subsequent calls, i.e. throw IgniteException "Iterator is
already fetched or query was cancelled."
was:
We are using apache ignite with reactor-core and since reactors upgrade from
3.2.12 to 3.3.3 {code:java}
org.apache.ignite.internal.processors.cache.QueryCursorImpl.iterator
{code}
is called multiple times. It starts with:
1. calling iterable.spliterator().hasCharacteristics(Spliterator.SIZED), where
iterable is instanceof QueryCursorImpl
2. calls default implementation Spliterators.spliteratorUnknownSize(iterator(),
0)
3. which in turn calls ignite's QueryCursorImpl.iterator() call and that "uses
it up" for subsequent calls, i.e. throw IgniteException "Iterator is already
fetched or query was cancelled."
> QueryKeyValueIterable missing custom spliterator() implementation
> -
>
> Key: IGNITE-12905
> URL: https://issues.apache.org/jira/browse/IGNITE-12905
> Project: Ignite
> Issue Type: Bug
> Components: cache, general
>Affects Versions: 2.8
> Environment: Windows 10
> JDK 1.8.0_172
> ignite-core 2.8.0
> reactor-core 3.3.3
>Reporter: Johnny Galatikitis
>Priority: Major
> Fix For: 2.8.1
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We are using apache ignite with reactor-core and since reactors upgrade from
> 3.2.12 to 3.3.3 {code:java}
> org.apache.ignite.internal.processors.cache.QueryCursorImpl.iterator
> {code}
> is called multiple times. It starts with:
> 1. calling iterable.spliterator().hasCharacteristics(Spliterator.SIZED),
> where iterable is instanceof QueryKeyValueIterable
> 2. calls default implementation
> Spliterators.spliteratorUnknownSize(iterator(), 0)
> 3. which in turn calls ignite's QueryKeyValueIterable.iterator() call and
> that "uses it up" for subsequent calls, i.e. throw IgniteException "Iterator
> is already fetched or query was cancelled."
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12905) QueryKeyValueIterable missing custom spliterator() implementation
[
https://issues.apache.org/jira/browse/IGNITE-12905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Johnny Galatikitis updated IGNITE-12905:
Summary: QueryKeyValueIterable missing custom spliterator() implementation
(was: QueryCursorImpl missing custom spliterator() implementation)
> QueryKeyValueIterable missing custom spliterator() implementation
> -
>
> Key: IGNITE-12905
> URL: https://issues.apache.org/jira/browse/IGNITE-12905
> Project: Ignite
> Issue Type: Bug
> Components: cache, general
>Affects Versions: 2.8
> Environment: Windows 10
> JDK 1.8.0_172
> ignite-core 2.8.0
> reactor-core 3.3.3
>Reporter: Johnny Galatikitis
>Priority: Major
> Fix For: 2.8.1
>
>
> We are using apache ignite with reactor-core and since reactors upgrade from
> 3.2.12 to 3.3.3 {code:java}
> org.apache.ignite.internal.processors.cache.QueryCursorImpl.iterator
> {code}
> is called multiple times. It starts with:
> 1. calling iterable.spliterator().hasCharacteristics(Spliterator.SIZED),
> where iterable is instanceof QueryCursorImpl
> 2. calls default implementation
> Spliterators.spliteratorUnknownSize(iterator(), 0)
> 3. which in turn calls ignite's QueryCursorImpl.iterator() call and that
> "uses it up" for subsequent calls, i.e. throw IgniteException "Iterator is
> already fetched or query was cancelled."
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (IGNITE-12890) JMX attribute 'getExecutorServiceFormatted' of IgniteMXBean returns getPublicThreadPoolSize() instead of formatted executor service
[
https://issues.apache.org/jira/browse/IGNITE-12890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maria Makedonskaya resolved IGNITE-12890.
-
Resolution: Won't Fix
> JMX attribute 'getExecutorServiceFormatted' of IgniteMXBean returns
> getPublicThreadPoolSize() instead of formatted executor service
> ---
>
> Key: IGNITE-12890
> URL: https://issues.apache.org/jira/browse/IGNITE-12890
> Project: Ignite
> Issue Type: Bug
>Reporter: Maria Makedonskaya
>Assignee: Maria Makedonskaya
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> while testing JmxWorker I found a possible bug in one of attributes of
> IgniteMXBean
> 1. start ignite node with IGNITE_JMX_PORT=1100
> 2. get ExecutorServiceFormatted attribute via JMX
> {noformat}
> /usr/lib/jvm/java-8-oracle/bin/java -cp
> ./ignite-test-tools-1.0.0-SNAPSHOT.jar org.apache.ignite.testtools.JmxWorker
> -host=127.0.0.1 -port=1100 -bean=IgniteKernal -group=Kernal
> -attribute=ExecutorServiceFormatted
> 8
> {noformat}
> a number does not looks like proper value for string representation of
> complex object, browsing the code reveals following:
> {noformat}
> @Override public String getExecutorServiceFormatted() {
> assert cfg != null;
> return String.valueOf(cfg.getPublicThreadPoolSize());
> }
> {noformat}
> We should deprecate 'getExecutorServiceFormatted' and create a new method
> 'getPublicThreadPoolSize'.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12891) Add userAttributes map to all GridClient messages
[ https://issues.apache.org/jira/browse/IGNITE-12891?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17084886#comment-17084886 ] Sergei Ryzhov commented on IGNITE-12891: LGTM > Add userAttributes map to all GridClient messages > - > > Key: IGNITE-12891 > URL: https://issues.apache.org/jira/browse/IGNITE-12891 > Project: Ignite > Issue Type: Bug >Reporter: Oleg Ostanin >Assignee: Oleg Ostanin >Priority: Major > Time Spent: 0.5h > Remaining Estimate: 0h > > Currently we are only sending userAttributes map in GridClient TOPOLOGY > message. In some particular circumstances it can lead to an authentication > failure. > Reproducer: > https://github.com/oleg-ostanin/ignite/blob/gridclient-fail-reproducer/modules/core/src/test/java/org/apache/ignite/internal/processors/security/client/AdditionalSecurityCheckGridClientTest.java -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12890) JMX attribute 'getExecutorServiceFormatted' of IgniteMXBean returns getPublicThreadPoolSize() instead of formatted executor service
[
https://issues.apache.org/jira/browse/IGNITE-12890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17084808#comment-17084808
]
Andrey N. Gura commented on IGNITE-12890:
-
[~makedonskaya] {{getExecutorServiceFormatted}} was already deprecated (see
{{org.apache.ignite.mxbean.IgniteMXBean#getExecutorServiceFormatted}}).
Method {{getPublicThreadPoolSize()}} doesn't make sense because:
* There are other thread pools in the system which don't have similar methods.
* There are metrics for thread pools that are better means for getting pools
information.
So I think this issue should be closed as won't fix.
> JMX attribute 'getExecutorServiceFormatted' of IgniteMXBean returns
> getPublicThreadPoolSize() instead of formatted executor service
> ---
>
> Key: IGNITE-12890
> URL: https://issues.apache.org/jira/browse/IGNITE-12890
> Project: Ignite
> Issue Type: Bug
>Reporter: Maria Makedonskaya
>Assignee: Maria Makedonskaya
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> while testing JmxWorker I found a possible bug in one of attributes of
> IgniteMXBean
> 1. start ignite node with IGNITE_JMX_PORT=1100
> 2. get ExecutorServiceFormatted attribute via JMX
> {noformat}
> /usr/lib/jvm/java-8-oracle/bin/java -cp
> ./ignite-test-tools-1.0.0-SNAPSHOT.jar org.apache.ignite.testtools.JmxWorker
> -host=127.0.0.1 -port=1100 -bean=IgniteKernal -group=Kernal
> -attribute=ExecutorServiceFormatted
> 8
> {noformat}
> a number does not looks like proper value for string representation of
> complex object, browsing the code reveals following:
> {noformat}
> @Override public String getExecutorServiceFormatted() {
> assert cfg != null;
> return String.valueOf(cfg.getPublicThreadPoolSize());
> }
> {noformat}
> We should deprecate 'getExecutorServiceFormatted' and create a new method
> 'getPublicThreadPoolSize'.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12879) Refactor test configuration of discovery messages interceptors.
[
https://issues.apache.org/jira/browse/IGNITE-12879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17084806#comment-17084806
]
Nikolay Izhikov commented on IGNITE-12879:
--
LGTM.
[~PetrovMikhail] Please, rerun TC prior merge.
> Refactor test configuration of discovery messages interceptors.
> ---
>
> Key: IGNITE-12879
> URL: https://issues.apache.org/jira/browse/IGNITE-12879
> Project: Ignite
> Issue Type: Improvement
>Reporter: Mikhail Petrov
>Assignee: Mikhail Petrov
>Priority: Minor
> Time Spent: 2h 50m
> Remaining Estimate: 0h
>
> It's needed to change DiscoveryHook class method naming to the following:
> {code:java}
> public void beforeDiscovery(DiscoverySpiCustomMessage msg)
> public void afterDiscovery(DiscoverySpiCustomMessage msg)
> {code}
> It will help to clarify the purpose of the methods.
> It's needed to add the ability to configure multiple DiscoveryHook instances
> through TestTcpDiscoverySpi for discovery messages interception. It helps to
> avoid redefinition of the TestTcpDiscoverySpi and its reconfiguration. The
> current approach is as follows:
> {code:java}
> TcpDiscoverySpi spi = new TestTcpDiscoverySpi() {
> @Override public void setListener(@Nullable DiscoverySpiListener lsnr) {
> super.setListener(DiscoverySpiListenerWrapper.wrap(lsnr,
> discoveryHook));
> }
> };
> spi.setIpFinder(((TcpDiscoverySpi)cfg.getDiscoverySpi()).getIpFinder());
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12903) Fix ML + SQL examples
[
https://issues.apache.org/jira/browse/IGNITE-12903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17084782#comment-17084782
]
Alexey Zinoviev commented on IGNITE-12903:
--
[~tledkov-gridgain] Are you going to fix it by yourself? It will be great! I
could review the PR if it will be prepared
> Fix ML + SQL examples
> -
>
> Key: IGNITE-12903
> URL: https://issues.apache.org/jira/browse/IGNITE-12903
> Project: Ignite
> Issue Type: Task
> Components: examples
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Major
>
> The examples
> {{DecisionTreeClassificationTrainerSQLInferenceExample}}
> {{DecisionTreeClassificationTrainerSQLTableExample}}
> are used CSVREAD function to initial load data into cluster.
> Must be changed because this function is disabled by default
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12906) Add to IgniteWalConverter possibility output only hashes instead real data
[ https://issues.apache.org/jira/browse/IGNITE-12906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Tkalenko updated IGNITE-12906: - Fix Version/s: 2.9 > Add to IgniteWalConverter possibility output only hashes instead real data > -- > > Key: IGNITE-12906 > URL: https://issues.apache.org/jira/browse/IGNITE-12906 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Tkalenko >Assignee: Kirill Tkalenko >Priority: Major > Fix For: 2.9 > > > Add flag to be able to hide sensitive data in WAL reader output. For example, > we can use cryptographic hash to hide data and see some representation of it > to know is it unique or not, with high probability. > If define binaryMetadata then output field name and hash field value, else > output hash of source binary value > This change is required for user security reasons -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12906) Add to IgniteWalConverter possibility output only hashes instead real data
Kirill Tkalenko created IGNITE-12906: Summary: Add to IgniteWalConverter possibility output only hashes instead real data Key: IGNITE-12906 URL: https://issues.apache.org/jira/browse/IGNITE-12906 Project: Ignite Issue Type: Improvement Reporter: Kirill Tkalenko Assignee: Kirill Tkalenko Add flag to be able to hide sensitive data in WAL reader output. For example, we can use cryptographic hash to hide data and see some representation of it to know is it unique or not, with high probability. If define binaryMetadata then output field name and hash field value, else output hash of source binary value This change is required for user security reasons -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12902) Concurrent modification in time to iterate by events
[
https://issues.apache.org/jira/browse/IGNITE-12902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17084761#comment-17084761
]
Ignite TC Bot commented on IGNITE-12902:
{panel:title=Branch: [pull/7675/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5226838buildTypeId=IgniteTests24Java8_RunAll]
> Concurrent modification in time to iterate by events
>
>
> Key: IGNITE-12902
> URL: https://issues.apache.org/jira/browse/IGNITE-12902
> Project: Ignite
> Issue Type: Improvement
>Reporter: Kirill Tkalenko
>Assignee: Kirill Tkalenko
>Priority: Major
> Fix For: 2.9
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {code:java}
> [10:20:37]W: [org.apache.ignite:ignite-core] [2020-02-20
> 10:20:37,324][ERROR][main][CacheExchangeMergeTest9] Failed to pre-stop
> processor: GridProcessorAdapter []
> [10:20:37]W: [org.apache.ignite:ignite-core]
> java.util.ConcurrentModificationException
> [10:20:37]W: [org.apache.ignite:ignite-core] at
> java.util.ArrayList$Itr.checkForComodification(ArrayList.java:909)
> [10:20:37]W: [org.apache.ignite:ignite-core] at
> java.util.ArrayList$Itr.next(ArrayList.java:859)
> [10:20:37]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onDone(GridDhtPartitionsExchangeFuture.java:2302)
> [10:20:37]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onDone(GridDhtPartitionsExchangeFuture.java:142)
> [10:20:37]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:464)
> [10:20:37]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.onKernalStop0(GridCachePartitionExchangeManager.java:821)
> [10:20:37]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.processors.cache.GridCacheSharedManagerAdapter.onKernalStop(GridCacheSharedManagerAdapter.java:120)
> [10:20:37]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.onKernalStop(GridCacheProcessor.java:972){code}
> In that place we are going over event’s collection, looking for server
> leave’s event:
> {code:java}
> for (DiscoveryEvent evt : evts.events()) {
> if (serverLeftEvent(evt)) {
> for (CacheGroupContext grp : cctx.cache().cacheGroups())
> grp.affinityFunction().removeNode(evt.eventNode().id());
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12853) ThinClient: Introduce Features for thin clients
[ https://issues.apache.org/jira/browse/IGNITE-12853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17084754#comment-17084754 ] Pavel Tupitsyn commented on IGNITE-12853: - [~isapego] I've checked .NET part. Thanks for cleaning up `ClientProtocolVersion` usages. However, there is one more case in `QueryField` - can we get rid of that too as part of this ticket? Let me know if I should help with that. > ThinClient: Introduce Features for thin clients > --- > > Key: IGNITE-12853 > URL: https://issues.apache.org/jira/browse/IGNITE-12853 > Project: Ignite > Issue Type: Bug > Components: thin client >Reporter: Igor Sapego >Assignee: Igor Sapego >Priority: Major > Fix For: 2.8.1 > > Time Spent: 1h 40m > Remaining Estimate: 0h > > As we have a lot of different thin clients now, maintained by different > people, the issues with our backward compatibility mechanism becomes more and > more prominent. > Currently, we use protocol versioning as the only approach to provide > backward compatibility. The main issue of this approach is that we can not > skip some change in protocol and implement i.e. protocol of version 1.5 > without implementation of 1.4. There are many cases when one may want to do > so: e.g. when feature provided in 1.4 is not relevant for a specific client, > or when protocol version 1.5 contains urgent fix or feature which is easy to > implement, but its blocked by not-so-urgent and hard-to-implement feature > introduced in 1.4. > So to fix this issue I propose to introduce another backward compatibility > mechanism. The idea is to send "supported features" mask by a client to a > server, which should be answered with the same mask by the server. The > resulting set of enabled features is acquired with a simple logical "AND" > operation on these two masks. > This change has many other positive effects: > 1. It improves readability and also potentially simplifies debugging. > 2. It gives users the ability to enable or disable features of thin clients > on both server and client as they desire. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12759) Getting a SecurityContext from GridSecurityProcessor
[ https://issues.apache.org/jira/browse/IGNITE-12759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17084735#comment-17084735 ] Anton Vinogradov commented on IGNITE-12759: --- [~ivan.glukos] During the internal review at "Ignite SE" we reduced the number of PR changes. So, I asked Denis to provide the internal review results as an updated PR. Good point is that we checked this PR with our real custom security processor and found no issues. Could you please check that fix looks good to you? Diff is small now and it should not take a lot of time to check :) > Getting a SecurityContext from GridSecurityProcessor > > > Key: IGNITE-12759 > URL: https://issues.apache.org/jira/browse/IGNITE-12759 > Project: Ignite > Issue Type: Improvement > Components: security >Reporter: Denis Garus >Assignee: Denis Garus >Priority: Major > Labels: iep-41 > Time Spent: 2h > Remaining Estimate: 0h > > Extend the _GridSecurityProcessor_ interface by adding _securityContext(UUID > subjId)_ method and use this method to get the actual security context. > h4. Backward compatibility > The logic of getting security context for Ignite: > # Try to get a security context using _ClusterNode_ attributes (as it works > now); > # Get a security context through _GridSecurityProcessor_. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12905) QueryCursorImpl missing custom spliterator() implementation
[
https://issues.apache.org/jira/browse/IGNITE-12905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Johnny Galatikitis updated IGNITE-12905:
Ignite Flags: (was: Docs Required,Release Notes Required)
> QueryCursorImpl missing custom spliterator() implementation
> ---
>
> Key: IGNITE-12905
> URL: https://issues.apache.org/jira/browse/IGNITE-12905
> Project: Ignite
> Issue Type: Bug
> Components: cache, general
>Affects Versions: 2.8
> Environment: Windows 10
> JDK 1.8.0_172
> ignite-core 2.8.0
> reactor-core 3.3.3
>Reporter: Johnny Galatikitis
>Priority: Major
> Fix For: 2.8.1
>
>
> We are using apache ignite with reactor-core and since reactors upgrade from
> 3.2.12 to 3.3.3 {code:java}
> org.apache.ignite.internal.processors.cache.QueryCursorImpl.iterator
> {code}
> is called multiple times. It starts with:
> 1. calling iterable.spliterator().hasCharacteristics(Spliterator.SIZED),
> where iterable is instanceof QueryCursorImpl
> 2. calls default implementation
> Spliterators.spliteratorUnknownSize(iterator(), 0)
> 3. which in turn calls ignite's QueryCursorImpl.iterator() call and that
> "uses it up" for subsequent calls, i.e. throw IgniteException "Iterator is
> already fetched or query was cancelled."
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
