[jira] [Commented] (IGNITE-10017) Infinite loop with 3rd party persistency and no value for the key in the data store
[ https://issues.apache.org/jira/browse/IGNITE-10017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16672593#comment-16672593 ] Roman Shtykh commented on IGNITE-10017: --- Looks like flaky tests only. > Infinite loop with 3rd party persistency and no value for the key in the data > store > --- > > Key: IGNITE-10017 > URL: https://issues.apache.org/jira/browse/IGNITE-10017 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.6 >Reporter: Roman Shtykh >Assignee: Roman Shtykh >Priority: Critical > Attachments: IgniteGetBinaryKeyReadThroughSelfTest.java > > > Basically, it happens because _GridCacheAdapter#clearReservationsIfNeeded_ > fails to clear its local map. > > The problem occurs when _IgniteBiTuple_ is used as a key, but the value for > the key is not available. The execution path goes through > _GridDhtCacheAdapter#getDhtAllAsync_ -> _GridCacheAdapter#getAllAsync0_, for > instance if you have an affinityCall and execute get() from within. > > What happens is > # On get operation, keys are stored in the local map of _GridCacheAdapter_. > For this, _UserKeyCacheObjectImpl#prepareForCache_ creates > _KeyCacheObjectImpl_ with an unmarshalled val (BinaryObject), which is > different from that of _UserKeyCacheObjectImpl_ (val is BiTuple here) that is > used further as a key to retrieve the value from the map. > # _GridCacheAdapter#clearReservationsIfNeeded_ is called to clear the map > from keys for which values were not found. It uses _UserKeyCacheObjectImpl_ > to check the map, but can’t peek and remove even if the key is in the map > (hashes won’t match). The key is left in the map. > # The problem comes with the 2nd get: > - we check if the key is not in the map and create a new one, then BOOM! > loops while _putIfAbsent == null_ succeeds (but it won’t) > All these data types are ok – > [https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/binary/BinaryUtils.java#L212-L239] > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-9679) Document critical workers liveness checking implementation
[
https://issues.apache.org/jira/browse/IGNITE-9679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Prachi Garg reassigned IGNITE-9679:
---
Assignee: Artem Budnikov (was: Prachi Garg)
> Document critical workers liveness checking implementation
> --
>
> Key: IGNITE-9679
> URL: https://issues.apache.org/jira/browse/IGNITE-9679
> Project: Ignite
> Issue Type: Task
> Components: documentation
>Reporter: Andrey Kuznetsov
>Assignee: Artem Budnikov
>Priority: Major
> Fix For: 2.7
>
>
> Newly implemented critical worker thread liveness checks should be mentioned
> in Ignite Documentation. Brief description of the functionality follows.
> Ignite node has a number of critical worker threads that should be alive and
> responsive, otherwise node's health is not guaranteed. These threads monitor
> each other periodically and track two aspects for a thread being checked:
> - whether it's alive;
> - whether it updates its internal heartbeat timestamp.
> Whenever at least one of the above conditions is violated, checker thread
> logs the error and calls currently configured {{FailureHandler}}.
> {{IgniteConfiguration.SystemWorkerBlockedTimeout}} configuration property
> affects monitoring behavior. At runtime monitoring settings can be changed
> via {{FailureHandlingMxBean}}.
> By default, liveness checks are enabled, but blocked system worker detection
> will not lead to failure handler invocation, see
> {{FailureProcessor#getDefaultFailureHandler}} .
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9679) Document critical workers liveness checking implementation
[
https://issues.apache.org/jira/browse/IGNITE-9679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16672441#comment-16672441
]
Prachi Garg commented on IGNITE-9679:
-
[~Artem Budnikov], Is failure handler called under two circumstances - either
there is critical failure or there is a critical worker that is not
operational? If so, then what is the difference in configuration for Failure
Handler section and Critical Workers Health Check section?
> Document critical workers liveness checking implementation
> --
>
> Key: IGNITE-9679
> URL: https://issues.apache.org/jira/browse/IGNITE-9679
> Project: Ignite
> Issue Type: Task
> Components: documentation
>Reporter: Andrey Kuznetsov
>Assignee: Prachi Garg
>Priority: Major
> Fix For: 2.7
>
>
> Newly implemented critical worker thread liveness checks should be mentioned
> in Ignite Documentation. Brief description of the functionality follows.
> Ignite node has a number of critical worker threads that should be alive and
> responsive, otherwise node's health is not guaranteed. These threads monitor
> each other periodically and track two aspects for a thread being checked:
> - whether it's alive;
> - whether it updates its internal heartbeat timestamp.
> Whenever at least one of the above conditions is violated, checker thread
> logs the error and calls currently configured {{FailureHandler}}.
> {{IgniteConfiguration.SystemWorkerBlockedTimeout}} configuration property
> affects monitoring behavior. At runtime monitoring settings can be changed
> via {{FailureHandlingMxBean}}.
> By default, liveness checks are enabled, but blocked system worker detection
> will not lead to failure handler invocation, see
> {{FailureProcessor#getDefaultFailureHandler}} .
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10017) Infinite loop with 3rd party persistency and no value for the key in the data store
[ https://issues.apache.org/jira/browse/IGNITE-10017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Shtykh updated IGNITE-10017: -- Description: Basically, it happens because _GridCacheAdapter#clearReservationsIfNeeded_ fails to clear its local map. The problem occurs when _IgniteBiTuple_ is used as a key, but the value for the key is not available. The execution path goes through _GridDhtCacheAdapter#getDhtAllAsync_ -> _GridCacheAdapter#getAllAsync0_, for instance if you have an affinityCall and execute get() from within. What happens is # On get operation, keys are stored in the local map of _GridCacheAdapter_. For this, _UserKeyCacheObjectImpl#prepareForCache_ creates _KeyCacheObjectImpl_ with an unmarshalled val (BinaryObject), which is different from that of _UserKeyCacheObjectImpl_ (val is BiTuple here) that is used further as a key to retrieve the value from the map. # _GridCacheAdapter#clearReservationsIfNeeded_ is called to clear the map from keys for which values were not found. It uses _UserKeyCacheObjectImpl_ to check the map, but can’t peek and remove even if the key is in the map (hashes won’t match). The key is left in the map. # The problem comes with the 2nd get: - we check if the key is not in the map and create a new one, then BOOM! loops while _putIfAbsent == null_ succeeds (but it won’t) All these data types are ok – [https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/binary/BinaryUtils.java#L212-L239] was: Basically, it happens because _GridCacheAdapter#clearReservationsIfNeeded_ fails to clear its local map. The problem occurs when _withKeepBinary_ is set and _IgniteBiTuple_ is used as a key, but the value for the key is not available. The execution path goes through _GridDhtCacheAdapter#getDhtAllAsync_ -> _GridCacheAdapter#getAllAsync0_, for instance if you have an affinityCall and execute get() from within. What happens is # On get operation, keys are stored in the local map of _GridCacheAdapter_. For this, _UserKeyCacheObjectImpl#prepareForCache_ creates _KeyCacheObjectImpl_ with an unmarshalled val (BinaryObject), which is different from that of _UserKeyCacheObjectImpl_ (val is BiTuple here) that is used further as a key to retrieve the value from the map. # _GridCacheAdapter#clearReservationsIfNeeded_ is called to clear the map from keys for which values were not found. It uses _UserKeyCacheObjectImpl_ to check the map, but can’t peek and remove even if the key is in the map (hashes won’t match). The key is left in the map. # The problem comes with the 2nd get: - we check if the key is not in the map and create a new one, then BOOM! loops while _putIfAbsent == null_ succeeds (but it won’t) All these data types are ok – [https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/binary/BinaryUtils.java#L212-L239] > Infinite loop with 3rd party persistency and no value for the key in the data > store > --- > > Key: IGNITE-10017 > URL: https://issues.apache.org/jira/browse/IGNITE-10017 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.6 >Reporter: Roman Shtykh >Assignee: Roman Shtykh >Priority: Critical > Attachments: IgniteGetBinaryKeyReadThroughSelfTest.java > > > Basically, it happens because _GridCacheAdapter#clearReservationsIfNeeded_ > fails to clear its local map. > > The problem occurs when _IgniteBiTuple_ is used as a key, but the value for > the key is not available. The execution path goes through > _GridDhtCacheAdapter#getDhtAllAsync_ -> _GridCacheAdapter#getAllAsync0_, for > instance if you have an affinityCall and execute get() from within. > > What happens is > # On get operation, keys are stored in the local map of _GridCacheAdapter_. > For this, _UserKeyCacheObjectImpl#prepareForCache_ creates > _KeyCacheObjectImpl_ with an unmarshalled val (BinaryObject), which is > different from that of _UserKeyCacheObjectImpl_ (val is BiTuple here) that is > used further as a key to retrieve the value from the map. > # _GridCacheAdapter#clearReservationsIfNeeded_ is called to clear the map > from keys for which values were not found. It uses _UserKeyCacheObjectImpl_ > to check the map, but can’t peek and remove even if the key is in the map > (hashes won’t match). The key is left in the map. > # The problem comes with the 2nd get: > - we check if the key is not in the map and create a new one, then BOOM! > loops while _putIfAbsent == null_ succeeds (but it won’t) > All these data types are ok – > [https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/binary/BinaryUtils.java#L212-L239] > -- This
[jira] [Updated] (IGNITE-10017) Infinite loop with 3rd party persistency and no value for the key in the data store
[ https://issues.apache.org/jira/browse/IGNITE-10017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Shtykh updated IGNITE-10017: -- Summary: Infinite loop with 3rd party persistency and no value for the key in the data store (was: Infinite loop with 3rd party persistency, keepBinary and no value for the key) > Infinite loop with 3rd party persistency and no value for the key in the data > store > --- > > Key: IGNITE-10017 > URL: https://issues.apache.org/jira/browse/IGNITE-10017 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.6 >Reporter: Roman Shtykh >Assignee: Roman Shtykh >Priority: Critical > Attachments: IgniteGetBinaryKeyReadThroughSelfTest.java > > > Basically, it happens because _GridCacheAdapter#clearReservationsIfNeeded_ > fails to clear its local map. > > The problem occurs when _withKeepBinary_ is set and _IgniteBiTuple_ is used > as a key, but the value for the key is not available. The execution path goes > through _GridDhtCacheAdapter#getDhtAllAsync_ -> > _GridCacheAdapter#getAllAsync0_, for instance if you have an affinityCall and > execute get() from within. > > What happens is > # On get operation, keys are stored in the local map of _GridCacheAdapter_. > For this, _UserKeyCacheObjectImpl#prepareForCache_ creates > _KeyCacheObjectImpl_ with an unmarshalled val (BinaryObject), which is > different from that of _UserKeyCacheObjectImpl_ (val is BiTuple here) that is > used further as a key to retrieve the value from the map. > # _GridCacheAdapter#clearReservationsIfNeeded_ is called to clear the map > from keys for which values were not found. It uses _UserKeyCacheObjectImpl_ > to check the map, but can’t peek and remove even if the key is in the map > (hashes won’t match). The key is left in the map. > # The problem comes with the 2nd get: > - we check if the key is not in the map and create a new one, then BOOM! > loops while _putIfAbsent == null_ succeeds (but it won’t) > All these data types are ok – > [https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/binary/BinaryUtils.java#L212-L239] > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-9828) MVCC: Continuous query failover.
[
https://issues.apache.org/jira/browse/IGNITE-9828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16672206#comment-16672206
]
Roman Kondakov edited comment on IGNITE-9828 at 11/1/18 9:11 PM:
-
[~vozerov], I made a fix for these issues:
p.1, p.2, p.3, p.4, p.5 - done.
p.6 - I made a solution described in p.5 - synchronous execution for small
system pools, and parallel for the big ones.
[~vozerov], [~gvvinblade], TC run is OK, please review.
was (Author: rkondakov):
[~vozerov], I made a fix for these issues:
p.1, p.2, p.3, p.4, p.5 - done.
p.6 - I made a solution described in p.4 - synchronous execution for small
system pools, and parallel for the big ones.
[~vozerov], [~gvvinblade], TC run is OK, please review.
> MVCC: Continuous query failover.
>
>
> Key: IGNITE-9828
> URL: https://issues.apache.org/jira/browse/IGNITE-9828
> Project: Ignite
> Issue Type: Task
> Components: mvcc
>Reporter: Roman Kondakov
>Assignee: Roman Kondakov
>Priority: Major
> Fix For: 2.7
>
>
> We need to implement failover procedure for CQ with MVCC caches. Thoughts:
> * CQ failover tests should be adopted for mvcc scenarios. See
> {{IgniteCacheQuerySelfTestSuite4}}
> * We need to ensure the correctness of CQ and partition counters consistency
> in cases when some of TX participants are in prepared state and others are
> marked as rollback only. It looks like it doesn't work properly now.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9828) MVCC: Continuous query failover.
[
https://issues.apache.org/jira/browse/IGNITE-9828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16672206#comment-16672206
]
Roman Kondakov commented on IGNITE-9828:
[~vozerov], I made a fix for these issues:
p.1, p.2, p.3, p.4, p.5 - done.
p.6 - I made a solution described in p.4 - synchronous execution for small
system pools, and parallel for the big ones.
[~vozerov], [~gvvinblade], TC run is OK, please review.
> MVCC: Continuous query failover.
>
>
> Key: IGNITE-9828
> URL: https://issues.apache.org/jira/browse/IGNITE-9828
> Project: Ignite
> Issue Type: Task
> Components: mvcc
>Reporter: Roman Kondakov
>Assignee: Roman Kondakov
>Priority: Major
> Fix For: 2.7
>
>
> We need to implement failover procedure for CQ with MVCC caches. Thoughts:
> * CQ failover tests should be adopted for mvcc scenarios. See
> {{IgniteCacheQuerySelfTestSuite4}}
> * We need to ensure the correctness of CQ and partition counters consistency
> in cases when some of TX participants are in prepared state and others are
> marked as rollback only. It looks like it doesn't work properly now.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9828) MVCC: Continuous query failover.
[
https://issues.apache.org/jira/browse/IGNITE-9828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16672192#comment-16672192
]
Ignite TC Bot commented on IGNITE-9828:
---
{panel:title=Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Cache 8{color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=2221257]]
* IgniteCacheTestSuite8: GridCachePreloadingEvictionsSelfTest.testEvictions -
0,0% fails in last 100 master runs.
{panel}
[TeamCity Run All
Results|http://ci.ignite.apache.org/viewLog.html?buildId=2221287buildTypeId=IgniteTests24Java8_RunAll]
> MVCC: Continuous query failover.
>
>
> Key: IGNITE-9828
> URL: https://issues.apache.org/jira/browse/IGNITE-9828
> Project: Ignite
> Issue Type: Task
> Components: mvcc
>Reporter: Roman Kondakov
>Assignee: Roman Kondakov
>Priority: Major
> Fix For: 2.7
>
>
> We need to implement failover procedure for CQ with MVCC caches. Thoughts:
> * CQ failover tests should be adopted for mvcc scenarios. See
> {{IgniteCacheQuerySelfTestSuite4}}
> * We need to ensure the correctness of CQ and partition counters consistency
> in cases when some of TX participants are in prepared state and others are
> marked as rollback only. It looks like it doesn't work properly now.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10118) JDBC v2: metadata.getSchemas returns cache names instead of schema names
Pavel Kuznetsov created IGNITE-10118:
Summary: JDBC v2: metadata.getSchemas returns cache names instead
of schema names
Key: IGNITE-10118
URL: https://issues.apache.org/jira/browse/IGNITE-10118
Project: Ignite
Issue Type: Bug
Reporter: Pavel Kuznetsov
jdbc v2 returns list of cache names instead of list of schemas.
It is correct only if we have a cache and table created in it using cache API.
If we create tables using ddl we expect to see "PUBLIC" schema name in results
of {{connection.getMetadata().getSchemas()}} not "SQL_PUBLIC_TABLENAME"
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10118) JDBC v2: metadata.getSchemas returns cache names instead of schema names
[
https://issues.apache.org/jira/browse/IGNITE-10118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Kuznetsov updated IGNITE-10118:
-
Affects Version/s: 2.6
> JDBC v2: metadata.getSchemas returns cache names instead of schema names
>
>
> Key: IGNITE-10118
> URL: https://issues.apache.org/jira/browse/IGNITE-10118
> Project: Ignite
> Issue Type: Bug
> Components: jdbc, sql
>Affects Versions: 2.6
>Reporter: Pavel Kuznetsov
>Priority: Major
>
> jdbc v2 returns list of cache names instead of list of schemas.
> It is correct only if we have a cache and table created in it using cache API.
> If we create tables using ddl we expect to see "PUBLIC" schema name in
> results of {{connection.getMetadata().getSchemas()}} not
> "SQL_PUBLIC_TABLENAME"
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10118) JDBC v2: metadata.getSchemas returns cache names instead of schema names
[
https://issues.apache.org/jira/browse/IGNITE-10118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Kuznetsov updated IGNITE-10118:
-
Component/s: sql
jdbc
> JDBC v2: metadata.getSchemas returns cache names instead of schema names
>
>
> Key: IGNITE-10118
> URL: https://issues.apache.org/jira/browse/IGNITE-10118
> Project: Ignite
> Issue Type: Bug
> Components: jdbc, sql
>Affects Versions: 2.6
>Reporter: Pavel Kuznetsov
>Priority: Major
>
> jdbc v2 returns list of cache names instead of list of schemas.
> It is correct only if we have a cache and table created in it using cache API.
> If we create tables using ddl we expect to see "PUBLIC" schema name in
> results of {{connection.getMetadata().getSchemas()}} not
> "SQL_PUBLIC_TABLENAME"
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9849) Remove invalid builds from the selection
[
https://issues.apache.org/jira/browse/IGNITE-9849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16672068#comment-16672068
]
ASF GitHub Bot commented on IGNITE-9849:
asfgit closed pull request #57: IGNITE-9849 Refactor Master trends
URL: https://github.com/apache/ignite-teamcity-bot/pull/57
This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:
As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):
diff --git
a/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/db/DbMigrations.java
b/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/db/DbMigrations.java
index 824dc4a3..121f895e 100644
---
a/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/db/DbMigrations.java
+++
b/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/db/DbMigrations.java
@@ -66,6 +66,8 @@
private static final String BUILD_STATISTICS = "buildStatistics";
+private static final String BUILD_CONDITIONS_CACHE_NAME =
"buildConditions";
+
public static final String TESTS_COUNT_7700 = ",count:7700";
//V1 caches, 1024 parts
@@ -407,6 +409,7 @@ public void dataMigration(
applyDestroyIgnCacheMigration(TESTS);
applyDestroyIgnCacheMigration(STAT);
applyDestroyIgnCacheMigration(BUILD_STATISTICS);
+applyDestroyIgnCacheMigration(BUILD_CONDITIONS_CACHE_NAME);
applyDestroyCacheMigration(TEAMCITY_BUILD_CACHE_NAME_OLD,
TEAMCITY_BUILD_CACHE_NAME_OLD);
}
diff --git
a/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/teamcity/ignited/BuildRefCompacted.java
b/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/teamcity/ignited/BuildRefCompacted.java
index a3aff88e..a0f6d369 100644
---
a/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/teamcity/ignited/BuildRefCompacted.java
+++
b/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/teamcity/ignited/BuildRefCompacted.java
@@ -140,7 +140,7 @@ public int branchName() {
}
/** */
-private int status() {
+public int status() {
return status;
}
diff --git
a/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/teamcity/ignited/BuildRefDao.java
b/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/teamcity/ignited/BuildRefDao.java
index 0d7467a9..8a9a2643 100644
---
a/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/teamcity/ignited/BuildRefDao.java
+++
b/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/teamcity/ignited/BuildRefDao.java
@@ -34,6 +34,7 @@
import org.apache.ignite.ci.di.AutoProfiling;
import org.apache.ignite.ci.di.cache.GuavaCached;
import org.apache.ignite.ci.tcmodel.hist.BuildRef;
+import org.apache.ignite.ci.teamcity.ignited.fatbuild.FatBuildCompacted;
import org.apache.ignite.configuration.CacheConfiguration;
import org.apache.ignite.internal.util.GridIntList;
import org.jetbrains.annotations.NotNull;
diff --git
a/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/teamcity/ignited/ITeamcityIgnited.java
b/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/teamcity/ignited/ITeamcityIgnited.java
index cfdaa2eb..3e69094d 100644
---
a/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/teamcity/ignited/ITeamcityIgnited.java
+++
b/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/teamcity/ignited/ITeamcityIgnited.java
@@ -17,9 +17,10 @@
package org.apache.ignite.ci.teamcity.ignited;
import java.util.Collection;
+import java.util.Date;
import java.util.List;
import javax.annotation.Nullable;
-import org.apache.ignite.ci.tcbot.condition.BuildCondition;
+import org.apache.ignite.ci.teamcity.ignited.buildcondition.BuildCondition;
import org.apache.ignite.ci.tcmodel.hist.BuildRef;
import org.apache.ignite.ci.tcmodel.result.Build;
import org.apache.ignite.ci.teamcity.ignited.change.ChangeCompacted;
@@ -40,7 +41,7 @@
public String host();
/**
- * Retun all builds for branch and suite, without relation to its status.
+ * Return all builds for branch and suite, without relation to its status.
*
* @param buildTypeId Build type identifier.
* @param branchName Branch name.
@@ -50,7 +51,6 @@
@Nullable String buildTypeId,
@Nullable String branchName);
-
/**
* Retun all builds for branch and suite, without relation to its status.
*
@@ -62,6 +62,21 @@
@Nullable String buildTypeId,
@Nullable String branchName);
+/**
+ * Return all builds for branch and suite with finish status.
+ *
+ * @param buildTypeId Build type identifier.
+ * @param branchName Branch name.
+ * @param sinceDate Since date.
+ * @param untilDate Until date.
+ * @return list of builds in history in finish status.
+ */
+public List
[jira] [Updated] (IGNITE-4206) .NET: ADO.NET Data Provider
[ https://issues.apache.org/jira/browse/IGNITE-4206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-4206: --- Description: Implement ADO.NET Data Provider that works with Ignite cache See https://docs.microsoft.com/en-us/dotnet/api/system.data.common.dbproviderfactories?view=netframework-4.7.2 was:Implement ADO.NET Data Provider that works with Ignite cache > .NET: ADO.NET Data Provider > --- > > Key: IGNITE-4206 > URL: https://issues.apache.org/jira/browse/IGNITE-4206 > Project: Ignite > Issue Type: New Feature > Components: platforms >Reporter: Pavel Tupitsyn >Priority: Major > Labels: .NET > > Implement ADO.NET Data Provider that works with Ignite cache > See > https://docs.microsoft.com/en-us/dotnet/api/system.data.common.dbproviderfactories?view=netframework-4.7.2 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9420) Move logical recovery phase outside of PME
[ https://issues.apache.org/jira/browse/IGNITE-9420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16671901#comment-16671901 ] ASF GitHub Bot commented on IGNITE-9420: Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/5067 > Move logical recovery phase outside of PME > -- > > Key: IGNITE-9420 > URL: https://issues.apache.org/jira/browse/IGNITE-9420 > Project: Ignite > Issue Type: Improvement > Components: cache >Affects Versions: 2.5 >Reporter: Pavel Kovalenko >Assignee: Pavel Kovalenko >Priority: Major > Labels: cache > Fix For: 2.8 > > > Currently, we perform logical recovery in PME here > org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager#restoreState > We should move logical recovery before discovery manager will start. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9970) Add ability to set nodeId for VisorIdleVerifyDumpTask executed from ./control.sh --host HOST --cache idle_verify
[
https://issues.apache.org/jira/browse/IGNITE-9970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16671886#comment-16671886
]
Ignite TC Bot commented on IGNITE-9970:
---
{panel:title=No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity Run All
Results|http://ci.ignite.apache.org/viewLog.html?buildId=2213318buildTypeId=IgniteTests24Java8_RunAll]
> Add ability to set nodeId for VisorIdleVerifyDumpTask executed from
> ./control.sh --host HOST --cache idle_verify
>
>
> Key: IGNITE-9970
> URL: https://issues.apache.org/jira/browse/IGNITE-9970
> Project: Ignite
> Issue Type: Improvement
>Reporter: Pavel Voronkin
>Assignee: Alexey Stelmak
>Priority: Major
>
> --cache idle_verify sets null nodeId on invocation of
> private R executeTaskByNameOnNode(GridClient client, String taskClsName,
> Object taskArgs, UUID nodeId
> ) throws GridClientException {
>
> Which causes reduce phase to be assigned on random node, we want to dump
> results on particular node.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10117) Node is mistakenly excluded from history suppliers preventing historical rebalance.
Alexei Scherbakov created IGNITE-10117:
--
Summary: Node is mistakenly excluded from history suppliers
preventing historical rebalance.
Key: IGNITE-10117
URL: https://issues.apache.org/jira/browse/IGNITE-10117
Project: Ignite
Issue Type: Bug
Reporter: Alexei Scherbakov
Fix For: 2.8
This is because
org.apache.ignite.internal.processors.cache.persistence.IgniteCacheDatabaseSharedManager#reserveHistoryForExchange
is called before
org.apache.ignite.internal.processors.cache.persistence.IgniteCacheDatabaseSharedManager#beforeExchange,
which restores correct partition state.
{noformat}
public void testHistory() throws Exception {
IgniteEx crd = startGrid(0);
startGrid(1);
crd.cluster().active(true);
awaitPartitionMapExchange();
int part = 0;
List keys = loadDataToPartition(part, DEFAULT_CACHE_NAME, 100,
0, 1);
forceCheckpoint(); // Prevent IGNITE-10088
stopAllGrids();
awaitPartitionMapExchange();
List keys1 = loadDataToPartition(part, DEFAULT_CACHE_NAME,
100, 100, 1);
startGrid(0);
startGrid(1);
awaitPartitionMapExchange(); // grid0 will not provide history.
}
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9897) Quering with PDO returns null for all column values except the 1st one
[
https://issues.apache.org/jira/browse/IGNITE-9897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16671856#comment-16671856
]
Igor Sapego commented on IGNITE-9897:
-
Attached a unixOdbc.log, and odbc.log showing that unixOdbc Driver Manager
passes {{SQLFetchScroll}} calls as {{SQLFetch}} and rejecting {{SQLGetData}}
calls without any notifications to a driver. I'm going to investigate unixOdbc
sources to find out the reason of this behaviour.
> Quering with PDO returns null for all column values except the 1st one
> --
>
> Key: IGNITE-9897
> URL: https://issues.apache.org/jira/browse/IGNITE-9897
> Project: Ignite
> Issue Type: Bug
> Components: odbc
>Affects Versions: 2.6
> Environment: CentOS
>Reporter: Roman Shtykh
>Assignee: Igor Sapego
>Priority: Major
> Attachments: odbc.log, phpPDO2.out, phpPdo.out, unixOdbc.log
>
>
> Using _odbc_connect_ returns all column values, but with _PDO_ only the 1st
> one – all the rest are null.
> Reproduced on CentOS.
> # Start a server node with Ignite CPP
> # Run odbc-example (which will create two tables)
> # Run a simple PHP script
> {code:php}
> try {
> echo PHP_EOL,PHP_EOL,"# Using PDO",PHP_EOL;
> $dbh = new PDO('odbc:ApacheIgnite');
> $dbh->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
> $sql = 'SELECT * FROM "Person".Person';
> $data = $dbh->query($sql);
> foreach($data as $row) {
> var_export($row);
> }
> echo PHP_EOL,PHP_EOL,"# Using odbc_*( ) Functions",PHP_EOL;
>
> $conn = odbc_connect('ApacheIgnite','','');
> $rs = odbc_exec($conn, $sql);
>
> while($row = odbc_fetch_array($rs)) {
> var_export($row);
> }
>
> } catch (PDOException $e) {
> print "Error!: " . $e->getMessage() . "\n";
> die();
> }
> ?>
> {code}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9897) Quering with PDO returns null for all column values except the 1st one
[
https://issues.apache.org/jira/browse/IGNITE-9897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Sapego updated IGNITE-9897:
Attachment: odbc.log
unixOdbc.log
> Quering with PDO returns null for all column values except the 1st one
> --
>
> Key: IGNITE-9897
> URL: https://issues.apache.org/jira/browse/IGNITE-9897
> Project: Ignite
> Issue Type: Bug
> Components: odbc
>Affects Versions: 2.6
> Environment: CentOS
>Reporter: Roman Shtykh
>Assignee: Igor Sapego
>Priority: Major
> Attachments: odbc.log, phpPDO2.out, phpPdo.out, unixOdbc.log
>
>
> Using _odbc_connect_ returns all column values, but with _PDO_ only the 1st
> one – all the rest are null.
> Reproduced on CentOS.
> # Start a server node with Ignite CPP
> # Run odbc-example (which will create two tables)
> # Run a simple PHP script
> {code:php}
> try {
> echo PHP_EOL,PHP_EOL,"# Using PDO",PHP_EOL;
> $dbh = new PDO('odbc:ApacheIgnite');
> $dbh->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
> $sql = 'SELECT * FROM "Person".Person';
> $data = $dbh->query($sql);
> foreach($data as $row) {
> var_export($row);
> }
> echo PHP_EOL,PHP_EOL,"# Using odbc_*( ) Functions",PHP_EOL;
>
> $conn = odbc_connect('ApacheIgnite','','');
> $rs = odbc_exec($conn, $sql);
>
> while($row = odbc_fetch_array($rs)) {
> var_export($row);
> }
>
> } catch (PDOException $e) {
> print "Error!: " . $e->getMessage() . "\n";
> die();
> }
> ?>
> {code}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9997) IgniteDiagnosticMessagesTest.testLongRunningTx fails on TC
[
https://issues.apache.org/jira/browse/IGNITE-9997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16671853#comment-16671853
]
Amelchev Nikita commented on IGNITE-9997:
-
I have fix IgniteDiagnosticMessagesTest.testLongRunningTx test.
Problem was that test can start PME after cache creating before start
transactions. In this case, the
_GridCachePartitionExchangeManager.dumpLongRunningOperations_ method ignores
long operations. I have rewrite test and use the await method in the correct
place.
Also, I have used new listening logger and optimized test duration.
TC tests are OK. Mass runs 200 times also good.
> IgniteDiagnosticMessagesTest.testLongRunningTx fails on TC
> --
>
> Key: IGNITE-9997
> URL: https://issues.apache.org/jira/browse/IGNITE-9997
> Project: Ignite
> Issue Type: Bug
>Reporter: Amelchev Nikita
>Assignee: Amelchev Nikita
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.8
>
>
> It fails with the assertion error. [Example of
> fail.|https://ci.ignite.apache.org/viewLog.html?buildId=2157923=buildResultsDiv=IgniteTests24Java8_BinaryObjectsSimpleMapperBasic#testNameId808105671819833392]
> Log:
> {noformat}
> junit.framework.AssertionFailedError
> at
> org.apache.ignite.internal.managers.IgniteDiagnosticMessagesTest.testLongRunningTx(IgniteDiagnosticMessagesTest.java:378){noformat}
> {code:java}
> assertTrue(log.contains("Cache entries [cacheId=" +
> CU.cacheId(DEFAULT_CACHE_NAME) + ", cacheName=" + DEFAULT_CACHE_NAME + "]:"));
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9997) IgniteDiagnosticMessagesTest.testLongRunningTx fails on TC
[
https://issues.apache.org/jira/browse/IGNITE-9997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16671849#comment-16671849
]
Ignite TC Bot commented on IGNITE-9997:
---
{panel:title=No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity Run All
Results|http://ci.ignite.apache.org/viewLog.html?buildId=2209076buildTypeId=IgniteTests24Java8_RunAll]
> IgniteDiagnosticMessagesTest.testLongRunningTx fails on TC
> --
>
> Key: IGNITE-9997
> URL: https://issues.apache.org/jira/browse/IGNITE-9997
> Project: Ignite
> Issue Type: Bug
>Reporter: Amelchev Nikita
>Assignee: Amelchev Nikita
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.8
>
>
> It fails with the assertion error. [Example of
> fail.|https://ci.ignite.apache.org/viewLog.html?buildId=2157923=buildResultsDiv=IgniteTests24Java8_BinaryObjectsSimpleMapperBasic#testNameId808105671819833392]
> Log:
> {noformat}
> junit.framework.AssertionFailedError
> at
> org.apache.ignite.internal.managers.IgniteDiagnosticMessagesTest.testLongRunningTx(IgniteDiagnosticMessagesTest.java:378){noformat}
> {code:java}
> assertTrue(log.contains("Cache entries [cacheId=" +
> CU.cacheId(DEFAULT_CACHE_NAME) + ", cacheName=" + DEFAULT_CACHE_NAME + "]:"));
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9880) Document MVCC write conflict exceptions
[
https://issues.apache.org/jira/browse/IGNITE-9880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16671739#comment-16671739
]
Artem Budnikov commented on IGNITE-9880:
[~pgarg]
Please review:
https://apacheignite.readme.io/v2.6/docs/multiversion-concurrency-control#section-concurrent-updates
> Document MVCC write conflict exceptions
> ---
>
> Key: IGNITE-9880
> URL: https://issues.apache.org/jira/browse/IGNITE-9880
> Project: Ignite
> Issue Type: Task
> Components: documentation
>Reporter: Vladimir Ozerov
>Assignee: Artem Budnikov
>Priority: Major
> Fix For: 2.7
>
>
> When an entry is read (1) inside a transaction and then updated (2), there is
> a chance that concurrent transaction will modify that entry in between (1)
> and (2). In this case an error is thrown from the first transaction when
> action (2) is performed and transaction is marked as "rollback only". User
> need to re-try the whole transaction in this case.
> When native APi is used, then {{CacheException}} is thrown with special
> message {{Cannot serialize transaction due to write conflict (transaction is
> marked for rollback)}}. This will be changed in future (AI 2.8|) - special
> exception type will be thrown.
> When JDBC or ODBC are used, then special SQLSTATE code 40001 (aka
> "Serialization failure") is propagated to user.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-9880) Document MVCC write conflict exceptions
[
https://issues.apache.org/jira/browse/IGNITE-9880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Artem Budnikov reassigned IGNITE-9880:
--
Assignee: Prachi Garg (was: Artem Budnikov)
> Document MVCC write conflict exceptions
> ---
>
> Key: IGNITE-9880
> URL: https://issues.apache.org/jira/browse/IGNITE-9880
> Project: Ignite
> Issue Type: Task
> Components: documentation
>Reporter: Vladimir Ozerov
>Assignee: Prachi Garg
>Priority: Major
> Fix For: 2.7
>
>
> When an entry is read (1) inside a transaction and then updated (2), there is
> a chance that concurrent transaction will modify that entry in between (1)
> and (2). In this case an error is thrown from the first transaction when
> action (2) is performed and transaction is marked as "rollback only". User
> need to re-try the whole transaction in this case.
> When native APi is used, then {{CacheException}} is thrown with special
> message {{Cannot serialize transaction due to write conflict (transaction is
> marked for rollback)}}. This will be changed in future (AI 2.8|) - special
> exception type will be thrown.
> When JDBC or ODBC are used, then special SQLSTATE code 40001 (aka
> "Serialization failure") is propagated to user.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-9888) Document MVCC continuous queries
[ https://issues.apache.org/jira/browse/IGNITE-9888?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Artem Budnikov reassigned IGNITE-9888: -- Assignee: Prachi Garg (was: Artem Budnikov) > Document MVCC continuous queries > > > Key: IGNITE-9888 > URL: https://issues.apache.org/jira/browse/IGNITE-9888 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Vladimir Ozerov >Assignee: Prachi Garg >Priority: Major > Fix For: 2.7 > > > Key differences with continuous queries for non-MVCC caches: > 1) When event is received, subsequent read of the same key may still return > previous value for some time (i.e. no guarantee of happens-before between > event and subsequent read) > 2) Keys for notification are kept in memory. If transaction is too large, > OOME could happen. In order to avoid that, we skip notification of too large > transactions. > [~rkondakov], could you please elaborate on how is this implemented? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9888) Document MVCC continuous queries
[ https://issues.apache.org/jira/browse/IGNITE-9888?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16671738#comment-16671738 ] Artem Budnikov commented on IGNITE-9888: [~pgarg] Please review [https://apacheignite.readme.io/v2.6/docs/multiversion-concurrency-control#section-continuous-queries] > Document MVCC continuous queries > > > Key: IGNITE-9888 > URL: https://issues.apache.org/jira/browse/IGNITE-9888 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Vladimir Ozerov >Assignee: Artem Budnikov >Priority: Major > Fix For: 2.7 > > > Key differences with continuous queries for non-MVCC caches: > 1) When event is received, subsequent read of the same key may still return > previous value for some time (i.e. no guarantee of happens-before between > event and subsequent read) > 2) Keys for notification are kept in memory. If transaction is too large, > OOME could happen. In order to avoid that, we skip notification of too large > transactions. > [~rkondakov], could you please elaborate on how is this implemented? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-9435) Document MVCC
[ https://issues.apache.org/jira/browse/IGNITE-9435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Artem Budnikov reassigned IGNITE-9435: -- Assignee: Prachi Garg (was: Artem Budnikov) > Document MVCC > - > > Key: IGNITE-9435 > URL: https://issues.apache.org/jira/browse/IGNITE-9435 > Project: Ignite > Issue Type: Task > Components: documentation, mvcc >Reporter: Vladimir Ozerov >Assignee: Prachi Garg >Priority: Major > Fix For: 2.7 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9435) Document MVCC
[ https://issues.apache.org/jira/browse/IGNITE-9435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16671734#comment-16671734 ] Artem Budnikov commented on IGNITE-9435: [~pgarg] Here is what changed under this issue: 1) Because the Transaction page has grown quite a lot, I moved three sections from it to a sub-page: [https://apacheignite.readme.io/v2.6/docs/concurrency-modes-and-isolation-levels.] 2) Added a sub-page dedicated to MVCC: [https://apacheignite.readme.io/v2.6/docs/multiversion-concurrency-control] 3) Added the description of the new atomicity mode to the Transaction page (changed the text where needed throughout the page): [https://dash.readme.io/project/apacheignite/v2.6/docs/transactions-27] 4) Added a page called "SQL transactions" to the SQL section of the documentation. This page contains SQL-related information about using MVCC.: [https://apacheignite-sql.readme.io/v2.6/docs/multiversion-concurrency-control] 5) Added a page to the "SQL Reference" section that describes transaction syntax: [https://dash.readme.io/project/apacheignite-sql/v2.6/docs/transactions] Please review points 2), 4), 5) and take a look at 3) (at least the "atomicity mode" section). > Document MVCC > - > > Key: IGNITE-9435 > URL: https://issues.apache.org/jira/browse/IGNITE-9435 > Project: Ignite > Issue Type: Task > Components: documentation, mvcc >Reporter: Vladimir Ozerov >Assignee: Artem Budnikov >Priority: Major > Fix For: 2.7 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10115) Remove excessive "setAccessible(oldAccessible)" in GridTestUtils
[ https://issues.apache.org/jira/browse/IGNITE-10115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16671678#comment-16671678 ] ASF GitHub Bot commented on IGNITE-10115: - GitHub user ibessonov opened a pull request: https://github.com/apache/ignite/pull/5235 IGNITE-10115 Remove excessive "setAccessible(oldAccessible)" in GridTestUtils You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-10115 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/5235.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 #5235 commit 47693921dcbd81709d68289eb6133bf17048928b Author: ibessonov Date: 2018-11-01T14:29:14Z IGNITE-10115 Removed excessive "setAccessible" invocations. > Remove excessive "setAccessible(oldAccessible)" in GridTestUtils > > > Key: IGNITE-10115 > URL: https://issues.apache.org/jira/browse/IGNITE-10115 > Project: Ignite > Issue Type: Improvement >Reporter: Ivan Bessonov >Assignee: Ivan Bessonov >Priority: Major > Fix For: 2.8 > > > Methods like > org.apache.ignite.testframework.GridTestUtils#setFieldValue(java.lang.Object, > java.lang.String, java.lang.Object) return old state of Field objects but > that doesn't make any sense. Removing such actions will make code more clear > and effective. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10107) Cache 7 tests optimization
[ https://issues.apache.org/jira/browse/IGNITE-10107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16671656#comment-16671656 ] ASF GitHub Bot commented on IGNITE-10107: - GitHub user ibessonov opened a pull request: https://github.com/apache/ignite/pull/5234 IGNITE-10107 Cache 7 tests optimization You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-10107 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/5234.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 #5234 commit 4e85c11c3a5781b88cf2e3ae2a70b033f66e6e5d Author: Alexey Platonov Date: 2018-10-29T13:59:05Z init commit commit 45076feec0dc4a26172eb79acb9dabcd1a8bab73 Author: Alexey Platonov Date: 2018-10-30T09:37:14Z add scale factor commit 907b19320d1bffbfbb9b3997201fd4b28718b2ee Author: Alexey Platonov Date: 2018-10-30T09:41:21Z remode useless code commit 8107297ea092d46c097b4575213deb593d7a0db4 Author: Alexey Platonov Date: 2018-10-30T10:08:55Z remove garbage commit 3ff73df5a016dcd6ea03d23ee4a2c8f0b37b0c2a Author: Alexey Platonov Date: 2018-10-30T10:18:56Z fix comments in code commit 0c0a043feaa1d4bcbf61bcc2137490cea41c7679 Author: ibessonov Date: 2018-11-01T14:09:55Z IGNITE-10107 Mainly "scale-factor" optimizations. Password hashing algorithm tweaked so authentication tests are much faster now in general. > Cache 7 tests optimization > -- > > Key: IGNITE-10107 > URL: https://issues.apache.org/jira/browse/IGNITE-10107 > Project: Ignite > Issue Type: Improvement >Reporter: Ivan Bessonov >Assignee: Ivan Bessonov >Priority: Major > Labels: MakeTeamcityGreenAgain > Fix For: 2.8 > > > These tests run over 1 minute each: > Authentication1kUsersNodeRestartTest.test1kUsersNodeRestartServer > TxRollbackAsyncWithPersistenceTest.testSynchronousRollback > IgniteCacheStartWithLoadTest.testNoRebalanceDuringCacheStart > WalModeChangeAdvancedSelfTest.testConcurrentOperations > TxRollbackAsyncWithPersistenceTest.testMixedAsyncRollbackTypes > GridCacheRebalancingWithAsyncClearingTest.testPartitionClearingNotBlockExchange > WalModeChangeAdvancedSelfTest.testServerRestartNonCoordinator > They should be either optimized or moved into overnight build (or both). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10092) Race in partition state when checkpoint started at the middle of starts caches
[
https://issues.apache.org/jira/browse/IGNITE-10092?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladislav Pyatkov updated IGNITE-10092:
---
Description:
In the method {{GridCacheDatabaseSharedManager#restorePartitionStates}} called
method of creation partition at start
{{GridDhtPartitionTopology#forceCreatePartition.}}
Partitions create in MOVING state, and can be accessible to on checkpoint
thread.
By the reason checkpoint thread ({{GridCacheOffheapManager#saveStoreMetadata}})
can to read MOVING partition state and store it after
{{GridCacheDatabaseSharedManager#restorePartitionStates}} completion in
parallel.
In result partition stet stored incorrect, should leads to rebalance.
> Race in partition state when checkpoint started at the middle of starts caches
> --
>
> Key: IGNITE-10092
> URL: https://issues.apache.org/jira/browse/IGNITE-10092
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Assignee: Vladislav Pyatkov
>Priority: Major
>
> In the method {{GridCacheDatabaseSharedManager#restorePartitionStates}}
> called method of creation partition at start
> {{GridDhtPartitionTopology#forceCreatePartition.}}
> Partitions create in MOVING state, and can be accessible to on checkpoint
> thread.
> By the reason checkpoint thread
> ({{GridCacheOffheapManager#saveStoreMetadata}}) can to read MOVING partition
> state and store it after
> {{GridCacheDatabaseSharedManager#restorePartitionStates}} completion in
> parallel.
> In result partition stet stored incorrect, should leads to rebalance.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8903) IgniteCacheGetRestartTest.testGetRestartReplicated fails in master
[
https://issues.apache.org/jira/browse/IGNITE-8903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16671642#comment-16671642
]
Ryabov Dmitrii commented on IGNITE-8903:
Hi, [~ruslangm]! I got 1 fail (3 tests failed) in one hour when running the
whole test class.
I investigated this fail and [log from
TC|https://ci.ignite.apache.org/viewLog.html?tab=buildLog=tree=debug=all=2214654&_focus=870180],
and I see 2 problems:
# Interrupted exceptions on node start - looks like fails in the IGNITE-9986.
Fix is merged, so we need to wait for statistic from TeamCity runs.
# NPEs in the previous tests.
Can you check the NPEs in the log and find out their possible reasons?
> IgniteCacheGetRestartTest.testGetRestartReplicated fails in master
> --
>
> Key: IGNITE-8903
> URL: https://issues.apache.org/jira/browse/IGNITE-8903
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.7
>Reporter: Maxim Muzafarov
>Assignee: Ruslan Gilemzyanov
>Priority: Major
> Labels: MakeTeamcityGreenAgain, newbie
>
> Test {{IgniteCacheGetRestartTest.testGetRestartReplicated}} fails with
> message:
> {code:java}
> org.apache.ignite.IgniteCheckedException: Ignite instance with this name has
> already been started: distributed.IgniteCacheGetRestartTest5{code}
> Probably some grids remains not stopped between test-cases within
> IgniteCacheGetRestartTest.
>
> TC (master):
> [https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=7917326378982816549=testDetails_IgniteTests24Java8=%3Cdefault%3E]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-7153) Redis: BufferUnderflowException at GridRedisProtocolParser.readBulkStr for values > 8kb
[
https://issues.apache.org/jira/browse/IGNITE-7153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16671637#comment-16671637
]
Dmitriy Pavlov commented on IGNITE-7153:
Hi [~roman_s] ,thank you.
[~mcfongtw], I've added you to the list of contributors, so you can now assign
an issue to yourself. I've also assigned this issue to you, I hope you don't
mind.
Please set the issue to 'patch available' once you think that change is ready.
> Redis: BufferUnderflowException at GridRedisProtocolParser.readBulkStr for
> values > 8kb
> ---
>
> Key: IGNITE-7153
> URL: https://issues.apache.org/jira/browse/IGNITE-7153
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 2.3
> Environment: Win, PHP 7, php_redis-3.1.1-7.0
>Reporter: Alexey Popov
>Assignee: Michael Fong
>Priority: Major
> Labels: redis
>
> Exception:
> {noformat}
> [15:03:23,690][SEVERE][grid-nio-worker-tcp-rest-0-#36][GridTcpRestProtocol]
> Failed to process selector key [ses=GridSelectorNioSessionImpl
> [worker=ByteBufferNioClientWorker [readBuf=java.nio.HeapByteBuffer[pos=28
> lim=8192 cap=8192], super=AbstractNioClientWorker [idx=0, bytesRcvd=0,
> bytesSent=0, bytesRcvd0=0, bytesSent0=0, select=true, super=GridWorker
> [name=grid-nio-worker-tcp-rest-0, igniteInstanceName=null, finished=false,
> hashCode=396395638, interrupted=false,
> runner=grid-nio-worker-tcp-rest-0-#36]]], writeBuf=null, readBuf=null,
> inRecovery=null, outRecovery=null, super=GridNioSessionImpl
> [locAddr=/127.0.0.1:6380, rmtAddr=/127.0.0.1:51794, createTime=1512734602674,
> closeTime=0, bytesSent=0, bytesRcvd=8192, bytesSent0=0, bytesRcvd0=8192,
> sndSchedTime=1512734602674, lastSndTime=1512734602674,
> lastRcvTime=1512734602674, readsPaused=false,
> filterChain=FilterChain[filters=[GridNioCodecFilter [parser=GridTcpRestParser
> [jdkMarshaller=JdkMarshaller [], routerClient=false], directMode=false]],
> accepted=true]]]
> java.nio.BufferUnderflowException
> at java.nio.HeapByteBuffer.get(HeapByteBuffer.java:151)
> at
> org.apache.ignite.internal.processors.rest.protocols.tcp.redis.GridRedisProtocolParser.readBulkStr(GridRedisProtocolParser.java:107)
> at
> org.apache.ignite.internal.processors.rest.protocols.tcp.redis.GridRedisProtocolParser.readArray(GridRedisProtocolParser.java:86)
> at
> org.apache.ignite.internal.processors.rest.protocols.tcp.GridTcpRestParser.decode(GridTcpRestParser.java:150)
> at
> org.apache.ignite.internal.processors.rest.protocols.tcp.GridTcpRestParser.decode(GridTcpRestParser.java:70)
> at
> org.apache.ignite.internal.util.nio.GridNioCodecFilter.onMessageReceived(GridNioCodecFilter.java:114)
> at
> org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedMessageReceived(GridNioFilterAdapter.java:109)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$HeadFilter.onMessageReceived(GridNioServer.java:3392)
> at
> org.apache.ignite.internal.util.nio.GridNioFilterChain.onMessageReceived(GridNioFilterChain.java:175)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$ByteBufferNioClientWorker.processRead(GridNioServer.java:1096)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.processSelectedKeysOptimized(GridNioServer.java:2272)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.bodyInternal(GridNioServer.java:2048)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.body(GridNioServer.java:1717)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:748)
> [15:03:23,691][SEVERE][grid-nio-worker-tcp-rest-0-#36][GridTcpRestProtocol]
> Closing NIO session because of unhandled exception.
> class org.apache.ignite.internal.util.nio.GridNioException: null
> at
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.processSelectedKeysOptimized(GridNioServer.java:2296)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.bodyInternal(GridNioServer.java:2048)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.body(GridNioServer.java:1717)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.nio.BufferUnderflowException
> at java.nio.HeapByteBuffer.get(HeapByteBuffer.java:151)
> at
> org.apache.ignite.internal.processors.rest.protocols.tcp.redis.GridRedisProtocolParser.readBulkStr(GridRedisProtocolParser.java:107)
> at
>
[jira] [Assigned] (IGNITE-7153) Redis: BufferUnderflowException at GridRedisProtocolParser.readBulkStr for values > 8kb
[
https://issues.apache.org/jira/browse/IGNITE-7153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Pavlov reassigned IGNITE-7153:
--
Assignee: Michael Fong (was: Roman Shtykh)
> Redis: BufferUnderflowException at GridRedisProtocolParser.readBulkStr for
> values > 8kb
> ---
>
> Key: IGNITE-7153
> URL: https://issues.apache.org/jira/browse/IGNITE-7153
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 2.3
> Environment: Win, PHP 7, php_redis-3.1.1-7.0
>Reporter: Alexey Popov
>Assignee: Michael Fong
>Priority: Major
> Labels: redis
>
> Exception:
> {noformat}
> [15:03:23,690][SEVERE][grid-nio-worker-tcp-rest-0-#36][GridTcpRestProtocol]
> Failed to process selector key [ses=GridSelectorNioSessionImpl
> [worker=ByteBufferNioClientWorker [readBuf=java.nio.HeapByteBuffer[pos=28
> lim=8192 cap=8192], super=AbstractNioClientWorker [idx=0, bytesRcvd=0,
> bytesSent=0, bytesRcvd0=0, bytesSent0=0, select=true, super=GridWorker
> [name=grid-nio-worker-tcp-rest-0, igniteInstanceName=null, finished=false,
> hashCode=396395638, interrupted=false,
> runner=grid-nio-worker-tcp-rest-0-#36]]], writeBuf=null, readBuf=null,
> inRecovery=null, outRecovery=null, super=GridNioSessionImpl
> [locAddr=/127.0.0.1:6380, rmtAddr=/127.0.0.1:51794, createTime=1512734602674,
> closeTime=0, bytesSent=0, bytesRcvd=8192, bytesSent0=0, bytesRcvd0=8192,
> sndSchedTime=1512734602674, lastSndTime=1512734602674,
> lastRcvTime=1512734602674, readsPaused=false,
> filterChain=FilterChain[filters=[GridNioCodecFilter [parser=GridTcpRestParser
> [jdkMarshaller=JdkMarshaller [], routerClient=false], directMode=false]],
> accepted=true]]]
> java.nio.BufferUnderflowException
> at java.nio.HeapByteBuffer.get(HeapByteBuffer.java:151)
> at
> org.apache.ignite.internal.processors.rest.protocols.tcp.redis.GridRedisProtocolParser.readBulkStr(GridRedisProtocolParser.java:107)
> at
> org.apache.ignite.internal.processors.rest.protocols.tcp.redis.GridRedisProtocolParser.readArray(GridRedisProtocolParser.java:86)
> at
> org.apache.ignite.internal.processors.rest.protocols.tcp.GridTcpRestParser.decode(GridTcpRestParser.java:150)
> at
> org.apache.ignite.internal.processors.rest.protocols.tcp.GridTcpRestParser.decode(GridTcpRestParser.java:70)
> at
> org.apache.ignite.internal.util.nio.GridNioCodecFilter.onMessageReceived(GridNioCodecFilter.java:114)
> at
> org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedMessageReceived(GridNioFilterAdapter.java:109)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$HeadFilter.onMessageReceived(GridNioServer.java:3392)
> at
> org.apache.ignite.internal.util.nio.GridNioFilterChain.onMessageReceived(GridNioFilterChain.java:175)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$ByteBufferNioClientWorker.processRead(GridNioServer.java:1096)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.processSelectedKeysOptimized(GridNioServer.java:2272)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.bodyInternal(GridNioServer.java:2048)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.body(GridNioServer.java:1717)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:748)
> [15:03:23,691][SEVERE][grid-nio-worker-tcp-rest-0-#36][GridTcpRestProtocol]
> Closing NIO session because of unhandled exception.
> class org.apache.ignite.internal.util.nio.GridNioException: null
> at
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.processSelectedKeysOptimized(GridNioServer.java:2296)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.bodyInternal(GridNioServer.java:2048)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.body(GridNioServer.java:1717)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.nio.BufferUnderflowException
> at java.nio.HeapByteBuffer.get(HeapByteBuffer.java:151)
> at
> org.apache.ignite.internal.processors.rest.protocols.tcp.redis.GridRedisProtocolParser.readBulkStr(GridRedisProtocolParser.java:107)
> at
> org.apache.ignite.internal.processors.rest.protocols.tcp.redis.GridRedisProtocolParser.readArray(GridRedisProtocolParser.java:86)
> at
> org.apache.ignite.internal.processors.rest.protocols.tcp.GridTcpRestParser.decode(GridTcpRestParser.java:150)
> at
>
[jira] [Commented] (IGNITE-9607) Service Grid redesign - phase 1
[
https://issues.apache.org/jira/browse/IGNITE-9607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16671629#comment-16671629
]
Ignite TC Bot commented on IGNITE-9607:
---
{panel:title=No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity Run All
Results|http://ci.ignite.apache.org/viewLog.html?buildId=2217976buildTypeId=IgniteTests24Java8_RunAll]
> Service Grid redesign - phase 1
> ---
>
> Key: IGNITE-9607
> URL: https://issues.apache.org/jira/browse/IGNITE-9607
> Project: Ignite
> Issue Type: Improvement
> Components: managed services
>Reporter: Vyacheslav Daradur
>Assignee: Vyacheslav Daradur
>Priority: Major
> Fix For: 2.8
>
>
> This is an umbrella ticket for tasks which should be implemented atomically
> in phase #1 of Service Grid redesign.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10116) Document implemented design of Service Grid (redesign phase 1)
Vyacheslav Daradur created IGNITE-10116: --- Summary: Document implemented design of Service Grid (redesign phase 1) Key: IGNITE-10116 URL: https://issues.apache.org/jira/browse/IGNITE-10116 Project: Ignite Issue Type: Task Components: managed services Reporter: Vyacheslav Daradur Assignee: Vyacheslav Daradur Fix For: 2.8 It's necessary to document implemented design of Service Grid and publish in wiki. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10115) Remove excessive "setAccessible(oldAccessible)" in GridTestUtils
Ivan Bessonov created IGNITE-10115: -- Summary: Remove excessive "setAccessible(oldAccessible)" in GridTestUtils Key: IGNITE-10115 URL: https://issues.apache.org/jira/browse/IGNITE-10115 Project: Ignite Issue Type: Improvement Reporter: Ivan Bessonov Assignee: Ivan Bessonov Fix For: 2.8 Methods like org.apache.ignite.testframework.GridTestUtils#setFieldValue(java.lang.Object, java.lang.String, java.lang.Object) return old state of Field objects but that doesn't make any sense. Removing such actions will make code more clear and effective. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9557) Assert exception on explain of any update query.
[
https://issues.apache.org/jira/browse/IGNITE-9557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16671620#comment-16671620
]
Ignite TC Bot commented on IGNITE-9557:
---
{panel:title=Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Platform .NET{color} [[tests
3|https://ci.ignite.apache.org/viewLog.html?buildId=2217851]]
* exe: CacheQueriesTest.TestScanQuery(True) - 0,0% fails in last 100 master
runs.
{color:#d04437}Data Structures{color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=2217838]]
* IgniteCacheDataStructuresSelfTestSuite:
GridCacheReplicatedQueueMultiNodeSelfTest.testAddPollMultinode - 0,0% fails in
last 100 master runs.
{color:#d04437}Binary Objects (Simple Mapper Basic){color} [[tests 0 TIMEOUT ,
Exit Code |https://ci.ignite.apache.org/viewLog.html?buildId=2217756]]
{panel}
[TeamCity Run All
Results|http://ci.ignite.apache.org/viewLog.html?buildId=2217863buildTypeId=IgniteTests24Java8_RunAll]
> Assert exception on explain of any update query.
>
>
> Key: IGNITE-9557
> URL: https://issues.apache.org/jira/browse/IGNITE-9557
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Vasiliy Sisko
>Assignee: Pavel Kuznetsov
>Priority: Major
> Fix For: 2.8
>
>
> On execution of an query:
> {code:java}
> explain delete from "schema".type {code}
> received exception:
> {code:java}
> java.lang.AssertionError
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.parseAndSplit(IgniteH2Indexing.java:2309)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.querySqlFields(IgniteH2Indexing.java:2105)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:2139)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:2134)
> at
> org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2711)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2148)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2083)
> at
> org.apache.ignite.internal.visor.query.VisorQueryTask$VisorQueryJob.run(VisorQueryTask.java:94)
> at
> org.apache.ignite.internal.visor.query.VisorQueryTask$VisorQueryJob.run(VisorQueryTask.java:59)
> at org.apache.ignite.internal.visor.VisorJob.execute(VisorJob.java:69)
> at
> org.apache.ignite.internal.processors.job.GridJobWorker$2.call(GridJobWorker.java:568)
> at
> org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:6765)
> at
> org.apache.ignite.internal.processors.job.GridJobWorker.execute0(GridJobWorker.java:562)
> at
> org.apache.ignite.internal.processors.job.GridJobWorker.body(GridJobWorker.java:491)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at
> org.apache.ignite.internal.processors.job.GridJobProcessor.processJobExecuteRequest(GridJobProcessor.java:1125)
> at
> org.apache.ignite.internal.processors.task.GridTaskWorker.sendRequest(GridTaskWorker.java:1420)
> at
> org.apache.ignite.internal.processors.task.GridTaskWorker.processMappedJobs(GridTaskWorker.java:666)
> at
> org.apache.ignite.internal.processors.task.GridTaskWorker.body(GridTaskWorker.java:538)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at
> org.apache.ignite.internal.processors.task.GridTaskProcessor.startTask(GridTaskProcessor.java:764)
> at
> org.apache.ignite.internal.processors.task.GridTaskProcessor.execute(GridTaskProcessor.java:509)
> at
> org.apache.ignite.internal.IgniteComputeImpl.executeAsync0(IgniteComputeImpl.java:488)
> at
> org.apache.ignite.internal.IgniteComputeImpl.executeAsync(IgniteComputeImpl.java:468)
> at
> org.apache.ignite.internal.visor.compute.VisorGatewayTask$VisorGatewayJob.execute(VisorGatewayTask.java:462)
> at
> org.apache.ignite.internal.processors.job.GridJobWorker$2.call(GridJobWorker.java:568)
> at
> org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:6765)
> at
> org.apache.ignite.internal.processors.job.GridJobWorker.execute0(GridJobWorker.java:562)
> at
> org.apache.ignite.internal.processors.job.GridJobWorker.body(GridJobWorker.java:491)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at
>
[jira] [Created] (IGNITE-10114) Potential deadlock in GridDhtPartitionTopologyImpl
Roman Kondakov created IGNITE-10114:
---
Summary: Potential deadlock in GridDhtPartitionTopologyImpl
Key: IGNITE-10114
URL: https://issues.apache.org/jira/browse/IGNITE-10114
Project: Ignite
Issue Type: Bug
Components: cache
Reporter: Roman Kondakov
There are several methods in {{GridDhtPartitionTopologyImpl}} where correct
checkpoint and topology readlock order is violated: topology lock is obtained
first, and after this an initialization of {{CacheDataStore}} could be called
under the checkpoint lock.
Affected methods:
* {{GridDhtPartitionTopologyImpl#localUpdateCounters}}
* {{GridDhtPartitionTopologyImpl#partitionSizes}}
* {{GridDhtPartitionTopologyImpl#printMemoryStats}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10058) resetLostPartitions() leaves an additional copy of a partition in the cluster
[ https://issues.apache.org/jira/browse/IGNITE-10058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16671599#comment-16671599 ] Stanislav Lukyanov commented on IGNITE-10058: - Looks like it's a duplicate of IGNITE-5302. Marking as "related" for now, need to confirm this to be a duplicate before closing. > resetLostPartitions() leaves an additional copy of a partition in the cluster > - > > Key: IGNITE-10058 > URL: https://issues.apache.org/jira/browse/IGNITE-10058 > Project: Ignite > Issue Type: Bug >Reporter: Stanislav Lukyanov >Priority: Major > > If there are several copies of a LOST partition, resetLostPartitions() will > leave all of them in the cluster as OWNING. > Scenario: > 1) Start 4 nodes, a cache with backups=0 and READ_WRITE_SAFE, fill the cache > 2) Stop one node - some partitions are recreated on the remaining nodes as > LOST > 3) Start one node - the LOST partitions are being rebalanced to the new node > from the existing ones > 4) Wait for rebalance to complete > 5) Call resetLostPartitions() > After that the partitions that were LOST become OWNING on all nodes that had > them. Eviction of these partitions doesn't start. > Need to correctly evict additional copies of LOST partitions either after > rebalance on step 4 or after resetLostPartitions() call on step 5. > Current resetLostPartitions() implementation does call checkEvictions(), but > the ready affinity assignment contains several nodes per partition for some > reason. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10113) Failure during build index isn't handled by failure handler
Sergey Antonov created IGNITE-10113: --- Summary: Failure during build index isn't handled by failure handler Key: IGNITE-10113 URL: https://issues.apache.org/jira/browse/IGNITE-10113 Project: Ignite Issue Type: Bug Reporter: Sergey Antonov Assignee: Sergey Antonov Fix For: 2.8 Attachments: StopNodeOnRebuildIndexFailureTest.java If exception will be thrown during index build, failure handler doesn't handle this exception. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-9824) Thin clients benches
[ https://issues.apache.org/jira/browse/IGNITE-9824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16671569#comment-16671569 ] Stepan Pilschikov edited comment on IGNITE-9824 at 11/1/18 12:54 PM: - Previous bench run was wrong, because hosts configuration is not identical others Also for best comparison ive take latest ignite nightly release and run clients from latest commit and 7e547b139143f08e707d0f084f4ce677c9ee6ec0 (where python clients was merged) [^thin_benches_v6.pdf] - latest report with comparison charts was (Author: spilschikov): Previous bench run was wrong, because hosts configuration is not identical others Also for best comparison ive take latest ignite nightly release and run clients from latest commit and 7e547b139143f08e707d0f084f4ce677c9ee6ec0 (where python clients was merged) [^thin_benches_v5.pdf] - latest report with comparison charts > Thin clients benches > > > Key: IGNITE-9824 > URL: https://issues.apache.org/jira/browse/IGNITE-9824 > Project: Ignite > Issue Type: Test > Components: thin client > Environment: Ignite 2.7 > Java 8 > NodeJS 10.+ > PHP 7.2.7 > Python 3.6 >Reporter: Stepan Pilschikov >Priority: Major > Attachments: thin_bench_simple_put_v3.pdf, thin_benches_v4.pdf, > thin_benches_v6.pdf, thin_clients_bench_results.pdf, > thin_clients_bench_results_v2.pdf > > > Benchmarks for all existed ignite thin clients > Case: > - Running 1 or 3 nodes on first host > - Running code on second host > Code: > - > [NodeJS|https://gist.github.com/pilshchikov/8a4bdb03a8304136c22c9bf7217ee447] > - [PHP|https://gist.github.com/pilshchikov/b4351d78ad59e9cd923689c2e387bc80] > - > [Python|https://gist.github.com/pilshchikov/8aff4e30d83f8bac20c5a4a9c3917abb] > - [Java|https://gist.github.com/pilshchikov/08096c78b425e00166a2ffa2aa5f49ce] > Results in attachments -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9824) Thin clients benches
[ https://issues.apache.org/jira/browse/IGNITE-9824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stepan Pilschikov updated IGNITE-9824: -- Attachment: (was: thin_benches_v5.pdf) > Thin clients benches > > > Key: IGNITE-9824 > URL: https://issues.apache.org/jira/browse/IGNITE-9824 > Project: Ignite > Issue Type: Test > Components: thin client > Environment: Ignite 2.7 > Java 8 > NodeJS 10.+ > PHP 7.2.7 > Python 3.6 >Reporter: Stepan Pilschikov >Priority: Major > Attachments: thin_bench_simple_put_v3.pdf, thin_benches_v4.pdf, > thin_benches_v6.pdf, thin_clients_bench_results.pdf, > thin_clients_bench_results_v2.pdf > > > Benchmarks for all existed ignite thin clients > Case: > - Running 1 or 3 nodes on first host > - Running code on second host > Code: > - > [NodeJS|https://gist.github.com/pilshchikov/8a4bdb03a8304136c22c9bf7217ee447] > - [PHP|https://gist.github.com/pilshchikov/b4351d78ad59e9cd923689c2e387bc80] > - > [Python|https://gist.github.com/pilshchikov/8aff4e30d83f8bac20c5a4a9c3917abb] > - [Java|https://gist.github.com/pilshchikov/08096c78b425e00166a2ffa2aa5f49ce] > Results in attachments -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9824) Thin clients benches
[ https://issues.apache.org/jira/browse/IGNITE-9824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stepan Pilschikov updated IGNITE-9824: -- Attachment: thin_benches_v6.pdf > Thin clients benches > > > Key: IGNITE-9824 > URL: https://issues.apache.org/jira/browse/IGNITE-9824 > Project: Ignite > Issue Type: Test > Components: thin client > Environment: Ignite 2.7 > Java 8 > NodeJS 10.+ > PHP 7.2.7 > Python 3.6 >Reporter: Stepan Pilschikov >Priority: Major > Attachments: thin_bench_simple_put_v3.pdf, thin_benches_v4.pdf, > thin_benches_v6.pdf, thin_clients_bench_results.pdf, > thin_clients_bench_results_v2.pdf > > > Benchmarks for all existed ignite thin clients > Case: > - Running 1 or 3 nodes on first host > - Running code on second host > Code: > - > [NodeJS|https://gist.github.com/pilshchikov/8a4bdb03a8304136c22c9bf7217ee447] > - [PHP|https://gist.github.com/pilshchikov/b4351d78ad59e9cd923689c2e387bc80] > - > [Python|https://gist.github.com/pilshchikov/8aff4e30d83f8bac20c5a4a9c3917abb] > - [Java|https://gist.github.com/pilshchikov/08096c78b425e00166a2ffa2aa5f49ce] > Results in attachments -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8895) Update yardstick libraries
[ https://issues.apache.org/jira/browse/IGNITE-8895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry Sherstobitov updated IGNITE-8895: Description: There is some conflicts in yardstick libraries for now ||yardstick||core||problem|| |jline-0.9.94.jar|bin/include/sqlline/jline-2.4.3.jar|./sqlline.sh unable to start because of yardstick libraries in the PATH| was: There is some conflicts in yardstick libraries for now ||yardstick||core||problem|| |jline-0.9.94.jar|bin/include/sqlline/jline-2.4.3.jar|./sqlline.sh unable to start if yardstick libraries in path| > Update yardstick libraries > --- > > Key: IGNITE-8895 > URL: https://issues.apache.org/jira/browse/IGNITE-8895 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.5 >Reporter: Dmitry Sherstobitov >Priority: Major > > There is some conflicts in yardstick libraries for now > ||yardstick||core||problem|| > |jline-0.9.94.jar|bin/include/sqlline/jline-2.4.3.jar|./sqlline.sh unable to > start because of yardstick libraries in the PATH| > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9824) Thin clients benches
[ https://issues.apache.org/jira/browse/IGNITE-9824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16671569#comment-16671569 ] Stepan Pilschikov commented on IGNITE-9824: --- Previous bench run is wrong, because hosts configuration is not identical others Also for best comparison ive take latest ignite nightly release and run clients from latest commit and 7e547b139143f08e707d0f084f4ce677c9ee6ec0 (where python clients was merged) [^thin_benches_v5.pdf] - latest report with comparison charts > Thin clients benches > > > Key: IGNITE-9824 > URL: https://issues.apache.org/jira/browse/IGNITE-9824 > Project: Ignite > Issue Type: Test > Components: thin client > Environment: Ignite 2.7 > Java 8 > NodeJS 10.+ > PHP 7.2.7 > Python 3.6 >Reporter: Stepan Pilschikov >Priority: Major > Attachments: thin_bench_simple_put_v3.pdf, thin_benches_v4.pdf, > thin_benches_v5.pdf, thin_clients_bench_results.pdf, > thin_clients_bench_results_v2.pdf > > > Benchmarks for all existed ignite thin clients > Case: > - Running 1 or 3 nodes on first host > - Running code on second host > Code: > - > [NodeJS|https://gist.github.com/pilshchikov/8a4bdb03a8304136c22c9bf7217ee447] > - [PHP|https://gist.github.com/pilshchikov/b4351d78ad59e9cd923689c2e387bc80] > - > [Python|https://gist.github.com/pilshchikov/8aff4e30d83f8bac20c5a4a9c3917abb] > - [Java|https://gist.github.com/pilshchikov/08096c78b425e00166a2ffa2aa5f49ce] > Results in attachments -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-9824) Thin clients benches
[ https://issues.apache.org/jira/browse/IGNITE-9824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16671569#comment-16671569 ] Stepan Pilschikov edited comment on IGNITE-9824 at 11/1/18 12:49 PM: - Previous bench run was wrong, because hosts configuration is not identical others Also for best comparison ive take latest ignite nightly release and run clients from latest commit and 7e547b139143f08e707d0f084f4ce677c9ee6ec0 (where python clients was merged) [^thin_benches_v5.pdf] - latest report with comparison charts was (Author: spilschikov): Previous bench run is wrong, because hosts configuration is not identical others Also for best comparison ive take latest ignite nightly release and run clients from latest commit and 7e547b139143f08e707d0f084f4ce677c9ee6ec0 (where python clients was merged) [^thin_benches_v5.pdf] - latest report with comparison charts > Thin clients benches > > > Key: IGNITE-9824 > URL: https://issues.apache.org/jira/browse/IGNITE-9824 > Project: Ignite > Issue Type: Test > Components: thin client > Environment: Ignite 2.7 > Java 8 > NodeJS 10.+ > PHP 7.2.7 > Python 3.6 >Reporter: Stepan Pilschikov >Priority: Major > Attachments: thin_bench_simple_put_v3.pdf, thin_benches_v4.pdf, > thin_benches_v5.pdf, thin_clients_bench_results.pdf, > thin_clients_bench_results_v2.pdf > > > Benchmarks for all existed ignite thin clients > Case: > - Running 1 or 3 nodes on first host > - Running code on second host > Code: > - > [NodeJS|https://gist.github.com/pilshchikov/8a4bdb03a8304136c22c9bf7217ee447] > - [PHP|https://gist.github.com/pilshchikov/b4351d78ad59e9cd923689c2e387bc80] > - > [Python|https://gist.github.com/pilshchikov/8aff4e30d83f8bac20c5a4a9c3917abb] > - [Java|https://gist.github.com/pilshchikov/08096c78b425e00166a2ffa2aa5f49ce] > Results in attachments -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9824) Thin clients benches
[ https://issues.apache.org/jira/browse/IGNITE-9824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stepan Pilschikov updated IGNITE-9824: -- Attachment: thin_benches_v5.pdf > Thin clients benches > > > Key: IGNITE-9824 > URL: https://issues.apache.org/jira/browse/IGNITE-9824 > Project: Ignite > Issue Type: Test > Components: thin client > Environment: Ignite 2.7 > Java 8 > NodeJS 10.+ > PHP 7.2.7 > Python 3.6 >Reporter: Stepan Pilschikov >Priority: Major > Attachments: thin_bench_simple_put_v3.pdf, thin_benches_v4.pdf, > thin_benches_v5.pdf, thin_clients_bench_results.pdf, > thin_clients_bench_results_v2.pdf > > > Benchmarks for all existed ignite thin clients > Case: > - Running 1 or 3 nodes on first host > - Running code on second host > Code: > - > [NodeJS|https://gist.github.com/pilshchikov/8a4bdb03a8304136c22c9bf7217ee447] > - [PHP|https://gist.github.com/pilshchikov/b4351d78ad59e9cd923689c2e387bc80] > - > [Python|https://gist.github.com/pilshchikov/8aff4e30d83f8bac20c5a4a9c3917abb] > - [Java|https://gist.github.com/pilshchikov/08096c78b425e00166a2ffa2aa5f49ce] > Results in attachments -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10112) Prioritize processing of tx finish=false message due to timeout
Alexei Scherbakov created IGNITE-10112: -- Summary: Prioritize processing of tx finish=false message due to timeout Key: IGNITE-10112 URL: https://issues.apache.org/jira/browse/IGNITE-10112 Project: Ignite Issue Type: Improvement Reporter: Alexei Scherbakov Fix For: 2.8 Currently tx rollback messages are processed in the same way as others. For forced rollback on example triggered by tx timeouts on PME (see org.apache.ignite.configuration.TransactionConfiguration#getTxTimeoutOnPartitionMapExchange) they should be prioritized to avoid timeout violation under load. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10045) Add fail-fast mode to bounded iteration of StandaloneWalRecordsIterator
[ https://issues.apache.org/jira/browse/IGNITE-10045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16671543#comment-16671543 ] Alexey Stelmak commented on IGNITE-10045: - Fixed > Add fail-fast mode to bounded iteration of StandaloneWalRecordsIterator > --- > > Key: IGNITE-10045 > URL: https://issues.apache.org/jira/browse/IGNITE-10045 > Project: Ignite > Issue Type: Improvement >Reporter: Ivan Rakov >Assignee: Alexey Stelmak >Priority: Major > Fix For: 2.8 > > > Since IGNITE-9294 StandaloneWalRecordsIterator supports bounded iteration. > That means we can specify "from" and "to" WAL pointers and iterator will > return records only between given bounds. > The problem is that in current implementation StandaloneWalRecordsIterator > just skips segments if they are missing. For example: if we'll specify > fromIdx=0, toIdx = 10 and segments with indexes=[9, 10] will be missing, > we'll just silently finish iteration on idx=8. > To prevent that, we should be able to switch on fail-fast mode, in which > StandaloneWalRecordsIterator will throw error unless iteration is really > started from left bound and ended on right bound. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10111) Affinity doesn't recalculate after lost partitions
Anton Kalashnikov created IGNITE-10111: -- Summary: Affinity doesn't recalculate after lost partitions Key: IGNITE-10111 URL: https://issues.apache.org/jira/browse/IGNITE-10111 Project: Ignite Issue Type: Bug Reporter: Anton Kalashnikov Attachments: AffinityLostPartitionTest.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. At this moment some partitions from DN2 marked as LOST. 6)Start DN3. In fact all data was come back but affinity instead of DN3 use DN2 which have partitions(lost) with loss some data. Reproducer is attached. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10092) Race in partition state when checkpoint started at the middle of starts caches
[ https://issues.apache.org/jira/browse/IGNITE-10092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16671484#comment-16671484 ] ASF GitHub Bot commented on IGNITE-10092: - GitHub user vldpyatkov opened a pull request: https://github.com/apache/ignite/pull/5233 IGNITE-10092 Race in partition state when checkpoint started at the m… …iddle of starts caches You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-10092 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/5233.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 #5233 commit e0ee0c765b9e51fbb412582eaa91e92dbd2f3342 Author: vd-pyatkov Date: 2018-11-01T11:19:01Z IGNITE-10092 Race in partition state when checkpoint started at the middle of starts caches > Race in partition state when checkpoint started at the middle of starts caches > -- > > Key: IGNITE-10092 > URL: https://issues.apache.org/jira/browse/IGNITE-10092 > Project: Ignite > Issue Type: Bug >Reporter: Vladislav Pyatkov >Assignee: Vladislav Pyatkov >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9420) Move logical recovery phase outside of PME
[ https://issues.apache.org/jira/browse/IGNITE-9420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16671475#comment-16671475 ] Dmitriy Govorukhin commented on IGNITE-9420: [~Jokser] Changes looks good for me, thanks! > Move logical recovery phase outside of PME > -- > > Key: IGNITE-9420 > URL: https://issues.apache.org/jira/browse/IGNITE-9420 > Project: Ignite > Issue Type: Improvement > Components: cache >Affects Versions: 2.5 >Reporter: Pavel Kovalenko >Assignee: Pavel Kovalenko >Priority: Major > Labels: cache > Fix For: 2.8 > > > Currently, we perform logical recovery in PME here > org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager#restoreState > We should move logical recovery before discovery manager will start. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-10101) Web Console: Filed to get cache list on Query page.
[ https://issues.apache.org/jira/browse/IGNITE-10101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Novikov reassigned IGNITE-10101: --- Assignee: Vasiliy Sisko (was: Andrey Novikov) > Web Console: Filed to get cache list on Query page. > --- > > Key: IGNITE-10101 > URL: https://issues.apache.org/jira/browse/IGNITE-10101 > Project: Ignite > Issue Type: Bug > Components: wizards >Affects Versions: 2.8 >Reporter: Vasiliy Sisko >Assignee: Vasiliy Sisko >Priority: Major > Fix For: 2.8 > > Attachments: ignite-10101.png > > > On opening of Queries page: > # For scan query field with cache selection is empty > # For query list of caches is empty. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10110) SQL query with DISTINCT and JOIN in suquery produces "Column not found"
[
https://issues.apache.org/jira/browse/IGNITE-10110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Vinokurov updated IGNITE-10110:
-
Description:
Initial script:
CREATE TABLE Person(
person_id INTEGER PRIMARY KEY,
company_id INTEGER,
last_name VARCHAR(100)
);
CREATE TABLE Company(
company_id INTEGER PRIMARY KEY,
location_id INTEGER
);
CREATE TABLE Department(
department_id INTEGER PRIMARY KEY,
person_id INTEGER
);
CREATE TABLE Organization(
organization_id INTEGER PRIMARY KEY,
company_id INTEGER
);
Query:
{code:java}
SELECT
last_name
FROM
( SELECT
last_name,
person_id,
company_id
FROM
( SELECT
last_name,
person_id,
p.company_id as company_id
FROM
Person p
INNER JOIN
(
SELECT
DISTINCT location_id,
company_id
FROM
Company
WHERE
location_id = 1
) cpy
ON (
p.company_id = cpy.company_id
)
) a
) src
INNER JOIN
department dep
ON src.person_id = dep.person_id
LEFT JOIN
organization og
ON src.company_id = og.company_id
{code}
Result:
Caused by: org.h2.jdbc.JdbcSQLException: Column "SRC__Z4.COMPANY_ID" not found;
SQL statement:
SELECT
DEP__Z5.PERSON_ID __C2_0
FROM PUBLIC.DEPARTMENT DEP__Z5
LEFT OUTER JOIN PUBLIC.ORGANIZATION OG__Z6
ON SRC__Z4.COMPANY_ID = OG__Z6.COMPANY_ID
was:
Initial script:
CREATE TABLE Person(
person_id INTEGER PRIMARY KEY,
company_id INTEGER,
last_name VARCHAR(100)
);
CREATE TABLE Company(
company_id INTEGER PRIMARY KEY,
location_id INTEGER
);
CREATE TABLE Department(
department_id INTEGER PRIMARY KEY,
person_id INTEGER
);
CREATE TABLE Organization(
organization_id INTEGER PRIMARY KEY,
company_id INTEGER
);
Query:
SELECT
last_name
FROM
( SELECT
last_name,
person_id,
company_id
FROM
( SELECT
last_name,
person_id,
p.company_id as company_id
FROM
Person p
INNER JOIN
(
SELECT
DISTINCT location_id,
company_id
FROM
Company
WHERE
location_id = 1
) cpy
ON (
p.company_id = cpy.company_id
)
) a
) src
INNER JOIN
department dep
ON src.person_id = dep.person_id
LEFT JOIN
organization og
ON src.company_id = og.company_id
Result:
Caused by: org.h2.jdbc.JdbcSQLException: Column "SRC__Z4.COMPANY_ID" not found;
SQL statement:
SELECT
DEP__Z5.PERSON_ID __C2_0
FROM PUBLIC.DEPARTMENT DEP__Z5
LEFT OUTER JOIN PUBLIC.ORGANIZATION OG__Z6
ON SRC__Z4.COMPANY_ID = OG__Z6.COMPANY_ID
> SQL query with DISTINCT and JOIN in suquery produces "Column not found"
> -
>
> Key: IGNITE-10110
> URL: https://issues.apache.org/jira/browse/IGNITE-10110
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.4
>Reporter: Pavel Vinokurov
>Priority: Major
> Labels: sql
>
> Initial script:
> CREATE TABLE Person(
> person_id INTEGER PRIMARY KEY,
> company_id INTEGER,
> last_name VARCHAR(100)
> );
> CREATE TABLE Company(
> company_id INTEGER PRIMARY KEY,
> location_id INTEGER
> );
> CREATE TABLE Department(
> department_id INTEGER PRIMARY KEY,
> person_id INTEGER
> );
> CREATE TABLE Organization(
> organization_id INTEGER PRIMARY KEY,
> company_id INTEGER
> );
> Query:
> {code:java}
> SELECT
> last_name
> FROM
> ( SELECT
> last_name,
> person_id,
> company_id
> FROM
> ( SELECT
> last_name,
> person_id,
> p.company_id as company_id
> FROM
> Person p
> INNER JOIN
> (
> SELECT
> DISTINCT location_id,
> company_id
> FROM
> Company
> WHERE
> location_id = 1
> ) cpy
> ON (
> p.company_id = cpy.company_id
> )
> ) a
> ) src
> INNER JOIN
> department dep
> ON src.person_id = dep.person_id
> LEFT JOIN
> organization og
> ON src.company_id = og.company_id
> {code}
> Result:
> Caused by: org.h2.jdbc.JdbcSQLException: Column "SRC__Z4.COMPANY_ID" not
> found; SQL statement:
> SELECT
> DEP__Z5.PERSON_ID __C2_0
> FROM PUBLIC.DEPARTMENT DEP__Z5
> LEFT OUTER JOIN PUBLIC.ORGANIZATION OG__Z6
> ON SRC__Z4.COMPANY_ID = OG__Z6.COMPANY_ID
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10110) SQL query with DISTINCT and JOIN in suquery produces "Column not found"
[
https://issues.apache.org/jira/browse/IGNITE-10110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Vinokurov updated IGNITE-10110:
-
Description:
Initial script:
CREATE TABLE Person(
person_id INTEGER PRIMARY KEY,
company_id INTEGER,
last_name VARCHAR(100)
);
CREATE TABLE Company(
company_id INTEGER PRIMARY KEY,
location_id INTEGER
);
CREATE TABLE Department(
department_id INTEGER PRIMARY KEY,
person_id INTEGER
);
CREATE TABLE Organization(
organization_id INTEGER PRIMARY KEY,
company_id INTEGER
);
Query:
{code:java}
SELECT
last_name
FROM
( SELECT
last_name,
person_id,
company_id
FROM
( SELECT
last_name,
person_id,
p.company_id as company_id
FROM
Person p
INNER JOIN
(
SELECT
DISTINCT location_id,
company_id
FROM
Company
WHERE
location_id = 1
) cpy
ON (
p.company_id = cpy.company_id
)
) a
) src
INNER JOIN
department dep
ON src.person_id = dep.person_id
LEFT JOIN
organization og
ON src.company_id = og.company_id
{code}
Result:
Caused by: org.h2.jdbc.JdbcSQLException: Column "SRC__Z4.COMPANY_ID" not found;
SQL statement:
SELECT
DEP__Z5.PERSON_ID __C2_0
FROM PUBLIC.DEPARTMENT DEP__Z5
LEFT OUTER JOIN PUBLIC.ORGANIZATION OG__Z6
ON SRC__Z4.COMPANY_ID = OG__Z6.COMPANY_ID
was:
Initial script:
CREATE TABLE Person(
person_id INTEGER PRIMARY KEY,
company_id INTEGER,
last_name VARCHAR(100)
);
CREATE TABLE Company(
company_id INTEGER PRIMARY KEY,
location_id INTEGER
);
CREATE TABLE Department(
department_id INTEGER PRIMARY KEY,
person_id INTEGER
);
CREATE TABLE Organization(
organization_id INTEGER PRIMARY KEY,
company_id INTEGER
);
Query:
{code:java}
SELECT
last_name
FROM
( SELECT
last_name,
person_id,
company_id
FROM
( SELECT
last_name,
person_id,
p.company_id as company_id
FROM
Person p
INNER JOIN
(
SELECT
DISTINCT location_id,
company_id
FROM
Company
WHERE
location_id = 1
) cpy
ON (
p.company_id = cpy.company_id
)
) a
) src
INNER JOIN
department dep
ON src.person_id = dep.person_id
LEFT JOIN
organization og
ON src.company_id = og.company_id
{code}
Result:
Caused by: org.h2.jdbc.JdbcSQLException: Column "SRC__Z4.COMPANY_ID" not found;
SQL statement:
SELECT
DEP__Z5.PERSON_ID __C2_0
FROM PUBLIC.DEPARTMENT DEP__Z5
LEFT OUTER JOIN PUBLIC.ORGANIZATION OG__Z6
ON SRC__Z4.COMPANY_ID = OG__Z6.COMPANY_ID
> SQL query with DISTINCT and JOIN in suquery produces "Column not found"
> -
>
> Key: IGNITE-10110
> URL: https://issues.apache.org/jira/browse/IGNITE-10110
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.4
>Reporter: Pavel Vinokurov
>Priority: Major
> Labels: sql
>
> Initial script:
> CREATE TABLE Person(
> person_id INTEGER PRIMARY KEY,
> company_id INTEGER,
> last_name VARCHAR(100)
> );
> CREATE TABLE Company(
> company_id INTEGER PRIMARY KEY,
> location_id INTEGER
> );
> CREATE TABLE Department(
> department_id INTEGER PRIMARY KEY,
> person_id INTEGER
> );
> CREATE TABLE Organization(
> organization_id INTEGER PRIMARY KEY,
> company_id INTEGER
> );
> Query:
> {code:java}
> SELECT
> last_name
> FROM
> ( SELECT
> last_name,
> person_id,
> company_id
> FROM
> ( SELECT
> last_name,
> person_id,
> p.company_id as company_id
> FROM
> Person p
> INNER JOIN
> (
> SELECT
> DISTINCT location_id,
> company_id
> FROM
> Company
> WHERE
> location_id = 1
> ) cpy
> ON (
> p.company_id = cpy.company_id
> )
> ) a
> ) src
> INNER JOIN
> department dep
> ON src.person_id = dep.person_id
> LEFT JOIN
> organization og
> ON src.company_id = og.company_id
> {code}
> Result:
> Caused by: org.h2.jdbc.JdbcSQLException: Column "SRC__Z4.COMPANY_ID" not
> found; SQL statement:
> SELECT
> DEP__Z5.PERSON_ID __C2_0
> FROM PUBLIC.DEPARTMENT DEP__Z5
> LEFT OUTER JOIN PUBLIC.ORGANIZATION OG__Z6
> ON SRC__Z4.COMPANY_ID = OG__Z6.COMPANY_ID
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-10110) SQL query with DISTINCT and JOIN in suquery produces "Column not found"
[
https://issues.apache.org/jira/browse/IGNITE-10110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16671457#comment-16671457
]
Pavel Vinokurov edited comment on IGNITE-10110 at 11/1/18 10:48 AM:
{code:java}
SELECT
last_name
FROM
( SELECT
DISTINCT last_name,
person_id,
company_id
FROM Person
) src
INNER JOIN
department dep
ON src.person_id = dep.person_id
LEFT JOIN
organization og
ON src.company_id = og.company_id
{code}
was (Author: pvinokurov):
Simplified query:
SELECT
last_name
FROM
( SELECT
DISTINCT last_name,
person_id,
company_id
FROM Person
) src
INNER JOIN
department dep
ON src.person_id = dep.person_id
LEFT JOIN
organization og
ON src.company_id = og.company_id
> SQL query with DISTINCT and JOIN in suquery produces "Column not found"
> -
>
> Key: IGNITE-10110
> URL: https://issues.apache.org/jira/browse/IGNITE-10110
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.4
>Reporter: Pavel Vinokurov
>Priority: Major
> Labels: sql
>
> Initial script:
> CREATE TABLE Person(
> person_id INTEGER PRIMARY KEY,
> company_id INTEGER,
> last_name VARCHAR(100)
> );
> CREATE TABLE Company(
> company_id INTEGER PRIMARY KEY,
> location_id INTEGER
> );
> CREATE TABLE Department(
> department_id INTEGER PRIMARY KEY,
> person_id INTEGER
> );
> CREATE TABLE Organization(
> organization_id INTEGER PRIMARY KEY,
> company_id INTEGER
> );
> Query:
> SELECT
> last_name
> FROM
> ( SELECT
> last_name,
> person_id,
> company_id
> FROM
> ( SELECT
> last_name,
> person_id,
> p.company_id as company_id
> FROM
> Person p
> INNER JOIN
> (
> SELECT
> DISTINCT location_id,
> company_id
> FROM
> Company
> WHERE
> location_id = 1
> ) cpy
> ON (
> p.company_id = cpy.company_id
> )
> ) a
> ) src
> INNER JOIN
> department dep
> ON src.person_id = dep.person_id
> LEFT JOIN
> organization og
> ON src.company_id = og.company_id
> Result:
> Caused by: org.h2.jdbc.JdbcSQLException: Column "SRC__Z4.COMPANY_ID" not
> found; SQL statement:
> SELECT
> DEP__Z5.PERSON_ID __C2_0
> FROM PUBLIC.DEPARTMENT DEP__Z5
> LEFT OUTER JOIN PUBLIC.ORGANIZATION OG__Z6
> ON SRC__Z4.COMPANY_ID = OG__Z6.COMPANY_ID
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-10110) SQL query with DISTINCT and JOIN in suquery produces "Column not found"
[
https://issues.apache.org/jira/browse/IGNITE-10110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16671457#comment-16671457
]
Pavel Vinokurov edited comment on IGNITE-10110 at 11/1/18 10:48 AM:
Simplified query:
{code:java}
SELECT
last_name
FROM
( SELECT
DISTINCT last_name,
person_id,
company_id
FROM Person
) src
INNER JOIN
department dep
ON src.person_id = dep.person_id
LEFT JOIN
organization og
ON src.company_id = og.company_id
{code}
was (Author: pvinokurov):
{code:java}
SELECT
last_name
FROM
( SELECT
DISTINCT last_name,
person_id,
company_id
FROM Person
) src
INNER JOIN
department dep
ON src.person_id = dep.person_id
LEFT JOIN
organization og
ON src.company_id = og.company_id
{code}
> SQL query with DISTINCT and JOIN in suquery produces "Column not found"
> -
>
> Key: IGNITE-10110
> URL: https://issues.apache.org/jira/browse/IGNITE-10110
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.4
>Reporter: Pavel Vinokurov
>Priority: Major
> Labels: sql
>
> Initial script:
> CREATE TABLE Person(
> person_id INTEGER PRIMARY KEY,
> company_id INTEGER,
> last_name VARCHAR(100)
> );
> CREATE TABLE Company(
> company_id INTEGER PRIMARY KEY,
> location_id INTEGER
> );
> CREATE TABLE Department(
> department_id INTEGER PRIMARY KEY,
> person_id INTEGER
> );
> CREATE TABLE Organization(
> organization_id INTEGER PRIMARY KEY,
> company_id INTEGER
> );
> Query:
> SELECT
> last_name
> FROM
> ( SELECT
> last_name,
> person_id,
> company_id
> FROM
> ( SELECT
> last_name,
> person_id,
> p.company_id as company_id
> FROM
> Person p
> INNER JOIN
> (
> SELECT
> DISTINCT location_id,
> company_id
> FROM
> Company
> WHERE
> location_id = 1
> ) cpy
> ON (
> p.company_id = cpy.company_id
> )
> ) a
> ) src
> INNER JOIN
> department dep
> ON src.person_id = dep.person_id
> LEFT JOIN
> organization og
> ON src.company_id = og.company_id
> Result:
> Caused by: org.h2.jdbc.JdbcSQLException: Column "SRC__Z4.COMPANY_ID" not
> found; SQL statement:
> SELECT
> DEP__Z5.PERSON_ID __C2_0
> FROM PUBLIC.DEPARTMENT DEP__Z5
> LEFT OUTER JOIN PUBLIC.ORGANIZATION OG__Z6
> ON SRC__Z4.COMPANY_ID = OG__Z6.COMPANY_ID
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10110) SQL query with DISTINCT and JOIN in suquery produces "Column not found"
[ https://issues.apache.org/jira/browse/IGNITE-10110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16671457#comment-16671457 ] Pavel Vinokurov commented on IGNITE-10110: -- Simplified query: SELECT last_name FROM ( SELECT DISTINCT last_name, person_id, company_id FROM Person ) src INNER JOIN department dep ON src.person_id = dep.person_id LEFT JOIN organization og ON src.company_id = og.company_id > SQL query with DISTINCT and JOIN in suquery produces "Column not found" > - > > Key: IGNITE-10110 > URL: https://issues.apache.org/jira/browse/IGNITE-10110 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.4 >Reporter: Pavel Vinokurov >Priority: Major > Labels: sql > > Initial script: > CREATE TABLE Person( > person_id INTEGER PRIMARY KEY, > company_id INTEGER, > last_name VARCHAR(100) > ); > CREATE TABLE Company( > company_id INTEGER PRIMARY KEY, > location_id INTEGER > ); > CREATE TABLE Department( > department_id INTEGER PRIMARY KEY, > person_id INTEGER > ); > CREATE TABLE Organization( > organization_id INTEGER PRIMARY KEY, > company_id INTEGER > ); > Query: > SELECT > last_name > FROM > ( SELECT > last_name, > person_id, > company_id > FROM > ( SELECT > last_name, > person_id, > p.company_id as company_id > FROM > Person p > INNER JOIN > ( > SELECT > DISTINCT location_id, > company_id > FROM > Company > WHERE > location_id = 1 > ) cpy > ON ( > p.company_id = cpy.company_id > ) > ) a > ) src > INNER JOIN > department dep > ON src.person_id = dep.person_id > LEFT JOIN > organization og > ON src.company_id = og.company_id > Result: > Caused by: org.h2.jdbc.JdbcSQLException: Column "SRC__Z4.COMPANY_ID" not > found; SQL statement: > SELECT > DEP__Z5.PERSON_ID __C2_0 > FROM PUBLIC.DEPARTMENT DEP__Z5 > LEFT OUTER JOIN PUBLIC.ORGANIZATION OG__Z6 > ON SRC__Z4.COMPANY_ID = OG__Z6.COMPANY_ID -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10101) Web Console: Filed to get cache list on Query page.
[ https://issues.apache.org/jira/browse/IGNITE-10101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Novikov updated IGNITE-10101: Summary: Web Console: Filed to get cache list on Query page. (was: Filed to get cache list on Query page.) > Web Console: Filed to get cache list on Query page. > --- > > Key: IGNITE-10101 > URL: https://issues.apache.org/jira/browse/IGNITE-10101 > Project: Ignite > Issue Type: Bug > Components: wizards >Affects Versions: 2.8 >Reporter: Vasiliy Sisko >Assignee: Andrey Novikov >Priority: Major > Attachments: ignite-10101.png > > > On opening of Queries page: > # For scan query field with cache selection is empty > # For query list of caches is empty. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9970) Add ability to set nodeId for VisorIdleVerifyDumpTask executed from ./control.sh --host HOST --cache idle_verify
[
https://issues.apache.org/jira/browse/IGNITE-9970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16671433#comment-16671433
]
Alexey Stelmak commented on IGNITE-9970:
PR: https://github.com/apache/ignite/pull/5227
> Add ability to set nodeId for VisorIdleVerifyDumpTask executed from
> ./control.sh --host HOST --cache idle_verify
>
>
> Key: IGNITE-9970
> URL: https://issues.apache.org/jira/browse/IGNITE-9970
> Project: Ignite
> Issue Type: Improvement
>Reporter: Pavel Voronkin
>Assignee: Alexey Stelmak
>Priority: Major
>
> --cache idle_verify sets null nodeId on invocation of
> private R executeTaskByNameOnNode(GridClient client, String taskClsName,
> Object taskArgs, UUID nodeId
> ) throws GridClientException {
>
> Which causes reduce phase to be assigned on random node, we want to dump
> results on particular node.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-7955) MVCC TX: cache peek for key-value API
[
https://issues.apache.org/jira/browse/IGNITE-7955?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16671416#comment-16671416
]
Ivan Pavlukhin edited comment on IGNITE-7955 at 11/1/18 10:20 AM:
--
Attention should be also paid on peek modes for unsupported behavior. They are
{{NEAR, ONHEAP}} (keep an {{ALL}} peek mode in mind).
was (Author: pavlukhin):
Attention should be also paid on peek modes for unsupported behavior. They are
{NEAR, ONHEAP} (keep an {ALL} peek mode in mind).
> MVCC TX: cache peek for key-value API
> -
>
> Key: IGNITE-7955
> URL: https://issues.apache.org/jira/browse/IGNITE-7955
> Project: Ignite
> Issue Type: Task
> Components: cache, mvcc
>Reporter: Alexander Paschenko
>Assignee: Ivan Pavlukhin
>Priority: Major
> Fix For: 2.8
>
>
> We need to implement MVCC-compatible cache peek operation for key-value API.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-7955) MVCC TX: cache peek for key-value API
[
https://issues.apache.org/jira/browse/IGNITE-7955?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16671416#comment-16671416
]
Ivan Pavlukhin commented on IGNITE-7955:
Attention should be also paid on peek modes for unsupported behavior. They are
{NEAR, ONHEAP} (keep an {ALL} peek mode in mind).
> MVCC TX: cache peek for key-value API
> -
>
> Key: IGNITE-7955
> URL: https://issues.apache.org/jira/browse/IGNITE-7955
> Project: Ignite
> Issue Type: Task
> Components: cache, mvcc
>Reporter: Alexander Paschenko
>Assignee: Ivan Pavlukhin
>Priority: Major
> Fix For: 2.8
>
>
> We need to implement MVCC-compatible cache peek operation for key-value API.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-9582) Document Model Updating
[ https://issues.apache.org/jira/browse/IGNITE-9582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Babak reassigned IGNITE-9582: -- Assignee: Akmal Chaudhri (was: Yury Babak) [~abchaudhri] please check related page on readme io > Document Model Updating > --- > > Key: IGNITE-9582 > URL: https://issues.apache.org/jira/browse/IGNITE-9582 > Project: Ignite > Issue Type: Task > Components: documentation, ml >Reporter: Aleksey Zinoviev >Assignee: Akmal Chaudhri >Priority: Major > > The documentation for the new page with name "Model Updating / Online > Learning" > [https://docs.google.com/document/d/113WZTNdge0Ubom8RndnpOsPZ7yetYT9jZx16Fp_uJhE/edit?usp=sharing] > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9420) Move logical recovery phase outside of PME
[ https://issues.apache.org/jira/browse/IGNITE-9420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16671408#comment-16671408 ] Pavel Kovalenko commented on IGNITE-9420: - Link for review https://reviews.ignite.apache.org/ignite/review/IGNT-CR-940 > Move logical recovery phase outside of PME > -- > > Key: IGNITE-9420 > URL: https://issues.apache.org/jira/browse/IGNITE-9420 > Project: Ignite > Issue Type: Improvement > Components: cache >Affects Versions: 2.5 >Reporter: Pavel Kovalenko >Assignee: Pavel Kovalenko >Priority: Major > Labels: cache > Fix For: 2.8 > > > Currently, we perform logical recovery in PME here > org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager#restoreState > We should move logical recovery before discovery manager will start. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-10103) Fix IgnitePersistentStoreDataStructuresTest.testSequenceAfterAutoactivation
[ https://issues.apache.org/jira/browse/IGNITE-10103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16671406#comment-16671406 ] Ivan Pavlukhin edited comment on IGNITE-10103 at 11/1/18 10:14 AM: --- [~slukyanov] An original test purpose was to ensure that `atomicSequence` call does not hang. Fair awaiting for an activation would break an experiment. was (Author: pavlukhin): [~slukyanov] Original test purpose was to ensure that `atomicSequence` call does not hang. Fair awaiting for an activation would break an experiment. > Fix IgnitePersistentStoreDataStructuresTest.testSequenceAfterAutoactivation > --- > > Key: IGNITE-10103 > URL: https://issues.apache.org/jira/browse/IGNITE-10103 > Project: Ignite > Issue Type: Bug > Components: cache >Reporter: Ivan Pavlukhin >Assignee: Ivan Pavlukhin >Priority: Major > Labels: MakeTeamcityGreenAgain > > IgnitePersistentStoreDataStructuresTest.testSequenceAfterAutoactivation can > fail with exception stating that the cluster is not activated. A proposed fix > is catching exception and retrying an operation until success. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10103) Fix IgnitePersistentStoreDataStructuresTest.testSequenceAfterAutoactivation
[ https://issues.apache.org/jira/browse/IGNITE-10103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16671406#comment-16671406 ] Ivan Pavlukhin commented on IGNITE-10103: - [~slukyanov] Original test purpose was to ensure that `atomicSequence` call does not hang. Fair awaiting for an activation would break an experiment. > Fix IgnitePersistentStoreDataStructuresTest.testSequenceAfterAutoactivation > --- > > Key: IGNITE-10103 > URL: https://issues.apache.org/jira/browse/IGNITE-10103 > Project: Ignite > Issue Type: Bug > Components: cache >Reporter: Ivan Pavlukhin >Assignee: Ivan Pavlukhin >Priority: Major > Labels: MakeTeamcityGreenAgain > > IgnitePersistentStoreDataStructuresTest.testSequenceAfterAutoactivation can > fail with exception stating that the cluster is not activated. A proposed fix > is catching exception and retrying an operation until success. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9420) Move logical recovery phase outside of PME
[ https://issues.apache.org/jira/browse/IGNITE-9420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16671405#comment-16671405 ] ASF GitHub Bot commented on IGNITE-9420: GitHub user Jokser opened a pull request: https://github.com/apache/ignite/pull/5232 IGNITE-9420 Logical recovery (squash just for review) You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-9420-squash-2 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/5232.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 #5232 commit bfe7cd8a9d83092140b642505b880a8c7b369e2e Author: Pavel Kovalenko Date: 2018-11-01T10:10:40Z IGNITE-9420 Logical recovery (squash just for review) > Move logical recovery phase outside of PME > -- > > Key: IGNITE-9420 > URL: https://issues.apache.org/jira/browse/IGNITE-9420 > Project: Ignite > Issue Type: Improvement > Components: cache >Affects Versions: 2.5 >Reporter: Pavel Kovalenko >Assignee: Pavel Kovalenko >Priority: Major > Labels: cache > Fix For: 2.8 > > > Currently, we perform logical recovery in PME here > org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager#restoreState > We should move logical recovery before discovery manager will start. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9420) Move logical recovery phase outside of PME
[ https://issues.apache.org/jira/browse/IGNITE-9420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16671400#comment-16671400 ] ASF GitHub Bot commented on IGNITE-9420: Github user Jokser closed the pull request at: https://github.com/apache/ignite/pull/5016 > Move logical recovery phase outside of PME > -- > > Key: IGNITE-9420 > URL: https://issues.apache.org/jira/browse/IGNITE-9420 > Project: Ignite > Issue Type: Improvement > Components: cache >Affects Versions: 2.5 >Reporter: Pavel Kovalenko >Assignee: Pavel Kovalenko >Priority: Major > Labels: cache > Fix For: 2.8 > > > Currently, we perform logical recovery in PME here > org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager#restoreState > We should move logical recovery before discovery manager will start. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9420) Move logical recovery phase outside of PME
[ https://issues.apache.org/jira/browse/IGNITE-9420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16671399#comment-16671399 ] ASF GitHub Bot commented on IGNITE-9420: Github user Jokser closed the pull request at: https://github.com/apache/ignite/pull/5212 > Move logical recovery phase outside of PME > -- > > Key: IGNITE-9420 > URL: https://issues.apache.org/jira/browse/IGNITE-9420 > Project: Ignite > Issue Type: Improvement > Components: cache >Affects Versions: 2.5 >Reporter: Pavel Kovalenko >Assignee: Pavel Kovalenko >Priority: Major > Labels: cache > Fix For: 2.8 > > > Currently, we perform logical recovery in PME here > org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager#restoreState > We should move logical recovery before discovery manager will start. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-9582) Document Model Updating
[ https://issues.apache.org/jira/browse/IGNITE-9582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Babak reassigned IGNITE-9582: -- Assignee: Yury Babak (was: Denis Magda) > Document Model Updating > --- > > Key: IGNITE-9582 > URL: https://issues.apache.org/jira/browse/IGNITE-9582 > Project: Ignite > Issue Type: Task > Components: documentation, ml >Reporter: Aleksey Zinoviev >Assignee: Yury Babak >Priority: Major > > The documentation for the new page with name "Model Updating / Online > Learning" > [https://docs.google.com/document/d/113WZTNdge0Ubom8RndnpOsPZ7yetYT9jZx16Fp_uJhE/edit?usp=sharing] > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10103) Fix IgnitePersistentStoreDataStructuresTest.testSequenceAfterAutoactivation
[ https://issues.apache.org/jira/browse/IGNITE-10103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16671392#comment-16671392 ] Stanislav Lukyanov commented on IGNITE-10103: - Took a look at the patch - I'd rather waited for activation, either via `active(true)` or `awaitForPartitionMapExchange()`. > Fix IgnitePersistentStoreDataStructuresTest.testSequenceAfterAutoactivation > --- > > Key: IGNITE-10103 > URL: https://issues.apache.org/jira/browse/IGNITE-10103 > Project: Ignite > Issue Type: Bug > Components: cache >Reporter: Ivan Pavlukhin >Assignee: Ivan Pavlukhin >Priority: Major > Labels: MakeTeamcityGreenAgain > > IgnitePersistentStoreDataStructuresTest.testSequenceAfterAutoactivation can > fail with exception stating that the cluster is not activated. A proposed fix > is catching exception and retrying an operation until success. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7153) Redis: BufferUnderflowException at GridRedisProtocolParser.readBulkStr for values > 8kb
[
https://issues.apache.org/jira/browse/IGNITE-7153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16671386#comment-16671386
]
Roman Shtykh commented on IGNITE-7153:
--
[~dpavlov] Sure, but can't do that – 'No matches found.' [~mcfongtw], thanks
for the fix! Please go ahead and reassign to yourself.
> Redis: BufferUnderflowException at GridRedisProtocolParser.readBulkStr for
> values > 8kb
> ---
>
> Key: IGNITE-7153
> URL: https://issues.apache.org/jira/browse/IGNITE-7153
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 2.3
> Environment: Win, PHP 7, php_redis-3.1.1-7.0
>Reporter: Alexey Popov
>Assignee: Roman Shtykh
>Priority: Major
> Labels: redis
>
> Exception:
> {noformat}
> [15:03:23,690][SEVERE][grid-nio-worker-tcp-rest-0-#36][GridTcpRestProtocol]
> Failed to process selector key [ses=GridSelectorNioSessionImpl
> [worker=ByteBufferNioClientWorker [readBuf=java.nio.HeapByteBuffer[pos=28
> lim=8192 cap=8192], super=AbstractNioClientWorker [idx=0, bytesRcvd=0,
> bytesSent=0, bytesRcvd0=0, bytesSent0=0, select=true, super=GridWorker
> [name=grid-nio-worker-tcp-rest-0, igniteInstanceName=null, finished=false,
> hashCode=396395638, interrupted=false,
> runner=grid-nio-worker-tcp-rest-0-#36]]], writeBuf=null, readBuf=null,
> inRecovery=null, outRecovery=null, super=GridNioSessionImpl
> [locAddr=/127.0.0.1:6380, rmtAddr=/127.0.0.1:51794, createTime=1512734602674,
> closeTime=0, bytesSent=0, bytesRcvd=8192, bytesSent0=0, bytesRcvd0=8192,
> sndSchedTime=1512734602674, lastSndTime=1512734602674,
> lastRcvTime=1512734602674, readsPaused=false,
> filterChain=FilterChain[filters=[GridNioCodecFilter [parser=GridTcpRestParser
> [jdkMarshaller=JdkMarshaller [], routerClient=false], directMode=false]],
> accepted=true]]]
> java.nio.BufferUnderflowException
> at java.nio.HeapByteBuffer.get(HeapByteBuffer.java:151)
> at
> org.apache.ignite.internal.processors.rest.protocols.tcp.redis.GridRedisProtocolParser.readBulkStr(GridRedisProtocolParser.java:107)
> at
> org.apache.ignite.internal.processors.rest.protocols.tcp.redis.GridRedisProtocolParser.readArray(GridRedisProtocolParser.java:86)
> at
> org.apache.ignite.internal.processors.rest.protocols.tcp.GridTcpRestParser.decode(GridTcpRestParser.java:150)
> at
> org.apache.ignite.internal.processors.rest.protocols.tcp.GridTcpRestParser.decode(GridTcpRestParser.java:70)
> at
> org.apache.ignite.internal.util.nio.GridNioCodecFilter.onMessageReceived(GridNioCodecFilter.java:114)
> at
> org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedMessageReceived(GridNioFilterAdapter.java:109)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$HeadFilter.onMessageReceived(GridNioServer.java:3392)
> at
> org.apache.ignite.internal.util.nio.GridNioFilterChain.onMessageReceived(GridNioFilterChain.java:175)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$ByteBufferNioClientWorker.processRead(GridNioServer.java:1096)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.processSelectedKeysOptimized(GridNioServer.java:2272)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.bodyInternal(GridNioServer.java:2048)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.body(GridNioServer.java:1717)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:748)
> [15:03:23,691][SEVERE][grid-nio-worker-tcp-rest-0-#36][GridTcpRestProtocol]
> Closing NIO session because of unhandled exception.
> class org.apache.ignite.internal.util.nio.GridNioException: null
> at
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.processSelectedKeysOptimized(GridNioServer.java:2296)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.bodyInternal(GridNioServer.java:2048)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.body(GridNioServer.java:1717)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.nio.BufferUnderflowException
> at java.nio.HeapByteBuffer.get(HeapByteBuffer.java:151)
> at
> org.apache.ignite.internal.processors.rest.protocols.tcp.redis.GridRedisProtocolParser.readBulkStr(GridRedisProtocolParser.java:107)
> at
> org.apache.ignite.internal.processors.rest.protocols.tcp.redis.GridRedisProtocolParser.readArray(GridRedisProtocolParser.java:86)
> at
>
[jira] [Commented] (IGNITE-9579) Document Random Forest
[ https://issues.apache.org/jira/browse/IGNITE-9579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16671384#comment-16671384 ] Yury Babak commented on IGNITE-9579: [~abchaudhri], please check related page on readme io site > Document Random Forest > -- > > Key: IGNITE-9579 > URL: https://issues.apache.org/jira/browse/IGNITE-9579 > Project: Ignite > Issue Type: Task > Components: documentation, ml >Reporter: Aleksey Zinoviev >Assignee: Akmal Chaudhri >Priority: Major > Fix For: 2.7 > > Attachments: Random Forest.docx > > > The link for new page with name "Random Forest" is here > https://docs.google.com/document/d/14t67HlWBaoV91887NjqbrsT0dAuExIxUOxYiaIbwEt4/edit?usp=sharing -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10103) Fix IgnitePersistentStoreDataStructuresTest.testSequenceAfterAutoactivation
[ https://issues.apache.org/jira/browse/IGNITE-10103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16671379#comment-16671379 ] Ivan Pavlukhin commented on IGNITE-10103: - Run only a touched suite on TC as changes were made only in one test. > Fix IgnitePersistentStoreDataStructuresTest.testSequenceAfterAutoactivation > --- > > Key: IGNITE-10103 > URL: https://issues.apache.org/jira/browse/IGNITE-10103 > Project: Ignite > Issue Type: Bug > Components: cache >Reporter: Ivan Pavlukhin >Assignee: Ivan Pavlukhin >Priority: Major > Labels: MakeTeamcityGreenAgain > > IgnitePersistentStoreDataStructuresTest.testSequenceAfterAutoactivation can > fail with exception stating that the cluster is not activated. A proposed fix > is catching exception and retrying an operation until success. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9237) [ML] Random forest optimization
[ https://issues.apache.org/jira/browse/IGNITE-9237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Platonov updated IGNITE-9237: Ignite Flags: (was: Docs Required) > [ML] Random forest optimization > --- > > Key: IGNITE-9237 > URL: https://issues.apache.org/jira/browse/IGNITE-9237 > Project: Ignite > Issue Type: Improvement > Components: ml >Reporter: Yury Babak >Assignee: Alexey Platonov >Priority: Major > Fix For: 2.7 > > > We need to implement best split selection by statistics over impurity data > and share this data for several nodes in several trees while learning process. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9064) Decision tree optimization
[ https://issues.apache.org/jira/browse/IGNITE-9064?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Platonov updated IGNITE-9064: Ignite Flags: (was: Docs Required) > Decision tree optimization > -- > > Key: IGNITE-9064 > URL: https://issues.apache.org/jira/browse/IGNITE-9064 > Project: Ignite > Issue Type: Improvement > Components: ml >Reporter: Yury Babak >Assignee: Alexey Platonov >Priority: Major > Fix For: 2.7 > > > We need to optimize impurity function calculation by additional index > structure for all sorted features and reusing it in learning iterations. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9065) Gradient boosting optimization
[ https://issues.apache.org/jira/browse/IGNITE-9065?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Platonov updated IGNITE-9065: Ignite Flags: (was: Docs Required) > 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] [Created] (IGNITE-10110) SQL query with DISTINCT and JOIN in suquery produces "Column not found"
Pavel Vinokurov created IGNITE-10110: Summary: SQL query with DISTINCT and JOIN in suquery produces "Column not found" Key: IGNITE-10110 URL: https://issues.apache.org/jira/browse/IGNITE-10110 Project: Ignite Issue Type: Bug Components: sql Affects Versions: 2.4 Reporter: Pavel Vinokurov Initial script: CREATE TABLE Person( person_id INTEGER PRIMARY KEY, company_id INTEGER, last_name VARCHAR(100) ); CREATE TABLE Company( company_id INTEGER PRIMARY KEY, location_id INTEGER ); CREATE TABLE Department( department_id INTEGER PRIMARY KEY, person_id INTEGER ); CREATE TABLE Organization( organization_id INTEGER PRIMARY KEY, company_id INTEGER ); Query: SELECT last_name FROM ( SELECT last_name, person_id, company_id FROM ( SELECT last_name, person_id, p.company_id as company_id FROM Person p INNER JOIN ( SELECT DISTINCT location_id, company_id FROM Company WHERE location_id = 1 ) cpy ON ( p.company_id = cpy.company_id ) ) a ) src INNER JOIN department dep ON src.person_id = dep.person_id LEFT JOIN organization og ON src.company_id = og.company_id Result: Caused by: org.h2.jdbc.JdbcSQLException: Column "SRC__Z4.COMPANY_ID" not found; SQL statement: SELECT DEP__Z5.PERSON_ID __C2_0 FROM PUBLIC.DEPARTMENT DEP__Z5 LEFT OUTER JOIN PUBLIC.ORGANIZATION OG__Z6 ON SRC__Z4.COMPANY_ID = OG__Z6.COMPANY_ID -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10109) MVCC TX: data become inconsistent after several updates
[ https://issues.apache.org/jira/browse/IGNITE-10109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-10109: - Ignite Flags: (was: Docs Required) > MVCC TX: data become inconsistent after several updates > --- > > Key: IGNITE-10109 > URL: https://issues.apache.org/jira/browse/IGNITE-10109 > Project: Ignite > Issue Type: Bug > Components: mvcc >Reporter: Igor Seliverstov >Assignee: Igor Seliverstov >Priority: Major > Fix For: 2.7 > > > see [TC test > history|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=4365543959682167276=testDetails] > Here we do concurrent updates on several accounts (update their balances > incrementing one and decrementing another), we expect consistent sum of all > accounts at any time. > The sum become inconsistent after while. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9412) [ML] GDB convergence by error support.
[ https://issues.apache.org/jira/browse/IGNITE-9412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Platonov updated IGNITE-9412: Ignite Flags: (was: Docs Required) > [ML] GDB convergence by error support. > -- > > Key: IGNITE-9412 > URL: https://issues.apache.org/jira/browse/IGNITE-9412 > Project: Ignite > Issue Type: Improvement > Components: ml >Reporter: Yury Babak >Assignee: Alexey Platonov >Priority: Major > Fix For: 2.7 > > > We need to support early training interruption when GDB has small error rate > on learning sample -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-9782) Webconsole: Form too large
[
https://issues.apache.org/jira/browse/IGNITE-9782?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Medvedev reassigned IGNITE-9782:
---
Assignee: Alexey Kuznetsov (was: Andrew Medvedev)
> Webconsole: Form too large
> --
>
> Key: IGNITE-9782
> URL: https://issues.apache.org/jira/browse/IGNITE-9782
> Project: Ignite
> Issue Type: Bug
>Reporter: Andrew Medvedev
>Assignee: Alexey Kuznetsov
>Priority: Major
> Attachments: image.png
>
>
> On large topologies form size increases jetty defaults
> Consider increasing "{{org.mortbay.jetty.Request.maxFormContentSize}}"
>
> !image.png!
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-9782) Webconsole: Form too large
[
https://issues.apache.org/jira/browse/IGNITE-9782?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Medvedev reassigned IGNITE-9782:
---
Assignee: Andrew Medvedev
> Webconsole: Form too large
> --
>
> Key: IGNITE-9782
> URL: https://issues.apache.org/jira/browse/IGNITE-9782
> Project: Ignite
> Issue Type: Bug
>Reporter: Andrew Medvedev
>Assignee: Andrew Medvedev
>Priority: Major
> Attachments: image.png
>
>
> On large topologies form size increases jetty defaults
> Consider increasing "{{org.mortbay.jetty.Request.maxFormContentSize}}"
>
> !image.png!
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9420) Move logical recovery phase outside of PME
[ https://issues.apache.org/jira/browse/IGNITE-9420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16671360#comment-16671360 ] Pavel Kovalenko commented on IGNITE-9420: - Actual branch to merge is ignite-9420-proper-recovery > Move logical recovery phase outside of PME > -- > > Key: IGNITE-9420 > URL: https://issues.apache.org/jira/browse/IGNITE-9420 > Project: Ignite > Issue Type: Improvement > Components: cache >Affects Versions: 2.5 >Reporter: Pavel Kovalenko >Assignee: Pavel Kovalenko >Priority: Major > Labels: cache > Fix For: 2.8 > > > Currently, we perform logical recovery in PME here > org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager#restoreState > We should move logical recovery before discovery manager will start. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9420) Move logical recovery phase outside of PME
[ https://issues.apache.org/jira/browse/IGNITE-9420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16671357#comment-16671357 ] Pavel Kovalenko commented on IGNITE-9420: - [~agoncharuk] [~DmitriyGovorukhin] Changes are ready. Summary: # Logical recovery is moved outside of PME as next stage of binary recovery implemented there IGNITE-7196 # In logical recovery stage WAL resumes logging but allows to log only Page Delta and Page Snapshot records. # Before logical updates will be applied all locally available caches start in special "recovery mode". In this mode cache group offheap manager can apply cache updates from WAL and create/restore partitions. Other parts that require discovery (preloading, affinity fetching) are off. # After logical updates were applied all cache groups restore their latest partition states and WAL manager is deactivated. # First PME (node join to active cluster or activation) finishes recovery for all caches and groups that were started in the recovery phase enabling preloading, affinity fetching and attaching start topology version. > Move logical recovery phase outside of PME > -- > > Key: IGNITE-9420 > URL: https://issues.apache.org/jira/browse/IGNITE-9420 > Project: Ignite > Issue Type: Improvement > Components: cache >Affects Versions: 2.5 >Reporter: Pavel Kovalenko >Assignee: Pavel Kovalenko >Priority: Major > Labels: cache > Fix For: 2.8 > > > Currently, we perform logical recovery in PME here > org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager#restoreState > We should move logical recovery before discovery manager will start. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9557) Assert exception on explain of any update query.
[
https://issues.apache.org/jira/browse/IGNITE-9557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Kuznetsov updated IGNITE-9557:
Summary: Assert exception on explain of any update query. (was: Assert
exception on explain of DELETE query.)
> Assert exception on explain of any update query.
>
>
> Key: IGNITE-9557
> URL: https://issues.apache.org/jira/browse/IGNITE-9557
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Vasiliy Sisko
>Assignee: Pavel Kuznetsov
>Priority: Major
> Fix For: 2.8
>
>
> On execution of an query:
> {code:java}
> explain delete from "schema".type {code}
> received exception:
> {code:java}
> java.lang.AssertionError
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.parseAndSplit(IgniteH2Indexing.java:2309)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.querySqlFields(IgniteH2Indexing.java:2105)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:2139)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:2134)
> at
> org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2711)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2148)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2083)
> at
> org.apache.ignite.internal.visor.query.VisorQueryTask$VisorQueryJob.run(VisorQueryTask.java:94)
> at
> org.apache.ignite.internal.visor.query.VisorQueryTask$VisorQueryJob.run(VisorQueryTask.java:59)
> at org.apache.ignite.internal.visor.VisorJob.execute(VisorJob.java:69)
> at
> org.apache.ignite.internal.processors.job.GridJobWorker$2.call(GridJobWorker.java:568)
> at
> org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:6765)
> at
> org.apache.ignite.internal.processors.job.GridJobWorker.execute0(GridJobWorker.java:562)
> at
> org.apache.ignite.internal.processors.job.GridJobWorker.body(GridJobWorker.java:491)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at
> org.apache.ignite.internal.processors.job.GridJobProcessor.processJobExecuteRequest(GridJobProcessor.java:1125)
> at
> org.apache.ignite.internal.processors.task.GridTaskWorker.sendRequest(GridTaskWorker.java:1420)
> at
> org.apache.ignite.internal.processors.task.GridTaskWorker.processMappedJobs(GridTaskWorker.java:666)
> at
> org.apache.ignite.internal.processors.task.GridTaskWorker.body(GridTaskWorker.java:538)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at
> org.apache.ignite.internal.processors.task.GridTaskProcessor.startTask(GridTaskProcessor.java:764)
> at
> org.apache.ignite.internal.processors.task.GridTaskProcessor.execute(GridTaskProcessor.java:509)
> at
> org.apache.ignite.internal.IgniteComputeImpl.executeAsync0(IgniteComputeImpl.java:488)
> at
> org.apache.ignite.internal.IgniteComputeImpl.executeAsync(IgniteComputeImpl.java:468)
> at
> org.apache.ignite.internal.visor.compute.VisorGatewayTask$VisorGatewayJob.execute(VisorGatewayTask.java:462)
> at
> org.apache.ignite.internal.processors.job.GridJobWorker$2.call(GridJobWorker.java:568)
> at
> org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:6765)
> at
> org.apache.ignite.internal.processors.job.GridJobWorker.execute0(GridJobWorker.java:562)
> at
> org.apache.ignite.internal.processors.job.GridJobWorker.body(GridJobWorker.java:491)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at
> org.apache.ignite.internal.processors.job.GridJobProcessor.processJobExecuteRequest(GridJobProcessor.java:1125)
> at
> org.apache.ignite.internal.processors.task.GridTaskWorker.sendRequest(GridTaskWorker.java:1420)
> at
> org.apache.ignite.internal.processors.task.GridTaskWorker.processMappedJobs(GridTaskWorker.java:666)
> at
> org.apache.ignite.internal.processors.task.GridTaskWorker.body(GridTaskWorker.java:538)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at
> org.apache.ignite.internal.processors.task.GridTaskProcessor.startTask(GridTaskProcessor.java:764)
> at
> org.apache.ignite.internal.processors.task.GridTaskProcessor.execute(GridTaskProcessor.java:509)
> at
>
[jira] [Closed] (IGNITE-7926) Web console: demo faled to start under java >= 9
[ https://issues.apache.org/jira/browse/IGNITE-7926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Novikov closed IGNITE-7926. -- > Web console: demo faled to start under java >= 9 > > > Key: IGNITE-7926 > URL: https://issues.apache.org/jira/browse/IGNITE-7926 > Project: Ignite > Issue Type: Bug > Components: wizards >Affects Versions: 2.4 >Reporter: Pavel Konstantinov >Assignee: Andrey Novikov >Priority: Minor > Fix For: 2.7 > > > We need to add support for Java 9 to web console demo. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7926) Web console: demo faled to start under java >= 9
[ https://issues.apache.org/jira/browse/IGNITE-7926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16671340#comment-16671340 ] ASF GitHub Bot commented on IGNITE-7926: Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/5221 > Web console: demo faled to start under java >= 9 > > > Key: IGNITE-7926 > URL: https://issues.apache.org/jira/browse/IGNITE-7926 > Project: Ignite > Issue Type: Bug > Components: wizards >Affects Versions: 2.4 >Reporter: Pavel Konstantinov >Assignee: Andrey Novikov >Priority: Minor > Fix For: 2.7 > > > We need to add support for Java 9 to web console demo. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10109) MVCC TX: data become inconsistent after several updates
Igor Seliverstov created IGNITE-10109: - Summary: MVCC TX: data become inconsistent after several updates Key: IGNITE-10109 URL: https://issues.apache.org/jira/browse/IGNITE-10109 Project: Ignite Issue Type: Bug Components: mvcc Reporter: Igor Seliverstov Assignee: Igor Seliverstov Fix For: 2.7 see [TC test history|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=4365543959682167276=testDetails] Here we do concurrent updates on several accounts (update their balances incrementing one and decrementing another), we expect consistent sum of all accounts at any time. The sum become inconsistent after while. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-5883) Ignite Start Nodes test suite is flaky
[ https://issues.apache.org/jira/browse/IGNITE-5883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Medvedev reassigned IGNITE-5883: --- Assignee: (was: Andrew Medvedev) > Ignite Start Nodes test suite is flaky > -- > > Key: IGNITE-5883 > URL: https://issues.apache.org/jira/browse/IGNITE-5883 > Project: Ignite > Issue Type: Bug >Reporter: Ivan Rakov >Priority: Major > Labels: MakeTeamcityGreenAgain > > Ignite Start Nodes suite contains several flaky tests. > Example runs with sporadic fails: > 1) > http://ci.ignite.apache.org/viewLog.html?buildId=746188=buildResultsDiv=Ignite20Tests_IgniteStartNodes > 2) > http://ci.ignite.apache.org/viewLog.html?buildId=747364=buildResultsDiv=Ignite20Tests_IgniteStartNodes > The ticket is for investigation and making tests stable. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10108) Non-static class is passed between cluster nodes
[
https://issues.apache.org/jira/browse/IGNITE-10108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16671327#comment-16671327
]
Vladislav Pyatkov commented on IGNITE-10108:
[~Mmuzaf] Hi, could you please look at the ticket.
I think you a well know that code.
> Non-static class is passed between cluster nodes
>
>
> Key: IGNITE-10108
> URL: https://issues.apache.org/jira/browse/IGNITE-10108
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Priority: Major
>
> Need to avoid passing anonymous classes on compute, because this lead to
> serialize whole test-class context.
> By the reason need to refactor that place
> {code}
> ignite.compute().withTimeout(5_000).broadcastAsync(new IgniteRunnable() {
> ...
> });
> {code}
> in method \{{GridCommonAbstractTest#manualCacheRebalancing}} into private
> static nested class.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10108) Non-static class is passed between cluster nodes
Vladislav Pyatkov created IGNITE-10108:
--
Summary: Non-static class is passed between cluster nodes
Key: IGNITE-10108
URL: https://issues.apache.org/jira/browse/IGNITE-10108
Project: Ignite
Issue Type: Bug
Reporter: Vladislav Pyatkov
Need to avoid passing anonymous classes on compute, because this lead to
serialize whole test-class context.
By the reason need to refactor that place
{code}
ignite.compute().withTimeout(5_000).broadcastAsync(new IgniteRunnable() {
...
});
{code}
in method \{{GridCommonAbstractTest#manualCacheRebalancing}} into private
static nested class.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10107) Cache 7 tests optimization
[ https://issues.apache.org/jira/browse/IGNITE-10107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16671315#comment-16671315 ] Ivan Bessonov commented on IGNITE-10107: ignite-10037 branch contains "scale factor" mechanism implementation that is going to be used to optimize these tests. > Cache 7 tests optimization > -- > > Key: IGNITE-10107 > URL: https://issues.apache.org/jira/browse/IGNITE-10107 > Project: Ignite > Issue Type: Improvement >Reporter: Ivan Bessonov >Assignee: Ivan Bessonov >Priority: Major > Labels: MakeTeamcityGreenAgain > Fix For: 2.8 > > > These tests run over 1 minute each: > Authentication1kUsersNodeRestartTest.test1kUsersNodeRestartServer > TxRollbackAsyncWithPersistenceTest.testSynchronousRollback > IgniteCacheStartWithLoadTest.testNoRebalanceDuringCacheStart > WalModeChangeAdvancedSelfTest.testConcurrentOperations > TxRollbackAsyncWithPersistenceTest.testMixedAsyncRollbackTypes > GridCacheRebalancingWithAsyncClearingTest.testPartitionClearingNotBlockExchange > WalModeChangeAdvancedSelfTest.testServerRestartNonCoordinator > They should be either optimized or moved into overnight build (or both). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10107) Cache 7 tests optimization
Ivan Bessonov created IGNITE-10107: -- Summary: Cache 7 tests optimization Key: IGNITE-10107 URL: https://issues.apache.org/jira/browse/IGNITE-10107 Project: Ignite Issue Type: Improvement Reporter: Ivan Bessonov Assignee: Ivan Bessonov Fix For: 2.8 These tests run over 1 minute each: Authentication1kUsersNodeRestartTest.test1kUsersNodeRestartServer TxRollbackAsyncWithPersistenceTest.testSynchronousRollback IgniteCacheStartWithLoadTest.testNoRebalanceDuringCacheStart WalModeChangeAdvancedSelfTest.testConcurrentOperations TxRollbackAsyncWithPersistenceTest.testMixedAsyncRollbackTypes GridCacheRebalancingWithAsyncClearingTest.testPartitionClearingNotBlockExchange WalModeChangeAdvancedSelfTest.testServerRestartNonCoordinator They should be either optimized or moved into overnight build (or both). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9824) Thin clients benches
[ https://issues.apache.org/jira/browse/IGNITE-9824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stepan Pilschikov updated IGNITE-9824: -- Attachment: thin_benches_v4.pdf > Thin clients benches > > > Key: IGNITE-9824 > URL: https://issues.apache.org/jira/browse/IGNITE-9824 > Project: Ignite > Issue Type: Test > Components: thin client > Environment: Ignite 2.7 > Java 8 > NodeJS 10.+ > PHP 7.2.7 > Python 3.6 >Reporter: Stepan Pilschikov >Priority: Major > Attachments: thin_bench_simple_put_v3.pdf, thin_benches_v4.pdf, > thin_clients_bench_results.pdf, thin_clients_bench_results_v2.pdf > > > Benchmarks for all existed ignite thin clients > Case: > - Running 1 or 3 nodes on first host > - Running code on second host > Code: > - > [NodeJS|https://gist.github.com/pilshchikov/8a4bdb03a8304136c22c9bf7217ee447] > - [PHP|https://gist.github.com/pilshchikov/b4351d78ad59e9cd923689c2e387bc80] > - > [Python|https://gist.github.com/pilshchikov/8aff4e30d83f8bac20c5a4a9c3917abb] > - [Java|https://gist.github.com/pilshchikov/08096c78b425e00166a2ffa2aa5f49ce] > Results in attachments -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9824) Thin clients benches
[ https://issues.apache.org/jira/browse/IGNITE-9824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16671314#comment-16671314 ] Stepan Pilschikov commented on IGNITE-9824: --- New benches results [^thin_benches_v4.pdf] - latest ignite sources (optimized python) > Thin clients benches > > > Key: IGNITE-9824 > URL: https://issues.apache.org/jira/browse/IGNITE-9824 > Project: Ignite > Issue Type: Test > Components: thin client > Environment: Ignite 2.7 > Java 8 > NodeJS 10.+ > PHP 7.2.7 > Python 3.6 >Reporter: Stepan Pilschikov >Priority: Major > Attachments: thin_bench_simple_put_v3.pdf, thin_benches_v4.pdf, > thin_clients_bench_results.pdf, thin_clients_bench_results_v2.pdf > > > Benchmarks for all existed ignite thin clients > Case: > - Running 1 or 3 nodes on first host > - Running code on second host > Code: > - > [NodeJS|https://gist.github.com/pilshchikov/8a4bdb03a8304136c22c9bf7217ee447] > - [PHP|https://gist.github.com/pilshchikov/b4351d78ad59e9cd923689c2e387bc80] > - > [Python|https://gist.github.com/pilshchikov/8aff4e30d83f8bac20c5a4a9c3917abb] > - [Java|https://gist.github.com/pilshchikov/08096c78b425e00166a2ffa2aa5f49ce] > Results in attachments -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-9972) Deleted entries remain in local partition internal map
[ https://issues.apache.org/jira/browse/IGNITE-9972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16671283#comment-16671283 ] Ivan Bessonov edited comment on IGNITE-9972 at 11/1/18 9:06 AM: [~agoncharuk] my bad, didn't think about it. I'll push this fix in a few minutes, thank you! EDIT: done, you can proceed with the review. was (Author: ibessonov): [~agoncharuk] my bad, didn't think about it. I'll push this fix in a few minutes, thank you! > Deleted entries remain in local partition internal map > -- > > Key: IGNITE-9972 > URL: https://issues.apache.org/jira/browse/IGNITE-9972 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.6 >Reporter: Anton Kurbanov >Assignee: Ivan Bessonov >Priority: Major > Fix For: 2.8 > > Attachments: IgniteTxConcurrentRemoveObjectsTest.java > > > Concurrent transactions leave entries in deleted state in local partition map. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10106) Cache 5 test suite optimization
Alexey Platonov created IGNITE-10106: Summary: Cache 5 test suite optimization Key: IGNITE-10106 URL: https://issues.apache.org/jira/browse/IGNITE-10106 Project: Ignite Issue Type: Improvement Reporter: Alexey Platonov Assignee: Alexey Platonov We need to investigate how to optimize these tests: |CacheSerializableTransactionsTest.testGetRemoveTxNearCache2| |[CacheSerializableTransactionsTest.testGetRemoveTxNearCache1|https://ci.ignite.apache.org/viewLog.html?currentGroup=test=org.apache.ignite.testsuites.IgniteCacheTestSuite5%23teamcity%23org.apache.ignite.internal.processors.cache%23teamcity%23CacheSerializableTransactionsTest=1=DURATION_DESC=20===IgniteTests24Java8_Cache5=2160072=testsInfo]| |CacheSerializableTransactionsTest.testRandomOperations| |[CacheSerializableTransactionsTest.testIncrementTxRestart|https://ci.ignite.apache.org/viewLog.html?currentGroup=test=org.apache.ignite.testsuites.IgniteCacheTestSuite5%23teamcity%23org.apache.ignite.internal.processors.cache%23teamcity%23CacheSerializableTransactionsTest=1=DURATION_DESC=20===IgniteTests24Java8_Cache5=2160072=testsInfo]| |CacheSerializableTransactionsTest.testConcurrentUpdateNoDeadlockNodeRestart| |[CacheSerializableTransactionsTest.testConcurrentUpdateNoDeadlockFromClientsNodeRestart|https://ci.ignite.apache.org/viewLog.html?currentGroup=test=org.apache.ignite.testsuites.IgniteCacheTestSuite5%23teamcity%23org.apache.ignite.internal.processors.cache%23teamcity%23CacheSerializableTransactionsTest=1=DURATION_DESC=20===IgniteTests24Java8_Cache5=2160072=testsInfo]| |[CacheSerializableTransactionsTest.testConcurrentUpdateNoDeadlockWithNonSerializable|https://ci.ignite.apache.org/viewLog.html?currentGroup=test=org.apache.ignite.testsuites.IgniteCacheTestSuite5%23teamcity%23org.apache.ignite.internal.processors.cache%23teamcity%23CacheSerializableTransactionsTest=1=DURATION_DESC=20===IgniteTests24Java8_Cache5=2160072=testsInfo]| |[CacheSerializableTransactionsTest.testConcurrentUpdateNoDeadlockGetPut|https://ci.ignite.apache.org/viewLog.html?currentGroup=test=org.apache.ignite.testsuites.IgniteCacheTestSuite5%23teamcity%23org.apache.ignite.internal.processors.cache%23teamcity%23CacheSerializableTransactionsTest=1=DURATION_DESC=20===IgniteTests24Java8_Cache5=2160072=testsInfo]| |[CacheSerializableTransactionsTest.testConcurrentUpdateNoDeadlockFromClients|https://ci.ignite.apache.org/viewLog.html?currentGroup=test=org.apache.ignite.testsuites.IgniteCacheTestSuite5%23teamcity%23org.apache.ignite.internal.processors.cache%23teamcity%23CacheSerializableTransactionsTest=1=DURATION_DESC=20===IgniteTests24Java8_Cache5=2160072=testsInfo]| |[CacheSerializableTransactionsTest.testConcurrentUpdateNoDeadlock|https://ci.ignite.apache.org/viewLog.html?currentGroup=test=org.apache.ignite.testsuites.IgniteCacheTestSuite5%23teamcity%23org.apache.ignite.internal.processors.cache%23teamcity%23CacheSerializableTransactionsTest=1=DURATION_DESC=20===IgniteTests24Java8_Cache5=2160072=testsInfo]| and optimize them. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9986) TcpDiscoverySelfTest.testNodeShutdownOnRingMessageWorkerStartNotFinished is flaky
[ https://issues.apache.org/jira/browse/IGNITE-9986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16671289#comment-16671289 ] ASF GitHub Bot commented on IGNITE-9986: Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/5082 > TcpDiscoverySelfTest.testNodeShutdownOnRingMessageWorkerStartNotFinished is > flaky > -- > > Key: IGNITE-9986 > URL: https://issues.apache.org/jira/browse/IGNITE-9986 > Project: Ignite > Issue Type: Bug >Reporter: Ryabov Dmitrii >Assignee: Ryabov Dmitrii >Priority: Minor > Labels: MakeTeamcityGreenAgain > Fix For: 2.8 > > > [TeamCity > fails|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8==testDetails=-6988766947783986136=TEST_STATUS_DESC=50_IgniteTests24Java8=]. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10105) AI 2.7: Prepare release notes
Vladimir Ozerov created IGNITE-10105: Summary: AI 2.7: Prepare release notes Key: IGNITE-10105 URL: https://issues.apache.org/jira/browse/IGNITE-10105 Project: Ignite Issue Type: Task Components: general Reporter: Vladimir Ozerov Fix For: 2.7 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9986) TcpDiscoverySelfTest.testNodeShutdownOnRingMessageWorkerStartNotFinished is flaky
[ https://issues.apache.org/jira/browse/IGNITE-9986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-9986: - Labels: MakeTeamcityGreenAgain (was: ) > TcpDiscoverySelfTest.testNodeShutdownOnRingMessageWorkerStartNotFinished is > flaky > -- > > Key: IGNITE-9986 > URL: https://issues.apache.org/jira/browse/IGNITE-9986 > Project: Ignite > Issue Type: Bug >Reporter: Ryabov Dmitrii >Assignee: Ryabov Dmitrii >Priority: Minor > Labels: MakeTeamcityGreenAgain > Fix For: 2.8 > > > [TeamCity > fails|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8==testDetails=-6988766947783986136=TEST_STATUS_DESC=50_IgniteTests24Java8=]. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9986) TcpDiscoverySelfTest.testNodeShutdownOnRingMessageWorkerStartNotFinished is flaky
[ https://issues.apache.org/jira/browse/IGNITE-9986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-9986: - Fix Version/s: 2.8 > TcpDiscoverySelfTest.testNodeShutdownOnRingMessageWorkerStartNotFinished is > flaky > -- > > Key: IGNITE-9986 > URL: https://issues.apache.org/jira/browse/IGNITE-9986 > Project: Ignite > Issue Type: Bug >Reporter: Ryabov Dmitrii >Assignee: Ryabov Dmitrii >Priority: Minor > Labels: MakeTeamcityGreenAgain > Fix For: 2.8 > > > [TeamCity > fails|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8==testDetails=-6988766947783986136=TEST_STATUS_DESC=50_IgniteTests24Java8=]. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
