[jira] [Updated] (IGNITE-9202) .NET `TestRemoteNodes` fails with "Failed to map SQL query to topology"
[
https://issues.apache.org/jira/browse/IGNITE-9202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated IGNITE-9202:
Labels: MakeTeamcityGreenAgain (was: )
> .NET `TestRemoteNodes` fails with "Failed to map SQL query to topology"
> ---
>
> Key: IGNITE-9202
> URL: https://issues.apache.org/jira/browse/IGNITE-9202
> Project: Ignite
> Issue Type: Test
>Reporter: Maxim Muzafarov
>Priority: Minor
> Labels: MakeTeamcityGreenAgain
>
> Tests constantly fails with exception `Failed to map SQL query to topology.`
> * ExamplesTest.TestRemoteNodes(BinaryModeExample)
> * ExamplesTest.TestRemoteNodes(LinqExample)
> * ExamplesTest.TestRemoteNodes(SqlExample)
> {code:java}
> Test(s) failed. Apache.Ignite.Core.Cache.CacheException : Failed to map SQL
> query to topology. > Apache.Ignite.Core.Common.JavaException :
> javax.cache.CacheException: Failed to map SQL query to topology.
> at
> org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.query(GridReduceQueryExecutor.java:577)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing$8.iterator(IgniteH2Indexing.java:1447)
> at
> org.apache.ignite.internal.processors.cache.QueryCursorImpl.iterator(QueryCursorImpl.java:95)
> at
> org.apache.ignite.internal.processors.platform.cache.query.PlatformAbstractQueryCursor.processInLongOutLong(PlatformAbstractQueryCursor.java:147)
> at
> org.apache.ignite.internal.processors.platform.PlatformTargetProxyImpl.inLongOutLong(PlatformTargetProxyImpl.java:55)
> {code}
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=-3155722801840665529&branch=%3Cdefault%3E&tab=testDetails
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9202) .NET `TestRemoteNodes` fails with "Failed to map SQL query to topology"
[
https://issues.apache.org/jira/browse/IGNITE-9202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated IGNITE-9202:
Component/s: (was: sql)
> .NET `TestRemoteNodes` fails with "Failed to map SQL query to topology"
> ---
>
> Key: IGNITE-9202
> URL: https://issues.apache.org/jira/browse/IGNITE-9202
> Project: Ignite
> Issue Type: Test
>Reporter: Maxim Muzafarov
>Priority: Minor
>
> Tests constantly fails with exception `Failed to map SQL query to topology.`
> * ExamplesTest.TestRemoteNodes(BinaryModeExample)
> * ExamplesTest.TestRemoteNodes(LinqExample)
> * ExamplesTest.TestRemoteNodes(SqlExample)
> {code:java}
> Test(s) failed. Apache.Ignite.Core.Cache.CacheException : Failed to map SQL
> query to topology. > Apache.Ignite.Core.Common.JavaException :
> javax.cache.CacheException: Failed to map SQL query to topology.
> at
> org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.query(GridReduceQueryExecutor.java:577)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing$8.iterator(IgniteH2Indexing.java:1447)
> at
> org.apache.ignite.internal.processors.cache.QueryCursorImpl.iterator(QueryCursorImpl.java:95)
> at
> org.apache.ignite.internal.processors.platform.cache.query.PlatformAbstractQueryCursor.processInLongOutLong(PlatformAbstractQueryCursor.java:147)
> at
> org.apache.ignite.internal.processors.platform.PlatformTargetProxyImpl.inLongOutLong(PlatformTargetProxyImpl.java:55)
> {code}
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=-3155722801840665529&branch=%3Cdefault%3E&tab=testDetails
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9202) .NET `TestRemoteNodes` fails with "Failed to map SQL query to topology"
[
https://issues.apache.org/jira/browse/IGNITE-9202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated IGNITE-9202:
Labels: (was: sql)
> .NET `TestRemoteNodes` fails with "Failed to map SQL query to topology"
> ---
>
> Key: IGNITE-9202
> URL: https://issues.apache.org/jira/browse/IGNITE-9202
> Project: Ignite
> Issue Type: Test
>Reporter: Maxim Muzafarov
>Priority: Minor
>
> Tests constantly fails with exception `Failed to map SQL query to topology.`
> * ExamplesTest.TestRemoteNodes(BinaryModeExample)
> * ExamplesTest.TestRemoteNodes(LinqExample)
> * ExamplesTest.TestRemoteNodes(SqlExample)
> {code:java}
> Test(s) failed. Apache.Ignite.Core.Cache.CacheException : Failed to map SQL
> query to topology. > Apache.Ignite.Core.Common.JavaException :
> javax.cache.CacheException: Failed to map SQL query to topology.
> at
> org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.query(GridReduceQueryExecutor.java:577)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing$8.iterator(IgniteH2Indexing.java:1447)
> at
> org.apache.ignite.internal.processors.cache.QueryCursorImpl.iterator(QueryCursorImpl.java:95)
> at
> org.apache.ignite.internal.processors.platform.cache.query.PlatformAbstractQueryCursor.processInLongOutLong(PlatformAbstractQueryCursor.java:147)
> at
> org.apache.ignite.internal.processors.platform.PlatformTargetProxyImpl.inLongOutLong(PlatformTargetProxyImpl.java:55)
> {code}
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=-3155722801840665529&branch=%3Cdefault%3E&tab=testDetails
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9202) .NET `TestRemoteNodes` fails with "Failed to map SQL query to topology"
[
https://issues.apache.org/jira/browse/IGNITE-9202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated IGNITE-9202:
Description:
Tests constantly fails with exception `Failed to map SQL query to topology.`
* ExamplesTest.TestRemoteNodes(BinaryModeExample)
* ExamplesTest.TestRemoteNodes(LinqExample)
* ExamplesTest.TestRemoteNodes(SqlExample)
{code:java}
Test(s) failed. Apache.Ignite.Core.Cache.CacheException : Failed to map SQL
query to topology. > Apache.Ignite.Core.Common.JavaException :
javax.cache.CacheException: Failed to map SQL query to topology.
at
org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.query(GridReduceQueryExecutor.java:577)
at
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing$8.iterator(IgniteH2Indexing.java:1447)
at
org.apache.ignite.internal.processors.cache.QueryCursorImpl.iterator(QueryCursorImpl.java:95)
at
org.apache.ignite.internal.processors.platform.cache.query.PlatformAbstractQueryCursor.processInLongOutLong(PlatformAbstractQueryCursor.java:147)
at
org.apache.ignite.internal.processors.platform.PlatformTargetProxyImpl.inLongOutLong(PlatformTargetProxyImpl.java:55)
{code}
https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=-3155722801840665529&branch=%3Cdefault%3E&tab=testDetails
was:
Tests constantly fails with exception `Failed to map SQL query to topology.`
* ExamplesTest.TestRemoteNodes(BinaryModeExample)
* ExamplesTest.TestRemoteNodes(LinqExample)
* ExamplesTest.TestRemoteNodes(SqlExample)
{code:java}
Test(s) failed. Apache.Ignite.Core.Cache.CacheException : Failed to map SQL
query to topology. > Apache.Ignite.Core.Common.JavaException :
javax.cache.CacheException: Failed to map SQL query to topology.
at
org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.query(GridReduceQueryExecutor.java:577)
at
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing$8.iterator(IgniteH2Indexing.java:1447)
at
org.apache.ignite.internal.processors.cache.QueryCursorImpl.iterator(QueryCursorImpl.java:95)
at
org.apache.ignite.internal.processors.platform.cache.query.PlatformAbstractQueryCursor.processInLongOutLong(PlatformAbstractQueryCursor.java:147)
at
org.apache.ignite.internal.processors.platform.PlatformTargetProxyImpl.inLongOutLong(PlatformTargetProxyImpl.java:55)
{code}
> .NET `TestRemoteNodes` fails with "Failed to map SQL query to topology"
> ---
>
> Key: IGNITE-9202
> URL: https://issues.apache.org/jira/browse/IGNITE-9202
> Project: Ignite
> Issue Type: Test
> Components: sql
>Reporter: Maxim Muzafarov
>Priority: Minor
> Labels: sql
>
> Tests constantly fails with exception `Failed to map SQL query to topology.`
> * ExamplesTest.TestRemoteNodes(BinaryModeExample)
> * ExamplesTest.TestRemoteNodes(LinqExample)
> * ExamplesTest.TestRemoteNodes(SqlExample)
> {code:java}
> Test(s) failed. Apache.Ignite.Core.Cache.CacheException : Failed to map SQL
> query to topology. > Apache.Ignite.Core.Common.JavaException :
> javax.cache.CacheException: Failed to map SQL query to topology.
> at
> org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.query(GridReduceQueryExecutor.java:577)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing$8.iterator(IgniteH2Indexing.java:1447)
> at
> org.apache.ignite.internal.processors.cache.QueryCursorImpl.iterator(QueryCursorImpl.java:95)
> at
> org.apache.ignite.internal.processors.platform.cache.query.PlatformAbstractQueryCursor.processInLongOutLong(PlatformAbstractQueryCursor.java:147)
> at
> org.apache.ignite.internal.processors.platform.PlatformTargetProxyImpl.inLongOutLong(PlatformTargetProxyImpl.java:55)
> {code}
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=-3155722801840665529&branch=%3Cdefault%3E&tab=testDetails
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9114) Fail fast in org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor#query
[
https://issues.apache.org/jira/browse/IGNITE-9114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16571143#comment-16571143
]
Maxim Muzafarov commented on IGNITE-9114:
-
Hello [~vozerov],
.NET examples began to fall due to these changes.
I've created issue for investigating it --
[IGNITE-9202|https://issues.apache.org/jira/browse/IGNITE-9202]
{code:java|title=GridReduceQueryExecutor.java\:577}
throw new CacheException("Failed to map SQL query to topology.");
{code}
> Fail fast in
> org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor#query
> -
>
> Key: IGNITE-9114
> URL: https://issues.apache.org/jira/browse/IGNITE-9114
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.5
>Reporter: Andrew Medvedev
>Assignee: Vladimir Ozerov
>Priority: Major
> Fix For: 2.7
>
>
> org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor#query
> has infinite loop with exit condition on success, thus failure to make
> reservation on partition can "hang" query. Exception should be thrown and
> method should return if cycle does not succeed in reasonable time.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-9202) .NET `TestRemoteNodes` fails with "Failed to map SQL query to topology"
Maxim Muzafarov created IGNITE-9202:
---
Summary: .NET `TestRemoteNodes` fails with "Failed to map SQL
query to topology"
Key: IGNITE-9202
URL: https://issues.apache.org/jira/browse/IGNITE-9202
Project: Ignite
Issue Type: Test
Components: sql
Reporter: Maxim Muzafarov
Tests constantly fails with exception `Failed to map SQL query to topology.`
* ExamplesTest.TestRemoteNodes(BinaryModeExample)
* ExamplesTest.TestRemoteNodes(LinqExample)
* ExamplesTest.TestRemoteNodes(SqlExample)
{code:java}
Test(s) failed. Apache.Ignite.Core.Cache.CacheException : Failed to map SQL
query to topology. > Apache.Ignite.Core.Common.JavaException :
javax.cache.CacheException: Failed to map SQL query to topology.
at
org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.query(GridReduceQueryExecutor.java:577)
at
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing$8.iterator(IgniteH2Indexing.java:1447)
at
org.apache.ignite.internal.processors.cache.QueryCursorImpl.iterator(QueryCursorImpl.java:95)
at
org.apache.ignite.internal.processors.platform.cache.query.PlatformAbstractQueryCursor.processInLongOutLong(PlatformAbstractQueryCursor.java:147)
at
org.apache.ignite.internal.processors.platform.PlatformTargetProxyImpl.inLongOutLong(PlatformTargetProxyImpl.java:55)
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9191) Web Console: Cluster saved with empty name in special case
[ https://issues.apache.org/jira/browse/IGNITE-9191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov updated IGNITE-9191: - Labels: web-console-configuration (was: ) > Web Console: Cluster saved with empty name in special case > -- > > Key: IGNITE-9191 > URL: https://issues.apache.org/jira/browse/IGNITE-9191 > Project: Ignite > Issue Type: Task > Components: wizards >Reporter: Alexey Kuznetsov >Assignee: Pavel Konstantinov >Priority: Major > Labels: web-console-configuration > Fix For: 2.7 > > Time Spent: 3.5h > Remaining Estimate: 0h > > # Create a new cluster, DON'T save > # Open Advanced screen > # Go to caches. > # Create cache. > # Save cache. > # Clsuter saved with EMPTY name (bug). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-9191) Web Console: Cluster saved with empty name in special case
[ https://issues.apache.org/jira/browse/IGNITE-9191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov reassigned IGNITE-9191: Resolution: Fixed Assignee: Pavel Konstantinov (was: Alexey Kuznetsov) Merged to master. > Web Console: Cluster saved with empty name in special case > -- > > Key: IGNITE-9191 > URL: https://issues.apache.org/jira/browse/IGNITE-9191 > Project: Ignite > Issue Type: Task > Components: wizards >Reporter: Alexey Kuznetsov >Assignee: Pavel Konstantinov >Priority: Major > Fix For: 2.7 > > Time Spent: 3.5h > Remaining Estimate: 0h > > # Create a new cluster, DON'T save > # Open Advanced screen > # Go to caches. > # Create cache. > # Save cache. > # Clsuter saved with EMPTY name (bug). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-9028) Web console: update to Babel 7
[ https://issues.apache.org/jira/browse/IGNITE-9028?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Borisov reassigned IGNITE-9028: Assignee: Andrey Novikov (was: Ilya Borisov) > Web console: update to Babel 7 > -- > > Key: IGNITE-9028 > URL: https://issues.apache.org/jira/browse/IGNITE-9028 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Ilya Borisov >Assignee: Andrey Novikov >Priority: Major > > While Babel 7 is still in beta, I think it might be a good idea to update a > beta version of major dependency once in a while. It will be released soon > enough, so even if any issues occur we'll most like be able to iron those > out. As a benefit, Babel 7 will also provide an easy TypeScript migration > path. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9028) Web console: update to Babel 7
[ https://issues.apache.org/jira/browse/IGNITE-9028?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16571088#comment-16571088 ] Ilya Borisov commented on IGNITE-9028: -- [~anovikov] you were right, because there were backticks in browserUpdate.js it broke in older browsers. I've fixed that and IE11 shows browser update message again. > Web console: update to Babel 7 > -- > > Key: IGNITE-9028 > URL: https://issues.apache.org/jira/browse/IGNITE-9028 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Ilya Borisov >Assignee: Ilya Borisov >Priority: Major > > While Babel 7 is still in beta, I think it might be a good idea to update a > beta version of major dependency once in a while. It will be released soon > enough, so even if any issues occur we'll most like be able to iron those > out. As a benefit, Babel 7 will also provide an easy TypeScript migration > path. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-9191) Web Console: Cluster saved with empty name in special case
[ https://issues.apache.org/jira/browse/IGNITE-9191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16571062#comment-16571062 ] Pavel Konstantinov edited comment on IGNITE-9191 at 8/7/18 3:18 AM: The reason is some errors after the configuration migration. On a clean DB it is not reproduced. was (Author: pkonstantinov): The reason is some errors after configuration migration. On a clear DB it is not reproduced. > Web Console: Cluster saved with empty name in special case > -- > > Key: IGNITE-9191 > URL: https://issues.apache.org/jira/browse/IGNITE-9191 > Project: Ignite > Issue Type: Task > Components: wizards >Reporter: Alexey Kuznetsov >Assignee: Alexey Kuznetsov >Priority: Major > Fix For: 2.7 > > Time Spent: 3h > Remaining Estimate: 0h > > # Create a new cluster, DON'T save > # Open Advanced screen > # Go to caches. > # Create cache. > # Save cache. > # Clsuter saved with EMPTY name (bug). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9191) Web Console: Cluster saved with empty name in special case
[ https://issues.apache.org/jira/browse/IGNITE-9191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16571078#comment-16571078 ] Pavel Konstantinov commented on IGNITE-9191: Successfully tested on the branch on a clear DB. > Web Console: Cluster saved with empty name in special case > -- > > Key: IGNITE-9191 > URL: https://issues.apache.org/jira/browse/IGNITE-9191 > Project: Ignite > Issue Type: Task > Components: wizards >Reporter: Alexey Kuznetsov >Assignee: Alexey Kuznetsov >Priority: Major > Fix For: 2.7 > > Time Spent: 3h > Remaining Estimate: 0h > > # Create a new cluster, DON'T save > # Open Advanced screen > # Go to caches. > # Create cache. > # Save cache. > # Clsuter saved with EMPTY name (bug). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-9191) Web Console: Cluster saved with empty name in special case
[ https://issues.apache.org/jira/browse/IGNITE-9191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16571078#comment-16571078 ] Pavel Konstantinov edited comment on IGNITE-9191 at 8/7/18 3:17 AM: Successfully tested on the branch on a clean DB. was (Author: pkonstantinov): Successfully tested on the branch on a clear DB. > Web Console: Cluster saved with empty name in special case > -- > > Key: IGNITE-9191 > URL: https://issues.apache.org/jira/browse/IGNITE-9191 > Project: Ignite > Issue Type: Task > Components: wizards >Reporter: Alexey Kuznetsov >Assignee: Alexey Kuznetsov >Priority: Major > Fix For: 2.7 > > Time Spent: 3h > Remaining Estimate: 0h > > # Create a new cluster, DON'T save > # Open Advanced screen > # Go to caches. > # Create cache. > # Save cache. > # Clsuter saved with EMPTY name (bug). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-9191) Web Console: Cluster saved with empty name in special case
[ https://issues.apache.org/jira/browse/IGNITE-9191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16571062#comment-16571062 ] Pavel Konstantinov edited comment on IGNITE-9191 at 8/7/18 2:57 AM: The reason is some errors after configuration migration. On a clear DB it is not reproduced. was (Author: pkonstantinov): The reason is some errors after configuration migration. On a clear DB is not reproduced. > Web Console: Cluster saved with empty name in special case > -- > > Key: IGNITE-9191 > URL: https://issues.apache.org/jira/browse/IGNITE-9191 > Project: Ignite > Issue Type: Task > Components: wizards >Reporter: Alexey Kuznetsov >Assignee: Alexey Kuznetsov >Priority: Major > Fix For: 2.7 > > Time Spent: 3h > Remaining Estimate: 0h > > # Create a new cluster, DON'T save > # Open Advanced screen > # Go to caches. > # Create cache. > # Save cache. > # Clsuter saved with EMPTY name (bug). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9191) Web Console: Cluster saved with empty name in special case
[ https://issues.apache.org/jira/browse/IGNITE-9191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16571062#comment-16571062 ] Pavel Konstantinov commented on IGNITE-9191: The reason is some errors after configuration migration. On a clear DB is not reproduced. > Web Console: Cluster saved with empty name in special case > -- > > Key: IGNITE-9191 > URL: https://issues.apache.org/jira/browse/IGNITE-9191 > Project: Ignite > Issue Type: Task > Components: wizards >Reporter: Alexey Kuznetsov >Assignee: Ilya Borisov >Priority: Major > Fix For: 2.7 > > Time Spent: 3h > Remaining Estimate: 0h > > # Create a new cluster, DON'T save > # Open Advanced screen > # Go to caches. > # Create cache. > # Save cache. > # Clsuter saved with EMPTY name (bug). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-9191) Web Console: Cluster saved with empty name in special case
[ https://issues.apache.org/jira/browse/IGNITE-9191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Konstantinov reassigned IGNITE-9191: -- Assignee: Alexey Kuznetsov (was: Ilya Borisov) > Web Console: Cluster saved with empty name in special case > -- > > Key: IGNITE-9191 > URL: https://issues.apache.org/jira/browse/IGNITE-9191 > Project: Ignite > Issue Type: Task > Components: wizards >Reporter: Alexey Kuznetsov >Assignee: Alexey Kuznetsov >Priority: Major > Fix For: 2.7 > > Time Spent: 3h > Remaining Estimate: 0h > > # Create a new cluster, DON'T save > # Open Advanced screen > # Go to caches. > # Create cache. > # Save cache. > # Clsuter saved with EMPTY name (bug). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9028) Web console: update to Babel 7
[ https://issues.apache.org/jira/browse/IGNITE-9028?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16571058#comment-16571058 ] Ilya Borisov commented on IGNITE-9028: -- [~anovikov] I'll check that IE11 shows browser-update message. > Web console: update to Babel 7 > -- > > Key: IGNITE-9028 > URL: https://issues.apache.org/jira/browse/IGNITE-9028 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Ilya Borisov >Assignee: Ilya Borisov >Priority: Major > > While Babel 7 is still in beta, I think it might be a good idea to update a > beta version of major dependency once in a while. It will be released soon > enough, so even if any issues occur we'll most like be able to iron those > out. As a benefit, Babel 7 will also provide an easy TypeScript migration > path. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-9191) Web Console: Cluster saved with empty name in special case
[ https://issues.apache.org/jira/browse/IGNITE-9191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16571021#comment-16571021 ] Ilya Borisov edited comment on IGNITE-9191 at 8/7/18 2:01 AM: -- [~pkonstantinov] I need more info about your environment. Did you have any cluster configs prior to test? Maybe you removed some? When you got the name clash error, was there a cluster with such a name or it matched the name of cluster you've already removed? The issue you experienced might be another case of corrupted state in DB, similar to what you used to get after configuration migrations. was (Author: klaster_1): [~pkonstantinov] I need more info about your environment. Did you have any cluster configs prior to test? Maybe you removed some? When you got the name clash error, was there a cluster with such a name or it matched the name of cluster you've already removed? > Web Console: Cluster saved with empty name in special case > -- > > Key: IGNITE-9191 > URL: https://issues.apache.org/jira/browse/IGNITE-9191 > Project: Ignite > Issue Type: Task > Components: wizards >Reporter: Alexey Kuznetsov >Assignee: Ilya Borisov >Priority: Major > Fix For: 2.7 > > Time Spent: 3h > Remaining Estimate: 0h > > # Create a new cluster, DON'T save > # Open Advanced screen > # Go to caches. > # Create cache. > # Save cache. > # Clsuter saved with EMPTY name (bug). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9191) Web Console: Cluster saved with empty name in special case
[ https://issues.apache.org/jira/browse/IGNITE-9191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16571021#comment-16571021 ] Ilya Borisov commented on IGNITE-9191: -- [~pkonstantinov] I need more info about your environment. Did you have any cluster configs prior to test? Maybe you removed some? When you got the name clash error, was there a cluster with such a name or it matched the name of cluster you've already removed? > Web Console: Cluster saved with empty name in special case > -- > > Key: IGNITE-9191 > URL: https://issues.apache.org/jira/browse/IGNITE-9191 > Project: Ignite > Issue Type: Task > Components: wizards >Reporter: Alexey Kuznetsov >Assignee: Ilya Borisov >Priority: Major > Fix For: 2.7 > > Time Spent: 3h > Remaining Estimate: 0h > > # Create a new cluster, DON'T save > # Open Advanced screen > # Go to caches. > # Create cache. > # Save cache. > # Clsuter saved with EMPTY name (bug). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7054) S3 IP finder: support client side encryption
[
https://issues.apache.org/jira/browse/IGNITE-7054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16570930#comment-16570930
]
Valentin Kulichenko commented on IGNITE-7054:
-
[~uday], well, any data that IP finder wants to write into a bucket. To my
knowledge, this means only IPs and port numbers, yes.
> S3 IP finder: support client side encryption
>
>
> Key: IGNITE-7054
> URL: https://issues.apache.org/jira/browse/IGNITE-7054
> Project: Ignite
> Issue Type: Improvement
> Components: s3
>Affects Versions: 2.3
>Reporter: Valentin Kulichenko
>Assignee: Uday Kale
>Priority: Major
> Fix For: 2.7
>
>
> In case client side encryption [1] is used, it may be required to use
> {{AmazonS3EncryptionClient}} instead of regular {{AmazonS3Client}}. We need
> to add this option to the S3 IP finder, along with any applicable
> configuration parameters.
> [1]
> http://docs.aws.amazon.com/AmazonS3/latest/dev/UsingClientSideEncryption.html
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-9201) Immutables derived values aren't properly set on deserialization
Glen Takahashi created IGNITE-9201: -- Summary: Immutables derived values aren't properly set on deserialization Key: IGNITE-9201 URL: https://issues.apache.org/jira/browse/IGNITE-9201 Project: Ignite Issue Type: Bug Components: cache Affects Versions: 2.6 Reporter: Glen Takahashi When using the @Value.Derived annotation for an Immutables class, the Immutables-generated class implementation sets those values as `transient` because they are meant to be constructed by the builder. Because Ignite ignores transient variables when marshalling to a BinaryObject, and also because Ignite uses reflection to unmarshal from a BinaryObject, those transient variables are left uninitialized in the returned Immutables object from the cache. One idea would be instead to use an ObjectMapper and store a string/json representation in the cache and deserialize manually with the ObjectMapper, but was hoping there would be a better way to natively support Immutables and/or Jackson-serializable objects by not using Reflection in some cases. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9200) Continuous query notifications can be missed if entry processor is retried due to binary type registration
[ https://issues.apache.org/jira/browse/IGNITE-9200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Valentin Kulichenko updated IGNITE-9200: Priority: Blocker (was: Critical) > Continuous query notifications can be missed if entry processor is retried > due to binary type registration > -- > > Key: IGNITE-9200 > URL: https://issues.apache.org/jira/browse/IGNITE-9200 > Project: Ignite > Issue Type: Improvement > Components: cache >Reporter: Valentin Kulichenko >Assignee: Mikhail Cherkasov >Priority: Blocker > Fix For: 2.7 > > Attachments: InvokeAllContinuousQueryTest.java > > > Due to fix introduced in IGNITE-8926, entry processor will be retried if it > triggers binary meta data registration. However, such retries may cause loss > of continuous query notifications. > Reproducer attached. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9200) Continuous query notifications can be missed if entry processor is retried due to binary type registration
Valentin Kulichenko created IGNITE-9200: --- Summary: Continuous query notifications can be missed if entry processor is retried due to binary type registration Key: IGNITE-9200 URL: https://issues.apache.org/jira/browse/IGNITE-9200 Project: Ignite Issue Type: Improvement Components: cache Reporter: Valentin Kulichenko Assignee: Mikhail Cherkasov Fix For: 2.7 Attachments: InvokeAllContinuousQueryTest.java Due to fix introduced in IGNITE-8926, entry processor will be retried if it triggers binary meta data registration. However, such retries may cause loss of continuous query notifications. Reproducer attached. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9200) Continuous query notifications can be missed if entry processor is retried due to binary type registration
[ https://issues.apache.org/jira/browse/IGNITE-9200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Valentin Kulichenko updated IGNITE-9200: Attachment: InvokeAllContinuousQueryTest.java > Continuous query notifications can be missed if entry processor is retried > due to binary type registration > -- > > Key: IGNITE-9200 > URL: https://issues.apache.org/jira/browse/IGNITE-9200 > Project: Ignite > Issue Type: Improvement > Components: cache >Reporter: Valentin Kulichenko >Assignee: Mikhail Cherkasov >Priority: Critical > Fix For: 2.7 > > Attachments: InvokeAllContinuousQueryTest.java > > > Due to fix introduced in IGNITE-8926, entry processor will be retried if it > triggers binary meta data registration. However, such retries may cause loss > of continuous query notifications. > Reproducer attached. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9196) SQL: Memory leak in MapNodeResults
[
https://issues.apache.org/jira/browse/IGNITE-9196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Gerus updated IGNITE-9196:
Priority: Blocker (was: Major)
> SQL: Memory leak in MapNodeResults
> --
>
> Key: IGNITE-9196
> URL: https://issues.apache.org/jira/browse/IGNITE-9196
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.6
>Reporter: Denis Mekhanikov
>Priority: Blocker
>
> When size of a SQL query result set is a multiple of {{Query#pageSize}}, then
> {{MapQueryResult}} is never closed and removed from {{MapNodeResults#res}}
> collection.
> The following code leads to OOME when run with 1Gb heap:
> {code:java}
> public class MemLeakRepro {
> public static void main(String[] args) {
> Ignition.start(getConfiguration("server"));
> try (Ignite client =
> Ignition.start(getConfiguration("client").setClientMode(true))) {
> IgniteCache cache = startPeopleCache(client);
> int pages = 10;
> int pageSize = 1024;
> for (int i = 0; i < pages * pageSize; i++) {
> Person p = new Person("Person #" + i, 25);
> cache.put(i, p);
> }
> for (int i = 0; i < 1_000_000; i++) {
> if (i % 1000 == 0)
> System.out.println("Select iteration #" + i);
> Query> qry = new SqlFieldsQuery("select * from
> people");
> qry.setPageSize(pageSize);
> QueryCursor> cursor = cache.query(qry);
> cursor.getAll();
> cursor.close();
> }
> }
> }
> private static IgniteConfiguration getConfiguration(String instanceName) {
> IgniteConfiguration igniteCfg = new IgniteConfiguration();
> igniteCfg.setIgniteInstanceName(instanceName);
> TcpDiscoverySpi discoSpi = new TcpDiscoverySpi();
> discoSpi.setIpFinder(new TcpDiscoveryVmIpFinder(true));
> return igniteCfg;
> }
> private static IgniteCache startPeopleCache(Ignite node)
> {
> CacheConfiguration cacheCfg = new
> CacheConfiguration<>("cache");
> QueryEntity qe = new QueryEntity(Integer.class, Person.class);
> qe.setTableName("people");
> cacheCfg.setQueryEntities(Collections.singleton(qe));
> cacheCfg.setSqlSchema("PUBLIC");
> return node.getOrCreateCache(cacheCfg);
> }
> public static class Person {
> @QuerySqlField
> private String name;
> @QuerySqlField
> private int age;
> public Person(String name, int age) {
> this.name = name;
> this.age = age;
> }
> }
> }
> {code}
>
> At the same time it works perfectly fine, when there are, for example,
> {{pages * pageSize - 1}} records in cache instead.
> The reason for it is that {{MapQueryResult#fetchNextPage(...)}} method
> doesn't return true, when the result set size is a multiple of the page size.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-1905) High contention for CacheLockImpl causes AssertionErrors
[
https://issues.apache.org/jira/browse/IGNITE-1905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16570667#comment-16570667
]
ASF GitHub Bot commented on IGNITE-1905:
GitHub user BiryukovVA opened a pull request:
https://github.com/apache/ignite/pull/4490
IGNITE-1905: Fix AssertionError.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/BiryukovVA/ignite IGNITE-1905
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/4490.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #4490
commit 3b8782f7d0de59fced728a8ac1d74959b326ecfb
Author: Vitaliy Biryukov
Date: 2018-08-06T19:10:07Z
IGNITE-1905: Fix AssertionError.
> High contention for CacheLockImpl causes AssertionErrors
>
>
> Key: IGNITE-1905
> URL: https://issues.apache.org/jira/browse/IGNITE-1905
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: ignite-1.4
> Environment: Windows 7
>Reporter: Denis Magda
>Assignee: Vitaliy Biryukov
>Priority: Major
> Attachments: ClientTest.java, ServerTest.java
>
>
> When multiple threads, running on the same client node, compete for
> CacheLockImpl this leads to AssertionErrors.
> Pseudo-code snippet, that is called from multiple threads and causes the
> assertions, looks like this:
> {noformat}
> boolean locked = lock.tryLock(100, TimeUnit.MILLISECONDS);
> if (locked)
> lock.unlock();
> {noformat}
> Initially the issue was detected on ignite-1.4.
> In server's node logs the following assertion appears
> {noformat}
> java.lang.AssertionError
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLockFuture.addOwned(GridDhtLockFuture.java:958)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLockFuture.map(GridDhtLockFuture.java:918)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLockFuture.onOwnerChanged(GridDhtLockFuture.java:663)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMvccManager$2.onOwnerChanged(GridCacheMvccManager.java:155)
> at
> org.apache.ignite.internal.processors.cache.distributed.GridDistributedCacheEntry.checkOwnerChanged(GridDistributedCacheEntry.java:810)
> at
> org.apache.ignite.internal.processors.cache.distributed.GridDistributedCacheEntry.readyLock(GridDistributedCacheEntry.java:516)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLockFuture.readyLocks(GridDhtLockFuture.java:576)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLockFuture.map(GridDhtLockFuture.java:764)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter.lockAllAsync(GridDhtTransactionalCacheAdapter.java:973)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter.processNearLockRequest(GridDhtTransactionalCacheAdapter.java:557)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter.access$000(GridDhtTransactionalCacheAdapter.java:88)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter$2.apply(GridDhtTransactionalCacheAdapter.java:132)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter$2.apply(GridDhtTransactionalCacheAdapter.java:130)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:580)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:280)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:198)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$000(GridCacheIoManager.java:77)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:160)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:811)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$1500(GridIoManager.java:106)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$5.run(GridIoManager.java:774)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
[jira] [Assigned] (IGNITE-1905) High contention for CacheLockImpl causes AssertionErrors
[
https://issues.apache.org/jira/browse/IGNITE-1905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vitaliy Biryukov reassigned IGNITE-1905:
Assignee: Vitaliy Biryukov
> High contention for CacheLockImpl causes AssertionErrors
>
>
> Key: IGNITE-1905
> URL: https://issues.apache.org/jira/browse/IGNITE-1905
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: ignite-1.4
> Environment: Windows 7
>Reporter: Denis Magda
>Assignee: Vitaliy Biryukov
>Priority: Major
> Attachments: ClientTest.java, ServerTest.java
>
>
> When multiple threads, running on the same client node, compete for
> CacheLockImpl this leads to AssertionErrors.
> Pseudo-code snippet, that is called from multiple threads and causes the
> assertions, looks like this:
> {noformat}
> boolean locked = lock.tryLock(100, TimeUnit.MILLISECONDS);
> if (locked)
> lock.unlock();
> {noformat}
> Initially the issue was detected on ignite-1.4.
> In server's node logs the following assertion appears
> {noformat}
> java.lang.AssertionError
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLockFuture.addOwned(GridDhtLockFuture.java:958)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLockFuture.map(GridDhtLockFuture.java:918)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLockFuture.onOwnerChanged(GridDhtLockFuture.java:663)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMvccManager$2.onOwnerChanged(GridCacheMvccManager.java:155)
> at
> org.apache.ignite.internal.processors.cache.distributed.GridDistributedCacheEntry.checkOwnerChanged(GridDistributedCacheEntry.java:810)
> at
> org.apache.ignite.internal.processors.cache.distributed.GridDistributedCacheEntry.readyLock(GridDistributedCacheEntry.java:516)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLockFuture.readyLocks(GridDhtLockFuture.java:576)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLockFuture.map(GridDhtLockFuture.java:764)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter.lockAllAsync(GridDhtTransactionalCacheAdapter.java:973)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter.processNearLockRequest(GridDhtTransactionalCacheAdapter.java:557)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter.access$000(GridDhtTransactionalCacheAdapter.java:88)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter$2.apply(GridDhtTransactionalCacheAdapter.java:132)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter$2.apply(GridDhtTransactionalCacheAdapter.java:130)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:580)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:280)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:198)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$000(GridCacheIoManager.java:77)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:160)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:811)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$1500(GridIoManager.java:106)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$5.run(GridIoManager.java:774)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
>
> In addition from time to time a client node also outputs a different kind of
> assertion:
> {noformat}
> Exception in thread "ignite-#4%sys-null%" java.lang.AssertionError
> at
> org.apache.ignite.internal.processors.cache.GridCacheExplicitLockSpan.markOwned(GridCacheExplicitLockSpan.java:196)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMvccManager.markExplicitOwner(GridCacheMvccManager.java:862)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.colocated.GridDhtColocatedLockFuture$MiniFuture.onResult(GridDhtColocatedLockFuture.java:1412)
> at
> org.apache.i
[jira] [Commented] (IGNITE-9146) Analyse and improve code coverage in ML module
e3c5505dae6 Author: Oleg Ignatenko Date: 2018-08-03T18:45:45Z Merge branch 'master-ml' into ignite-9146 # Conflicts: # modules/ml/src/test/java/org/apache/ignite/ml/preprocessing/encoding/StringEncoderPreprocessorTest.java commit 261651a685cc006025c46b95b4cbb0d6e689c496 Author: Oleg Ignatenko Date: 2018-08-03T19:04:51Z IGNITE-9146 Analyse and improve code coverage in ML module - merge follow up commit a2922cc7a009c16fe274d6ab50483d409619c45a Author: Oleg Ignatenko Date: 2018-08-03T19:06:26Z IGNITE-9146 Analyse and improve code coverage in ML module - merge follow up commit 256c683c2d42dc6ab76d0ea60fc690a4a33f417e Author: Oleg Ignatenko Date: 2018-08-03T20:15:36Z IGNITE-9146 Analyse and improve code coverage in ML module - removal of dead code -- verified with diffs overview and clean rebuild commit d6b200d880fd54e217363eac5165f92dd6004d7c Author: Oleg Ignatenko Date: 2018-08-03T20:49:05Z IGNITE-9146 Analyse and improve code coverage in ML module - merge follow up commit f179d4176725ff742ed96fa8f25b7dcfe8c66656 Author: Oleg Ignatenko Date: 2018-08-03T21:11:31Z IGNITE-9146 Analyse and improve code coverage in ML module - unit tests for classes that were covered only in examples -- verified with diffs overview, rebuild, running with coverage and results analysis commit 706fd487c6b15b6b354458a7ab44addc66d538c3 Author: Oleg Ignatenko Date: 2018-08-03T22:11:51Z IGNITE-9146 Analyse and improve code coverage in ML module - corrected typo in javadoc -- verified with diffs overview commit f05f6f88b1fba60a38e30f1025307b9db5050ea4 Author: Oleg Ignatenko Date: 2018-08-03T23:06:26Z IGNITE-9146 Analyse and improve code coverage in ML module - unit tests for classes that were covered only in examples -- verified with diffs overview, rebuild, running with coverage and results analysis commit 99f97877f5131b18767bc4363e7b82115ac60f94 Author: Oleg Ignatenko Date: 2018-08-03T23:34:50Z IGNITE-9146 Analyse and improve code coverage in ML module - unit tests for classes that were covered only in examples -- verified with diffs overview, rebuild, running with coverage and results analysis commit 37f23ff04591c64ddcd586f1be5c82a27b49a9e8 Author: Oleg Ignatenko Date: 2018-08-03T23:54:26Z IGNITE-9146 Analyse and improve code coverage in ML module - unit tests for classes that were covered only in examples -- verified with diffs overview, rebuild, running with coverage and results analysis commit 6a90ec8b4ea914bf450e40474155d19544c0d6a7 Author: Oleg Ignatenko Date: 2018-08-04T00:29:30Z IGNITE-9146 Analyse and improve code coverage in ML module - unit tests for classes that were covered only in examples -- verified with diffs overview, rebuild, running with coverage and results analysis commit 55a6172d89cf749ea186894d54be6dd77e7f3f3a Author: Oleg Ignatenko Date: 2018-08-04T00:59:45Z IGNITE-9146 Analyse and improve code coverage in ML module - unit tests for classes that were covered only in examples -- verified with diffs overview, rebuild, running with coverage and results analysis commit 807be13c803018a7f1fa248f5415baea86da36d6 Author: Oleg Ignatenko Date: 2018-08-04T01:19:13Z IGNITE-9146 Analyse and improve code coverage in ML module - unit tests for classes that were covered only in examples -- verified with diffs overview, rebuild, running with coverage and results analysis commit 0df89813bea843b28f33c81101ec136e644f6aa8 Author: Oleg Ignatenko Date: 2018-08-04T01:34:28Z IGNITE-9146 Analyse and improve code coverage in ML module - unit tests for classes that were covered only in examples -- verified with diffs overview, rebuild, running with coverage and results analysis commit aefc310e1a8f2ccb31a45c93bbfe880fe335a66c Author: Oleg Ignatenko Date: 2018-08-04T07:22:51Z IGNITE-9146 Analyse and improve code coverage in ML module - unit tests for classes that were covered only in examples -- verified with diffs overview, rebuild, running with coverage and results analysis > Analyse and improve code coverage in ML module > -- > > Key: IGNITE-9146 > URL: https://issues.apache.org/jira/browse/IGNITE-9146 > Project: Ignite > Issue Type: Task > Components: ml >Affects Versions: 2.6 >Reporter: Oleg Ignatenko >Assignee: Oleg Ignatenko >Priority: Major > Fix For: 2.7 > > Attachments: 20180731-ml-coverage.zip, > 20180805.IgniteMLTestSuite.coverage.zip, > 20180806.IgniteMLTestSuite.coverage.zip > > > Run code coverage analysis, study results and add missing tests where needed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9198) REST command active/inactive respone null, other command have correct response value
[
https://issues.apache.org/jira/browse/IGNITE-9198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ARomantsov updated IGNITE-9198:
---
Description:
Output of active/inactive should have response value like other command
For example version
{code:java}
{
"result": {
"error": null,
*"response": "2.4.0",*
"sessionToken": "CE2C38BF41114B63856A4D1388E7F938",
"successStatus": 0
},
"status": "OK"
}
{code}
But active
{code:java}
{
"result": {
"error": null,
*"response": null,* , should be - cluster inactive
"sessionToken": "CE2C38BF41114B63856A4D1388E7F938",
"successStatus": 0
},
"status": "OK"
}
{code}
and inactive
{code:java}
{
"result": {
"error": null,
*"response": null,* , should be - cluster active
"sessionToken": "CE2C38BF41114B63856A4D1388E7F938",
"successStatus": 0
},
"status": "OK"
}
{code}
was:
Output of active/inactive should have response value like other command
For example version
{code:java}
{
"result": {
"error": null,
*"response": "2.4.0",*
"sessionToken": "CE2C38BF41114B63856A4D1388E7F938",
"successStatus": 0
},
"status": "OK"
}
{code}
But active
{code:java}
{
"result": {
"error": null,
*"response": null,* , should be - cluster active
"sessionToken": "CE2C38BF41114B63856A4D1388E7F938",
"successStatus": 0
},
"status": "OK"
}
{code}
and inactive
{code:java}
{
"result": {
"error": null,
*"response": null,* , should be - cluster active
"sessionToken": "CE2C38BF41114B63856A4D1388E7F938",
"successStatus": 0
},
"status": "OK"
}
{code}
> REST command active/inactive respone null, other command have correct
> response value
>
>
> Key: IGNITE-9198
> URL: https://issues.apache.org/jira/browse/IGNITE-9198
> Project: Ignite
> Issue Type: Bug
> Components: rest
>Affects Versions: 2.5
>Reporter: ARomantsov
>Priority: Major
> Fix For: 2.7
>
>
> Output of active/inactive should have response value like other command
> For example version
> {code:java}
> {
> "result": {
> "error": null,
> *"response": "2.4.0",*
> "sessionToken": "CE2C38BF41114B63856A4D1388E7F938",
> "successStatus": 0
> },
> "status": "OK"
> }
> {code}
> But active
> {code:java}
> {
> "result": {
> "error": null,
> *"response": null,* , should be - cluster inactive
> "sessionToken": "CE2C38BF41114B63856A4D1388E7F938",
> "successStatus": 0
> },
> "status": "OK"
> }
> {code}
> and inactive
> {code:java}
> {
> "result": {
> "error": null,
> *"response": null,* , should be - cluster active
> "sessionToken": "CE2C38BF41114B63856A4D1388E7F938",
> "successStatus": 0
> },
> "status": "OK"
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-9146) Analyse and improve code coverage in ML module
[ https://issues.apache.org/jira/browse/IGNITE-9146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16569562#comment-16569562 ] Oleg Ignatenko edited comment on IGNITE-9146 at 8/6/18 4:53 PM: (/) completed low hanging fruits, IDEA coverage report for the branch attached: [^20180806.IgniteMLTestSuite.coverage.zip] (-[^20180805.IgniteMLTestSuite.coverage.zip]-) was (Author: oignatenko): (/) completed low hanging fruits, IDEA coverage report for the branch attached: [^20180805.IgniteMLTestSuite.coverage.zip] > Analyse and improve code coverage in ML module > -- > > Key: IGNITE-9146 > URL: https://issues.apache.org/jira/browse/IGNITE-9146 > Project: Ignite > Issue Type: Task > Components: ml >Affects Versions: 2.6 >Reporter: Oleg Ignatenko >Assignee: Oleg Ignatenko >Priority: Major > Fix For: 2.7 > > Attachments: 20180731-ml-coverage.zip, > 20180805.IgniteMLTestSuite.coverage.zip, > 20180806.IgniteMLTestSuite.coverage.zip > > > Run code coverage analysis, study results and add missing tests where needed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9146) Analyse and improve code coverage in ML module
[ https://issues.apache.org/jira/browse/IGNITE-9146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oleg Ignatenko updated IGNITE-9146: --- Attachment: 20180806.IgniteMLTestSuite.coverage.zip > Analyse and improve code coverage in ML module > -- > > Key: IGNITE-9146 > URL: https://issues.apache.org/jira/browse/IGNITE-9146 > Project: Ignite > Issue Type: Task > Components: ml >Affects Versions: 2.6 >Reporter: Oleg Ignatenko >Assignee: Oleg Ignatenko >Priority: Major > Fix For: 2.7 > > Attachments: 20180731-ml-coverage.zip, > 20180805.IgniteMLTestSuite.coverage.zip, > 20180806.IgniteMLTestSuite.coverage.zip > > > Run code coverage analysis, study results and add missing tests where needed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-9191) Web Console: Cluster saved with empty name in special case
[ https://issues.apache.org/jira/browse/IGNITE-9191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov reassigned IGNITE-9191: Assignee: Ilya Borisov (was: Alexey Kuznetsov) > Web Console: Cluster saved with empty name in special case > -- > > Key: IGNITE-9191 > URL: https://issues.apache.org/jira/browse/IGNITE-9191 > Project: Ignite > Issue Type: Task > Components: wizards >Reporter: Alexey Kuznetsov >Assignee: Ilya Borisov >Priority: Major > Fix For: 2.7 > > Time Spent: 3h > Remaining Estimate: 0h > > # Create a new cluster, DON'T save > # Open Advanced screen > # Go to caches. > # Create cache. > # Save cache. > # Clsuter saved with EMPTY name (bug). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9197) Java thin client querying empty table results in NoSuchElementException
[
https://issues.apache.org/jira/browse/IGNITE-9197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16570447#comment-16570447
]
Alexey Kukushkin commented on IGNITE-9197:
--
TeamCity:
https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_RunAll&branch_IgniteTests24Java8=pull%2F4488%2Fhead&tab=buildTypeStatusDiv
> Java thin client querying empty table results in NoSuchElementException
> ---
>
> Key: IGNITE-9197
> URL: https://issues.apache.org/jira/browse/IGNITE-9197
> Project: Ignite
> Issue Type: Bug
> Components: thin client
>Affects Versions: 2.6
>Reporter: Alexey Kukushkin
>Assignee: Alexey Kukushkin
>Priority: Critical
> Fix For: 2.7
>
>
> +*Reproducer*+
> {code:java}
> @Test
> public void testGettingEmptyResultWhenQueryingEmptyTable() throws Exception {
> try (Ignite ignored = Ignition.start(Config.getServerConfiguration());
> IgniteClient client = Ignition.startClient(new
> ClientConfiguration().setAddresses(Config.SERVER))
> ) {
> final String TBL = "Person";
> client.query(
> new SqlFieldsQuery("CREATE TABLE IF NOT EXISTS " + TBL + " (id
> INT PRIMARY KEY, name VARCHAR)")
> ).getAll();
> List> res = client.query(new SqlFieldsQuery("SELECT * FROM "
> + TBL)).getAll();
> assertNotNull(res);
> assertEquals(0, res.size());
> }
> }
> {code}
> *Expected*
> The test above should pass
> *Actual*
> java.util.NoSuchElementException
> at java.util.ArrayList$Itr.next(ArrayList.java:862)
> at
> org.apache.ignite.internal.client.thin.ClientQueryCursor$1.next(ClientQueryCursor.java:87)
> at
> org.apache.ignite.internal.client.thin.ClientQueryCursor.getAll(ClientQueryCursor.java:45)
> at
> org.apache.ignite.client.FunctionalQueryTest.testGettingEmptyResultWhenQueryingEmptyTable(FunctionalQueryTest.java:171)
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9197) Java thin client querying empty table results in NoSuchElementException
[
https://issues.apache.org/jira/browse/IGNITE-9197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16570432#comment-16570432
]
ASF GitHub Bot commented on IGNITE-9197:
GitHub user kukushal opened a pull request:
https://github.com/apache/ignite/pull/4488
IGNITE-9197 Java thin client querying empty table results in
NoSuchElementException
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-9197
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/4488.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #4488
commit c07e904c8ac76daa5229fbb874c78b05378fe1e3
Author: Alexey Kukushkin
Date: 2018-08-06T16:23:05Z
Initial revision
> Java thin client querying empty table results in NoSuchElementException
> ---
>
> Key: IGNITE-9197
> URL: https://issues.apache.org/jira/browse/IGNITE-9197
> Project: Ignite
> Issue Type: Bug
> Components: thin client
>Affects Versions: 2.6
>Reporter: Alexey Kukushkin
>Assignee: Alexey Kukushkin
>Priority: Critical
> Fix For: 2.7
>
>
> +*Reproducer*+
> {code:java}
> @Test
> public void testGettingEmptyResultWhenQueryingEmptyTable() throws Exception {
> try (Ignite ignored = Ignition.start(Config.getServerConfiguration());
> IgniteClient client = Ignition.startClient(new
> ClientConfiguration().setAddresses(Config.SERVER))
> ) {
> final String TBL = "Person";
> client.query(
> new SqlFieldsQuery("CREATE TABLE IF NOT EXISTS " + TBL + " (id
> INT PRIMARY KEY, name VARCHAR)")
> ).getAll();
> List> res = client.query(new SqlFieldsQuery("SELECT * FROM "
> + TBL)).getAll();
> assertNotNull(res);
> assertEquals(0, res.size());
> }
> }
> {code}
> *Expected*
> The test above should pass
> *Actual*
> java.util.NoSuchElementException
> at java.util.ArrayList$Itr.next(ArrayList.java:862)
> at
> org.apache.ignite.internal.client.thin.ClientQueryCursor$1.next(ClientQueryCursor.java:87)
> at
> org.apache.ignite.internal.client.thin.ClientQueryCursor.getAll(ClientQueryCursor.java:45)
> at
> org.apache.ignite.client.FunctionalQueryTest.testGettingEmptyResultWhenQueryingEmptyTable(FunctionalQueryTest.java:171)
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-9199) Ignite doesn't save history for SQL queries after setting queryDetailMetricsSize
Evgenii Zhuravlev created IGNITE-9199: - Summary: Ignite doesn't save history for SQL queries after setting queryDetailMetricsSize Key: IGNITE-9199 URL: https://issues.apache.org/jira/browse/IGNITE-9199 Project: Ignite Issue Type: Bug Reporter: Evgenii Zhuravlev Steps to reproduce: 1. Start cluster with persistence without queryDetailMetricsSize. 2. Restart cluster with configured queryDetailMetricsSize. Ignite save history for SCAN queries only. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9198) REST command active/inactive respone null, other command have correct response value
[
https://issues.apache.org/jira/browse/IGNITE-9198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ARomantsov updated IGNITE-9198:
---
Description:
Output of active/inactive should have response value like other command
For example version
{code:java}
{
"result": {
"error": null,
*"response": "2.4.0",*
"sessionToken": "CE2C38BF41114B63856A4D1388E7F938",
"successStatus": 0
},
"status": "OK"
}
{code}
But active
{code:java}
{
"result": {
"error": null,
*"response": null,* , should be - cluster active
"sessionToken": "CE2C38BF41114B63856A4D1388E7F938",
"successStatus": 0
},
"status": "OK"
}
{code}
and inactive
{code:java}
{
"result": {
"error": null,
*"response": null,* , should be - cluster active
"sessionToken": "CE2C38BF41114B63856A4D1388E7F938",
"successStatus": 0
},
"status": "OK"
}
{code}
was:
Output of active/inactive should have response value like other command
For example version
{code:java}
{
"result": {
"error": null,
*"response": "2.4.0",*
"sessionToken": "CE2C38BF41114B63856A4D1388E7F938",
"successStatus": 0
},
"status": "OK"
}
{code}
But active
{
"result": {
"error": null,
*"response": null,* , should be - cluster active
"sessionToken": "CE2C38BF41114B63856A4D1388E7F938",
"successStatus": 0
},
"status": "OK"
}
and inactive
{
"result": {
"error": null,
*"response": null,* , should be - cluster inactive
"sessionToken": "CE2C38BF41114B63856A4D1388E7F938",
"successStatus": 0
},
"status": "OK"
}
> REST command active/inactive respone null, other command have correct
> response value
>
>
> Key: IGNITE-9198
> URL: https://issues.apache.org/jira/browse/IGNITE-9198
> Project: Ignite
> Issue Type: Bug
> Components: rest
>Affects Versions: 2.5
>Reporter: ARomantsov
>Priority: Major
> Fix For: 2.7
>
>
> Output of active/inactive should have response value like other command
> For example version
> {code:java}
> {
> "result": {
> "error": null,
> *"response": "2.4.0",*
> "sessionToken": "CE2C38BF41114B63856A4D1388E7F938",
> "successStatus": 0
> },
> "status": "OK"
> }
> {code}
> But active
> {code:java}
> {
> "result": {
> "error": null,
> *"response": null,* , should be - cluster active
> "sessionToken": "CE2C38BF41114B63856A4D1388E7F938",
> "successStatus": 0
> },
> "status": "OK"
> }
> {code}
> and inactive
> {code:java}
> {
> "result": {
> "error": null,
> *"response": null,* , should be - cluster active
> "sessionToken": "CE2C38BF41114B63856A4D1388E7F938",
> "successStatus": 0
> },
> "status": "OK"
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9198) REST command active/inactive respone null, other command have correct response value
[
https://issues.apache.org/jira/browse/IGNITE-9198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ARomantsov updated IGNITE-9198:
---
Description:
Output of active/inactive should have response value like other command
For example version
{code:java}
{
"result": {
"error": null,
*"response": "2.4.0",*
"sessionToken": "CE2C38BF41114B63856A4D1388E7F938",
"successStatus": 0
},
"status": "OK"
}
{code}
But active
{
"result": {
"error": null,
*"response": null,* , should be - cluster active
"sessionToken": "CE2C38BF41114B63856A4D1388E7F938",
"successStatus": 0
},
"status": "OK"
}
and inactive
{
"result": {
"error": null,
*"response": null,* , should be - cluster inactive
"sessionToken": "CE2C38BF41114B63856A4D1388E7F938",
"successStatus": 0
},
"status": "OK"
}
was:
Output of active/inactive should have response value like other command
For example version
{code:java}
{
"result": {
"error": null,
*"response": "2.5.1-p9",*
"sessionToken": "CE2C38BF41114B63856A4D1388E7F938",
"successStatus": 0
},
"status": "OK"
}
{code}
But active
{
"result": {
"error": null,
*"response": null,* , should be - cluster active
"sessionToken": "CE2C38BF41114B63856A4D1388E7F938",
"successStatus": 0
},
"status": "OK"
}
and inactive
{
"result": {
"error": null,
*"response": null,* , should be - cluster inactive
"sessionToken": "CE2C38BF41114B63856A4D1388E7F938",
"successStatus": 0
},
"status": "OK"
}
> REST command active/inactive respone null, other command have correct
> response value
>
>
> Key: IGNITE-9198
> URL: https://issues.apache.org/jira/browse/IGNITE-9198
> Project: Ignite
> Issue Type: Bug
> Components: rest
>Affects Versions: 2.5
>Reporter: ARomantsov
>Priority: Major
> Fix For: 2.7
>
>
> Output of active/inactive should have response value like other command
> For example version
> {code:java}
> {
> "result": {
> "error": null,
> *"response": "2.4.0",*
> "sessionToken": "CE2C38BF41114B63856A4D1388E7F938",
> "successStatus": 0
> },
> "status": "OK"
> }
> {code}
> But active
> {
> "result": {
> "error": null,
> *"response": null,* , should be - cluster active
> "sessionToken": "CE2C38BF41114B63856A4D1388E7F938",
> "successStatus": 0
> },
> "status": "OK"
> }
> and inactive
> {
> "result": {
> "error": null,
> *"response": null,* , should be - cluster inactive
> "sessionToken": "CE2C38BF41114B63856A4D1388E7F938",
> "successStatus": 0
> },
> "status": "OK"
> }
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9198) REST command active/inactive respone null, other command have correct response value
[
https://issues.apache.org/jira/browse/IGNITE-9198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ARomantsov updated IGNITE-9198:
---
Description:
Output of active/inactive should have response value like other command
For example version
{code:java}
{
"result": {
"error": null,
*"response": "2.5.1-p9",*
"sessionToken": "CE2C38BF41114B63856A4D1388E7F938",
"successStatus": 0
},
"status": "OK"
}
{code}
But active
{
"result": {
"error": null,
*"response": null,* , should be - cluster active
"sessionToken": "CE2C38BF41114B63856A4D1388E7F938",
"successStatus": 0
},
"status": "OK"
}
and inactive
{
"result": {
"error": null,
*"response": null,* , should be - cluster inactive
"sessionToken": "CE2C38BF41114B63856A4D1388E7F938",
"successStatus": 0
},
"status": "OK"
}
was:
Output of active/inactive should have response value like other command
For example version
{
"result": {
"error": null,
*"response": "2.5.1-p9",*
"sessionToken": "CE2C38BF41114B63856A4D1388E7F938",
"successStatus": 0
},
"status": "OK"
}
But active
{
"result": {
"error": null,
*"response": null,* , should be - cluster active
"sessionToken": "CE2C38BF41114B63856A4D1388E7F938",
"successStatus": 0
},
"status": "OK"
}
and inactive
{
"result": {
"error": null,
*"response": null,* , should be - cluster inactive
"sessionToken": "CE2C38BF41114B63856A4D1388E7F938",
"successStatus": 0
},
"status": "OK"
}
> REST command active/inactive respone null, other command have correct
> response value
>
>
> Key: IGNITE-9198
> URL: https://issues.apache.org/jira/browse/IGNITE-9198
> Project: Ignite
> Issue Type: Bug
> Components: rest
>Affects Versions: 2.5
>Reporter: ARomantsov
>Priority: Major
> Fix For: 2.7
>
>
> Output of active/inactive should have response value like other command
> For example version
> {code:java}
> {
> "result": {
> "error": null,
> *"response": "2.5.1-p9",*
> "sessionToken": "CE2C38BF41114B63856A4D1388E7F938",
> "successStatus": 0
> },
> "status": "OK"
> }
> {code}
> But active
> {
> "result": {
> "error": null,
> *"response": null,* , should be - cluster active
> "sessionToken": "CE2C38BF41114B63856A4D1388E7F938",
> "successStatus": 0
> },
> "status": "OK"
> }
> and inactive
> {
> "result": {
> "error": null,
> *"response": null,* , should be - cluster inactive
> "sessionToken": "CE2C38BF41114B63856A4D1388E7F938",
> "successStatus": 0
> },
> "status": "OK"
> }
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-896) Configuration inconsistency
[ https://issues.apache.org/jira/browse/IGNITE-896?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolai Kulagin reassigned IGNITE-896: -- Assignee: Nikolai Kulagin > Configuration inconsistency > --- > > Key: IGNITE-896 > URL: https://issues.apache.org/jira/browse/IGNITE-896 > Project: Ignite > Issue Type: Bug > Components: general >Affects Versions: sprint-5 >Reporter: Valentin Kulichenko >Assignee: Nikolai Kulagin >Priority: Minor > Labels: Usability > > I noticed that some entities on cache configuration are configured via > factories, while others are set directly. For example, we use factory for > ExpiryPolicy, but not for EvictionPolicy, which looks inconsistent. Since > factory-based approach comes from JCache, I think we should use it wherever > possible. > Here is the list of settings that need to be fixed: > * Affinity > * AffinityMapper > * EvictionFilter > * EvictionPolicy > * CacheInterceptor > * TopologyValidator > Need to add new configuration properties that use factories and deprecate old > ones (do not remove for compatibility). > Also need to check other configuration beans (list above is for cache config > only). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9198) REST command active/inactive respone null, other command have correct response value
ARomantsov created IGNITE-9198:
--
Summary: REST command active/inactive respone null, other command
have correct response value
Key: IGNITE-9198
URL: https://issues.apache.org/jira/browse/IGNITE-9198
Project: Ignite
Issue Type: Bug
Components: rest
Affects Versions: 2.5
Reporter: ARomantsov
Fix For: 2.7
Output of active/inactive should have response value like other command
For example version
{
"result": {
"error": null,
*"response": "2.5.1-p9",*
"sessionToken": "CE2C38BF41114B63856A4D1388E7F938",
"successStatus": 0
},
"status": "OK"
}
But active
{
"result": {
"error": null,
*"response": null,* , should be - cluster active
"sessionToken": "CE2C38BF41114B63856A4D1388E7F938",
"successStatus": 0
},
"status": "OK"
}
and inactive
{
"result": {
"error": null,
*"response": null,* , should be - cluster inactive
"sessionToken": "CE2C38BF41114B63856A4D1388E7F938",
"successStatus": 0
},
"status": "OK"
}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9186) Datastreamer may ignores perNodeBuffer size unexpectedly.
[ https://issues.apache.org/jira/browse/IGNITE-9186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16570352#comment-16570352 ] Igor Seliverstov commented on IGNITE-9186: -- [~amashenkov], looks OK to me. > Datastreamer may ignores perNodeBuffer size unexpectedly. > - > > Key: IGNITE-9186 > URL: https://issues.apache.org/jira/browse/IGNITE-9186 > Project: Ignite > Issue Type: Improvement > Components: streaming >Reporter: Andrew Mashenkov >Assignee: Igor Seliverstov >Priority: Major > > Looks like we have to omit per-thread buffer for batches that are passed to > data streamer. > Large per-thread buffer size may have negative affect on latency in some > cases (small batch or small per-node buffer size). > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-9146) Analyse and improve code coverage in ML module
[
https://issues.apache.org/jira/browse/IGNITE-9146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16568663#comment-16568663
]
Oleg Ignatenko edited comment on IGNITE-9146 at 8/6/18 2:43 PM:
Further study of coverage reports revealed some dead code that needs to be
removed:
- class {{SmallTrainingDatasetSizeException}}. It was introduced per
IGNITE-6880 but the code that used this class was later changed to go without
it per IGNITE-7702
- class {{math.Precision}}. It was introduced (adopted from apache commons
math) per IGNITE-5012 but in later changes turned out of extremely low demand
(as of now only use is a private constant in {{AbstractLSQR}}). Per discussion
with [~amalykh] who is most involved in this code it is better to remove. (to
avoid confusion, note that there is another class with same name but in another
package: {{selection.scoring.metric.Precision}} - that one is to be kept)
- class {{Isomorphism}}. It was introduced in IGNITE-7322 with the intention to
maybe use it some time later as it implemented a concept that looked like
promising back then However in the further development need for it did not
appear and per discussion with author ([~amalykh]) it is currently better to
remove it.
- class {{MurmurHash}} - introduced per IGNITE-4572 for use in
{{RandomMatrixStorage}} and {{RandomVectorStorage}} which were in turn later
removed per IGNITE-8450
was (Author: oignatenko):
Further study of coverage reports revealed some dead code that needs to be
removed:
- class {{SmallTrainingDatasetSizeException}}. It was introduced per
IGNITE-6880 but the code that used this class was later changed to go without
it per IGNITE-7702
- class {{math.Precision}}. It was introduced (adopted from apache commons
math) per IGNITE-5012 but in later changes turned out of extremely low demand
(as of now only use is a private constant in {{AbstractLSQR}}). Per discussion
with [~amalykh] who is most involved in this code it is better to remove. (to
avoid confusion, note that there is another class with same name but in another
package: {{selection.scoring.metric.Precision}} - that one is to be kept)
- class {{Isomorphism}}. It was introduced in IGNITE-7322 with the intention to
maybe use it some time later as it implemented a concept that looked like
promising back then However in the further development need for it did not
appear and per discussion with author ([~amalykh]) it is currently better to
remove it.
> Analyse and improve code coverage in ML module
> --
>
> Key: IGNITE-9146
> URL: https://issues.apache.org/jira/browse/IGNITE-9146
> Project: Ignite
> Issue Type: Task
> Components: ml
>Affects Versions: 2.6
>Reporter: Oleg Ignatenko
>Assignee: Oleg Ignatenko
>Priority: Major
> Fix For: 2.7
>
> Attachments: 20180731-ml-coverage.zip,
> 20180805.IgniteMLTestSuite.coverage.zip
>
>
> Run code coverage analysis, study results and add missing tests where needed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8930) ODBC: Cursors are not closed when used through Go
[
https://issues.apache.org/jira/browse/IGNITE-8930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16570237#comment-16570237
]
Taras Ledkov commented on IGNITE-8930:
--
[~isapego], the fix looks good. My comment:
- You change the behavior of the query with multiple statements and don't add
tests for it. New test checks only query with one statement. Is it OK? I guess
the existed tests for multiple statements don't reproduce the problem.
> ODBC: Cursors are not closed when used through Go
> -
>
> Key: IGNITE-8930
> URL: https://issues.apache.org/jira/browse/IGNITE-8930
> Project: Ignite
> Issue Type: Bug
> Components: odbc
>Affects Versions: 2.5
>Reporter: Igor Sapego
>Assignee: Igor Sapego
>Priority: Major
> Labels: odbc
> Fix For: 2.7
>
>
> Client used: https://github.com/alexbrainman/odbc
> Example app for reproducing:
> [https://github.com/nombiezinja/ignite-cursor-example]
> After several execution of statements user begins to get the following error:
> {noformat}
> 2018/06/29 20:46:06 SQLExecute: {HY000} Too many open cursors (either close
> other open cursors or increase the limit through
> ClientConnectorConfiguration.maxOpenCursorsPerConnection) [maximum=128,
> current=128]{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8189) Improve ZkDistributedCollectDataFuture#deleteFutureData implementation
[ https://issues.apache.org/jira/browse/IGNITE-8189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16570233#comment-16570233 ] Dmitriy Pavlov commented on IGNITE-8189: [~Jokser], could you please step in? > Improve ZkDistributedCollectDataFuture#deleteFutureData implementation > -- > > Key: IGNITE-8189 > URL: https://issues.apache.org/jira/browse/IGNITE-8189 > Project: Ignite > Issue Type: Improvement > Components: zookeeper >Reporter: Sergey Chugunov >Assignee: Amelchev Nikita >Priority: Major > > Three issues need to be improved in implementation: > * two more deleteIfExists methods within the *deleteFutureData* to be > included in batching *deleteAll* operation; > * if request exceeds ZooKeeper max size limit fallback to one-by-one deletion > should be used (related ticket IGNITE-8188); > * ZookeeperClient#deleteAll implementation may throw NoNodeException is case > of concurrent operation removing the same nodes, in this case fallback to > one-by-one deletion should be used too. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-8149) MVCC TX Size method should use tx snapshot
[ https://issues.apache.org/jira/browse/IGNITE-8149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Seliverstov reassigned IGNITE-8149: Assignee: Igor Seliverstov (was: Ivan Pavlukhin) > MVCC TX Size method should use tx snapshot > -- > > Key: IGNITE-8149 > URL: https://issues.apache.org/jira/browse/IGNITE-8149 > Project: Ignite > Issue Type: Task > Components: cache >Reporter: Igor Seliverstov >Assignee: Igor Seliverstov >Priority: Major > > Currently cache.size() returns number of entries in cache trees while there > can be several versions of one key-value pairs. > We should use tx snapshot and count all passed mvcc filter entries instead. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-8149) MVCC TX Size method should use tx snapshot
[ https://issues.apache.org/jira/browse/IGNITE-8149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Seliverstov reassigned IGNITE-8149: Assignee: Ivan Pavlukhin (was: Igor Seliverstov) > MVCC TX Size method should use tx snapshot > -- > > Key: IGNITE-8149 > URL: https://issues.apache.org/jira/browse/IGNITE-8149 > Project: Ignite > Issue Type: Task > Components: cache >Reporter: Igor Seliverstov >Assignee: Ivan Pavlukhin >Priority: Major > > Currently cache.size() returns number of entries in cache trees while there > can be several versions of one key-value pairs. > We should use tx snapshot and count all passed mvcc filter entries instead. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9196) SQL: Memory leak in MapNodeResults
[
https://issues.apache.org/jira/browse/IGNITE-9196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Mekhanikov updated IGNITE-9196:
-
Description:
When size of a SQL query result set is a multiple of {{Query#pageSize}}, then
{{MapQueryResult}} is never closed and removed from {{MapNodeResults#res}}
collection.
The following code leads to OOME when run with 1Gb heap:
{code:java}
public class MemLeakRepro {
public static void main(String[] args) {
Ignition.start(getConfiguration("server"));
try (Ignite client =
Ignition.start(getConfiguration("client").setClientMode(true))) {
IgniteCache cache = startPeopleCache(client);
int pages = 10;
int pageSize = 1024;
for (int i = 0; i < pages * pageSize; i++) {
Person p = new Person("Person #" + i, 25);
cache.put(i, p);
}
for (int i = 0; i < 1_000_000; i++) {
if (i % 1000 == 0)
System.out.println("Select iteration #" + i);
Query> qry = new SqlFieldsQuery("select * from people");
qry.setPageSize(pageSize);
QueryCursor> cursor = cache.query(qry);
cursor.getAll();
cursor.close();
}
}
}
private static IgniteConfiguration getConfiguration(String instanceName) {
IgniteConfiguration igniteCfg = new IgniteConfiguration();
igniteCfg.setIgniteInstanceName(instanceName);
TcpDiscoverySpi discoSpi = new TcpDiscoverySpi();
discoSpi.setIpFinder(new TcpDiscoveryVmIpFinder(true));
return igniteCfg;
}
private static IgniteCache startPeopleCache(Ignite node) {
CacheConfiguration cacheCfg = new
CacheConfiguration<>("cache");
QueryEntity qe = new QueryEntity(Integer.class, Person.class);
qe.setTableName("people");
cacheCfg.setQueryEntities(Collections.singleton(qe));
cacheCfg.setSqlSchema("PUBLIC");
return node.getOrCreateCache(cacheCfg);
}
public static class Person {
@QuerySqlField
private String name;
@QuerySqlField
private int age;
public Person(String name, int age) {
this.name = name;
this.age = age;
}
}
}
{code}
At the same time it works perfectly fine, when there are, for example, {{pages
* pageSize - 1}} records in cache instead.
The reason for it is that {{MapQueryResult#fetchNextPage(...)}} method doesn't
return true, when the result set size is a multiple of the page size.
was:
When size of a SQL query result set is a multiple of {{Query#pageSize}}, then
{{MapQueryResult}} is never closed and removed from {{MapNodeResults#res}}
collection.
The following code leads to OOME when run with 1Gb heap:
{code:java}
public class MemLeakRepro {
public static void main(String[] args) {
Ignition.start(getConfiguration("server"));
try (Ignite client =
Ignition.start(getConfiguration("client").setClientMode(true))) {
IgniteCache cache = startPeopleCache(client);
int pages = 10;
int pageSize = 1024;
for (int i = 0; i < pages * pageSize; i++) {
Person p = new Person("Person #" + i, 25);
cache.put(i, p);
}
for (int i = 0; i < 1_000_000; i++) {
if (i % 1000 == 0)
System.out.println("Select iteration #" + i);
Query> qry = new SqlFieldsQuery("select * from people");
qry.setPageSize(pageSize);
QueryCursor> cursor = cache.query(qry);
cursor.getAll();
cursor.close();
}
}
}
private static IgniteConfiguration getConfiguration(String instanceName) {
IgniteConfiguration igniteCfg = new IgniteConfiguration();
igniteCfg.setIgniteInstanceName(instanceName);
TcpDiscoverySpi discoSpi = new TcpDiscoverySpi();
discoSpi.setIpFinder(new TcpDiscoveryVmIpFinder(true));
return igniteCfg;
}
private static IgniteCache startPeopleCache(Ignite node) {
CacheConfiguration cacheCfg = new
CacheConfiguration<>("cache");
QueryEntity qe = new QueryEntity(Integer.class, Person.class);
qe.setTableName("people");
cacheCfg.setQueryEntities(Collections.singleton(qe));
cacheCfg.setSqlSchema("PUBLIC");
return node.getOrCreateCache(cacheCfg);
}
public static class Person {
@QuerySqlField
private String name;
@QuerySqlField
private int age;
public Person(String name, int age) {
this.name = name;
this.age = age;
}
}
}
{code}
At the same time it works perfectly fine, when there are, for example, {{pages
* (pageSize + 1)}} records in
[jira] [Assigned] (IGNITE-9184) Cluster hangs during concurrent node restart and continues query registration
[ https://issues.apache.org/jira/browse/IGNITE-9184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Govorukhin reassigned IGNITE-9184: -- Assignee: Ilya Lantukh (was: Dmitriy Govorukhin) > Cluster hangs during concurrent node restart and continues query registration > - > > Key: IGNITE-9184 > URL: https://issues.apache.org/jira/browse/IGNITE-9184 > Project: Ignite > Issue Type: Bug > Components: general >Affects Versions: 2.6 >Reporter: Mikhail Cherkasov >Assignee: Ilya Lantukh >Priority: Blocker > Fix For: 2.7 > > Attachments: StressTest.java, logs, stacktrace > > > Please check the attached test case and stack trace. > I can see: "Failed to wait for initial partition map exchange" message. > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9184) Cluster hangs during concurrent node restart and continues query registration
[
https://issues.apache.org/jira/browse/IGNITE-9184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16570181#comment-16570181
]
Mikhail Cherkasov commented on IGNITE-9184:
---
Stacktraces shows that client and server node are stuck on initial exchange:
{code:java}
"Thread-0" #10 prio=5 os_prio=31 tid=0x7fd2a28e7800 nid=0x4003 waiting on
condition [0x751c8000]
java.lang.Thread.State: TIMED_WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:338)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:217)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:159)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:151)
at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.onKernalStart(GridCachePartitionExchangeManager.java:632)
at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.onKernalStart(GridCacheProcessor.java:865)
at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1043)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1973)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1716)
- locked <0x0006d9f1e598> (a
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance)
at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1144)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:664)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:589)
at org.apache.ignite.Ignition.start(Ignition.java:327)
at continues_query.StressTest$StartStopTask.run(StressTest.java:201)
at java.lang.Thread.run(Thread.java:748)
"main" #1 prio=5 os_prio=31 tid=0x7fd2a3800800 nid=0x2503 waiting on
condition [0x74218000]
java.lang.Thread.State: TIMED_WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:338)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:217)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:159)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:151)
at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.onKernalStart(GridCachePartitionExchangeManager.java:632)
at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.onKernalStart(GridCacheProcessor.java:865)
at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1043)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1973)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1716)
- locked <0x0006de0aa3b0> (a
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance)
at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1144)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:664)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:589)
at org.apache.ignite.Ignition.start(Ignition.java:327)
at continues_query.StressTest.main(StressTest.java:81)
{code}
I don't see any other stuck threads.
> Cluster hangs during concurrent node restart and continues query registration
> -
>
> Key: IGNITE-9184
> URL: https://issues.apache.org/jira/browse/IGNITE-9184
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 2.6
>Reporter: Mikhail Cherkasov
>Assignee: Dmitriy Govorukhin
>Priority: Blocker
> Fix For: 2.7
>
> Attachments: StressTest.java, logs, stacktrace
>
>
> Please check the attached test case and stack trace.
> I can see: "Failed to wait for initial partition map exchange" message.
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9197) Java thin client querying empty table results in NoSuchElementException
[
https://issues.apache.org/jira/browse/IGNITE-9197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Kukushkin updated IGNITE-9197:
-
Description:
+*Reproducer*+
{code:java}
@Test
public void testGettingEmptyResultWhenQueryingEmptyTable() throws Exception {
try (Ignite ignored = Ignition.start(Config.getServerConfiguration());
IgniteClient client = Ignition.startClient(new
ClientConfiguration().setAddresses(Config.SERVER))
) {
final String TBL = "Person";
client.query(
new SqlFieldsQuery("CREATE TABLE IF NOT EXISTS " + TBL + " (id INT
PRIMARY KEY, name VARCHAR)")
).getAll();
List> res = client.query(new SqlFieldsQuery("SELECT * FROM " +
TBL)).getAll();
assertNotNull(res);
assertEquals(0, res.size());
}
}
{code}
*Expected*
The test above should pass
*Actual*
java.util.NoSuchElementException
at java.util.ArrayList$Itr.next(ArrayList.java:862)
at
org.apache.ignite.internal.client.thin.ClientQueryCursor$1.next(ClientQueryCursor.java:87)
at
org.apache.ignite.internal.client.thin.ClientQueryCursor.getAll(ClientQueryCursor.java:45)
at
org.apache.ignite.client.FunctionalQueryTest.testGettingEmptyResultWhenQueryingEmptyTable(FunctionalQueryTest.java:171)
was:
+*Reproducer*+
> Java thin client querying empty table results in NoSuchElementException
> ---
>
> Key: IGNITE-9197
> URL: https://issues.apache.org/jira/browse/IGNITE-9197
> Project: Ignite
> Issue Type: Bug
> Components: thin client
>Affects Versions: 2.6
>Reporter: Alexey Kukushkin
>Assignee: Alexey Kukushkin
>Priority: Critical
> Fix For: 2.7
>
>
> +*Reproducer*+
> {code:java}
> @Test
> public void testGettingEmptyResultWhenQueryingEmptyTable() throws Exception {
> try (Ignite ignored = Ignition.start(Config.getServerConfiguration());
> IgniteClient client = Ignition.startClient(new
> ClientConfiguration().setAddresses(Config.SERVER))
> ) {
> final String TBL = "Person";
> client.query(
> new SqlFieldsQuery("CREATE TABLE IF NOT EXISTS " + TBL + " (id
> INT PRIMARY KEY, name VARCHAR)")
> ).getAll();
> List> res = client.query(new SqlFieldsQuery("SELECT * FROM "
> + TBL)).getAll();
> assertNotNull(res);
> assertEquals(0, res.size());
> }
> }
> {code}
> *Expected*
> The test above should pass
> *Actual*
> java.util.NoSuchElementException
> at java.util.ArrayList$Itr.next(ArrayList.java:862)
> at
> org.apache.ignite.internal.client.thin.ClientQueryCursor$1.next(ClientQueryCursor.java:87)
> at
> org.apache.ignite.internal.client.thin.ClientQueryCursor.getAll(ClientQueryCursor.java:45)
> at
> org.apache.ignite.client.FunctionalQueryTest.testGettingEmptyResultWhenQueryingEmptyTable(FunctionalQueryTest.java:171)
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9197) Java thin client querying empty table results in NoSuchElementException
[
https://issues.apache.org/jira/browse/IGNITE-9197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Kukushkin updated IGNITE-9197:
-
Environment: (was: +*Reproducer*+
{code:java}
@Test
public void testGettingEmptyResultWhenQueryingEmptyTable() throws Exception {
try (Ignite ignored = Ignition.start(Config.getServerConfiguration());
IgniteClient client = Ignition.startClient(new
ClientConfiguration().setAddresses(Config.SERVER))
) {
final String TBL = "Person";
client.query(
new SqlFieldsQuery("CREATE TABLE IF NOT EXISTS " + TBL + " (id INT
PRIMARY KEY, name VARCHAR)")
).getAll();
List> res = client.query(new SqlFieldsQuery("SELECT * FROM " +
TBL)).getAll();
assertNotNull(res);
assertEquals(0, res.size());
}
}
{code}
*Expected*
The test above should pass
*Actual*
java.util.NoSuchElementException
at java.util.ArrayList$Itr.next(ArrayList.java:862)
at
org.apache.ignite.internal.client.thin.ClientQueryCursor$1.next(ClientQueryCursor.java:87)
at
org.apache.ignite.internal.client.thin.ClientQueryCursor.getAll(ClientQueryCursor.java:45)
at
org.apache.ignite.client.FunctionalQueryTest.testGettingEmptyResultWhenQueryingEmptyTable(FunctionalQueryTest.java:171))
> Java thin client querying empty table results in NoSuchElementException
> ---
>
> Key: IGNITE-9197
> URL: https://issues.apache.org/jira/browse/IGNITE-9197
> Project: Ignite
> Issue Type: Bug
> Components: thin client
>Affects Versions: 2.6
>Reporter: Alexey Kukushkin
>Assignee: Alexey Kukushkin
>Priority: Critical
> Fix For: 2.7
>
>
> +*Reproducer*+
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-9197) Java thin client querying empty table results in NoSuchElementException
Alexey Kukushkin created IGNITE-9197:
Summary: Java thin client querying empty table results in
NoSuchElementException
Key: IGNITE-9197
URL: https://issues.apache.org/jira/browse/IGNITE-9197
Project: Ignite
Issue Type: Bug
Components: thin client
Affects Versions: 2.6
Environment: +*Reproducer*+
{code:java}
@Test
public void testGettingEmptyResultWhenQueryingEmptyTable() throws Exception {
try (Ignite ignored = Ignition.start(Config.getServerConfiguration());
IgniteClient client = Ignition.startClient(new
ClientConfiguration().setAddresses(Config.SERVER))
) {
final String TBL = "Person";
client.query(
new SqlFieldsQuery("CREATE TABLE IF NOT EXISTS " + TBL + " (id INT
PRIMARY KEY, name VARCHAR)")
).getAll();
List> res = client.query(new SqlFieldsQuery("SELECT * FROM " +
TBL)).getAll();
assertNotNull(res);
assertEquals(0, res.size());
}
}
{code}
*Expected*
The test above should pass
*Actual*
java.util.NoSuchElementException
at java.util.ArrayList$Itr.next(ArrayList.java:862)
at
org.apache.ignite.internal.client.thin.ClientQueryCursor$1.next(ClientQueryCursor.java:87)
at
org.apache.ignite.internal.client.thin.ClientQueryCursor.getAll(ClientQueryCursor.java:45)
at
org.apache.ignite.client.FunctionalQueryTest.testGettingEmptyResultWhenQueryingEmptyTable(FunctionalQueryTest.java:171)
Reporter: Alexey Kukushkin
Assignee: Alexey Kukushkin
Fix For: 2.7
+*Reproducer*+
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-5551) Optimize service deployment assignments object
[ https://issues.apache.org/jira/browse/IGNITE-5551?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kukushkin updated IGNITE-5551: - Affects Version/s: (was: 1.7) 3.0 > Optimize service deployment assignments object > -- > > Key: IGNITE-5551 > URL: https://issues.apache.org/jira/browse/IGNITE-5551 > Project: Ignite > Issue Type: Improvement > Components: managed services >Affects Versions: 3.0 >Reporter: Alexey Goncharuk >Assignee: Alexey Kukushkin >Priority: Minor > Labels: iep-17 > Fix For: 2.7 > > > 1) The deployment assignment is stored using a map [node ID -> number of > assigned services]. However, this assignment is not very effective for cases > when service configuration is (maxPerCluster = 0, maxPerNode > 0), because in > this case, we can avoid assignment recalculation at all. The assignment for > this case may look like (eachNode=N). In this case, the assignment does not > change and we can effectively skip it during the reassign loop. > 2) We store zero assignment counters, which does not make sense at all - if > there are no service deployments for a node, there should be no corresponding > entry in the map at all. The size of assignments for (maxPerCluster > 0) > configurations is O(number of nodes in the cluster), but it should be > O(maxPerCluster). > 3) If an assignment did not change, we should not commit the assignment > transaction - this is redundant > 4) Perhaps, it also makes sense to calculate several assignments at once and > do a putAll commit instead of single puts - this should also decrease the > assignment calculation latency -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-5551) Optimize service deployment assignments object
[ https://issues.apache.org/jira/browse/IGNITE-5551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16570160#comment-16570160 ] Alexey Kukushkin commented on IGNITE-5551: -- Set Priority to Minor. This fix will most likely NOT be committed since there is an effort in progress to re-design service grid. When the re-design effort is complete, I will review the code, make sure the new code has no similar issue and close this ticket. > Optimize service deployment assignments object > -- > > Key: IGNITE-5551 > URL: https://issues.apache.org/jira/browse/IGNITE-5551 > Project: Ignite > Issue Type: Improvement > Components: managed services >Affects Versions: 3.0 >Reporter: Alexey Goncharuk >Assignee: Alexey Kukushkin >Priority: Minor > Labels: iep-17 > Fix For: 2.7 > > > 1) The deployment assignment is stored using a map [node ID -> number of > assigned services]. However, this assignment is not very effective for cases > when service configuration is (maxPerCluster = 0, maxPerNode > 0), because in > this case, we can avoid assignment recalculation at all. The assignment for > this case may look like (eachNode=N). In this case, the assignment does not > change and we can effectively skip it during the reassign loop. > 2) We store zero assignment counters, which does not make sense at all - if > there are no service deployments for a node, there should be no corresponding > entry in the map at all. The size of assignments for (maxPerCluster > 0) > configurations is O(number of nodes in the cluster), but it should be > O(maxPerCluster). > 3) If an assignment did not change, we should not commit the assignment > transaction - this is redundant > 4) Perhaps, it also makes sense to calculate several assignments at once and > do a putAll commit instead of single puts - this should also decrease the > assignment calculation latency -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-5551) Optimize service deployment assignments object
[ https://issues.apache.org/jira/browse/IGNITE-5551?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kukushkin updated IGNITE-5551: - Priority: Minor (was: Critical) > Optimize service deployment assignments object > -- > > Key: IGNITE-5551 > URL: https://issues.apache.org/jira/browse/IGNITE-5551 > Project: Ignite > Issue Type: Improvement > Components: managed services >Affects Versions: 1.7 >Reporter: Alexey Goncharuk >Assignee: Alexey Kukushkin >Priority: Minor > Labels: iep-17 > Fix For: 2.7 > > > 1) The deployment assignment is stored using a map [node ID -> number of > assigned services]. However, this assignment is not very effective for cases > when service configuration is (maxPerCluster = 0, maxPerNode > 0), because in > this case, we can avoid assignment recalculation at all. The assignment for > this case may look like (eachNode=N). In this case, the assignment does not > change and we can effectively skip it during the reassign loop. > 2) We store zero assignment counters, which does not make sense at all - if > there are no service deployments for a node, there should be no corresponding > entry in the map at all. The size of assignments for (maxPerCluster > 0) > configurations is O(number of nodes in the cluster), but it should be > O(maxPerCluster). > 3) If an assignment did not change, we should not commit the assignment > transaction - this is redundant > 4) Perhaps, it also makes sense to calculate several assignments at once and > do a putAll commit instead of single puts - this should also decrease the > assignment calculation latency -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-9194) Web Console: Refactor SVG icons support
[ https://issues.apache.org/jira/browse/IGNITE-9194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Konstantinov reassigned IGNITE-9194: -- Assignee: Alexey Kuznetsov (was: Pavel Konstantinov) > Web Console: Refactor SVG icons support > --- > > Key: IGNITE-9194 > URL: https://issues.apache.org/jira/browse/IGNITE-9194 > Project: Ignite > Issue Type: Task > Components: wizards >Reporter: Alexey Kuznetsov >Assignee: Alexey Kuznetsov >Priority: Major > Fix For: 2.7 > > > # Use latest svg-sprite-loader 3.9.0 > # Extract svg icons to separate web pack rule. > # add ''.icon" to all icons to make them distinct from other resources. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-9193) ML TF Integration: Python process still running after node sigkill shutdown
[ https://issues.apache.org/jira/browse/IGNITE-9193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Dmitriev reassigned IGNITE-9193: -- Assignee: Anton Dmitriev > ML TF Integration: Python process still running after node sigkill shutdown > --- > > Key: IGNITE-9193 > URL: https://issues.apache.org/jira/browse/IGNITE-9193 > Project: Ignite > Issue Type: Bug > Components: ml >Affects Versions: 2.7 >Reporter: Stepan Pilschikov >Assignee: Anton Dmitriev >Priority: Major > Labels: tf-integration > > 1. Running gird > 2. Fill caches with training data > 3. Run python script > 4. Gird run several python processes on each node > 5. Kill SIGNKILL one node > Processes restore on other nodes > Script is doing rerun > But python processes which was created by killed node are still running -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9194) Web Console: Refactor SVG icons support
[ https://issues.apache.org/jira/browse/IGNITE-9194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16570153#comment-16570153 ] Pavel Konstantinov commented on IGNITE-9194: Tested. > Web Console: Refactor SVG icons support > --- > > Key: IGNITE-9194 > URL: https://issues.apache.org/jira/browse/IGNITE-9194 > Project: Ignite > Issue Type: Task > Components: wizards >Reporter: Alexey Kuznetsov >Assignee: Pavel Konstantinov >Priority: Major > Fix For: 2.7 > > > # Use latest svg-sprite-loader 3.9.0 > # Extract svg icons to separate web pack rule. > # add ''.icon" to all icons to make them distinct from other resources. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (IGNITE-9194) Web Console: Refactor SVG icons support
[ https://issues.apache.org/jira/browse/IGNITE-9194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Konstantinov closed IGNITE-9194. -- > Web Console: Refactor SVG icons support > --- > > Key: IGNITE-9194 > URL: https://issues.apache.org/jira/browse/IGNITE-9194 > Project: Ignite > Issue Type: Task > Components: wizards >Reporter: Alexey Kuznetsov >Assignee: Alexey Kuznetsov >Priority: Major > Fix For: 2.7 > > > # Use latest svg-sprite-loader 3.9.0 > # Extract svg icons to separate web pack rule. > # add ''.icon" to all icons to make them distinct from other resources. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9194) Web Console: Refactor SVG icons support
[ https://issues.apache.org/jira/browse/IGNITE-9194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Konstantinov updated IGNITE-9194: --- Ignite Flags: (was: Docs Required) > Web Console: Refactor SVG icons support > --- > > Key: IGNITE-9194 > URL: https://issues.apache.org/jira/browse/IGNITE-9194 > Project: Ignite > Issue Type: Task > Components: wizards >Reporter: Alexey Kuznetsov >Assignee: Alexey Kuznetsov >Priority: Major > Fix For: 2.7 > > > # Use latest svg-sprite-loader 3.9.0 > # Extract svg icons to separate web pack rule. > # add ''.icon" to all icons to make them distinct from other resources. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9065) Gradient boosting optimization
[ https://issues.apache.org/jira/browse/IGNITE-9065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16570150#comment-16570150 ] ASF GitHub Bot commented on IGNITE-9065: GitHub user avplatonov opened a pull request: https://github.com/apache/ignite/pull/4486 IGNITE-9065: Indexes integration for GDB You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite IGNITE-9065 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4486.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #4486 commit e85afb7391ae9c189606685c1bdd73749ff761c9 Author: Alexey Platonov Date: 2018-08-03T16:30:38Z init comit commit bf515c5feb1d4e1de46c25a0d3e6a99edc142c72 Author: Alexey Platonov Date: 2018-08-06T12:05:55Z indexes reusing for gradient boosting commit 415edd5036e323af974e44b7669bbb7ea3dc7b60 Author: Alexey Platonov Date: 2018-08-06T12:08:29Z Merge branch 'master' of https://github.com/apache/ignite into IGNITE-9065 commit 2a6f461b6add763ce5e4b7e8d063a53dc2dc2293 Author: Alexey Platonov Date: 2018-08-06T12:26:21Z delete useless generics > Gradient boosting optimization > -- > > Key: IGNITE-9065 > URL: https://issues.apache.org/jira/browse/IGNITE-9065 > Project: Ignite > Issue Type: Improvement > Components: ml >Reporter: Yury Babak >Assignee: Alexey Platonov >Priority: Major > Fix For: 2.7 > > > We need to optimize GDB learning by reusing same index for learning decision > trees. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-5510) AssertionError: null instead of GridCacheReturnCompletableWrapper
[
https://issues.apache.org/jira/browse/IGNITE-5510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Pavlov reassigned IGNITE-5510:
--
Assignee: Semen Boikov
> AssertionError: null instead of GridCacheReturnCompletableWrapper
> -
>
> Key: IGNITE-5510
> URL: https://issues.apache.org/jira/browse/IGNITE-5510
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Reporter: Vladimir Ozerov
>Assignee: Semen Boikov
>Priority: Major
> Labels: MakeTeamcityGreenAgain, test-fail
> Fix For: 2.7
>
>
> Reproducer: {{CacheLateAffinityAssignmentTest#testNoForceKeysRequests}}
> Sample log:
> http://ci.ignite.apache.org/viewLog.html?buildId=666034&tab=buildResultsDiv&buildTypeId=Ignite20Tests_IgniteCache5
> Stack trace:
> {code}
> java.lang.AssertionError: null instead of GridCacheReturnCompletableWrapper
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxManager.removeTxReturn(IgniteTxManager.java:1040)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processDhtTxOnePhaseCommitAckRequest(IgniteTxHandler.java:1070)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.access$700(IgniteTxHandler.java:95)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$8.apply(IgniteTxHandler.java:183)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$8.apply(IgniteTxHandler.java:181)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1032)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:553)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:371)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:301)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:104)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:291)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1554)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1182)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:124)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1095)
> at
> org.apache.ignite.internal.util.StripedExecutor$Stripe.run(StripedExecutor.java:483)
> at java.lang.Thread.run(Thread.java:745)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-8297) TxRollbackOnTimeoutNearCacheTest.testRandomMixedTxConfigurations fails flakily
[ https://issues.apache.org/jira/browse/IGNITE-8297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov reassigned IGNITE-8297: -- Assignee: Semen Boikov > TxRollbackOnTimeoutNearCacheTest.testRandomMixedTxConfigurations fails > flakily > --- > > Key: IGNITE-8297 > URL: https://issues.apache.org/jira/browse/IGNITE-8297 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.4 >Reporter: Andrey Kuznetsov >Assignee: Semen Boikov >Priority: Major > Labels: MakeTeamcityGreenAgain > Fix For: 2.7 > > Attachments: 7770-new2.txt > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-6467) Ignite cache 6: new tests CacheExchangeMergeTest.testConcurrentStartServersAndClients() and testDelayExchangeMessages() have flaky junit assertion after cache get
[
https://issues.apache.org/jira/browse/IGNITE-6467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Pavlov reassigned IGNITE-6467:
--
Assignee: Semen Boikov
> Ignite cache 6: new tests
> CacheExchangeMergeTest.testConcurrentStartServersAndClients() and
> testDelayExchangeMessages() have flaky junit assertion after cache get
> --
>
> Key: IGNITE-6467
> URL: https://issues.apache.org/jira/browse/IGNITE-6467
> Project: Ignite
> Issue Type: Bug
>Reporter: Dmitriy Pavlov
>Assignee: Semen Boikov
>Priority: Major
> Labels: MakeTeamcityGreenAgain, Muted_test
> Fix For: 2.7
>
>
> Ignite cache 6: CacheExchangeMergeTest: 3 tests fails with probability >10%
> in master and in PRs
> IgniteCacheTestSuite6:
> CacheExchangeMergeTest.testConcurrentStartServersAndClients()
> IgniteCacheTestSuite6: CacheExchangeMergeTest.testDelayExchangeMessages()
> IgniteCacheTestSuite6: CacheExchangeMergeTest.testMergeServersFail1_2 (fail
> rate 22,6%)
> https://ci.ignite.apache.org/project.html?projectId=Ignite20Tests&testNameId=741151191800314619&tab=testDetails
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=-8990224019412265556&tab=testDetails
> latest failure from master
> https://ci.ignite.apache.org/viewLog.html?buildId=843261&tab=buildResultsDiv&buildTypeId=Ignite20Tests_IgniteCache6#testNameId741151191800314619
> {noformat}
> Invalid value [node=distributed.CacheExchangeMergeTest0, client=false,
> order=1, cache=c1] expected:<0> but was:
> at java.util.concurrent.FutureTask.report(FutureTask.java:122)
> at java.util.concurrent.FutureTask.get(FutureTask.java:188)
> at
> org.apache.ignite.internal.processors.cache.distributed.CacheExchangeMergeTest.checkNodeCaches(CacheExchangeMergeTest.java:1343)
> at
> org.apache.ignite.internal.processors.cache.distributed.CacheExchangeMergeTest.checkCaches0(CacheExchangeMergeTest.java:1213)
> at
> org.apache.ignite.internal.processors.cache.distributed.CacheExchangeMergeTest.checkCaches(CacheExchangeMergeTest.java:1195)
> at
> org.apache.ignite.internal.processors.cache.distributed.CacheExchangeMergeTest.concurrentStart(CacheExchangeMergeTest.java:446)
> at
> org.apache.ignite.internal.processors.cache.distributed.CacheExchangeMergeTest.testConcurrentStartServersAndClients(CacheExchangeMergeTest.java:414)
> Caused by: junit.framework.AssertionFailedError: Invalid value
> [node=distributed.CacheExchangeMergeTest0, client=false, order=1, cache=c1]
> expected:<0> but was:
> 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.TestCase.assertEquals(TestCase.java:244)
> at
> org.apache.ignite.internal.processors.cache.distributed.CacheExchangeMergeTest$16.run(CacheExchangeMergeTest.java:1312)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9196) SQL: Memory leak in MapNodeResults
[
https://issues.apache.org/jira/browse/IGNITE-9196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Mekhanikov updated IGNITE-9196:
-
Ignite Flags: (was: Docs Required)
> SQL: Memory leak in MapNodeResults
> --
>
> Key: IGNITE-9196
> URL: https://issues.apache.org/jira/browse/IGNITE-9196
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.6
>Reporter: Denis Mekhanikov
>Priority: Major
>
> When size of a SQL query result set is a multiple of {{Query#pageSize}}, then
> {{MapQueryResult}} is never closed and removed from {{MapNodeResults#res}}
> collection.
> The following code leads to OOME when run with 1Gb heap:
> {code:java}
> public class MemLeakRepro {
> public static void main(String[] args) {
> Ignition.start(getConfiguration("server"));
> try (Ignite client =
> Ignition.start(getConfiguration("client").setClientMode(true))) {
> IgniteCache cache = startPeopleCache(client);
> int pages = 10;
> int pageSize = 1024;
> for (int i = 0; i < pages * pageSize; i++) {
> Person p = new Person("Person #" + i, 25);
> cache.put(i, p);
> }
> for (int i = 0; i < 1_000_000; i++) {
> if (i % 1000 == 0)
> System.out.println("Select iteration #" + i);
> Query> qry = new SqlFieldsQuery("select * from
> people");
> qry.setPageSize(pageSize);
> QueryCursor> cursor = cache.query(qry);
> cursor.getAll();
> cursor.close();
> }
> }
> }
> private static IgniteConfiguration getConfiguration(String instanceName) {
> IgniteConfiguration igniteCfg = new IgniteConfiguration();
> igniteCfg.setIgniteInstanceName(instanceName);
> TcpDiscoverySpi discoSpi = new TcpDiscoverySpi();
> discoSpi.setIpFinder(new TcpDiscoveryVmIpFinder(true));
> return igniteCfg;
> }
> private static IgniteCache startPeopleCache(Ignite node)
> {
> CacheConfiguration cacheCfg = new
> CacheConfiguration<>("cache");
> QueryEntity qe = new QueryEntity(Integer.class, Person.class);
> qe.setTableName("people");
> cacheCfg.setQueryEntities(Collections.singleton(qe));
> cacheCfg.setSqlSchema("PUBLIC");
> return node.getOrCreateCache(cacheCfg);
> }
> public static class Person {
> @QuerySqlField
> private String name;
> @QuerySqlField
> private int age;
> public Person(String name, int age) {
> this.name = name;
> this.age = age;
> }
> }
> }
> {code}
>
> At the same time it works perfectly fine, when there are, for example,
> {{pages * (pageSize + 1)}} records in cache instead.
> The reason for it is that {{MapQueryResult#fetchNextPage(...)}} method
> doesn't return true, when the result set size is a multiple of the page size.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-9196) SQL: Memory leak in MapNodeResults
Denis Mekhanikov created IGNITE-9196:
Summary: SQL: Memory leak in MapNodeResults
Key: IGNITE-9196
URL: https://issues.apache.org/jira/browse/IGNITE-9196
Project: Ignite
Issue Type: Bug
Components: sql
Affects Versions: 2.6
Reporter: Denis Mekhanikov
When size of a SQL query result set is a multiple of {{Query#pageSize}}, then
{{MapQueryResult}} is never closed and removed from {{MapNodeResults#res}}
collection.
The following code leads to OOME when run with 1Gb heap:
{code:java}
public class MemLeakRepro {
public static void main(String[] args) {
Ignition.start(getConfiguration("server"));
try (Ignite client =
Ignition.start(getConfiguration("client").setClientMode(true))) {
IgniteCache cache = startPeopleCache(client);
int pages = 10;
int pageSize = 1024;
for (int i = 0; i < pages * pageSize; i++) {
Person p = new Person("Person #" + i, 25);
cache.put(i, p);
}
for (int i = 0; i < 1_000_000; i++) {
if (i % 1000 == 0)
System.out.println("Select iteration #" + i);
Query> qry = new SqlFieldsQuery("select * from people");
qry.setPageSize(pageSize);
QueryCursor> cursor = cache.query(qry);
cursor.getAll();
cursor.close();
}
}
}
private static IgniteConfiguration getConfiguration(String instanceName) {
IgniteConfiguration igniteCfg = new IgniteConfiguration();
igniteCfg.setIgniteInstanceName(instanceName);
TcpDiscoverySpi discoSpi = new TcpDiscoverySpi();
discoSpi.setIpFinder(new TcpDiscoveryVmIpFinder(true));
return igniteCfg;
}
private static IgniteCache startPeopleCache(Ignite node) {
CacheConfiguration cacheCfg = new
CacheConfiguration<>("cache");
QueryEntity qe = new QueryEntity(Integer.class, Person.class);
qe.setTableName("people");
cacheCfg.setQueryEntities(Collections.singleton(qe));
cacheCfg.setSqlSchema("PUBLIC");
return node.getOrCreateCache(cacheCfg);
}
public static class Person {
@QuerySqlField
private String name;
@QuerySqlField
private int age;
public Person(String name, int age) {
this.name = name;
this.age = age;
}
}
}
{code}
At the same time it works perfectly fine, when there are, for example, {{pages
* (pageSize + 1)}} records in cache instead.
The reason for it is that {{MapQueryResult#fetchNextPage(...)}} method doesn't
return true, when the result set size is a multiple of the page size.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9195) Split PDS 2 TC configuration.
[ https://issues.apache.org/jira/browse/IGNITE-9195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16570103#comment-16570103 ] Dmitriy Pavlov commented on IGNITE-9195: Just for you information, PDS 2 direct IO is more or less copy (subset) of tests running in Direct IO mode. In parallel with splitting of PDS 2 suite it will be reasonable to maintain split of Direct IO version of these tests. > Split PDS 2 TC configuration. > - > > Key: IGNITE-9195 > URL: https://issues.apache.org/jira/browse/IGNITE-9195 > Project: Ignite > Issue Type: Improvement >Reporter: Pavel Pereslegin >Assignee: Pavel Pereslegin >Priority: Major > Fix For: 2.7 > > > PDS 2 TC configuration takes too long time to complete (avg >2h) and should > be split into two. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9195) Split PDS 2 TC configuration.
[ https://issues.apache.org/jira/browse/IGNITE-9195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Pereslegin updated IGNITE-9195: - Fix Version/s: 2.7 > Split PDS 2 TC configuration. > - > > Key: IGNITE-9195 > URL: https://issues.apache.org/jira/browse/IGNITE-9195 > Project: Ignite > Issue Type: Improvement >Reporter: Pavel Pereslegin >Assignee: Pavel Pereslegin >Priority: Major > Fix For: 2.7 > > > PDS 2 TC configuration takes too long time to complete (avg >2h) and should > be split into two. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9195) Split PDS 2 TC configuration.
Pavel Pereslegin created IGNITE-9195: Summary: Split PDS 2 TC configuration. Key: IGNITE-9195 URL: https://issues.apache.org/jira/browse/IGNITE-9195 Project: Ignite Issue Type: Improvement Reporter: Pavel Pereslegin Assignee: Pavel Pereslegin PDS 2 TC configuration takes too long time to complete (avg >2h) and should be split into two. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8888) Possible data loss durring restaring of the nodes with empty pds
[ https://issues.apache.org/jira/browse/IGNITE-?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16570062#comment-16570062 ] Alexey Stelmak commented on IGNITE-: TC: https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_RunAll&branch_IgniteTests24Java8=pull%2F4485%2Fhead&tab=buildTypeStatusDiv > Possible data loss durring restaring of the nodes with empty pds > > > Key: IGNITE- > URL: https://issues.apache.org/jira/browse/IGNITE- > Project: Ignite > Issue Type: Bug > Components: persistence >Affects Versions: 2.4 >Reporter: Andrey Aleksandrov >Assignee: Alexey Stelmak >Priority: Major > Fix For: 2.7 > > Attachments: reproducer.java > > > Case: > 1)Start 3 data nodes and activate the cluster with cache with 1 backup and > PartitionLossPolicy.READ_ONLY_SAFE. > 2)Start client and add the data to your cache. Stop the client > 3)Stop DN2 and clear it pds and val > 4)Start DN2. Rebalance will start. > 5)During rebalance stop DN3. > 6)Start DN3. > At this moment some partitions from DN2 marked as LOST and cache size will be > less than expected. > 7) Run resetLostPartitions(caches). > Now all partitions on DN2 marked as OWNING but cache size is still less than > expected. > Workaround: > after step 6 do: > 7)force rebalance using deactivate/activate methods. > 8)wait for completion of rebalance > Now cache size is expected but some partitions from DN2 marked as LOST > 9)Run resetLostPartitions(caches). > Now cache size is OK and all partitions from DN2 marked as OWNING. > However, looks like without force rebalance we have data loss here. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8888) Possible data loss durring restaring of the nodes with empty pds
[ https://issues.apache.org/jira/browse/IGNITE-?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16570058#comment-16570058 ] Alexey Stelmak commented on IGNITE-: PR: https://github.com/apache/ignite/pull/4485 > Possible data loss durring restaring of the nodes with empty pds > > > Key: IGNITE- > URL: https://issues.apache.org/jira/browse/IGNITE- > Project: Ignite > Issue Type: Bug > Components: persistence >Affects Versions: 2.4 >Reporter: Andrey Aleksandrov >Assignee: Alexey Stelmak >Priority: Major > Fix For: 2.7 > > Attachments: reproducer.java > > > Case: > 1)Start 3 data nodes and activate the cluster with cache with 1 backup and > PartitionLossPolicy.READ_ONLY_SAFE. > 2)Start client and add the data to your cache. Stop the client > 3)Stop DN2 and clear it pds and val > 4)Start DN2. Rebalance will start. > 5)During rebalance stop DN3. > 6)Start DN3. > At this moment some partitions from DN2 marked as LOST and cache size will be > less than expected. > 7) Run resetLostPartitions(caches). > Now all partitions on DN2 marked as OWNING but cache size is still less than > expected. > Workaround: > after step 6 do: > 7)force rebalance using deactivate/activate methods. > 8)wait for completion of rebalance > Now cache size is expected but some partitions from DN2 marked as LOST > 9)Run resetLostPartitions(caches). > Now cache size is OK and all partitions from DN2 marked as OWNING. > However, looks like without force rebalance we have data loss here. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-9194) Web Console: Refactor SVG icons support
[ https://issues.apache.org/jira/browse/IGNITE-9194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov resolved IGNITE-9194. -- Resolution: Fixed Assignee: Pavel Konstantinov (was: Alexey Kuznetsov) Merged to master. [~pkonstantinov], Please do a smoke check, that icons are displayed correctly. > Web Console: Refactor SVG icons support > --- > > Key: IGNITE-9194 > URL: https://issues.apache.org/jira/browse/IGNITE-9194 > Project: Ignite > Issue Type: Task > Components: wizards >Reporter: Alexey Kuznetsov >Assignee: Pavel Konstantinov >Priority: Major > Fix For: 2.7 > > > # Use latest svg-sprite-loader 3.9.0 > # Extract svg icons to separate web pack rule. > # add ''.icon" to all icons to make them distinct from other resources. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9194) Web Console: Refactor SVG icons support
Alexey Kuznetsov created IGNITE-9194: Summary: Web Console: Refactor SVG icons support Key: IGNITE-9194 URL: https://issues.apache.org/jira/browse/IGNITE-9194 Project: Ignite Issue Type: Task Components: wizards Reporter: Alexey Kuznetsov Assignee: Alexey Kuznetsov Fix For: 2.7 # Use latest svg-sprite-loader 3.9.0 # Extract svg icons to separate web pack rule. # add ''.icon" to all icons to make them distinct from other resources. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-9191) Web Console: Cluster saved with empty name in special case
[ https://issues.apache.org/jira/browse/IGNITE-9191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16570032#comment-16570032 ] Pavel Konstantinov edited comment on IGNITE-9191 at 8/6/18 10:52 AM: - Test failed. I repeated steps from the description and got that the cluster with the same name already exists. # create the first cluster - ok # create the second cluster - failed. was (Author: pkonstantinov): Test failed. I repeated steps from the description and got that the cluster with the same name already exists. > Web Console: Cluster saved with empty name in special case > -- > > Key: IGNITE-9191 > URL: https://issues.apache.org/jira/browse/IGNITE-9191 > Project: Ignite > Issue Type: Task > Components: wizards >Reporter: Alexey Kuznetsov >Assignee: Alexey Kuznetsov >Priority: Major > Fix For: 2.7 > > Time Spent: 3h > Remaining Estimate: 0h > > # Create a new cluster, DON'T save > # Open Advanced screen > # Go to caches. > # Create cache. > # Save cache. > # Clsuter saved with EMPTY name (bug). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9191) Web Console: Cluster saved with empty name in special case
[ https://issues.apache.org/jira/browse/IGNITE-9191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16570032#comment-16570032 ] Pavel Konstantinov commented on IGNITE-9191: Test failed. I repeated steps from the description and got that the cluster with the same name already exists. > Web Console: Cluster saved with empty name in special case > -- > > Key: IGNITE-9191 > URL: https://issues.apache.org/jira/browse/IGNITE-9191 > Project: Ignite > Issue Type: Task > Components: wizards >Reporter: Alexey Kuznetsov >Assignee: Alexey Kuznetsov >Priority: Major > Fix For: 2.7 > > Time Spent: 3h > Remaining Estimate: 0h > > # Create a new cluster, DON'T save > # Open Advanced screen > # Go to caches. > # Create cache. > # Save cache. > # Clsuter saved with EMPTY name (bug). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9193) ML TF Integration: Python process still running after node sigkill shutdown
Stepan Pilschikov created IGNITE-9193: - Summary: ML TF Integration: Python process still running after node sigkill shutdown Key: IGNITE-9193 URL: https://issues.apache.org/jira/browse/IGNITE-9193 Project: Ignite Issue Type: Bug Components: ml Affects Versions: 2.7 Reporter: Stepan Pilschikov 1. Running gird 2. Fill caches with training data 3. Run python script 4. Gird run several python processes on each node 5. Kill SIGNKILL one node Processes restore on other nodes Script is doing rerun But python processes which was created by killed node are still running -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9183) Proper handling UUID columns, that are added by DDL.
[ https://issues.apache.org/jira/browse/IGNITE-9183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16570028#comment-16570028 ] Ivan Daschinskiy commented on IGNITE-9183: -- [TC build |https://mtcga.gridgain.com/pr.html?serverId=apache&suiteId=IgniteTests24Java8_RunAll&branchForTc=pull%2F4483%2Fhead&action=Latest] > Proper handling UUID columns, that are added by DDL. > > > Key: IGNITE-9183 > URL: https://issues.apache.org/jira/browse/IGNITE-9183 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.5, 2.6 >Reporter: Ivan Daschinskiy >Assignee: Ivan Daschinskiy >Priority: Major > Fix For: 2.7 > > > Currently, if we added new UUID columnt thru DDL, it is saved to schema as > byte[]. So it's impossible to use it with DML without placeholders and put > values thru cache api without converting UUID to byte[]. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8158) Missed cleanups if afterTestsStop throws exception
[
https://issues.apache.org/jira/browse/IGNITE-8158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolai Kulagin updated IGNITE-8158:
Attachment: StopAllGridsTest.java
> Missed cleanups if afterTestsStop throws exception
> --
>
> Key: IGNITE-8158
> URL: https://issues.apache.org/jira/browse/IGNITE-8158
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.4
>Reporter: Maxim Muzafarov
>Assignee: Nikolai Kulagin
>Priority: Minor
> Labels: newbie, test
> Fix For: 2.7
>
> Attachments: StopAllGridsTest.java
>
>
> Method {{afterTestsStopped}} might throw exception. Contibutor should provide
> solution for ensuring that all cleanups in {{tearDown}} method would be
> executed in this case.
> {code:java|title=GridAbstractTest.java}
> /** {@inheritDoc} */
> @Override protected void tearDown() throws Exception {
> ...
> try {
> afterTest();
> }
> finally {
> serializedObj.clear();
> if (isLastTest()) {
> ...
> afterTestsStopped();
> if (startGrid)
> G.stop(getTestIgniteInstanceName(), true);
> // Remove counters.
> tests.remove(getClass());
> // Remove resources cached in static, if any.
> GridClassLoaderCache.clear();
> U.clearClassCache();
> MarshallerExclusions.clearCache();
> BinaryEnumCache.clear();
> }
> Thread.currentThread().setContextClassLoader(clsLdr);
> clsLdr = null;
> cleanReferences();
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-9191) Web Console: Cluster saved with empty name in special case
[
https://issues.apache.org/jira/browse/IGNITE-9191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16569993#comment-16569993
]
Ilya Borisov edited comment on IGNITE-9191 at 8/6/18 10:09 AM:
---
[~kuaw26] to understand why this was happening, you first have to understand to
data flow of configuration edit forms: all cluster configuration edits are done
against a copy of config, which is stored under {{changes.cluster}} path in
store. This is done in order to share changes state across several forms. When
user creates a new cluster config, {{Clusters}} service generates an empty
config with default values, _but without a name_, this is the value that goes
into {{changes.cluster}}. The actual cluster name is assigned in
{{selectClusterToEdit}} selector, which is used only on basic/advanced cluster
screens and not on advanced entity edit screens. Because of all of the above,
when user saves new cache (or other entity) along with a new cluster config,
the value in {{changes.cluster}} does not have {{name}} property.
In order to fix the issue, I've updated the {{loadAndEditClusterEffect$}}
that's responsible for new cluster object (i.e. the one with default values)
creation so it assigns a unique name too. This will ensure that
{{changes.cluster}} always has a name.
was (Author: klaster_1):
[~kuaw26] to understand why this was happening, you first to understand to data
flow of configuration edit forms: all cluster configuration edits are done
against a copy of config, which is stored under {{changes.cluster}} in store.
This is done in order to share changes state across several forms. When user
creates a new cluster config, Cluster service generates an empty config with
default values, _but without name_, this is the value that goes into
{{changes.cluster}}. The actual cluster name is assigned in
{{selectClusterToEdit}} selector, which is used only on basic/advanced cluster
screens and not on advanced entity edit screens. Because of all of the above,
when user saves new cache (or other entity) along with a new cluster config,
the value in {{changes.cluster}} does not have {{name}} property.
In order to fix the issue, I've updated the {{loadAndEditClusterEffect$}}
that's responsible for new cluster object (i.e. the one with default values)
creation so it assigns a unique name too. This will ensure that
{{changes.cluster}} always has a name.
> Web Console: Cluster saved with empty name in special case
> --
>
> Key: IGNITE-9191
> URL: https://issues.apache.org/jira/browse/IGNITE-9191
> Project: Ignite
> Issue Type: Task
> Components: wizards
>Reporter: Alexey Kuznetsov
>Assignee: Alexey Kuznetsov
>Priority: Major
> Fix For: 2.7
>
>
> # Create a new cluster, DON'T save
> # Open Advanced screen
> # Go to caches.
> # Create cache.
> # Save cache.
> # Clsuter saved with EMPTY name (bug).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9191) Web Console: Cluster saved with empty name in special case
[ https://issues.apache.org/jira/browse/IGNITE-9191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16569996#comment-16569996 ] Ilya Borisov commented on IGNITE-9191: -- [~pkonstantinov] please test the branch. > Web Console: Cluster saved with empty name in special case > -- > > Key: IGNITE-9191 > URL: https://issues.apache.org/jira/browse/IGNITE-9191 > Project: Ignite > Issue Type: Task > Components: wizards >Reporter: Alexey Kuznetsov >Assignee: Alexey Kuznetsov >Priority: Major > Fix For: 2.7 > > > # Create a new cluster, DON'T save > # Open Advanced screen > # Go to caches. > # Create cache. > # Save cache. > # Clsuter saved with EMPTY name (bug). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9191) Web Console: Cluster saved with empty name in special case
[
https://issues.apache.org/jira/browse/IGNITE-9191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16569993#comment-16569993
]
Ilya Borisov commented on IGNITE-9191:
--
[~kuaw26] to understand why this was happening, you first to understand to data
flow of configuration edit forms: all cluster configuration edits are done
against a copy of config, which is stored under {{changes.cluster}} in store.
This is done in order to share changes state across several forms. When user
creates a new cluster config, Cluster service generates an empty config with
default values, _but without name_, this is the value that goes into
{{changes.cluster}}. The actual cluster name is assigned in
{{selectClusterToEdit}} selector, which is used only on basic/advanced cluster
screens and not on advanced entity edit screens. Because of all of the above,
when user saves new cache (or other entity) along with a new cluster config,
the value in {{changes.cluster}} does not have {{name}} property.
In order to fix the issue, I've updated the {{loadAndEditClusterEffect$}}
that's responsible for new cluster object (i.e. the one with default values)
creation so it assigns a unique name too. This will ensure that
{{changes.cluster}} always has a name.
> Web Console: Cluster saved with empty name in special case
> --
>
> Key: IGNITE-9191
> URL: https://issues.apache.org/jira/browse/IGNITE-9191
> Project: Ignite
> Issue Type: Task
> Components: wizards
>Reporter: Alexey Kuznetsov
>Assignee: Alexey Kuznetsov
>Priority: Major
> Fix For: 2.7
>
>
> # Create a new cluster, DON'T save
> # Open Advanced screen
> # Go to caches.
> # Create cache.
> # Save cache.
> # Clsuter saved with EMPTY name (bug).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-9191) Web Console: Cluster saved with empty name in special case
[ https://issues.apache.org/jira/browse/IGNITE-9191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16569969#comment-16569969 ] Ilya Borisov edited comment on IGNITE-9191 at 8/6/18 9:55 AM: -- [~kuaw26] please review, I'll explain the issue details shortly. was (Author: klaster_1): [~kuaw26] please review. > Web Console: Cluster saved with empty name in special case > -- > > Key: IGNITE-9191 > URL: https://issues.apache.org/jira/browse/IGNITE-9191 > Project: Ignite > Issue Type: Task > Components: wizards >Reporter: Alexey Kuznetsov >Assignee: Alexey Kuznetsov >Priority: Major > Fix For: 2.7 > > > # Create a new cluster, DON'T save > # Open Advanced screen > # Go to caches. > # Create cache. > # Save cache. > # Clsuter saved with EMPTY name (bug). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-9191) Web Console: Cluster saved with empty name in special case
[ https://issues.apache.org/jira/browse/IGNITE-9191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Borisov reassigned IGNITE-9191: Assignee: Alexey Kuznetsov (was: Ilya Borisov) [~kuaw26] please review. > Web Console: Cluster saved with empty name in special case > -- > > Key: IGNITE-9191 > URL: https://issues.apache.org/jira/browse/IGNITE-9191 > Project: Ignite > Issue Type: Task > Components: wizards >Reporter: Alexey Kuznetsov >Assignee: Alexey Kuznetsov >Priority: Major > Fix For: 2.7 > > > # Create a new cluster, DON'T save > # Open Advanced screen > # Go to caches. > # Create cache. > # Save cache. > # Clsuter saved with EMPTY name (bug). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9192) Dump statistics of processing IO messages.
Ivan Daschinskiy created IGNITE-9192: Summary: Dump statistics of processing IO messages. Key: IGNITE-9192 URL: https://issues.apache.org/jira/browse/IGNITE-9192 Project: Ignite Issue Type: Improvement Reporter: Ivan Daschinskiy Assignee: Ivan Daschinskiy When debugging various performance problem, it's crucial to understand how long and what messages are processing. When enabled, this statistics should be collected and dumped in log with predefined frequency. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9191) Web Console: Cluster saved with empty name in special case
[ https://issues.apache.org/jira/browse/IGNITE-9191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov updated IGNITE-9191: - Fix Version/s: 2.7 > Web Console: Cluster saved with empty name in special case > -- > > Key: IGNITE-9191 > URL: https://issues.apache.org/jira/browse/IGNITE-9191 > Project: Ignite > Issue Type: Task > Components: wizards >Reporter: Alexey Kuznetsov >Assignee: Ilya Borisov >Priority: Major > Fix For: 2.7 > > > # Create a new cluster, DON'T save > # Open Advanced screen > # Go to caches. > # Create cache. > # Save cache. > # Clsuter saved with EMPTY name (bug). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-5103) TcpDiscoverySpi ignores maxMissedClientHeartbeats property
[
https://issues.apache.org/jira/browse/IGNITE-5103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16569937#comment-16569937
]
Anton Kalashnikov edited comment on IGNITE-5103 at 8/6/18 9:29 AM:
---
Changes looks good for me. But various tests in SPI suit started to fail often
than usual. Perhaps we will need to change tests or maybe
clientFailureDetectionTimeout is incorrect.
https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_Spi&branch_IgniteTests24Java8=pull%2F4446%2Fhead&tab=buildTypeStatusDiv
[~ezhuravl], can do you check it?
was (Author: akalashnikov):
Changes looks good for me. But various tests in SPI suit started to fail often
than usual. Perhaps we will need to change tests or maybe
clientFailureDetectionTimeout is incorrect.
https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_Spi&branch_IgniteTests24Java8=pull%2F4446%2Fhead&tab=buildTypeStatusDiv
> TcpDiscoverySpi ignores maxMissedClientHeartbeats property
> --
>
> Key: IGNITE-5103
> URL: https://issues.apache.org/jira/browse/IGNITE-5103
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 1.9
>Reporter: Valentin Kulichenko
>Assignee: Evgenii Zhuravlev
>Priority: Blocker
> Fix For: 2.7
>
> Attachments: TcpDiscoveryClientSuspensionSelfTest.java
>
>
> Test scenario is the following:
> * Start one or more servers.
> * Start a client node.
> * Suspend client process using {{-SIGSTOP}} signal.
> * Wait for {{maxMissedClientHeartbeats*heartbeatFrequency}}.
> * Client node is expected to be removed from topology, but server nodes don't
> do that.
> Attached is the unit test reproducing the same by stopping the heartbeat
> sender thread on the client.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-5103) TcpDiscoverySpi ignores maxMissedClientHeartbeats property
[
https://issues.apache.org/jira/browse/IGNITE-5103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16569937#comment-16569937
]
Anton Kalashnikov commented on IGNITE-5103:
---
Changes looks good for me. But various tests in SPI suit started to fail often
than usual. Perhaps we will need to change tests or maybe
clientFailureDetectionTimeout is incorrect.
https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_Spi&branch_IgniteTests24Java8=pull%2F4446%2Fhead&tab=buildTypeStatusDiv
> TcpDiscoverySpi ignores maxMissedClientHeartbeats property
> --
>
> Key: IGNITE-5103
> URL: https://issues.apache.org/jira/browse/IGNITE-5103
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 1.9
>Reporter: Valentin Kulichenko
>Assignee: Evgenii Zhuravlev
>Priority: Blocker
> Fix For: 2.7
>
> Attachments: TcpDiscoveryClientSuspensionSelfTest.java
>
>
> Test scenario is the following:
> * Start one or more servers.
> * Start a client node.
> * Suspend client process using {{-SIGSTOP}} signal.
> * Wait for {{maxMissedClientHeartbeats*heartbeatFrequency}}.
> * Client node is expected to be removed from topology, but server nodes don't
> do that.
> Attached is the unit test reproducing the same by stopping the heartbeat
> sender thread on the client.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-7251) Remove term "fabric" from Ignite deliverables
[
https://issues.apache.org/jira/browse/IGNITE-7251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton Vinogradov reassigned IGNITE-7251:
Assignee: Anton Vinogradov (was: Peter Ivanov)
> Remove term "fabric" from Ignite deliverables
> -
>
> Key: IGNITE-7251
> URL: https://issues.apache.org/jira/browse/IGNITE-7251
> Project: Ignite
> Issue Type: Task
>Reporter: Denis Magda
>Assignee: Anton Vinogradov
>Priority: Blocker
> Labels: important
> Fix For: 2.7
>
>
> Apache Ignite binary releases still include “fabric” word in their names:
> https://ignite.apache.org/download.cgi#binaries
> For instance, this is a full name of the previous release -
> apache-ignite-fabric-2.3.0-bin.
> It’s a little oversight on our side because the project has not been
> positioned as a fabric for a while.
> Remove “fabric” from the name and have the binary releases named as -
> {{apache-ignite-\{version}-bin}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (IGNITE-9102) Remove support for IE11
[ https://issues.apache.org/jira/browse/IGNITE-9102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Konstantinov closed IGNITE-9102. -- Assignee: Alexey Kuznetsov (was: Pavel Konstantinov) > Remove support for IE11 > --- > > Key: IGNITE-9102 > URL: https://issues.apache.org/jira/browse/IGNITE-9102 > Project: Ignite > Issue Type: Task > Components: wizards >Reporter: Alexander Kalinin >Assignee: Alexey Kuznetsov >Priority: Major > Fix For: 2.7 > > > Internet Expolorer 11 is an obsolete browser that needs much development > efforts. > We should remove and suggest user to update if user opens web app from IE11. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9102) Remove support for IE11
[ https://issues.apache.org/jira/browse/IGNITE-9102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16569912#comment-16569912 ] Pavel Konstantinov commented on IGNITE-9102: Tested in master. > Remove support for IE11 > --- > > Key: IGNITE-9102 > URL: https://issues.apache.org/jira/browse/IGNITE-9102 > Project: Ignite > Issue Type: Task > Components: wizards >Reporter: Alexander Kalinin >Assignee: Pavel Konstantinov >Priority: Major > Fix For: 2.7 > > > Internet Expolorer 11 is an obsolete browser that needs much development > efforts. > We should remove and suggest user to update if user opens web app from IE11. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-9146) Analyse and improve code coverage in ML module
[
https://issues.apache.org/jira/browse/IGNITE-9146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16568663#comment-16568663
]
Oleg Ignatenko edited comment on IGNITE-9146 at 8/6/18 8:55 AM:
Further study of coverage reports revealed some dead code that needs to be
removed:
- class {{SmallTrainingDatasetSizeException}}. It was introduced per
IGNITE-6880 but the code that used this class was later changed to go without
it per IGNITE-7702
- class {{math.Precision}}. It was introduced (adopted from apache commons
math) per IGNITE-5012 but in later changes turned out of extremely low demand
(as of now only use is a private constant in {{AbstractLSQR}}). Per discussion
with [~amalykh] who is most involved in this code it is better to remove. (to
avoid confusion, note that there is another class with same name but in another
package: {{selection.scoring.metric.Precision}} - that one is to be kept)
- class {{Isomorphism}}. It was introduced in IGNITE-7322 with the intention to
maybe use it some time later as it implemented a concept that looked like
promising back then However in the further development need for it did not
appear and per discussion with author ([~amalykh]) it is currently better to
remove it.
was (Author: oignatenko):
Further study of coverage reports revealed some dead code that needs to be
removed:
- class {{SmallTrainingDatasetSizeException}}. It was introduced per
IGNITE-6880 but the code that used this class was later changed to go without
it per IGNITE-7702
- class {{math.Precision}}. It was introduced (adopted from apache commons
math) per IGNITE-5012 but in later changes turned out of extremely low demand
(as of now only use is a private constant in {{AbstractLSQR}}). Per discussion
with [~amalykh] who is most involved in this code it is better to remove. (to
avoid confusion, note that there is another class with same name but in another
package: {{selection.scoring.metric.Precision}} - that one is to be kept)
> Analyse and improve code coverage in ML module
> --
>
> Key: IGNITE-9146
> URL: https://issues.apache.org/jira/browse/IGNITE-9146
> Project: Ignite
> Issue Type: Task
> Components: ml
>Affects Versions: 2.6
>Reporter: Oleg Ignatenko
>Assignee: Oleg Ignatenko
>Priority: Major
> Fix For: 2.7
>
> Attachments: 20180731-ml-coverage.zip,
> 20180805.IgniteMLTestSuite.coverage.zip
>
>
> Run code coverage analysis, study results and add missing tests where needed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9122) Control.sh transactions utility not kill hang rollback transaction
[ https://issues.apache.org/jira/browse/IGNITE-9122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16569851#comment-16569851 ] Alexand Polyakov commented on IGNITE-9122: -- The reason for the suspended transaction: the place on one of the nodes has run out [WARN] [tcp-disco-msg-worker- # 2% DPL_GRID% DplGridNodeName%] [o.a.i.i.p.c.b.CacheObjectBinaryProcessorImpl] Failed to save metadata for typeId: 978611101; The exception was selected: there was no space left on the device > Control.sh transactions utility not kill hang rollback transaction > -- > > Key: IGNITE-9122 > URL: https://issues.apache.org/jira/browse/IGNITE-9122 > Project: Ignite > Issue Type: Bug >Reporter: Alexand Polyakov >Assignee: Alexei Scherbakov >Priority: Major > > Transaction for a long time in status rollback > After run "–tx xid XID kill" nothing happens. The transaction displayed in > list. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9187) Ignite spring data 2.7.0-SNAPSGOT not printing logs
[ https://issues.apache.org/jira/browse/IGNITE-9187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16569850#comment-16569850 ] Lokesh Sharma commented on IGNITE-9187: --- I just realized that the problem wasn't with logging but rather the annotations like "PostConstruct" and "Scheduled" are not working with Ignite Spring Data_2.0 > Ignite spring data 2.7.0-SNAPSGOT not printing logs > --- > > Key: IGNITE-9187 > URL: https://issues.apache.org/jira/browse/IGNITE-9187 > Project: Ignite > Issue Type: Bug > Components: spring >Affects Versions: 2.7 > Environment: Linux > Intelij Idea >Reporter: Lokesh Sharma >Priority: Major > > I built the "ignite-spring-data_2.0" from source to run it with Spring Boot > 2.0.2-RELEASE. The app is running fine but my spring application logging > stops working after a few seconds when I run the project. Also > "system.out.println" doesn't print anything on the console. > Here's my code: [https://github.com/lokeshh/ignite_with_spring_boot_2] > > I would be very grateful to the community if you fix this issue or help me > fix as this is the only that stands in my way to use ignite spring data with > spring boot 2. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9191) Web Console: Cluster saved with empty name in special case
Alexey Kuznetsov created IGNITE-9191: Summary: Web Console: Cluster saved with empty name in special case Key: IGNITE-9191 URL: https://issues.apache.org/jira/browse/IGNITE-9191 Project: Ignite Issue Type: Task Components: wizards Reporter: Alexey Kuznetsov Assignee: Ilya Borisov # Create a new cluster, DON'T save # Open Advanced screen # Go to caches. # Create cache. # Save cache. # Clsuter saved with EMPTY name (bug). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9190) Web console: align babel-env and "unsupported browsers" browser list
[ https://issues.apache.org/jira/browse/IGNITE-9190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov updated IGNITE-9190: - Ignite Flags: (was: Docs Required) > Web console: align babel-env and "unsupported browsers" browser list > > > Key: IGNITE-9190 > URL: https://issues.apache.org/jira/browse/IGNITE-9190 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Ilya Borisov >Assignee: Ilya Borisov >Priority: Minor > > IGNITE-9028 introduced a set of supported browsers because that's how > babel-env works and these versions are different from what's used in > browser-update config. I suggest to alias browser versions between babel-env > and browser-update. Unfortunately, browser-update does not support > [browserlist|https://github.com/browserslist/browserslist] notation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
