[jira] [Commented] (IGNITE-10758) remove from tests scaffolding annotations "@RunWith(JUnit4.class)" and their respective imports
[
https://issues.apache.org/jira/browse/IGNITE-10758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16746971#comment-16746971
]
Oleg Ignatenko commented on IGNITE-10758:
-
(i) despite involving many files, this change is easy to review and merge:
* Review recommendations: 1) make diff into some text file 2) remove from text
file all lines containing {{@RunWith(JUnit4.class}} and respective imports 3)
verify that there are no diffs anymore
* Merge recommendations: just accept everything from master as is. If some
isolated scaffolding annotations leak back in, ignore them: these are harmless
and can be removed manually later if desired
> remove from tests scaffolding annotations "@RunWith(JUnit4.class)" and their
> respective imports
> ---
>
> Key: IGNITE-10758
> URL: https://issues.apache.org/jira/browse/IGNITE-10758
> Project: Ignite
> Issue Type: Sub-task
>Affects Versions: 2.8
>Reporter: Oleg Ignatenko
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In the course of IGNITE-10175 and IGNITE-10176 many test classes were
> annotated {{@RunWith(JUnit4.class)}}. This was necessary to allow gradual
> switching to JUnit 4 to let classes run under the version that worked for
> these.
> After IGNITE-10177 is over, these scaffolding annotations will be not needed
> anymore (and will become even somewhat damaging by misleading readers to
> think that they serve some real purpose).
> The task is to remove these annotations and respective import statements
> after IGNITE-10177 is merged to master. Note it was initially planned as a
> part of IGNITE-10177 but per discussion with [~EdShangGG] we decided that it
> will be more convenient to do this in a separate ticket because this will
> make changes much easier to review, test and merge.
> (!) Thing worth paying attention is that mentioned annotations should be kept
> in one case - namely in root test class {{GridAbstractTest}} because over
> there these are necessary until JUnit 3 dependencies are wiped out from
> remaining cases listed in IGNITE-10739.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-10927) Relieve JUnit3TestLegacySupport from inheriting deprecated junit.framework.Assert (follow-up to IGNITE-10177)
[
https://issues.apache.org/jira/browse/IGNITE-10927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16746773#comment-16746773
]
Oleg Ignatenko edited comment on IGNITE-10927 at 1/18/19 11:43 PM:
---
(i) upon closer inspection this task turned out much larger than anticipated.
The reason for that is that many of current tests rely on catching deprecated
{{junit.framework.AssertionFaledError}} to determine success or failure
(ClusterNodeMetricsUpdateTest, IgniteClientReconnectCacheTest,
GridCacheAbstractFullApiSelfTest, IgniteCacheConfigVariationsFullApiTest etc).
As a result, straightforward attempt to delegate assertions to respective
methods of {{org.junit.Assert}} started failing tests like mentioned above
because newer assertions throw different kind of error when failed
({{java.lang.AssertionError}}).
Above means that first step prior to delegating assertions to proper class in
JUnit 4 should be (potentially risky and massive) rework of multiple existing
tests that rely on catching outdated AssertionFailedError.
Note that although AssertionError is a superclass of AssertionFailedError, my
trial attempt to simply replace it in tests that use deprecated error class in
[PR 5840|https://github.com/apache/ignite/pull/5840] has led to multiple test
failures at teamcity meaning that this could still be troublesome.
was (Author: oignatenko):
(i) upon closer inspection this task turned out much larger than anticipated.
The reason for that is that many of current tests rely on catching deprecated
{{junit.framework.AssertionFaledError}} to determine success or failure
(ClusterNodeMetricsUpdateTest, IgniteClientReconnectCacheTest,
GridCacheAbstractFullApiSelfTest, IgniteCacheConfigVariationsFullApiTest etc).
As a result, straightforward attempt to delegate assertions to respective
methods of {{org.junit.Assert}} started failing tests like mentioned above
because newer assertions throw different kind of error when failed
({{java.lang.AssertionError}}).
Above means that first step prior to delegating assertions to proper class in
JUnit 4 should be (potentially risky and massive) rework of multiple existing
tests that rely on catching outdated AssertionFailedError.
Note that although AssertionError is a superclass of AssertionFailedError, my
trial attempt to simply replace it in tests that use deprecated error class has
led to multiple test failures at teamcity meaning that this could still be
troublesome.
> Relieve JUnit3TestLegacySupport from inheriting deprecated
> junit.framework.Assert (follow-up to IGNITE-10177)
> -
>
> Key: IGNITE-10927
> URL: https://issues.apache.org/jira/browse/IGNITE-10927
> Project: Ignite
> Issue Type: Sub-task
>Affects Versions: 2.7
>Reporter: Oleg Ignatenko
>Assignee: Oleg Ignatenko
>Priority: Major
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> {{JUnit3TestLegacySupport}} currently inherits deprecated
> {{junit.framework.Assert}}. This was done only in order to minimize risky
> code changes when tests were migrating from Junit 3, after
> {{GridAbstractTest}} has dropped inheriting {{junit.framework.TestCase}}.
> Now that migration is over it is less risky to cleanup project from
> deprecated assert methods and drop the harmful inheritance. In order to make
> this smoother and minimize amount of test changes, after inheritance is
> dropped, {{JUnit3TestLegacySupport}} should be extended with a set of
> "temporary patch" methods that would delegate most popular assertions used by
> subclasses to respective methods of {{org.junit.Assert}}.
> Mentioned temporary patch methods, in turn, should respective
> {{2deprecation}} notices in javadocs that would encourage developers to
> (safely and gradually) change them to direct invocations and static imports
> of respective Assert methods instead of using those inherited from
> superclass. These patch methods should be declared {{protected final}} or
> {{protected static}}, in order to minimize their applicability and prevent
> them spreading more than intended. (as a side note, experimenting has shown
> that use of {{@Deprecated}} annotation is not feasible as it deprives
> developers an option to use static imports)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10927) Relieve JUnit3TestLegacySupport from inheriting deprecated junit.framework.Assert (follow-up to IGNITE-10177)
[
https://issues.apache.org/jira/browse/IGNITE-10927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16746773#comment-16746773
]
Oleg Ignatenko commented on IGNITE-10927:
-
(i) upon closer inspection this task turned out much larger than anticipated.
The reason for that is that many of current tests rely on catching deprecated
{{junit.framework.AssertionFaledError}} to determine success or failure
(ClusterNodeMetricsUpdateTest, IgniteClientReconnectCacheTest,
GridCacheAbstractFullApiSelfTest, IgniteCacheConfigVariationsFullApiTest etc).
As a result, straightforward attempt to delegate assertions to respective
methods of {{org.junit.Assert}} started failing tests like mentioned above
because newer assertions throw different kind of error when failed
({{java.lang.AssertionError}}).
Above means that first step prior to delegating assertions to proper class in
JUnit 4 should be (potentially risky and massive) rework of multiple existing
tests that rely on catching outdated AssertionFailedError.
Note that although AssertionError is a superclass of AssertionFailedError, my
trial attempt to simply replace it in tests that use deprecated error class has
led to multiple test failures at teamcity meaning that this could still be
troublesome.
> Relieve JUnit3TestLegacySupport from inheriting deprecated
> junit.framework.Assert (follow-up to IGNITE-10177)
> -
>
> Key: IGNITE-10927
> URL: https://issues.apache.org/jira/browse/IGNITE-10927
> Project: Ignite
> Issue Type: Sub-task
>Affects Versions: 2.7
>Reporter: Oleg Ignatenko
>Assignee: Oleg Ignatenko
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {{JUnit3TestLegacySupport}} currently inherits deprecated
> {{junit.framework.Assert}}. This was done only in order to minimize risky
> code changes when tests were migrating from Junit 3, after
> {{GridAbstractTest}} has dropped inheriting {{junit.framework.TestCase}}.
> Now that migration is over it is less risky to cleanup project from
> deprecated assert methods and drop the harmful inheritance. In order to make
> this smoother and minimize amount of test changes, after inheritance is
> dropped, {{JUnit3TestLegacySupport}} should be extended with a set of
> "temporary patch" methods that would delegate most popular assertions used by
> subclasses to respective methods of {{org.junit.Assert}}.
> Mentioned temporary patch methods, in turn, should respective
> {{2deprecation}} notices in javadocs that would encourage developers to
> (safely and gradually) change them to direct invocations and static imports
> of respective Assert methods instead of using those inherited from
> superclass. These patch methods should be declared {{protected final}} or
> {{protected static}}, in order to minimize their applicability and prevent
> them spreading more than intended. (as a side note, experimenting has shown
> that use of {{@Deprecated}} annotation is not feasible as it deprives
> developers an option to use static imports)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10927) Relieve JUnit3TestLegacySupport from inheriting deprecated junit.framework.Assert (follow-up to IGNITE-10177)
[
https://issues.apache.org/jira/browse/IGNITE-10927?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oleg Ignatenko updated IGNITE-10927:
Issue Type: Sub-task (was: Task)
Parent: IGNITE-10951
> Relieve JUnit3TestLegacySupport from inheriting deprecated
> junit.framework.Assert (follow-up to IGNITE-10177)
> -
>
> Key: IGNITE-10927
> URL: https://issues.apache.org/jira/browse/IGNITE-10927
> Project: Ignite
> Issue Type: Sub-task
>Affects Versions: 2.7
>Reporter: Oleg Ignatenko
>Assignee: Oleg Ignatenko
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {{JUnit3TestLegacySupport}} currently inherits deprecated
> {{junit.framework.Assert}}. This was done only in order to minimize risky
> code changes when tests were migrating from Junit 3, after
> {{GridAbstractTest}} has dropped inheriting {{junit.framework.TestCase}}.
> Now that migration is over it is less risky to cleanup project from
> deprecated assert methods and drop the harmful inheritance. In order to make
> this smoother and minimize amount of test changes, after inheritance is
> dropped, {{JUnit3TestLegacySupport}} should be extended with a set of
> "temporary patch" methods that would delegate most popular assertions used by
> subclasses to respective methods of {{org.junit.Assert}}.
> Mentioned temporary patch methods, in turn, should respective
> {{2deprecation}} notices in javadocs that would encourage developers to
> (safely and gradually) change them to direct invocations and static imports
> of respective Assert methods instead of using those inherited from
> superclass. These patch methods should be declared {{protected final}} or
> {{protected static}}, in order to minimize their applicability and prevent
> them spreading more than intended. (as a side note, experimenting has shown
> that use of {{@Deprecated}} annotation is not feasible as it deprives
> developers an option to use static imports)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10927) Relieve JUnit3TestLegacySupport from inheriting deprecated junit.framework.Assert (follow-up to IGNITE-10177)
[
https://issues.apache.org/jira/browse/IGNITE-10927?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oleg Ignatenko updated IGNITE-10927:
Issue Type: Task (was: Sub-task)
Parent: (was: IGNITE-10173)
> Relieve JUnit3TestLegacySupport from inheriting deprecated
> junit.framework.Assert (follow-up to IGNITE-10177)
> -
>
> Key: IGNITE-10927
> URL: https://issues.apache.org/jira/browse/IGNITE-10927
> Project: Ignite
> Issue Type: Task
>Affects Versions: 2.7
>Reporter: Oleg Ignatenko
>Assignee: Oleg Ignatenko
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {{JUnit3TestLegacySupport}} currently inherits deprecated
> {{junit.framework.Assert}}. This was done only in order to minimize risky
> code changes when tests were migrating from Junit 3, after
> {{GridAbstractTest}} has dropped inheriting {{junit.framework.TestCase}}.
> Now that migration is over it is less risky to cleanup project from
> deprecated assert methods and drop the harmful inheritance. In order to make
> this smoother and minimize amount of test changes, after inheritance is
> dropped, {{JUnit3TestLegacySupport}} should be extended with a set of
> "temporary patch" methods that would delegate most popular assertions used by
> subclasses to respective methods of {{org.junit.Assert}}.
> Mentioned temporary patch methods, in turn, should respective
> {{2deprecation}} notices in javadocs that would encourage developers to
> (safely and gradually) change them to direct invocations and static imports
> of respective Assert methods instead of using those inherited from
> superclass. These patch methods should be declared {{protected final}} or
> {{protected static}}, in order to minimize their applicability and prevent
> them spreading more than intended. (as a side note, experimenting has shown
> that use of {{@Deprecated}} annotation is not feasible as it deprives
> developers an option to use static imports)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10974) Node may hangs if an exception is throw from PageMemoryImpl.beforeReleaseWrite()
[
https://issues.apache.org/jira/browse/IGNITE-10974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16746746#comment-16746746
]
Dmitriy Govorukhin commented on IGNITE-10974:
-
Merged to master.
> Node may hangs if an exception is throw from
> PageMemoryImpl.beforeReleaseWrite()
>
>
> Key: IGNITE-10974
> URL: https://issues.apache.org/jira/browse/IGNITE-10974
> Project: Ignite
> Issue Type: Bug
>Reporter: Dmitriy Govorukhin
>Assignee: Dmitriy Govorukhin
>Priority: Critical
> Fix For: 2.8
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> There are situations when a node may hang during stopping. Bug in the
> PageMemoryImpl.writeUnlockPage(), this method invokes
> PageMemoryImpl.beforeReleaseWrite() which may throw a exception and
> writeUnlockPage does not release page lock, after that checkpoint try to do
> final checkpoint (if stop was gracefully) and next access for this page hangs
> on obtain write lock.
> {code:java}
> [2019-01-17 14:35:15,953][WARN ][main][root] Thread dump at 2019/01/17
> 14:35:15 UTC
> [17:35:15]W: [org.apache.ignite:ignite-core] Thread
> [name="sys-#857%failure.IoomFailureHandlerTest0%", id=931,
> state=TIMED_WAITING, blockCnt=0, waitCnt=1]
> [17:35:15]W: [org.apache.ignite:ignite-core] Lock
> [object=java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject@4339baec,
> ownerName=null, ownerId=-1]
> [17:35:15]W: [org.apache.ignite:ignite-core] at sun.misc.Unsafe.park(Native
> Method)
> [17:35:15]W: [org.apache.ignite:ignite-core] at
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
> [17:35:15]W: [org.apache.ignite:ignite-core] at
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
> [17:35:15]W: [org.apache.ignite:ignite-core] at
> java.util.concurrent.LinkedBlockingQueue.poll(LinkedBlockingQueue.java:467)
> [17:35:15]W: [org.apache.ignite:ignite-core] at
> java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1073)
> [17:35:15]W: [org.apache.ignite:ignite-core] at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134)
> [17:35:15]W: [org.apache.ignite:ignite-core] at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> [17:35:15]W: [org.apache.ignite:ignite-core] at
> java.lang.Thread.run(Thread.java:748)
> [17:35:15]W: [org.apache.ignite:ignite-core]
> [17:35:15]W: [org.apache.ignite:ignite-core] Thread
> [name="sys-#856%failure.IoomFailureHandlerTest0%", id=930,
> state=TIMED_WAITING, blockCnt=0, waitCnt=1]
> [17:35:15]W: [org.apache.ignite:ignite-core] Lock
> [object=java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject@4339baec,
> ownerName=null, ownerId=-1]
> [17:35:15]W: [org.apache.ignite:ignite-core] at sun.misc.Unsafe.park(Native
> Method)
> [17:35:15]W: [org.apache.ignite:ignite-core] at
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
> [17:35:15]W: [org.apache.ignite:ignite-core] at
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
> [17:35:15]W: [org.apache.ignite:ignite-core] at
> java.util.concurrent.LinkedBlockingQueue.poll(LinkedBlockingQueue.java:467)
> [17:35:15]W: [org.apache.ignite:ignite-core] at
> java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1073)
> [17:35:15]W: [org.apache.ignite:ignite-core] at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134)
> [17:35:15]W: [org.apache.ignite:ignite-core] at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> [17:35:15]W: [org.apache.ignite:ignite-core] at
> java.lang.Thread.run(Thread.java:748)
> [17:35:15]W: [org.apache.ignite:ignite-core]
> [17:35:15]W: [org.apache.ignite:ignite-core] Thread
> [name="sys-#855%failure.IoomFailureHandlerTest0%", id=929,
> state=TIMED_WAITING, blockCnt=0, waitCnt=1]
> [17:35:15]W: [org.apache.ignite:ignite-core] Lock
> [object=java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject@4339baec,
> ownerName=null, ownerId=-1]
> [17:35:15]W: [org.apache.ignite:ignite-core] at sun.misc.Unsafe.park(Native
> Method)
> [17:35:15]W: [org.apache.ignite:ignite-core] at
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
> [17:35:15]W: [org.apache.ignite:ignite-core] at
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
> [17:35:15]W: [org.apache.ignite:ignite-core] at
> java.util.concurrent.LinkedBlockingQueue.poll(LinkedBlockingQueue.java:467)
> [17:35:15]W: [org.apache.ignite:ignite-core] at
>
[jira] [Commented] (IGNITE-10974) Node may hangs if an exception is throw from PageMemoryImpl.beforeReleaseWrite()
[
https://issues.apache.org/jira/browse/IGNITE-10974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16746731#comment-16746731
]
Ignite TC Bot commented on IGNITE-10974:
{panel:title=-- Run :: All: No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=2835958buildTypeId=IgniteTests24Java8_RunAll]
> Node may hangs if an exception is throw from
> PageMemoryImpl.beforeReleaseWrite()
>
>
> Key: IGNITE-10974
> URL: https://issues.apache.org/jira/browse/IGNITE-10974
> Project: Ignite
> Issue Type: Bug
>Reporter: Dmitriy Govorukhin
>Assignee: Dmitriy Govorukhin
>Priority: Critical
> Fix For: 2.8
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> There are situations when a node may hang during stopping. Bug in the
> PageMemoryImpl.writeUnlockPage(), this method invokes
> PageMemoryImpl.beforeReleaseWrite() which may throw a exception and
> writeUnlockPage does not release page lock, after that checkpoint try to do
> final checkpoint (if stop was gracefully) and next access for this page hangs
> on obtain write lock.
> {code:java}
> [2019-01-17 14:35:15,953][WARN ][main][root] Thread dump at 2019/01/17
> 14:35:15 UTC
> [17:35:15]W: [org.apache.ignite:ignite-core] Thread
> [name="sys-#857%failure.IoomFailureHandlerTest0%", id=931,
> state=TIMED_WAITING, blockCnt=0, waitCnt=1]
> [17:35:15]W: [org.apache.ignite:ignite-core] Lock
> [object=java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject@4339baec,
> ownerName=null, ownerId=-1]
> [17:35:15]W: [org.apache.ignite:ignite-core] at sun.misc.Unsafe.park(Native
> Method)
> [17:35:15]W: [org.apache.ignite:ignite-core] at
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
> [17:35:15]W: [org.apache.ignite:ignite-core] at
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
> [17:35:15]W: [org.apache.ignite:ignite-core] at
> java.util.concurrent.LinkedBlockingQueue.poll(LinkedBlockingQueue.java:467)
> [17:35:15]W: [org.apache.ignite:ignite-core] at
> java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1073)
> [17:35:15]W: [org.apache.ignite:ignite-core] at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134)
> [17:35:15]W: [org.apache.ignite:ignite-core] at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> [17:35:15]W: [org.apache.ignite:ignite-core] at
> java.lang.Thread.run(Thread.java:748)
> [17:35:15]W: [org.apache.ignite:ignite-core]
> [17:35:15]W: [org.apache.ignite:ignite-core] Thread
> [name="sys-#856%failure.IoomFailureHandlerTest0%", id=930,
> state=TIMED_WAITING, blockCnt=0, waitCnt=1]
> [17:35:15]W: [org.apache.ignite:ignite-core] Lock
> [object=java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject@4339baec,
> ownerName=null, ownerId=-1]
> [17:35:15]W: [org.apache.ignite:ignite-core] at sun.misc.Unsafe.park(Native
> Method)
> [17:35:15]W: [org.apache.ignite:ignite-core] at
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
> [17:35:15]W: [org.apache.ignite:ignite-core] at
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
> [17:35:15]W: [org.apache.ignite:ignite-core] at
> java.util.concurrent.LinkedBlockingQueue.poll(LinkedBlockingQueue.java:467)
> [17:35:15]W: [org.apache.ignite:ignite-core] at
> java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1073)
> [17:35:15]W: [org.apache.ignite:ignite-core] at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134)
> [17:35:15]W: [org.apache.ignite:ignite-core] at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> [17:35:15]W: [org.apache.ignite:ignite-core] at
> java.lang.Thread.run(Thread.java:748)
> [17:35:15]W: [org.apache.ignite:ignite-core]
> [17:35:15]W: [org.apache.ignite:ignite-core] Thread
> [name="sys-#855%failure.IoomFailureHandlerTest0%", id=929,
> state=TIMED_WAITING, blockCnt=0, waitCnt=1]
> [17:35:15]W: [org.apache.ignite:ignite-core] Lock
> [object=java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject@4339baec,
> ownerName=null, ownerId=-1]
> [17:35:15]W: [org.apache.ignite:ignite-core] at sun.misc.Unsafe.park(Native
> Method)
> [17:35:15]W: [org.apache.ignite:ignite-core] at
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
> [17:35:15]W: [org.apache.ignite:ignite-core] at
>
[jira] [Commented] (IGNITE-10974) Node may hangs if an exception is throw from PageMemoryImpl.beforeReleaseWrite()
[
https://issues.apache.org/jira/browse/IGNITE-10974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16746722#comment-16746722
]
Dmitriy Govorukhin commented on IGNITE-10974:
-
I guess that problem in a test because they were run on windows agent. I
started new re-run.
> Node may hangs if an exception is throw from
> PageMemoryImpl.beforeReleaseWrite()
>
>
> Key: IGNITE-10974
> URL: https://issues.apache.org/jira/browse/IGNITE-10974
> Project: Ignite
> Issue Type: Bug
>Reporter: Dmitriy Govorukhin
>Assignee: Dmitriy Govorukhin
>Priority: Critical
> Fix For: 2.8
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> There are situations when a node may hang during stopping. Bug in the
> PageMemoryImpl.writeUnlockPage(), this method invokes
> PageMemoryImpl.beforeReleaseWrite() which may throw a exception and
> writeUnlockPage does not release page lock, after that checkpoint try to do
> final checkpoint (if stop was gracefully) and next access for this page hangs
> on obtain write lock.
> {code:java}
> [2019-01-17 14:35:15,953][WARN ][main][root] Thread dump at 2019/01/17
> 14:35:15 UTC
> [17:35:15]W: [org.apache.ignite:ignite-core] Thread
> [name="sys-#857%failure.IoomFailureHandlerTest0%", id=931,
> state=TIMED_WAITING, blockCnt=0, waitCnt=1]
> [17:35:15]W: [org.apache.ignite:ignite-core] Lock
> [object=java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject@4339baec,
> ownerName=null, ownerId=-1]
> [17:35:15]W: [org.apache.ignite:ignite-core] at sun.misc.Unsafe.park(Native
> Method)
> [17:35:15]W: [org.apache.ignite:ignite-core] at
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
> [17:35:15]W: [org.apache.ignite:ignite-core] at
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
> [17:35:15]W: [org.apache.ignite:ignite-core] at
> java.util.concurrent.LinkedBlockingQueue.poll(LinkedBlockingQueue.java:467)
> [17:35:15]W: [org.apache.ignite:ignite-core] at
> java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1073)
> [17:35:15]W: [org.apache.ignite:ignite-core] at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134)
> [17:35:15]W: [org.apache.ignite:ignite-core] at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> [17:35:15]W: [org.apache.ignite:ignite-core] at
> java.lang.Thread.run(Thread.java:748)
> [17:35:15]W: [org.apache.ignite:ignite-core]
> [17:35:15]W: [org.apache.ignite:ignite-core] Thread
> [name="sys-#856%failure.IoomFailureHandlerTest0%", id=930,
> state=TIMED_WAITING, blockCnt=0, waitCnt=1]
> [17:35:15]W: [org.apache.ignite:ignite-core] Lock
> [object=java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject@4339baec,
> ownerName=null, ownerId=-1]
> [17:35:15]W: [org.apache.ignite:ignite-core] at sun.misc.Unsafe.park(Native
> Method)
> [17:35:15]W: [org.apache.ignite:ignite-core] at
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
> [17:35:15]W: [org.apache.ignite:ignite-core] at
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
> [17:35:15]W: [org.apache.ignite:ignite-core] at
> java.util.concurrent.LinkedBlockingQueue.poll(LinkedBlockingQueue.java:467)
> [17:35:15]W: [org.apache.ignite:ignite-core] at
> java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1073)
> [17:35:15]W: [org.apache.ignite:ignite-core] at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134)
> [17:35:15]W: [org.apache.ignite:ignite-core] at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> [17:35:15]W: [org.apache.ignite:ignite-core] at
> java.lang.Thread.run(Thread.java:748)
> [17:35:15]W: [org.apache.ignite:ignite-core]
> [17:35:15]W: [org.apache.ignite:ignite-core] Thread
> [name="sys-#855%failure.IoomFailureHandlerTest0%", id=929,
> state=TIMED_WAITING, blockCnt=0, waitCnt=1]
> [17:35:15]W: [org.apache.ignite:ignite-core] Lock
> [object=java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject@4339baec,
> ownerName=null, ownerId=-1]
> [17:35:15]W: [org.apache.ignite:ignite-core] at sun.misc.Unsafe.park(Native
> Method)
> [17:35:15]W: [org.apache.ignite:ignite-core] at
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
> [17:35:15]W: [org.apache.ignite:ignite-core] at
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
> [17:35:15]W: [org.apache.ignite:ignite-core] at
>
[jira] [Commented] (IGNITE-10777) Cleanup remainders of JUnit4TestAdapter and other JUnit 3 API involving test suites
[ https://issues.apache.org/jira/browse/IGNITE-10777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16746715#comment-16746715 ] Dmitriy Govorukhin commented on IGNITE-10777: - [~oignatenko], Thanks for the contribution! Merged to master. [~EdShangGG] Thanks for the review. > Cleanup remainders of JUnit4TestAdapter and other JUnit 3 API involving test > suites > --- > > Key: IGNITE-10777 > URL: https://issues.apache.org/jira/browse/IGNITE-10777 > Project: Ignite > Issue Type: Sub-task >Affects Versions: 2.8 >Reporter: Oleg Ignatenko >Assignee: Oleg Ignatenko >Priority: Major > Labels: MakeTeamcityGreenAgain > Fix For: 2.8 > > Time Spent: 0.5h > Remaining Estimate: 0h > > This task is to cleanup remainders of JUnit4TestAdapter and other JUnit 3 API > involving test suites that may be missed in prior sub-tasks under the parent > task. > If needed, refer to parent task comments for more details. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-6564) Incorrect calculation size and keySize for cluster cache metrics
[
https://issues.apache.org/jira/browse/IGNITE-6564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16746676#comment-16746676
]
Ignite TC Bot commented on IGNITE-6564:
---
{panel:title=-- Run :: All: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Platform .NET (Long Running){color} [[tests 1 TIMEOUT
|https://ci.ignite.apache.org/viewLog.html?buildId=2835286]]
* exe: PersistentStoreTestObsolete.TestCacheDataSurvivesNodeRestart - 6,1%
fails in last 594 master runs.
{color:#d04437}Cache (Restarts) 1{color} [[tests
5|https://ci.ignite.apache.org/viewLog.html?buildId=2835257]]
* IgniteCacheRestartTestSuite: GridCachePartitionedNodeRestartTest.testRestart
- 0,0% fails in last 561 master runs.
* IgniteCacheRestartTestSuite:
GridCachePartitionedNodeRestartTest.testRestartWithPutTwoNodesNoBackups - 0,0%
fails in last 561 master runs.
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=2835311buildTypeId=IgniteTests24Java8_RunAll]
> Incorrect calculation size and keySize for cluster cache metrics
>
>
> Key: IGNITE-6564
> URL: https://issues.apache.org/jira/browse/IGNITE-6564
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Ilya Kasnacheev
>Assignee: Sergey Kosarev
>Priority: Minor
> Labels: iep-6
> Time Spent: 50m
> Remaining Estimate: 0h
>
> They are currently not passed by ring and therefore only taken from current
> node, which returns incorrect (local) value.
> See CacheMetricsSnapshot class.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-6564) Incorrect calculation size and keySize for cluster cache metrics
[ https://issues.apache.org/jira/browse/IGNITE-6564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16746677#comment-16746677 ] Ilya Kasnacheev commented on IGNITE-6564: - LGTM now! Hope to merge it after a few more checks. > Incorrect calculation size and keySize for cluster cache metrics > > > Key: IGNITE-6564 > URL: https://issues.apache.org/jira/browse/IGNITE-6564 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.2 >Reporter: Ilya Kasnacheev >Assignee: Sergey Kosarev >Priority: Minor > Labels: iep-6 > Time Spent: 50m > Remaining Estimate: 0h > > They are currently not passed by ring and therefore only taken from current > node, which returns incorrect (local) value. > See CacheMetricsSnapshot class. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10754) Query history statistics API
[
https://issues.apache.org/jira/browse/IGNITE-10754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16746665#comment-16746665
]
Ignite TC Bot commented on IGNITE-10754:
{panel:title=-- Run :: All: No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=2836509buildTypeId=IgniteTests24Java8_RunAll]
> Query history statistics API
>
>
> Key: IGNITE-10754
> URL: https://issues.apache.org/jira/browse/IGNITE-10754
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Yury Gerzhedovich
>Assignee: Yury Gerzhedovich
>Priority: Major
> Labels: iep-29, monitoring
> Fix For: 2.8
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> As of now we have query statistics
> (*_org.apache.ignite.IgniteCache#queryMetrics_*) , but have few issues.
> 1) Duration execution it just time between start execution and return cursor
> to client and doesn't include all life time of query.
> 2) It doesn't know about multistatement queries. Such queries participate in
> statistics as single query without splitting.
> 3) API to access the statistics expose as depend on cache, however query
> don't have such dependency.
>
> Need to create parallel similar realization as we already have.
> Use new infrastructure of tracking running queries developed under
> IGNITE-10621 and update statistics on unregister phase.
> Expose API on upper level then it placed now. Right place will be written
> later.
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10961) Web console: add more countries
[ https://issues.apache.org/jira/browse/IGNITE-10961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16746644#comment-16746644 ] Yuriy Sergeev commented on IGNITE-10961: [~Klaster_1] pls correct the list of countries: * China * Japan * South Korea * Hong Kong * Taiwan * Australia * Thailand * Singapore * Malaysia * Philippines * Indonesia * Vietnam * Macau * New Zealand Thx > Web console: add more countries > --- > > Key: IGNITE-10961 > URL: https://issues.apache.org/jira/browse/IGNITE-10961 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Ilya Borisov >Assignee: Alexey Kuznetsov >Priority: Minor > Time Spent: 0.5h > Remaining Estimate: 0h > > Countries to add: > * Taiwan > * Hong Kong > * Singapore -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10688) Expose SQL views for IO statistics
[
https://issues.apache.org/jira/browse/IGNITE-10688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16746622#comment-16746622
]
Ignite TC Bot commented on IGNITE-10688:
{panel:title=-- Run :: All: No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=2833015buildTypeId=IgniteTests24Java8_RunAll]
> Expose SQL views for IO statistics
> --
>
> Key: IGNITE-10688
> URL: https://issues.apache.org/jira/browse/IGNITE-10688
> Project: Ignite
> Issue Type: Task
> Components: persistence, sql
>Reporter: Yury Gerzhedovich
>Assignee: Yury Gerzhedovich
>Priority: Major
> Labels: iep-27
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> As of now no such way to get IO statistics through SQL.
> Need to expose two system SQL views to be able view statistics for indexes
> and cache group caches.
>
> 1) STATIO_CACHE_GRP
> {quote}cache_grp_name - Name of cache group
> physical_read - Number of physical read of pages
> logical_read - Number of logical read of pages{quote}
> 2) STATIO_IDX
> {quote}cache_grp_name - Name of cache group{quote}
> {quote}idx_name - Name of index
> physical_read - Common number of physical reads of pages for
> the index
> logical_read - Common number of logical reads of pages for
> the index{quote}
> {quote}leaf_logical_read - Number of logical reads of index leaf
> pages{quote}
> {quote}leaf_physical_read - Number of physical reads of index leaf
> pages{quote}
> {quote}inner_logical_read - Number of logical reads of index inner
> pages{quote}
> {quote}inner_physical_read - Number of physical reads of index leaf
> pages{quote}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10824) SQL: mixing _key and key columns in the DML queries must be disallowed
[
https://issues.apache.org/jira/browse/IGNITE-10824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16746608#comment-16746608
]
Ignite TC Bot commented on IGNITE-10824:
{panel:title=-- Run :: All: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Platform .NET (Long Running){color} [[tests 2 TIMEOUT
|https://ci.ignite.apache.org/viewLog.html?buildId=2836201]]
* exe: PersistentStoreTestObsolete.TestCacheDataSurvivesNodeRestart - 6,1%
fails in last 590 master runs.
* exe: CacheAbstractTest.TestCacheConfigurationExpiryPolicy - 3,6% fails in
last 590 master runs.
{color:#d04437}ZooKeeper (Discovery) 2{color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=2836150]]
{color:#d04437}Cache 1{color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=2836175]]
{color:#d04437}Cache (Restarts) 2{color} [[tests
3|https://ci.ignite.apache.org/viewLog.html?buildId=2836173]]
* IgniteCacheRestartTestSuite2:
IgniteCacheAtomicNodeRestartTest.testRestartWithPutTenNodesTwoBackups - 0,0%
fails in last 609 master runs.
* IgniteCacheRestartTestSuite2:
IgniteCacheAtomicNodeRestartTest.testRestartWithPutFourNodesNoBackups - 0,0%
fails in last 609 master runs.
{color:#d04437}MVCC Cache 2{color} [[tests
6|https://ci.ignite.apache.org/viewLog.html?buildId=2836214]]
* IgniteCacheMvccTestSuite2:
GridCacheDhtPreloadDelayedSelfTest.testAutomaticPreload - 0,0% fails in last 56
master runs.
* IgniteCacheMvccTestSuite2:
GridCacheDhtPreloadDelayedSelfTest.testManualPreload - 0,0% fails in last 56
master runs.
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=2836226buildTypeId=IgniteTests24Java8_RunAll]
> SQL: mixing _key and key columns in the DML queries must be disallowed
> --
>
> Key: IGNITE-10824
> URL: https://issues.apache.org/jira/browse/IGNITE-10824
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Pavel Kuznetsov
>Assignee: Pavel Kuznetsov
>Priority: Minor
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> DML should contain either placeholder for _key (_val) or subset of key
> (value) columns but not both. Also we should keep in mind _key/_value aliases
> Given table with primary key column {{id}} and value column {{salary}}. Next
> queries should be validated to parsing error:
> {code:sql}
> INSERT INTO TEST_TABLE (_key, id, salary) VALUES (1, 2, 42);
> UPDATE TEST_TABLE SET _val = 1, salary = 2;
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10974) Node may hangs if an exception is throw from PageMemoryImpl.beforeReleaseWrite()
[
https://issues.apache.org/jira/browse/IGNITE-10974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16746607#comment-16746607
]
Ignite TC Bot commented on IGNITE-10974:
{panel:title=-- Run :: All: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}JDBC Driver{color} [[tests
36|https://ci.ignite.apache.org/viewLog.html?buildId=2835866]]
* IgniteJdbcDriverTestSuite:
JdbcThinBulkLoadTransactionalPartitionedSelfTest.testDefaultCharsetPacketSize1
- 0,0% fails in last 572 master runs.
* IgniteJdbcDriverTestSuite:
JdbcThinBulkLoadTransactionalPartitionedSelfTest.testWrongCharset_Utf8AsAscii -
0,0% fails in last 572 master runs.
* IgniteJdbcDriverTestSuite:
JdbcThinBulkLoadTransactionalPartitionedSelfTest.testDefaultCharset - 0,0%
fails in last 572 master runs.
* IgniteJdbcDriverTestSuite:
JdbcThinBulkLoadTransactionalPartitionedSelfTest.testWrongCharset_Win1251AsAscii
- 0,0% fails in last 572 master runs.
* IgniteJdbcDriverTestSuite:
JdbcThinBulkLoadTransactionalPartitionedNearSelfTest.testBulkLoadToNonAffinityNode
- 0,0% fails in last 572 master runs.
* IgniteJdbcDriverTestSuite:
JdbcThinBulkLoadAtomicPartitionedNearSelfTest.testWrongCharset_Utf8AsWin1251 -
0,0% fails in last 572 master runs.
* IgniteJdbcDriverTestSuite:
JdbcThinBulkLoadTransactionalPartitionedSelfTest.testBulkLoadToNonAffinityNode
- 0,0% fails in last 572 master runs.
* IgniteJdbcDriverTestSuite:
JdbcThinBulkLoadAtomicPartitionedSelfTest.testWrongCharset_Utf8AsWin1251 - 0,0%
fails in last 572 master runs.
* IgniteJdbcDriverTestSuite:
JdbcThinBulkLoadAtomicPartitionedSelfTest.testUtf8Charset - 0,0% fails in last
572 master runs.
* IgniteJdbcDriverTestSuite:
JdbcThinBulkLoadTransactionalPartitionedNearSelfTest.testDefaultCharsetPacketSize1
- 0,0% fails in last 572 master runs.
* IgniteJdbcDriverTestSuite:
JdbcThinBulkLoadTransactionalPartitionedNearSelfTest.testWrongCharset_Utf8AsAscii
- 0,0% fails in last 572 master runs.
* IgniteJdbcDriverTestSuite:
JdbcThinBulkLoadAtomicPartitionedSelfTest.testWrongCharset_Win1251AsUtf8 - 0,0%
fails in last 572 master runs.
* IgniteJdbcDriverTestSuite:
JdbcThinBulkLoadAtomicPartitionedNearSelfTest.testUtf8Charset - 0,0% fails in
last 572 master runs.
* IgniteJdbcDriverTestSuite:
JdbcThinBulkLoadTransactionalPartitionedNearSelfTest.testDefaultCharset - 0,0%
fails in last 572 master runs.
* IgniteJdbcDriverTestSuite:
JdbcThinBulkLoadAtomicPartitionedSelfTest.testWin1251Charset - 0,0% fails in
last 572 master runs.
* IgniteJdbcDriverTestSuite:
JdbcThinBulkLoadAtomicPartitionedSelfTest.testDefaultCharsetPacketSize1 - 0,0%
fails in last 572 master runs.
* IgniteJdbcDriverTestSuite:
JdbcThinBulkLoadAtomicPartitionedSelfTest.testWrongCharset_Utf8AsAscii - 0,0%
fails in last 572 master runs.
* IgniteJdbcDriverTestSuite:
JdbcThinBulkLoadAtomicPartitionedSelfTest.testDefaultCharset - 0,0% fails in
last 572 master runs.
* IgniteJdbcDriverTestSuite:
JdbcThinBulkLoadTransactionalPartitionedNearSelfTest.testWrongCharset_Win1251AsAscii
- 0,0% fails in last 572 master runs.
* IgniteJdbcDriverTestSuite:
JdbcThinBulkLoadAtomicPartitionedSelfTest.testWrongCharset_Win1251AsAscii -
0,0% fails in last 572 master runs.
* IgniteJdbcDriverTestSuite:
JdbcThinBulkLoadAtomicPartitionedNearSelfTest.testWrongCharset_Win1251AsUtf8 -
0,0% fails in last 572 master runs.
* IgniteJdbcDriverTestSuite:
JdbcThinBulkLoadTransactionalPartitionedNearSelfTest.testUtf8Charset - 0,0%
fails in last 572 master runs.
* IgniteJdbcDriverTestSuite:
JdbcThinBulkLoadAtomicPartitionedNearSelfTest.testWin1251Charset - 0,0% fails
in last 572 master runs.
* IgniteJdbcDriverTestSuite:
JdbcThinBulkLoadTransactionalPartitionedNearSelfTest.testWrongCharset_Win1251AsUtf8
- 0,0% fails in last 572 master runs.
* IgniteJdbcDriverTestSuite:
JdbcThinBulkLoadAtomicPartitionedNearSelfTest.testDefaultCharsetPacketSize1 -
0,0% fails in last 572 master runs.
* IgniteJdbcDriverTestSuite:
JdbcThinBulkLoadTransactionalPartitionedSelfTest.testWrongCharset_Utf8AsWin1251
- 0,0% fails in last 572 master runs.
* IgniteJdbcDriverTestSuite:
JdbcThinBulkLoadAtomicPartitionedNearSelfTest.testWrongCharset_Utf8AsAscii -
0,0% fails in last 572 master runs.
* IgniteJdbcDriverTestSuite:
JdbcThinBulkLoadTransactionalPartitionedNearSelfTest.testWin1251Charset - 0,0%
fails in last 572 master runs.
* IgniteJdbcDriverTestSuite:
JdbcThinBulkLoadAtomicPartitionedNearSelfTest.testDefaultCharset - 0,0% fails
in last 572 master runs.
* IgniteJdbcDriverTestSuite:
JdbcThinBulkLoadTransactionalPartitionedSelfTest.testUtf8Charset - 0,0% fails
in last 572 master runs.
* IgniteJdbcDriverTestSuite:
JdbcThinBulkLoadAtomicPartitionedNearSelfTest.testWrongCharset_Win1251AsAscii -
0,0% fails in last 572 master runs.
* IgniteJdbcDriverTestSuite:
JdbcThinBulkLoadAtomicPartitionedNearSelfTest.testBulkLoadToNonAffinityNode -
0,0% fails in
[jira] [Commented] (IGNITE-2771) Document machine safety
[
https://issues.apache.org/jira/browse/IGNITE-2771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16746584#comment-16746584
]
Valentin Kulichenko commented on IGNITE-2771:
-
[~pgarg], I think it makes sense to all have an example for
{{AttributeNodeFilter}}, as it eliminates the requirement to implement custom
function if filtering is based on attributes. This covers vast majority of use
cases.
Also, why is it in performance tuning section? This technique doesn't have any
performance implications, it's rather a way to achieve availability in certain
deployments.
> Document machine safety
> ---
>
> Key: IGNITE-2771
> URL: https://issues.apache.org/jira/browse/IGNITE-2771
> Project: Ignite
> Issue Type: Task
> Components: documentation
>Reporter: Valentin Kulichenko
>Assignee: Prachi Garg
>Priority: Major
> Fix For: 2.8
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10989) [TC Bot] Finalize refactoring and remove REST data persistent caches
Dmitriy Pavlov created IGNITE-10989: --- Summary: [TC Bot] Finalize refactoring and remove REST data persistent caches Key: IGNITE-10989 URL: https://issues.apache.org/jira/browse/IGNITE-10989 Project: Ignite Issue Type: Task Reporter: Dmitriy Pavlov Assignee: Dmitriy Pavlov TC Bot was migrated to compacted storage of builds, so now it is no reason to keep old-fashioned REST request caches for TeamCity data -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10777) Cleanup remainders of JUnit4TestAdapter and other JUnit 3 API involving test suites
[ https://issues.apache.org/jira/browse/IGNITE-10777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16746523#comment-16746523 ] Eduard Shangareev commented on IGNITE-10777: Looks good, [~oignatenko], thank you! > Cleanup remainders of JUnit4TestAdapter and other JUnit 3 API involving test > suites > --- > > Key: IGNITE-10777 > URL: https://issues.apache.org/jira/browse/IGNITE-10777 > Project: Ignite > Issue Type: Sub-task >Affects Versions: 2.8 >Reporter: Oleg Ignatenko >Assignee: Oleg Ignatenko >Priority: Major > Labels: MakeTeamcityGreenAgain > Fix For: 2.8 > > Time Spent: 0.5h > Remaining Estimate: 0h > > This task is to cleanup remainders of JUnit4TestAdapter and other JUnit 3 API > involving test suites that may be missed in prior sub-tasks under the parent > task. > If needed, refer to parent task comments for more details. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10982) Kafka Ignite connect module listen to all related cache node events, not only the source cache
[
https://issues.apache.org/jira/browse/IGNITE-10982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16746522#comment-16746522
]
Mahmoud commented on IGNITE-10982:
--
[~roman_s]i have done that in my use case already :) , do want me to create a
pull request with that or a pull request with the continuous query usage
instead ?
> Kafka Ignite connect module listen to all related cache node events, not only
> the source cache
> --
>
> Key: IGNITE-10982
> URL: https://issues.apache.org/jira/browse/IGNITE-10982
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 2.7
>Reporter: Mahmoud
>Priority: Major
>
> Hey All ,
> I see in Kafka module , in
> IgniteSourceTask.java , we listen to all target cache node events not only
> the source cache event , is it by design like that ? we should only listen to
> the source cache events through continuous query:
> [https://apacheignite.readme.io/docs/continuous-queries]
>
> As we current implementation , we catch all caches events the belong to the
> same source cache node , not only the configured source cache name:
> code snippet from : IgniteSourceTask.java
> {code:java}
> rmtLsnrId = IgniteGrid.getIgnite().events(IgniteGrid.getIgnite().cluster()
> .forCacheNodes(cacheName))
> .remoteListen(locLsnr, rmtLsnr, evts);{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9279) Support custom default SQL schema name.
[ https://issues.apache.org/jira/browse/IGNITE-9279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16746511#comment-16746511 ] Evgenii Zhuravlev commented on IGNITE-9279: --- Hi [~vozerov], Do we have any plans for preparing documentation for this feature? It's not described anywhere. > Support custom default SQL schema name. > --- > > Key: IGNITE-9279 > URL: https://issues.apache.org/jira/browse/IGNITE-9279 > Project: Ignite > Issue Type: Wish > Components: sql >Reporter: Andrew Mashenkov >Assignee: Vladimir Ozerov >Priority: Major > Fix For: 2.7 > > > Default SQL schema is PUBLIC and there is no way to customize. > This may be useful when dynamic schema creation will be implemented. > Let's make default schema name configurable via node properties and then add > it to ignite configuration. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10944) Plugin discovery data from PluginProvider.provideDiscoveryData should be available in PluginProvider.validateNewNode
[ https://issues.apache.org/jira/browse/IGNITE-10944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16746506#comment-16746506 ] Mikhail Cherkasov commented on IGNITE-10944: Ignite already has method validateNode(ClusterNode node, JoiningNodeDiscoveryData discoData) in GridPlugingComponent, we just need to make ignite use this method and bypass discoData to plugin provider. I added a new method to plugins provider to implement this and added default implementation to interface to keep compatibility with existing plugins: [https://github.com/apache/ignite/pull/5865/files] [~agoncharuk] could you please review my changes? > Plugin discovery data from PluginProvider.provideDiscoveryData should be > available in PluginProvider.validateNewNode > > > Key: IGNITE-10944 > URL: https://issues.apache.org/jira/browse/IGNITE-10944 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.7 >Reporter: Andrey Aleksandrov >Assignee: Mikhail Cherkasov >Priority: Major > Fix For: 2.8 > > > *Current sequence:* > > 1)Server starts (coordinator) > 2)Client starts > 3)Client sends to the coordinator its discovery data using > *provideDiscoveryData* method > 4)Coordinator start validation of the node using *validateNewNode* > 5)The client joins the cluster; otherwise fails > 6)Coordinator provides the discovery data to plugin provider in > *receiveDiscoveryData.* After that this data could be passed to the plugin. > But in case if we require to validate new node using the discovery data from > *receiveDiscoveryData* method then we should add a possibility to get this > data in *validateNewNode* method. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-10863) Fix incorrect links to git repositories.
[ https://issues.apache.org/jira/browse/IGNITE-10863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov resolved IGNITE-10863. - Resolution: Fixed Apache ignite site was updated > Fix incorrect links to git repositories. > > > Key: IGNITE-10863 > URL: https://issues.apache.org/jira/browse/IGNITE-10863 > Project: Ignite > Issue Type: Task > Components: general >Reporter: Andrew Mashenkov >Assignee: Dmitriy Pavlov >Priority: Critical > Fix For: 2.8 > > > We have to refresh outdated links to project git repository. > [https://cwiki.apache.org/confluence/display/IGNITE/] [ > https://ignite.apache.org/community/resources.html#git] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10095) [TC Bot] Support Build Parameters storage in bot's DB and in run statistics
[ https://issues.apache.org/jira/browse/IGNITE-10095?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-10095: Ignite Flags: (was: Docs Required) > [TC Bot] Support Build Parameters storage in bot's DB and in run statistics > --- > > Key: IGNITE-10095 > URL: https://issues.apache.org/jira/browse/IGNITE-10095 > Project: Ignite > Issue Type: Task >Reporter: Dmitriy Pavlov >Assignee: Dmitriy Pavlov >Priority: Major > > [TC Bot] Support Build Parameters storage in bot's DB, and support > propagation of these parameters into run statistics > It is needed to have a future opportunity to separate Java 8,10,11 Runs and > also runs with short test set and full overnight run. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-1204) Cluster Discovery via Consul
[
https://issues.apache.org/jira/browse/IGNITE-1204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Saikat Maitra reassigned IGNITE-1204:
-
Assignee: Saikat Maitra
> Cluster Discovery via Consul
>
>
> Key: IGNITE-1204
> URL: https://issues.apache.org/jira/browse/IGNITE-1204
> Project: Ignite
> Issue Type: New Feature
> Components: general
>Reporter: Raúl Kripalani
>Assignee: Saikat Maitra
>Priority: Major
> Labels: discovery
>
> According to [their website|https://www.consul.io/]:
> {quote}
> * Consul makes it simple for services to register themselves and to discover
> other services via a DNS or HTTP interface.
> * Pairing service discovery with health checking prevents routing requests to
> unhealthy hosts and enables services to easily provide circuit breakers.
> * Consul scales to multiple datacenters out of the box with no complicated
> configuration. Look up services in other datacenters, or keep the request
> local.
> * Flexible key/value store for dynamic configuration, feature flagging,
> coordination, leader election and more. Long poll for near-instant
> notification of configuration changes.
> {quote}
> It would be nice to provide cluster discovery via Consul.
> Consul itself is MPL v2 licensed. According to [this ASF
> reference|https://www.apache.org/legal/resolved.html#category-b], this is a
> Category B license meaning that it's not viral by nature but it requires some
> degree of reciprocity. We don't really care much about this, because we won't
> be packaging Consul obviously.
> Moreover, there's a [client on GitHub|https://github.com/Ecwid/consul-api]
> that's ASLv2. Worse comes to worst, we could just invoke the HTTP API
> directly with no dependencies.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10988) Zookeeper test case testCommunicationFailureResolve_KillRandom frequently fails in GridAbstractTest.waitForTopology
[
https://issues.apache.org/jira/browse/IGNITE-10988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oleg Ignatenko updated IGNITE-10988:
Description:
Zookeeper test case testCommunicationFailureResolve_KillRandom frequently fails
in GridAbstractTest.waitForTopology.
Teamcity test history in master currently shows "Test runs: 625 total / 251
failures"
([link|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-3849782382784091413=testDetails).
Need to find out why is that and whether test case can be improved and made
more reliable.
Typical failure message looks as follows:
{noformat}
[2019-01-18 06:57:23,489][ERROR][main][root] Test failed.
junit.framework.AssertionFailedError
at junit.framework.Assert.fail(Assert.java:55)
at junit.framework.Assert.assertTrue(Assert.java:22)
at junit.framework.Assert.assertTrue(Assert.java:31)
at
org.apache.ignite.testframework.junits.GridAbstractTest.waitForTopology(GridAbstractTest.java:2294)
at
org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.waitForTopology(ZookeeperDiscoverySpiTest.java:5103)
at
org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.testCommunicationFailureResolve_KillRandom(ZookeeperDiscoverySpiTest.java:3145)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.apache.ignite.testframework.junits.GridAbstractTest$6.run(GridAbstractTest.java:2088)
at java.lang.Thread.run(Thread.java:748){noformat}
Side note per IGNITE-10777 this test case has moved to another class, from
{{ZookeeperDiscoverySpiTest}} to {{ZookeeperDiscoverySpiTest5}} (which was
further renamed to {{ZookeeperDiscoveryCommunicationFailureTest}}) but that
didn't change anything: it still fails frequently and failure message is the
same, with the only difference in the new test class name.
was:
Zookeeper test case testCommunicationFailureResolve_KillRandom frequently fails
in GridAbstractTest.waitForTopology.
Teamcity test history in master currently shows "Test runs: 625 total / 251
failures"
([link|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-3849782382784091413=testDetails).
Need to find out why is that and whether test case can be improved and made
more reliable.
Typical failure message looks as follows:
{noformat}
[2019-01-18 06:57:23,489][ERROR][main][root] Test failed.
junit.framework.AssertionFailedError
at junit.framework.Assert.fail(Assert.java:55)
at junit.framework.Assert.assertTrue(Assert.java:22)
at junit.framework.Assert.assertTrue(Assert.java:31)
at
org.apache.ignite.testframework.junits.GridAbstractTest.waitForTopology(GridAbstractTest.java:2294)
at
org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.waitForTopology(ZookeeperDiscoverySpiTest.java:5103)
at
org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.testCommunicationFailureResolve_KillRandom(ZookeeperDiscoverySpiTest.java:3145)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.apache.ignite.testframework.junits.GridAbstractTest$6.run(GridAbstractTest.java:2088)
at java.lang.Thread.run(Thread.java:748){noformat}
Side note per IGNITE-10777 this test case has moved to another class, from
{{ZookeeperDiscoverySpiTest}} to {{ZookeeperDiscoverySpiTest5}} but that didn't
change anything: it still fails frequently and failure message is the same,
with the only difference in the new test class name.
> Zookeeper test case testCommunicationFailureResolve_KillRandom frequently
>
[jira] [Commented] (IGNITE-10582) MVCC: Error on txLog initialization.
[
https://issues.apache.org/jira/browse/IGNITE-10582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16746441#comment-16746441
]
Ignite TC Bot commented on IGNITE-10582:
{panel:title=-- Run :: All: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Cache (Restarts) 2{color} [[tests
4|https://ci.ignite.apache.org/viewLog.html?buildId=2834134]]
* IgniteCacheRestartTestSuite2:
IgniteCacheAtomicReplicatedNodeRestartSelfTest.testRestartWithTxTwoNodesOneBackup
- 0,0% fails in last 607 master runs.
* IgniteCacheRestartTestSuite2:
IgniteCacheAtomicReplicatedNodeRestartSelfTest.testRestartWithTxSixNodesTwoBackups
- 0,0% fails in last 607 master runs.
* IgniteCacheRestartTestSuite2:
IgniteCacheAtomicReplicatedNodeRestartSelfTest.testRestartWithTxFourNodesOneBackups
- 0,0% fails in last 607 master runs.
* IgniteCacheRestartTestSuite2:
IgniteCacheAtomicReplicatedNodeRestartSelfTest.testRestartWithPutEightNodesTwoBackups
- 0,0% fails in last 607 master runs.
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=2834187buildTypeId=IgniteTests24Java8_RunAll]
> MVCC: Error on txLog initialization.
>
>
> Key: IGNITE-10582
> URL: https://issues.apache.org/jira/browse/IGNITE-10582
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Reporter: Roman Kondakov
>Assignee: Andrew Mashenkov
>Priority: Major
> Labels: Muted_test, mvcc_stabilization_stage_1, pagememory
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> A sporadic error occurs during {{txLog}} initialization. Reproducer:
> {{IgnitePdsCacheAssignmentNodeRestartsTest#testAssignmentAfterRestarts}}.
> This error may be the result of the test settings. We need to check it more
> carefully.
> Stacktrace:
> {noformat}
> javax.cache.CacheException: class org.apache.ignite.IgniteCheckedException:
> Failed to complete exchange process.
> at
> org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1337)
> at
> org.apache.ignite.internal.IgniteKernal.getOrCreateCaches(IgniteKernal.java:3068)
> at
> org.apache.ignite.internal.processors.cache.persistence.IgnitePdsCacheAssignmentNodeRestartsTest.testAssignmentAfterRestarts(IgnitePdsCacheAssignmentNodeRestartsTest.java:148)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.access$001(GridAbstractTest.java:149)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$6.evaluate(GridAbstractTest.java:2106)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$7.run(GridAbstractTest.java:2123)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to complete
> exchange process.
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.createExchangeException(GridDhtPartitionsExchangeFuture.java:3041)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.sendExchangeFailureMessage(GridDhtPartitionsExchangeFuture.java:3069)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.finishExchangeOnCoordinator(GridDhtPartitionsExchangeFuture.java:3151)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onAllReceived(GridDhtPartitionsExchangeFuture.java:3135)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.processSingleMessage(GridDhtPartitionsExchangeFuture.java:2748)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.access$100(GridDhtPartitionsExchangeFuture.java:138)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture$2.apply(GridDhtPartitionsExchangeFuture.java:2556)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture$2.apply(GridDhtPartitionsExchangeFuture.java:2544)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:395)
> at
>
[jira] [Commented] (IGNITE-10421) MVCC: Assertion in checkpointer thread.
[
https://issues.apache.org/jira/browse/IGNITE-10421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16746439#comment-16746439
]
Ignite TC Bot commented on IGNITE-10421:
{panel:title=-- Run :: All: No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=2834071buildTypeId=IgniteTests24Java8_RunAll]
> MVCC: Assertion in checkpointer thread.
> ---
>
> Key: IGNITE-10421
> URL: https://issues.apache.org/jira/browse/IGNITE-10421
> Project: Ignite
> Issue Type: Bug
> Components: mvcc, persistence
>Reporter: Roman Kondakov
>Assignee: Andrew Mashenkov
>Priority: Critical
> Labels: WAL, mvcc_stabilization_stage_1
> Fix For: 2.8
>
>
> Reproducers:
> * {{WalModeChangeAdvancedSelfTest#testJoin}} with enabled MVCC.
> * {{IgniteDynamicCacheStartFailWithPersistenceTest}}
> {noformat}
> [2018-11-27
> 14:56:47,548][ERROR][db-checkpoint-thread-#358%srv_3%][IgniteTestResources]
> Critical system error detected. Will be handled accordingly to configured
> handler [hnd=NoOpFailureHandler [super=AbstractFailureHandler
> [ignoredFailureTypes=SingletonSet [SYSTEM_WORKER_BLOCKED]]],
> failureCtx=FailureContext [type=CRITICAL_ERROR, err=class
> o.a.i.IgniteCheckedException: Compound exception for CountDownFuture.]]
> class org.apache.ignite.IgniteCheckedException: Compound exception for
> CountDownFuture.
> at
> org.apache.ignite.internal.util.future.CountDownFuture.addError(CountDownFuture.java:72)
> at
> org.apache.ignite.internal.util.future.CountDownFuture.onDone(CountDownFuture.java:46)
> at
> org.apache.ignite.internal.util.future.CountDownFuture.onDone(CountDownFuture.java:28)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:474)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$WriteCheckpointPages.run(GridCacheDatabaseSharedManager.java:3957)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> Suppressed: java.lang.AssertionError: off=3000,
> allocated=1000, pageId=00020002,
> file=/home/gridgain/Documents/work/incubator-ignite/work/db/node02-20092321-f30d-498f-8609-21ff87e4d104/TxLog/index.bin
> at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStore.write(FilePageStore.java:550)
> at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.writeInternal(FilePageStoreManager.java:520)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$WriteCheckpointPages.writePages(GridCacheDatabaseSharedManager.java:4022)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$WriteCheckpointPages.run(GridCacheDatabaseSharedManager.java:3930)
> ... 3 more
> Suppressed: java.lang.AssertionError: off=4000,
> allocated=1000, pageId=00020003,
> file=/home/gridgain/Documents/work/incubator-ignite/work/db/node02-20092321-f30d-498f-8609-21ff87e4d104/TxLog/index.bin
> at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStore.write(FilePageStore.java:550)
> at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.writeInternal(FilePageStoreManager.java:520)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$WriteCheckpointPages.writePages(GridCacheDatabaseSharedManager.java:4022)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$WriteCheckpointPages.run(GridCacheDatabaseSharedManager.java:3930)
> ... 3 more
> Suppressed: java.lang.AssertionError: off=2000,
> allocated=1000, pageId=00020001,
> file=/home/gridgain/Documents/work/incubator-ignite/work/db/node02-20092321-f30d-498f-8609-21ff87e4d104/TxLog/index.bin
> at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStore.write(FilePageStore.java:550)
> at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.writeInternal(FilePageStoreManager.java:520)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$WriteCheckpointPages.writePages(GridCacheDatabaseSharedManager.java:4022)
[jira] [Commented] (IGNITE-10777) Cleanup remainders of JUnit4TestAdapter and other JUnit 3 API involving test suites
[ https://issues.apache.org/jira/browse/IGNITE-10777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16746438#comment-16746438 ] Oleg Ignatenko commented on IGNITE-10777: - [~sergey-chugunov] - thanks for suggestion, test classes were renamed as you recommended > Cleanup remainders of JUnit4TestAdapter and other JUnit 3 API involving test > suites > --- > > Key: IGNITE-10777 > URL: https://issues.apache.org/jira/browse/IGNITE-10777 > Project: Ignite > Issue Type: Sub-task >Affects Versions: 2.8 >Reporter: Oleg Ignatenko >Assignee: Oleg Ignatenko >Priority: Major > Labels: MakeTeamcityGreenAgain > Fix For: 2.8 > > Time Spent: 0.5h > Remaining Estimate: 0h > > This task is to cleanup remainders of JUnit4TestAdapter and other JUnit 3 API > involving test suites that may be missed in prior sub-tasks under the parent > task. > If needed, refer to parent task comments for more details. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10988) Zookeeper test case testCommunicationFailureResolve_KillRandom frequently fails in GridAbstractTest.waitForTopology
Oleg Ignatenko created IGNITE-10988:
---
Summary: Zookeeper test case
testCommunicationFailureResolve_KillRandom frequently fails in
GridAbstractTest.waitForTopology
Key: IGNITE-10988
URL: https://issues.apache.org/jira/browse/IGNITE-10988
Project: Ignite
Issue Type: Bug
Affects Versions: 2.7
Reporter: Oleg Ignatenko
Zookeeper test case testCommunicationFailureResolve_KillRandom frequently fails
in GridAbstractTest.waitForTopology.
Teamcity test history in master currently shows "Test runs: 625 total / 251
failures"
([link|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-3849782382784091413=testDetails).
Need to find out why is that and whether test case can be improved and made
more reliable.
Typical failure message looks as follows:
{noformat}
[2019-01-18 06:57:23,489][ERROR][main][root] Test failed.
junit.framework.AssertionFailedError
at junit.framework.Assert.fail(Assert.java:55)
at junit.framework.Assert.assertTrue(Assert.java:22)
at junit.framework.Assert.assertTrue(Assert.java:31)
at
org.apache.ignite.testframework.junits.GridAbstractTest.waitForTopology(GridAbstractTest.java:2294)
at
org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.waitForTopology(ZookeeperDiscoverySpiTest.java:5103)
at
org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.testCommunicationFailureResolve_KillRandom(ZookeeperDiscoverySpiTest.java:3145)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.apache.ignite.testframework.junits.GridAbstractTest$6.run(GridAbstractTest.java:2088)
at java.lang.Thread.run(Thread.java:748){noformat}
Side note per IGNITE-10777 this test case has moved to another class, from
{{ZookeeperDiscoverySpiTest}} to {{ZookeeperDiscoverySpiTest5}} but that didn't
change anything: it still fails frequently and failure message is the same,
with the only difference in the new test class name.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10988) Zookeeper test case testCommunicationFailureResolve_KillRandom frequently fails in GridAbstractTest.waitForTopology
[
https://issues.apache.org/jira/browse/IGNITE-10988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oleg Ignatenko updated IGNITE-10988:
Labels: MakeTeamcityGreenAgain (was: )
> Zookeeper test case testCommunicationFailureResolve_KillRandom frequently
> fails in GridAbstractTest.waitForTopology
> ---
>
> Key: IGNITE-10988
> URL: https://issues.apache.org/jira/browse/IGNITE-10988
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.7
>Reporter: Oleg Ignatenko
>Priority: Major
> Labels: MakeTeamcityGreenAgain
>
> Zookeeper test case testCommunicationFailureResolve_KillRandom frequently
> fails in GridAbstractTest.waitForTopology.
> Teamcity test history in master currently shows "Test runs: 625 total / 251
> failures"
> ([link|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-3849782382784091413=testDetails).
> Need to find out why is that and whether test case can be improved and made
> more reliable.
> Typical failure message looks as follows:
> {noformat}
> [2019-01-18 06:57:23,489][ERROR][main][root] Test failed.
> junit.framework.AssertionFailedError
> at junit.framework.Assert.fail(Assert.java:55)
> at junit.framework.Assert.assertTrue(Assert.java:22)
> at junit.framework.Assert.assertTrue(Assert.java:31)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.waitForTopology(GridAbstractTest.java:2294)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.waitForTopology(ZookeeperDiscoverySpiTest.java:5103)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.testCommunicationFailureResolve_KillRandom(ZookeeperDiscoverySpiTest.java:3145)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$6.run(GridAbstractTest.java:2088)
> at java.lang.Thread.run(Thread.java:748){noformat}
>
> Side note per IGNITE-10777 this test case has moved to another class, from
> {{ZookeeperDiscoverySpiTest}} to {{ZookeeperDiscoverySpiTest5}} but that
> didn't change anything: it still fails frequently and failure message is the
> same, with the only difference in the new test class name.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10988) Zookeeper test case testCommunicationFailureResolve_KillRandom frequently fails in GridAbstractTest.waitForTopology
[
https://issues.apache.org/jira/browse/IGNITE-10988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oleg Ignatenko updated IGNITE-10988:
Ignite Flags: (was: Docs Required)
> Zookeeper test case testCommunicationFailureResolve_KillRandom frequently
> fails in GridAbstractTest.waitForTopology
> ---
>
> Key: IGNITE-10988
> URL: https://issues.apache.org/jira/browse/IGNITE-10988
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.7
>Reporter: Oleg Ignatenko
>Priority: Major
>
> Zookeeper test case testCommunicationFailureResolve_KillRandom frequently
> fails in GridAbstractTest.waitForTopology.
> Teamcity test history in master currently shows "Test runs: 625 total / 251
> failures"
> ([link|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-3849782382784091413=testDetails).
> Need to find out why is that and whether test case can be improved and made
> more reliable.
> Typical failure message looks as follows:
> {noformat}
> [2019-01-18 06:57:23,489][ERROR][main][root] Test failed.
> junit.framework.AssertionFailedError
> at junit.framework.Assert.fail(Assert.java:55)
> at junit.framework.Assert.assertTrue(Assert.java:22)
> at junit.framework.Assert.assertTrue(Assert.java:31)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.waitForTopology(GridAbstractTest.java:2294)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.waitForTopology(ZookeeperDiscoverySpiTest.java:5103)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.testCommunicationFailureResolve_KillRandom(ZookeeperDiscoverySpiTest.java:3145)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$6.run(GridAbstractTest.java:2088)
> at java.lang.Thread.run(Thread.java:748){noformat}
>
> Side note per IGNITE-10777 this test case has moved to another class, from
> {{ZookeeperDiscoverySpiTest}} to {{ZookeeperDiscoverySpiTest5}} but that
> didn't change anything: it still fails frequently and failure message is the
> same, with the only difference in the new test class name.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10987) --skip-zeros flag of idle_verify command should filter out empty partitions regardless of the value of update counter
[ https://issues.apache.org/jira/browse/IGNITE-10987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-10987: - Issue Type: Improvement (was: Test) > --skip-zeros flag of idle_verify command should filter out empty partitions > regardless of the value of update counter > -- > > Key: IGNITE-10987 > URL: https://issues.apache.org/jira/browse/IGNITE-10987 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.7 >Reporter: Vyacheslav Koptilin >Assignee: Vyacheslav Koptilin >Priority: Major > Fix For: 2.8 > > > Current implementation excludes empty partitions then and only then the > update counter and partition hash equal to zero. > It seems that the condition can be simplified and we should take into account > partition hash and size. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10987) --skip-zeros flag of idle_verify command should filter out empty partitions regardless of the value of update counter
[ https://issues.apache.org/jira/browse/IGNITE-10987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-10987: - Description: Current implementation excludes empty partitions then and only then the update counter and partition hash equal to zero. It seems that the condition can be simplified and we should take into account partition hash and size. was: Current implementation exludes empty partitions then and only then the update counter and partition hash are equal to zero. It seems that the condition can be simplified and we should take into account partition hash and size. > --skip-zeros flag of idle_verify command should filter out empty partitions > regardless of the value of update counter > -- > > Key: IGNITE-10987 > URL: https://issues.apache.org/jira/browse/IGNITE-10987 > Project: Ignite > Issue Type: Test >Affects Versions: 2.7 >Reporter: Vyacheslav Koptilin >Assignee: Vyacheslav Koptilin >Priority: Major > Fix For: 2.8 > > > Current implementation excludes empty partitions then and only then the > update counter and partition hash equal to zero. > It seems that the condition can be simplified and we should take into account > partition hash and size. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10987) --skip-zeros flag of idle_verify command should filter out empty partitions regardless of the value of update counter
[ https://issues.apache.org/jira/browse/IGNITE-10987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-10987: - Description: Current implementation exludes empty partitions then and only then the update counter and partition hash are equal to zero. It seems that the condition can be simplified and we should take into account partition hash and size. was: Current implementation exludes empty partitions then and only then update counter and partition hash are equal to zero. It seems that the condition can be simplified and we should take into account partition hash and size. > --skip-zeros flag of idle_verify command should filter out empty partitions > regardless of the value of update counter > -- > > Key: IGNITE-10987 > URL: https://issues.apache.org/jira/browse/IGNITE-10987 > Project: Ignite > Issue Type: Test >Affects Versions: 2.7 >Reporter: Vyacheslav Koptilin >Assignee: Vyacheslav Koptilin >Priority: Major > Fix For: 2.8 > > > Current implementation exludes empty partitions then and only then the update > counter and partition hash are equal to zero. > It seems that the condition can be simplified and we should take into account > partition hash and size. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10987) --skip-zeros flag of idle_verify command should filter out empty partitions regardless of the value of update counter
[ https://issues.apache.org/jira/browse/IGNITE-10987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-10987: - Description: Current implementation exludes empty partitions then and only then update counter and partition hash are equal to zero. It seems that the condition can be simplified and we should take into account partition hash and size. > --skip-zeros flag of idle_verify command should filter out empty partitions > regardless of the value of update counter > -- > > Key: IGNITE-10987 > URL: https://issues.apache.org/jira/browse/IGNITE-10987 > Project: Ignite > Issue Type: Test >Affects Versions: 2.7 >Reporter: Vyacheslav Koptilin >Assignee: Vyacheslav Koptilin >Priority: Major > Fix For: 2.8 > > > Current implementation exludes empty partitions then and only then update > counter and partition hash are equal to zero. > It seems that the condition can be simplified and we should take into account > partition hash and size. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10987) --skip-zeros flag of idle_verify command should filter out empty partitions regardless of the value of update counter
Vyacheslav Koptilin created IGNITE-10987: Summary: --skip-zeros flag of idle_verify command should filter out empty partitions regardless of the value of update counter Key: IGNITE-10987 URL: https://issues.apache.org/jira/browse/IGNITE-10987 Project: Ignite Issue Type: Test Affects Versions: 2.7 Reporter: Vyacheslav Koptilin Assignee: Vyacheslav Koptilin Fix For: 2.8 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10347) Expose system SQL view for running queries
[
https://issues.apache.org/jira/browse/IGNITE-10347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16746373#comment-16746373
]
Ignite TC Bot commented on IGNITE-10347:
{panel:title=-- Run :: All: No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=2824239buildTypeId=IgniteTests24Java8_RunAll]
> Expose system SQL view for running queries
> --
>
> Key: IGNITE-10347
> URL: https://issues.apache.org/jira/browse/IGNITE-10347
> Project: Ignite
> Issue Type: Task
>Reporter: Yury Gerzhedovich
>Assignee: Yury Gerzhedovich
>Priority: Major
> Labels: iep-29, sql
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Need to expose system SQL view to provide list of running queries. Proposed
> name is *running_queries* with following columns: query_id, node_id, sql,
> schema_name, duration.
> Where,
> query_id - cluster unique id of query with format \{node_order_id}
> {X}
> {node_qry_cntr}, both node_order_id and node_qry_cntr encoded to HEX. X - 'X'
> letter used as separator.
> node_id - id of node where query was started
> sql - sql command
> schema_name - SQL schema name
> duration - time in ms from start of execution of query
>
> The view should contains all kind of running queries from RunningQueryManager
> on local node
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-10980) CPP: Create TC suite for Windows 64 Debug mode
[ https://issues.apache.org/jira/browse/IGNITE-10980?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16746317#comment-16746317 ] Peter Ivanov edited comment on IGNITE-10980 at 1/18/19 2:59 PM: [Platform C++ (Win x64 / Debug) #2|https://ci.ignite.apache.org/viewQueued.html?itemId=2835990] was (Author: vveider): [Platform C++ (Win x64 / Debug) #2|https://ci.ignite.apache.org/viewQueued.html?itemId= 2835990] > CPP: Create TC suite for Windows 64 Debug mode > -- > > Key: IGNITE-10980 > URL: https://issues.apache.org/jira/browse/IGNITE-10980 > Project: Ignite > Issue Type: Task > Components: platforms >Affects Versions: 2.7 >Reporter: Igor Sapego >Assignee: Peter Ivanov >Priority: Major > Labels: cpp > > Currently, there is a [Platform C++ (Windows > x64)|https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_PlatformCWindowsX64=buildTypeStatusDiv_IgniteTests24Java8=__all_branches__] > suite, which builds and runs tests in Release mode. It's OK, as we need to > test Release mode in the first place, as this is the mode, in which user uses > Ignite C++. But we also need to run tests in Debug mode, as in debug > additional errors (such as heap corruption and memory leaks) can be detected. > So it is proposed to rename "Platform C++ (Windows x64)" test suite to > "Platform C++ (Windows x64 Release)" and add another suite "Platform C++ > (Windows x64 Debug)", which will build and run tests in Debug mode. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10754) Query history statistics API
[ https://issues.apache.org/jira/browse/IGNITE-10754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16746370#comment-16746370 ] Yury Gerzhedovich commented on IGNITE-10754: [~vozerov], all mentioned issues have been fixed. > Query history statistics API > > > Key: IGNITE-10754 > URL: https://issues.apache.org/jira/browse/IGNITE-10754 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Yury Gerzhedovich >Assignee: Yury Gerzhedovich >Priority: Major > Labels: iep-29, monitoring > Fix For: 2.8 > > Time Spent: 40m > Remaining Estimate: 0h > > As of now we have query statistics > (*_org.apache.ignite.IgniteCache#queryMetrics_*) , but have few issues. > 1) Duration execution it just time between start execution and return cursor > to client and doesn't include all life time of query. > 2) It doesn't know about multistatement queries. Such queries participate in > statistics as single query without splitting. > 3) API to access the statistics expose as depend on cache, however query > don't have such dependency. > > Need to create parallel similar realization as we already have. > Use new infrastructure of tracking running queries developed under > IGNITE-10621 and update statistics on unregister phase. > Expose API on upper level then it placed now. Right place will be written > later. > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-10980) CPP: Create TC suite for Windows 64 Debug mode
[ https://issues.apache.org/jira/browse/IGNITE-10980?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16746317#comment-16746317 ] Peter Ivanov edited comment on IGNITE-10980 at 1/18/19 2:45 PM: [Platform C++ (Win x64 / Debug) #2|https://ci.ignite.apache.org/viewQueued.html?itemId= 2835990] was (Author: vveider): [Platform C++ (Win x64 / Debug) #1|https://ci.ignite.apache.org/viewQueued.html?itemId=2835581] > CPP: Create TC suite for Windows 64 Debug mode > -- > > Key: IGNITE-10980 > URL: https://issues.apache.org/jira/browse/IGNITE-10980 > Project: Ignite > Issue Type: Task > Components: platforms >Affects Versions: 2.7 >Reporter: Igor Sapego >Assignee: Peter Ivanov >Priority: Major > Labels: cpp > > Currently, there is a [Platform C++ (Windows > x64)|https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_PlatformCWindowsX64=buildTypeStatusDiv_IgniteTests24Java8=__all_branches__] > suite, which builds and runs tests in Release mode. It's OK, as we need to > test Release mode in the first place, as this is the mode, in which user uses > Ignite C++. But we also need to run tests in Debug mode, as in debug > additional errors (such as heap corruption and memory leaks) can be detected. > So it is proposed to rename "Platform C++ (Windows x64)" test suite to > "Platform C++ (Windows x64 Release)" and add another suite "Platform C++ > (Windows x64 Debug)", which will build and run tests in Debug mode. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-7948) SQL: read only necessary fields into the row when possible
[
https://issues.apache.org/jira/browse/IGNITE-7948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov reassigned IGNITE-7948:
---
Assignee: Taras Ledkov (was: Vladimir Ozerov)
> SQL: read only necessary fields into the row when possible
> --
>
> Key: IGNITE-7948
> URL: https://issues.apache.org/jira/browse/IGNITE-7948
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Taras Ledkov
>Priority: Major
>
> When H2 row is read, we always fill it with data eagerly through link
> materialization. Materialization is performed under page "read lock" what
> guarantees row-level consistency. This may lead to excessive memory pressure
> due to memory copying. For example, consider a class with 50 fields and a
> query which reads only 2 of them. 48 other fields will be copied without a
> reason. Lazy initialization is not an option because it will only defer
> memcpy, but not eliminate it.
> Instead we can try using H2. It passes {{TableFilter}} class to some of index
> access methods*. We can analyze this class and create the list of required
> fields. Then we can read these fields under read lock from offheap and put
> them to the row.
> In addition to saved memcpy this could give us more benefits:
> 1) No more need for field cache ({{GridH2KeyValueRowOnheap#valCache}})
> 2) No more need to read {{_VER}} column and possibly {{_KEY}} or {{_VAL}}
> But there are a number of drawbacks as well. E.g. it is impossible to read
> strings from offheap efficiently, so queries with VARCHAR will definitely
> suffer from this change.
> \* {{org.h2.index.Index#find(org.h2.table.TableFilter,
> org.h2.result.SearchRow, org.h2.result.SearchRow)}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10986) SQL: drop _VER field support
[
https://issues.apache.org/jira/browse/IGNITE-10986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-10986:
-
Summary: SQL: drop _VER field support (was: SQL: Drop _VER field support)
> SQL: drop _VER field support
>
>
> Key: IGNITE-10986
> URL: https://issues.apache.org/jira/browse/IGNITE-10986
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Alexander Lapin
>Priority: Major
> Fix For: 2.8
>
>
> {{_VER}} is undocumented hidden field which is never used in practice. But
> profiling shows that it consumes a lot of memory. Let's drop support of this
> field from all {{GridH2SearchRow}} implementations, as well as from internal
> descriptors.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10985) SQL: create low-overhead implementation of Row for SELECTs
[
https://issues.apache.org/jira/browse/IGNITE-10985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-10985:
-
Description:
Currently we use {{GridH2KeyValueRowOnheap}} for both update and search
operations. This leads to *huge* memory overhead during {{SELECT}} execution.
If you take a closer look on what is inside the row, you will note the
following:
# It has both serialized and deserialized {{GridCacheVersion}} which is never
needed
# It has wrapped key and value object
# It has reference to {{CacheDataRow}} which is not needed either
# It has {{valCache}} field which is never used in SELECT
The goal of this ticket is to created optimized version of row which will be
created during {{SELECT}} operations only. It should contain only minimally
necessary information:
# Key (unwrapped!)
# Value (unwrapped!)
# Version (unwrapped, we will remove it completely in separate ticket
IGNITE-10986)
It should not contain reference to {{CacheDataRow}}. There is a chance that we
will need some pieces from it (e.g. cache ID and link for caching purposes),
but it definitely will be only small subset of the whole
{{CacheDataRowAdapter}} (or even worse - {{MvccDataRow}}).
Entry point: {{H2Tree.createRowFromLink}} methods. Note that they return
{{GridH2Row}}, while in their usages only very relaxed version of
{{GridH2SearchRow}} is needed. So let's start with new implementation of row
for these methods and then gradually remove all unnecessary stuff from there.
was:
Currently we use {{GridH2KeyValueRowOnheap}} for both update and search
operations. This leads to *huge* memory overhead during {{SELECT}} execution.
If you take a closer look on what is inside the row, you will note the
following:
# It has both serialized and deserialized {{GridCacheVersion}} which is never
needed
# It has wrapped key and value object
# It has reference to {{CacheDataRow}} which is not needed either
# It has {{valCache}} field which is never used in SELECT
The goal of this ticket is to created optimized version of row which will be
created during {{SELECT}} operations only. It should contain only minimally
necessary information:
# Key (unwrapped!)
# Value (unwrapped!)
# Version (unwrapped, we will remove it completely in separate ticket)
It should not contain reference to {{CacheDataRow}}. There is a chance that we
will need some pieces from it (e.g. cache ID and link for caching purposes),
but it definitely will be only small subset of the whole
{{CacheDataRowAdapter}} (or even worse - {{MvccDataRow}}).
Entry point: {{H2Tree.createRowFromLink}} methods. Note that they return
{{GridH2Row}}, while in their usages only very relaxed version of
{{GridH2SearchRow}} is needed. So let's start with new implementation of row
for these methods and then gradually remove all unnecessary stuff from there.
> SQL: create low-overhead implementation of Row for SELECTs
> --
>
> Key: IGNITE-10985
> URL: https://issues.apache.org/jira/browse/IGNITE-10985
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Alexander Lapin
>Priority: Major
> Fix For: 2.8
>
>
> Currently we use {{GridH2KeyValueRowOnheap}} for both update and search
> operations. This leads to *huge* memory overhead during {{SELECT}} execution.
> If you take a closer look on what is inside the row, you will note the
> following:
> # It has both serialized and deserialized {{GridCacheVersion}} which is never
> needed
> # It has wrapped key and value object
> # It has reference to {{CacheDataRow}} which is not needed either
> # It has {{valCache}} field which is never used in SELECT
> The goal of this ticket is to created optimized version of row which will be
> created during {{SELECT}} operations only. It should contain only minimally
> necessary information:
> # Key (unwrapped!)
> # Value (unwrapped!)
> # Version (unwrapped, we will remove it completely in separate ticket
> IGNITE-10986)
> It should not contain reference to {{CacheDataRow}}. There is a chance that
> we will need some pieces from it (e.g. cache ID and link for caching
> purposes), but it definitely will be only small subset of the whole
> {{CacheDataRowAdapter}} (or even worse - {{MvccDataRow}}).
> Entry point: {{H2Tree.createRowFromLink}} methods. Note that they return
> {{GridH2Row}}, while in their usages only very relaxed version of
> {{GridH2SearchRow}} is needed. So let's start with new implementation of row
> for these methods and then gradually remove all unnecessary stuff from there.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10986) SQL: Drop _VER field support
Vladimir Ozerov created IGNITE-10986:
Summary: SQL: Drop _VER field support
Key: IGNITE-10986
URL: https://issues.apache.org/jira/browse/IGNITE-10986
Project: Ignite
Issue Type: Task
Components: sql
Reporter: Vladimir Ozerov
Assignee: Alexander Lapin
Fix For: 2.8
{{_VER}} is undocumented hidden field which is never used in practice. But
profiling shows that it consumes a lot of memory. Let's drop support of this
field from all {{GridH2SearchRow}} implementations, as well as from internal
descriptors.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10985) SQL: create low-overhead implementation of Row for SELECTs
Vladimir Ozerov created IGNITE-10985:
Summary: SQL: create low-overhead implementation of Row for SELECTs
Key: IGNITE-10985
URL: https://issues.apache.org/jira/browse/IGNITE-10985
Project: Ignite
Issue Type: Task
Components: sql
Reporter: Vladimir Ozerov
Assignee: Alexander Lapin
Fix For: 2.8
Currently we use {{GridH2KeyValueRowOnheap}} for both update and search
operations. This leads to *huge* memory overhead during {{SELECT}} execution.
If you take a closer look on what is inside the row, you will note the
following:
# It has both serialized and deserialized {{GridCacheVersion}} which is never
needed
# It has wrapped key and value object
# It has reference to {{CacheDataRow}} which is not needed either
# It has {{valCache}} field which is never used in SELECT
The goal of this ticket is to created optimized version of row which will be
created during {{SELECT}} operations only. It should contain only minimally
necessary information:
# Key (unwrapped!)
# Value (unwrapped!)
# Version (unwrapped, we will remove it completely in separate ticket)
It should not contain reference to {{CacheDataRow}}. There is a chance that we
will need some pieces from it (e.g. cache ID and link for caching purposes),
but it definitely will be only small subset of the whole
{{CacheDataRowAdapter}} (or even worse - {{MvccDataRow}}).
Entry point: {{H2Tree.createRowFromLink}} methods. Note that they return
{{GridH2Row}}, while in their usages only very relaxed version of
{{GridH2SearchRow}} is needed. So let's start with new implementation of row
for these methods and then gradually remove all unnecessary stuff from there.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-10978) Remove unused tests marked with unclear todo
[
https://issues.apache.org/jira/browse/IGNITE-10978?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konstantin Bolyandra reassigned IGNITE-10978:
-
Assignee: Konstantin Bolyandra
> Remove unused tests marked with unclear todo
>
>
> Key: IGNITE-10978
> URL: https://issues.apache.org/jira/browse/IGNITE-10978
> Project: Ignite
> Issue Type: Task
>Reporter: Dmitriy Pavlov
>Assignee: Konstantin Bolyandra
>Priority: Major
> Labels: newbie
>
> {noformat}
> IgniteCacheTestSuite3
> // TODO GG-11141.
> //
> GridTestUtils.addTestIfNeeded(suite,GridCacheDeploymentSelfTest.class,
> ignoredTests);
> //
> GridTestUtils.addTestIfNeeded(suite,GridCacheDeploymentOffHeapSelfTest.class,
> ignoredTests);
> //
> GridTestUtils.addTestIfNeeded(suite,GridCacheDeploymentOffHeapValuesSelfTest.class,
> ignoredTests);
> IgniteCacheInterceptorSelfTestSuite
> // TODO GG-11141.
> //
> GridTestUtils.addTestIfNeeded(suite,GridCacheOnCopyFlagTxPartitionedSelfTest.class,
> ignoredTests);
> //
> GridTestUtils.addTestIfNeeded(suite,GridCacheOnCopyFlagReplicatedSelfTest.class,
> ignoredTests);
> //
> GridTestUtils.addTestIfNeeded(suite,GridCacheOnCopyFlagLocalSelfTest.class,
> ignoredTests);
> //
> GridTestUtils.addTestIfNeeded(suite,GridCacheOnCopyFlagAtomicSelfTest.class,
> ignoredTests);
> {noformat}
> Test classes not used, so there is no reason to keep it
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10982) Kafka Ignite connect module listen to all related cache node events, not only the source cache
[
https://issues.apache.org/jira/browse/IGNITE-10982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16746336#comment-16746336
]
Roman Shtykh commented on IGNITE-10982:
---
I think we better change it to continuous query.
For now, \{{TaskRemoteFilter}} has a user-specified filter, which you can
define to filter out events remotely by cache name.
> Kafka Ignite connect module listen to all related cache node events, not only
> the source cache
> --
>
> Key: IGNITE-10982
> URL: https://issues.apache.org/jira/browse/IGNITE-10982
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 2.7
>Reporter: Mahmoud
>Priority: Major
>
> Hey All ,
> I see in Kafka module , in
> IgniteSourceTask.java , we listen to all target cache node events not only
> the source cache event , is it by design like that ? we should only listen to
> the source cache events through continuous query:
> [https://apacheignite.readme.io/docs/continuous-queries]
>
> As we current implementation , we catch all caches events the belong to the
> same source cache node , not only the configured source cache name:
> code snippet from : IgniteSourceTask.java
> {code:java}
> rmtLsnrId = IgniteGrid.getIgnite().events(IgniteGrid.getIgnite().cluster()
> .forCacheNodes(cacheName))
> .remoteListen(locLsnr, rmtLsnr, evts);{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-6564) Incorrect calculation size and keySize for cluster cache metrics
[ https://issues.apache.org/jira/browse/IGNITE-6564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16746349#comment-16746349 ] Sergey Kosarev commented on IGNITE-6564: Returned old behavior https://github.com/apache/ignite/pull/5857 [~ilyak], review please. > Incorrect calculation size and keySize for cluster cache metrics > > > Key: IGNITE-6564 > URL: https://issues.apache.org/jira/browse/IGNITE-6564 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.2 >Reporter: Ilya Kasnacheev >Assignee: Sergey Kosarev >Priority: Minor > Labels: iep-6 > Time Spent: 50m > Remaining Estimate: 0h > > They are currently not passed by ring and therefore only taken from current > node, which returns incorrect (local) value. > See CacheMetricsSnapshot class. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-6564) Incorrect calculation size and keySize for cluster cache metrics
[ https://issues.apache.org/jira/browse/IGNITE-6564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Kosarev reassigned IGNITE-6564: -- Assignee: Sergey Kosarev (was: Alexand Polyakov) > Incorrect calculation size and keySize for cluster cache metrics > > > Key: IGNITE-6564 > URL: https://issues.apache.org/jira/browse/IGNITE-6564 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.2 >Reporter: Ilya Kasnacheev >Assignee: Sergey Kosarev >Priority: Minor > Labels: iep-6 > Time Spent: 50m > Remaining Estimate: 0h > > They are currently not passed by ring and therefore only taken from current > node, which returns incorrect (local) value. > See CacheMetricsSnapshot class. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10824) SQL: mixing _key and key columns in the DML queries must be disallowed
[
https://issues.apache.org/jira/browse/IGNITE-10824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16746334#comment-16746334
]
Pavel Kuznetsov commented on IGNITE-10824:
--
[~vozerov] Thank you,
1. Done
2. Actually we do create light-weight views for columns for the unification. In
{{planForInsert}} we have {{GridSqlColumn[]}}; For updates we've got
ArrayList; and in planForBulkLoad we've got just array of h2's
{{Column}}s.
3. Ok, I've updated code so, we can avoid the lookup into the hashmap, now we
take in {{#verifyUpdateColumns}} collection (which may be a light-weight view)
of h2's {{Column}}s
4. Sure, done.
> SQL: mixing _key and key columns in the DML queries must be disallowed
> --
>
> Key: IGNITE-10824
> URL: https://issues.apache.org/jira/browse/IGNITE-10824
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Pavel Kuznetsov
>Assignee: Pavel Kuznetsov
>Priority: Minor
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> DML should contain either placeholder for _key (_val) or subset of key
> (value) columns but not both. Also we should keep in mind _key/_value aliases
> Given table with primary key column {{id}} and value column {{salary}}. Next
> queries should be validated to parsing error:
> {code:sql}
> INSERT INTO TEST_TABLE (_key, id, salary) VALUES (1, 2, 42);
> UPDATE TEST_TABLE SET _val = 1, salary = 2;
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10984) Remove IGNITE_DISABLE_TRIGGERING_CACHE_INTERCEPTOR_ON_CONFLICT option
Sergey Antonov created IGNITE-10984: --- Summary: Remove IGNITE_DISABLE_TRIGGERING_CACHE_INTERCEPTOR_ON_CONFLICT option Key: IGNITE-10984 URL: https://issues.apache.org/jira/browse/IGNITE-10984 Project: Ignite Issue Type: Improvement Reporter: Sergey Antonov Fix For: 3.0 We should rework logic and remove IGNITE_DISABLE_TRIGGERING_CACHE_INTERCEPTOR_ON_CONFLICT option. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10984) Remove IGNITE_DISABLE_TRIGGERING_CACHE_INTERCEPTOR_ON_CONFLICT option
[ https://issues.apache.org/jira/browse/IGNITE-10984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Antonov updated IGNITE-10984: Affects Version/s: 2.8 > Remove IGNITE_DISABLE_TRIGGERING_CACHE_INTERCEPTOR_ON_CONFLICT option > - > > Key: IGNITE-10984 > URL: https://issues.apache.org/jira/browse/IGNITE-10984 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.8 >Reporter: Sergey Antonov >Priority: Major > Fix For: 3.0 > > > We should rework logic and remove > IGNITE_DISABLE_TRIGGERING_CACHE_INTERCEPTOR_ON_CONFLICT option. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10983) Check that persistenceEnabled is consistent on all nodes
Stanislav Lukyanov created IGNITE-10983: --- Summary: Check that persistenceEnabled is consistent on all nodes Key: IGNITE-10983 URL: https://issues.apache.org/jira/browse/IGNITE-10983 Project: Ignite Issue Type: Task Reporter: Stanislav Lukyanov Currently it is possible to have a cluster where the same data region is persistent on some nodes and not persistent on others. This use case doesn't have enough testing, so it's better to deny it for now by adding a check for that and not allowing a node with a different persistenceEnabled value to join the cluster. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8575) Change Baseline auto-adjust parameters via console.sh
[
https://issues.apache.org/jira/browse/IGNITE-8575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16746309#comment-16746309
]
Ignite TC Bot commented on IGNITE-8575:
---
{panel:title=-- Run :: All: No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=2832899buildTypeId=IgniteTests24Java8_RunAll]
> Change Baseline auto-adjust parameters via console.sh
> -
>
> Key: IGNITE-8575
> URL: https://issues.apache.org/jira/browse/IGNITE-8575
> Project: Ignite
> Issue Type: New Feature
>Reporter: Eduard Shangareev
>Assignee: Ivan Bessonov
>Priority: Major
> Labels: IEP-4, Phase-2
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We would introduce at IGNITE-8571 new parameters.
> We need to have option change them via console.sh.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-10980) CPP: Create TC suite for Windows 64 Debug mode
[ https://issues.apache.org/jira/browse/IGNITE-10980?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16746317#comment-16746317 ] Peter Ivanov edited comment on IGNITE-10980 at 1/18/19 2:07 PM: [Platform C++ (Win x64 / Debug) #1|https://ci.ignite.apache.org/viewQueued.html?itemId=2835581] was (Author: vveider): [Platform C++ (Win x64 || Debug) #1|https://ci.ignite.apache.org/viewQueued.html?itemId=2835581] > CPP: Create TC suite for Windows 64 Debug mode > -- > > Key: IGNITE-10980 > URL: https://issues.apache.org/jira/browse/IGNITE-10980 > Project: Ignite > Issue Type: Task > Components: platforms >Affects Versions: 2.7 >Reporter: Igor Sapego >Assignee: Peter Ivanov >Priority: Major > Labels: cpp > > Currently, there is a [Platform C++ (Windows > x64)|https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_PlatformCWindowsX64=buildTypeStatusDiv_IgniteTests24Java8=__all_branches__] > suite, which builds and runs tests in Release mode. It's OK, as we need to > test Release mode in the first place, as this is the mode, in which user uses > Ignite C++. But we also need to run tests in Debug mode, as in debug > additional errors (such as heap corruption and memory leaks) can be detected. > So it is proposed to rename "Platform C++ (Windows x64)" test suite to > "Platform C++ (Windows x64 Release)" and add another suite "Platform C++ > (Windows x64 Debug)", which will build and run tests in Debug mode. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-10980) CPP: Create TC suite for Windows 64 Debug mode
[ https://issues.apache.org/jira/browse/IGNITE-10980?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16746317#comment-16746317 ] Peter Ivanov edited comment on IGNITE-10980 at 1/18/19 2:07 PM: [Platform C++ (Win x64 || Debug) #1|https://ci.ignite.apache.org/viewQueued.html?itemId=2835581] was (Author: vveider): [Platform C++ (Win x64 | Debug) #1|https://ci.ignite.apache.org/viewQueued.html?itemId=2835581] > CPP: Create TC suite for Windows 64 Debug mode > -- > > Key: IGNITE-10980 > URL: https://issues.apache.org/jira/browse/IGNITE-10980 > Project: Ignite > Issue Type: Task > Components: platforms >Affects Versions: 2.7 >Reporter: Igor Sapego >Assignee: Peter Ivanov >Priority: Major > Labels: cpp > > Currently, there is a [Platform C++ (Windows > x64)|https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_PlatformCWindowsX64=buildTypeStatusDiv_IgniteTests24Java8=__all_branches__] > suite, which builds and runs tests in Release mode. It's OK, as we need to > test Release mode in the first place, as this is the mode, in which user uses > Ignite C++. But we also need to run tests in Debug mode, as in debug > additional errors (such as heap corruption and memory leaks) can be detected. > So it is proposed to rename "Platform C++ (Windows x64)" test suite to > "Platform C++ (Windows x64 Release)" and add another suite "Platform C++ > (Windows x64 Debug)", which will build and run tests in Debug mode. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-10980) CPP: Create TC suite for Windows 64 Debug mode
[ https://issues.apache.org/jira/browse/IGNITE-10980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Ivanov resolved IGNITE-10980. --- Resolution: Fixed Fix Version/s: (was: 2.8) [Platform C++ (Win x64 | Debug) #1|https://ci.ignite.apache.org/viewQueued.html?itemId=2835581] > CPP: Create TC suite for Windows 64 Debug mode > -- > > Key: IGNITE-10980 > URL: https://issues.apache.org/jira/browse/IGNITE-10980 > Project: Ignite > Issue Type: Task > Components: platforms >Affects Versions: 2.7 >Reporter: Igor Sapego >Assignee: Peter Ivanov >Priority: Major > Labels: cpp > > Currently, there is a [Platform C++ (Windows > x64)|https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_PlatformCWindowsX64=buildTypeStatusDiv_IgniteTests24Java8=__all_branches__] > suite, which builds and runs tests in Release mode. It's OK, as we need to > test Release mode in the first place, as this is the mode, in which user uses > Ignite C++. But we also need to run tests in Debug mode, as in debug > additional errors (such as heap corruption and memory leaks) can be detected. > So it is proposed to rename "Platform C++ (Windows x64)" test suite to > "Platform C++ (Windows x64 Release)" and add another suite "Platform C++ > (Windows x64 Debug)", which will build and run tests in Debug mode. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10974) Node may hangs if an exception is throw from PageMemoryImpl.beforeReleaseWrite()
[
https://issues.apache.org/jira/browse/IGNITE-10974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16746315#comment-16746315
]
Dmitriy Pavlov commented on IGNITE-10974:
-
LGTM for me provided that is it approved by the Bot.
> Node may hangs if an exception is throw from
> PageMemoryImpl.beforeReleaseWrite()
>
>
> Key: IGNITE-10974
> URL: https://issues.apache.org/jira/browse/IGNITE-10974
> Project: Ignite
> Issue Type: Bug
>Reporter: Dmitriy Govorukhin
>Assignee: Dmitriy Govorukhin
>Priority: Critical
> Fix For: 2.8
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> There are situations when a node may hang during stopping. Bug in the
> PageMemoryImpl.writeUnlockPage(), this method invokes
> PageMemoryImpl.beforeReleaseWrite() which may throw a exception and
> writeUnlockPage does not release page lock, after that checkpoint try to do
> final checkpoint (if stop was gracefully) and next access for this page hangs
> on obtain write lock.
> {code:java}
> [2019-01-17 14:35:15,953][WARN ][main][root] Thread dump at 2019/01/17
> 14:35:15 UTC
> [17:35:15]W: [org.apache.ignite:ignite-core] Thread
> [name="sys-#857%failure.IoomFailureHandlerTest0%", id=931,
> state=TIMED_WAITING, blockCnt=0, waitCnt=1]
> [17:35:15]W: [org.apache.ignite:ignite-core] Lock
> [object=java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject@4339baec,
> ownerName=null, ownerId=-1]
> [17:35:15]W: [org.apache.ignite:ignite-core] at sun.misc.Unsafe.park(Native
> Method)
> [17:35:15]W: [org.apache.ignite:ignite-core] at
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
> [17:35:15]W: [org.apache.ignite:ignite-core] at
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
> [17:35:15]W: [org.apache.ignite:ignite-core] at
> java.util.concurrent.LinkedBlockingQueue.poll(LinkedBlockingQueue.java:467)
> [17:35:15]W: [org.apache.ignite:ignite-core] at
> java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1073)
> [17:35:15]W: [org.apache.ignite:ignite-core] at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134)
> [17:35:15]W: [org.apache.ignite:ignite-core] at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> [17:35:15]W: [org.apache.ignite:ignite-core] at
> java.lang.Thread.run(Thread.java:748)
> [17:35:15]W: [org.apache.ignite:ignite-core]
> [17:35:15]W: [org.apache.ignite:ignite-core] Thread
> [name="sys-#856%failure.IoomFailureHandlerTest0%", id=930,
> state=TIMED_WAITING, blockCnt=0, waitCnt=1]
> [17:35:15]W: [org.apache.ignite:ignite-core] Lock
> [object=java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject@4339baec,
> ownerName=null, ownerId=-1]
> [17:35:15]W: [org.apache.ignite:ignite-core] at sun.misc.Unsafe.park(Native
> Method)
> [17:35:15]W: [org.apache.ignite:ignite-core] at
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
> [17:35:15]W: [org.apache.ignite:ignite-core] at
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
> [17:35:15]W: [org.apache.ignite:ignite-core] at
> java.util.concurrent.LinkedBlockingQueue.poll(LinkedBlockingQueue.java:467)
> [17:35:15]W: [org.apache.ignite:ignite-core] at
> java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1073)
> [17:35:15]W: [org.apache.ignite:ignite-core] at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134)
> [17:35:15]W: [org.apache.ignite:ignite-core] at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> [17:35:15]W: [org.apache.ignite:ignite-core] at
> java.lang.Thread.run(Thread.java:748)
> [17:35:15]W: [org.apache.ignite:ignite-core]
> [17:35:15]W: [org.apache.ignite:ignite-core] Thread
> [name="sys-#855%failure.IoomFailureHandlerTest0%", id=929,
> state=TIMED_WAITING, blockCnt=0, waitCnt=1]
> [17:35:15]W: [org.apache.ignite:ignite-core] Lock
> [object=java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject@4339baec,
> ownerName=null, ownerId=-1]
> [17:35:15]W: [org.apache.ignite:ignite-core] at sun.misc.Unsafe.park(Native
> Method)
> [17:35:15]W: [org.apache.ignite:ignite-core] at
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
> [17:35:15]W: [org.apache.ignite:ignite-core] at
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
> [17:35:15]W: [org.apache.ignite:ignite-core] at
> java.util.concurrent.LinkedBlockingQueue.poll(LinkedBlockingQueue.java:467)
> [17:35:15]W:
[jira] [Created] (IGNITE-10982) Kafka Ignite connect module listen to all related cache node events, not only the source cache
Mahmoud created IGNITE-10982:
Summary: Kafka Ignite connect module listen to all related cache
node events, not only the source cache
Key: IGNITE-10982
URL: https://issues.apache.org/jira/browse/IGNITE-10982
Project: Ignite
Issue Type: Bug
Components: general
Affects Versions: 2.7
Reporter: Mahmoud
Hey All ,
I see in Kafka module , in
IgniteSourceTask.java , we listen to all target cache node events not only the
source cache event , is it by design like that ? we should only listen to the
source cache events through continuous query:
[https://apacheignite.readme.io/docs/continuous-queries]
As we current implementation , we catch all caches events the belong to the
same source cache node , not only the configured source cache name:
code snippet from : IgniteSourceTask.java
{code:java}
rmtLsnrId = IgniteGrid.getIgnite().events(IgniteGrid.getIgnite().cluster()
.forCacheNodes(cacheName))
.remoteListen(locLsnr, rmtLsnr, evts);{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10974) Node may hangs if an exception is throw from PageMemoryImpl.beforeReleaseWrite()
[
https://issues.apache.org/jira/browse/IGNITE-10974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16746310#comment-16746310
]
Dmitriy Govorukhin commented on IGNITE-10974:
-
[~dpavlov] Fixed, please take a look again.
> Node may hangs if an exception is throw from
> PageMemoryImpl.beforeReleaseWrite()
>
>
> Key: IGNITE-10974
> URL: https://issues.apache.org/jira/browse/IGNITE-10974
> Project: Ignite
> Issue Type: Bug
>Reporter: Dmitriy Govorukhin
>Assignee: Dmitriy Govorukhin
>Priority: Critical
> Fix For: 2.8
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> There are situations when a node may hang during stopping. Bug in the
> PageMemoryImpl.writeUnlockPage(), this method invokes
> PageMemoryImpl.beforeReleaseWrite() which may throw a exception and
> writeUnlockPage does not release page lock, after that checkpoint try to do
> final checkpoint (if stop was gracefully) and next access for this page hangs
> on obtain write lock.
> {code:java}
> [2019-01-17 14:35:15,953][WARN ][main][root] Thread dump at 2019/01/17
> 14:35:15 UTC
> [17:35:15]W: [org.apache.ignite:ignite-core] Thread
> [name="sys-#857%failure.IoomFailureHandlerTest0%", id=931,
> state=TIMED_WAITING, blockCnt=0, waitCnt=1]
> [17:35:15]W: [org.apache.ignite:ignite-core] Lock
> [object=java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject@4339baec,
> ownerName=null, ownerId=-1]
> [17:35:15]W: [org.apache.ignite:ignite-core] at sun.misc.Unsafe.park(Native
> Method)
> [17:35:15]W: [org.apache.ignite:ignite-core] at
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
> [17:35:15]W: [org.apache.ignite:ignite-core] at
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
> [17:35:15]W: [org.apache.ignite:ignite-core] at
> java.util.concurrent.LinkedBlockingQueue.poll(LinkedBlockingQueue.java:467)
> [17:35:15]W: [org.apache.ignite:ignite-core] at
> java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1073)
> [17:35:15]W: [org.apache.ignite:ignite-core] at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134)
> [17:35:15]W: [org.apache.ignite:ignite-core] at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> [17:35:15]W: [org.apache.ignite:ignite-core] at
> java.lang.Thread.run(Thread.java:748)
> [17:35:15]W: [org.apache.ignite:ignite-core]
> [17:35:15]W: [org.apache.ignite:ignite-core] Thread
> [name="sys-#856%failure.IoomFailureHandlerTest0%", id=930,
> state=TIMED_WAITING, blockCnt=0, waitCnt=1]
> [17:35:15]W: [org.apache.ignite:ignite-core] Lock
> [object=java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject@4339baec,
> ownerName=null, ownerId=-1]
> [17:35:15]W: [org.apache.ignite:ignite-core] at sun.misc.Unsafe.park(Native
> Method)
> [17:35:15]W: [org.apache.ignite:ignite-core] at
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
> [17:35:15]W: [org.apache.ignite:ignite-core] at
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
> [17:35:15]W: [org.apache.ignite:ignite-core] at
> java.util.concurrent.LinkedBlockingQueue.poll(LinkedBlockingQueue.java:467)
> [17:35:15]W: [org.apache.ignite:ignite-core] at
> java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1073)
> [17:35:15]W: [org.apache.ignite:ignite-core] at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134)
> [17:35:15]W: [org.apache.ignite:ignite-core] at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> [17:35:15]W: [org.apache.ignite:ignite-core] at
> java.lang.Thread.run(Thread.java:748)
> [17:35:15]W: [org.apache.ignite:ignite-core]
> [17:35:15]W: [org.apache.ignite:ignite-core] Thread
> [name="sys-#855%failure.IoomFailureHandlerTest0%", id=929,
> state=TIMED_WAITING, blockCnt=0, waitCnt=1]
> [17:35:15]W: [org.apache.ignite:ignite-core] Lock
> [object=java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject@4339baec,
> ownerName=null, ownerId=-1]
> [17:35:15]W: [org.apache.ignite:ignite-core] at sun.misc.Unsafe.park(Native
> Method)
> [17:35:15]W: [org.apache.ignite:ignite-core] at
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
> [17:35:15]W: [org.apache.ignite:ignite-core] at
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
> [17:35:15]W: [org.apache.ignite:ignite-core] at
> java.util.concurrent.LinkedBlockingQueue.poll(LinkedBlockingQueue.java:467)
> [17:35:15]W:
[jira] [Updated] (IGNITE-8532) [ML] GA Grid: Implement Roulette Wheel Selection
[ https://issues.apache.org/jira/browse/IGNITE-8532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Babak updated IGNITE-8532: --- Labels: genetics (was: ) > [ML] GA Grid: Implement Roulette Wheel Selection > > > Key: IGNITE-8532 > URL: https://issues.apache.org/jira/browse/IGNITE-8532 > Project: Ignite > Issue Type: New Feature > Components: ml >Reporter: Turik Campbell >Assignee: Yury Babak >Priority: Minor > Labels: genetics > Fix For: 2.8 > > Time Spent: 20m > Remaining Estimate: 0h > > Roulette Wheel Selection Method is a type of selection used for selecting > potentially useful solutions for recombination. This selection method gives > more chances of selection to the better performing chromosomes. > IE: > https://en.wikipedia.org/wiki/Fitness_proportionate_selection -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-6564) Incorrect calculation size and keySize for cluster cache metrics
[ https://issues.apache.org/jira/browse/IGNITE-6564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16746298#comment-16746298 ] Alexand Polyakov commented on IGNITE-6564: -- Tests wiil be broken without adding of the awaiting metrics, so these changes were included here. > Incorrect calculation size and keySize for cluster cache metrics > > > Key: IGNITE-6564 > URL: https://issues.apache.org/jira/browse/IGNITE-6564 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.2 >Reporter: Ilya Kasnacheev >Assignee: Alexand Polyakov >Priority: Minor > Labels: iep-6 > Time Spent: 50m > Remaining Estimate: 0h > > They are currently not passed by ring and therefore only taken from current > node, which returns incorrect (local) value. > See CacheMetricsSnapshot class. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8575) Change Baseline auto-adjust parameters via console.sh
[ https://issues.apache.org/jira/browse/IGNITE-8575?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Govorukhin updated IGNITE-8575: --- Fix Version/s: 2.8 > Change Baseline auto-adjust parameters via console.sh > - > > Key: IGNITE-8575 > URL: https://issues.apache.org/jira/browse/IGNITE-8575 > Project: Ignite > Issue Type: New Feature >Reporter: Eduard Shangareev >Assignee: Ivan Bessonov >Priority: Major > Labels: IEP-4, Phase-2 > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > We would introduce at IGNITE-8571 new parameters. > We need to have option change them via console.sh. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-6564) Incorrect calculation size and keySize for cluster cache metrics
[ https://issues.apache.org/jira/browse/IGNITE-6564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16746295#comment-16746295 ] Alexand Polyakov commented on IGNITE-6564: -- @[~ilyak] size return incorrect metrics, in order not to create misconceptions, zeroed, since it is impossible to delete > Incorrect calculation size and keySize for cluster cache metrics > > > Key: IGNITE-6564 > URL: https://issues.apache.org/jira/browse/IGNITE-6564 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.2 >Reporter: Ilya Kasnacheev >Assignee: Alexand Polyakov >Priority: Minor > Labels: iep-6 > Time Spent: 50m > Remaining Estimate: 0h > > They are currently not passed by ring and therefore only taken from current > node, which returns incorrect (local) value. > See CacheMetricsSnapshot class. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-6564) Incorrect calculation size and keySize for cluster cache metrics
[ https://issues.apache.org/jira/browse/IGNITE-6564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16746291#comment-16746291 ] Alexand Polyakov commented on IGNITE-6564: -- [~macrergate] ok > Incorrect calculation size and keySize for cluster cache metrics > > > Key: IGNITE-6564 > URL: https://issues.apache.org/jira/browse/IGNITE-6564 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.2 >Reporter: Ilya Kasnacheev >Assignee: Alexand Polyakov >Priority: Minor > Labels: iep-6 > Time Spent: 50m > Remaining Estimate: 0h > > They are currently not passed by ring and therefore only taken from current > node, which returns incorrect (local) value. > See CacheMetricsSnapshot class. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10981) CPP: Heap corruption when running C++ tests in Debug mode
[ https://issues.apache.org/jira/browse/IGNITE-10981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16746285#comment-16746285 ] Igor Sapego commented on IGNITE-10981: -- The root cause of the issue - is assigning value out of bonds of the allocated memory in IGNITE-10732 (see [this line|https://github.com/apache/ignite/pull/5725/files#diff-95adc73f1949d1d4405f1a8789325835R149]) > CPP: Heap corruption when running C++ tests in Debug mode > - > > Key: IGNITE-10981 > URL: https://issues.apache.org/jira/browse/IGNITE-10981 > Project: Ignite > Issue Type: Bug > Components: platforms >Affects Versions: 2.7 >Reporter: Igor Sapego >Assignee: Igor Sapego >Priority: Major > Labels: cpp > Fix For: 2.8 > > > Currently, heap corruption is detected, when any C++ test is run in Debug > mode. Need to find out the root cause and fix the issue. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10974) Node may hangs if an exception is throw from PageMemoryImpl.beforeReleaseWrite()
[
https://issues.apache.org/jira/browse/IGNITE-10974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16746284#comment-16746284
]
Dmitriy Pavlov commented on IGNITE-10974:
-
I left several comments and questions in the PR. Provided that TC bot issues a
green VISA, and comments will be addressed - I agree with the change.
> Node may hangs if an exception is throw from
> PageMemoryImpl.beforeReleaseWrite()
>
>
> Key: IGNITE-10974
> URL: https://issues.apache.org/jira/browse/IGNITE-10974
> Project: Ignite
> Issue Type: Bug
>Reporter: Dmitriy Govorukhin
>Assignee: Dmitriy Govorukhin
>Priority: Critical
> Fix For: 2.8
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> There are situations when a node may hang during stopping. Bug in the
> PageMemoryImpl.writeUnlockPage(), this method invokes
> PageMemoryImpl.beforeReleaseWrite() which may throw a exception and
> writeUnlockPage does not release page lock, after that checkpoint try to do
> final checkpoint (if stop was gracefully) and next access for this page hangs
> on obtain write lock.
> {code:java}
> [2019-01-17 14:35:15,953][WARN ][main][root] Thread dump at 2019/01/17
> 14:35:15 UTC
> [17:35:15]W: [org.apache.ignite:ignite-core] Thread
> [name="sys-#857%failure.IoomFailureHandlerTest0%", id=931,
> state=TIMED_WAITING, blockCnt=0, waitCnt=1]
> [17:35:15]W: [org.apache.ignite:ignite-core] Lock
> [object=java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject@4339baec,
> ownerName=null, ownerId=-1]
> [17:35:15]W: [org.apache.ignite:ignite-core] at sun.misc.Unsafe.park(Native
> Method)
> [17:35:15]W: [org.apache.ignite:ignite-core] at
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
> [17:35:15]W: [org.apache.ignite:ignite-core] at
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
> [17:35:15]W: [org.apache.ignite:ignite-core] at
> java.util.concurrent.LinkedBlockingQueue.poll(LinkedBlockingQueue.java:467)
> [17:35:15]W: [org.apache.ignite:ignite-core] at
> java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1073)
> [17:35:15]W: [org.apache.ignite:ignite-core] at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134)
> [17:35:15]W: [org.apache.ignite:ignite-core] at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> [17:35:15]W: [org.apache.ignite:ignite-core] at
> java.lang.Thread.run(Thread.java:748)
> [17:35:15]W: [org.apache.ignite:ignite-core]
> [17:35:15]W: [org.apache.ignite:ignite-core] Thread
> [name="sys-#856%failure.IoomFailureHandlerTest0%", id=930,
> state=TIMED_WAITING, blockCnt=0, waitCnt=1]
> [17:35:15]W: [org.apache.ignite:ignite-core] Lock
> [object=java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject@4339baec,
> ownerName=null, ownerId=-1]
> [17:35:15]W: [org.apache.ignite:ignite-core] at sun.misc.Unsafe.park(Native
> Method)
> [17:35:15]W: [org.apache.ignite:ignite-core] at
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
> [17:35:15]W: [org.apache.ignite:ignite-core] at
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
> [17:35:15]W: [org.apache.ignite:ignite-core] at
> java.util.concurrent.LinkedBlockingQueue.poll(LinkedBlockingQueue.java:467)
> [17:35:15]W: [org.apache.ignite:ignite-core] at
> java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1073)
> [17:35:15]W: [org.apache.ignite:ignite-core] at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134)
> [17:35:15]W: [org.apache.ignite:ignite-core] at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> [17:35:15]W: [org.apache.ignite:ignite-core] at
> java.lang.Thread.run(Thread.java:748)
> [17:35:15]W: [org.apache.ignite:ignite-core]
> [17:35:15]W: [org.apache.ignite:ignite-core] Thread
> [name="sys-#855%failure.IoomFailureHandlerTest0%", id=929,
> state=TIMED_WAITING, blockCnt=0, waitCnt=1]
> [17:35:15]W: [org.apache.ignite:ignite-core] Lock
> [object=java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject@4339baec,
> ownerName=null, ownerId=-1]
> [17:35:15]W: [org.apache.ignite:ignite-core] at sun.misc.Unsafe.park(Native
> Method)
> [17:35:15]W: [org.apache.ignite:ignite-core] at
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
> [17:35:15]W: [org.apache.ignite:ignite-core] at
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
> [17:35:15]W: [org.apache.ignite:ignite-core] at
>
[jira] [Assigned] (IGNITE-10980) CPP: Create TC suite for Windows 64 Debug mode
[ https://issues.apache.org/jira/browse/IGNITE-10980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Ivanov reassigned IGNITE-10980: - Assignee: Peter Ivanov > CPP: Create TC suite for Windows 64 Debug mode > -- > > Key: IGNITE-10980 > URL: https://issues.apache.org/jira/browse/IGNITE-10980 > Project: Ignite > Issue Type: Task > Components: platforms >Affects Versions: 2.7 >Reporter: Igor Sapego >Assignee: Peter Ivanov >Priority: Major > Labels: cpp > Fix For: 2.8 > > > Currently, there is a [Platform C++ (Windows > x64)|https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_PlatformCWindowsX64=buildTypeStatusDiv_IgniteTests24Java8=__all_branches__] > suite, which builds and runs tests in Release mode. It's OK, as we need to > test Release mode in the first place, as this is the mode, in which user uses > Ignite C++. But we also need to run tests in Debug mode, as in debug > additional errors (such as heap corruption and memory leaks) can be detected. > So it is proposed to rename "Platform C++ (Windows x64)" test suite to > "Platform C++ (Windows x64 Release)" and add another suite "Platform C++ > (Windows x64 Debug)", which will build and run tests in Debug mode. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10981) CPP: Heap corruption when running C++ tests in Debug mode
[ https://issues.apache.org/jira/browse/IGNITE-10981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16746279#comment-16746279 ] Igor Sapego commented on IGNITE-10981: -- Need to add TC suite in Debug mode to detect such issues early. > CPP: Heap corruption when running C++ tests in Debug mode > - > > Key: IGNITE-10981 > URL: https://issues.apache.org/jira/browse/IGNITE-10981 > Project: Ignite > Issue Type: Bug > Components: platforms >Affects Versions: 2.7 >Reporter: Igor Sapego >Assignee: Igor Sapego >Priority: Major > Labels: cpp > Fix For: 2.8 > > > Currently, heap corruption is detected, when any C++ test is run in Debug > mode. Need to find out the root cause and fix the issue. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10981) CPP: Heap corruption when running C++ tests in Debug mode
Igor Sapego created IGNITE-10981: Summary: CPP: Heap corruption when running C++ tests in Debug mode Key: IGNITE-10981 URL: https://issues.apache.org/jira/browse/IGNITE-10981 Project: Ignite Issue Type: Bug Components: platforms Affects Versions: 2.7 Reporter: Igor Sapego Assignee: Igor Sapego Fix For: 2.8 Currently, heap corruption is detected, when any C++ test is run in Debug mode. Need to find out the root cause and fix the issue. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10981) CPP: Heap corruption when running C++ tests in Debug mode
[ https://issues.apache.org/jira/browse/IGNITE-10981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Sapego updated IGNITE-10981: - Ignite Flags: (was: Docs Required) > CPP: Heap corruption when running C++ tests in Debug mode > - > > Key: IGNITE-10981 > URL: https://issues.apache.org/jira/browse/IGNITE-10981 > Project: Ignite > Issue Type: Bug > Components: platforms >Affects Versions: 2.7 >Reporter: Igor Sapego >Assignee: Igor Sapego >Priority: Major > Labels: cpp > Fix For: 2.8 > > > Currently, heap corruption is detected, when any C++ test is run in Debug > mode. Need to find out the root cause and fix the issue. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10980) CPP: Create TC suite for Windows 64 Debug mode
Igor Sapego created IGNITE-10980: Summary: CPP: Create TC suite for Windows 64 Debug mode Key: IGNITE-10980 URL: https://issues.apache.org/jira/browse/IGNITE-10980 Project: Ignite Issue Type: Task Components: platforms Affects Versions: 2.7 Reporter: Igor Sapego Fix For: 2.8 Currently, there is a [Platform C++ (Windows x64)|https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_PlatformCWindowsX64=buildTypeStatusDiv_IgniteTests24Java8=__all_branches__] suite, which builds and runs tests in Release mode. It's OK, as we need to test Release mode in the first place, as this is the mode, in which user uses Ignite C++. But we also need to run tests in Debug mode, as in debug additional errors (such as heap corruption and memory leaks) can be detected. So it is proposed to rename "Platform C++ (Windows x64)" test suite to "Platform C++ (Windows x64 Release)" and add another suite "Platform C++ (Windows x64 Debug)", which will build and run tests in Debug mode. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10740) Add documentation for IGNITE_DISABLE_TRIGGERING_CACHE_INTERCEPTOR_ON_CONFLICT
[
https://issues.apache.org/jira/browse/IGNITE-10740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16746264#comment-16746264
]
Sergey Antonov commented on IGNITE-10740:
-
[~Artem Budnikov] DR is a Datacenter Replication. In case of update was got by
DR (from another DC (datacenter)) and interceptor is non-idempotent we could
broke users data. So we should disable cache interceptor for this updates.
> Add documentation for IGNITE_DISABLE_TRIGGERING_CACHE_INTERCEPTOR_ON_CONFLICT
> -
>
> Key: IGNITE-10740
> URL: https://issues.apache.org/jira/browse/IGNITE-10740
> Project: Ignite
> Issue Type: Task
> Components: documentation
>Reporter: Sergey Antonov
>Assignee: Artem Budnikov
>Priority: Major
> Fix For: 2.8
>
>
> We should add to documentation
> IGNITE_DISABLE_TRIGGERING_CACHE_INTERCEPTOR_ON_CONFLICT option.
> As a reference you could get javadoc from skipInterceptor() :
> {{Checks, that cache interceptor should be skipped. It is expects by default
> behavior that Interceptor methods (\{@link
> CacheInterceptor#onBeforePut(Cache.Entry, Object)}, \{@link
> CacheInterceptor#onAfterPut(Cache.Entry)}, \{@link
> CacheInterceptor#onBeforeRemove(Cache.Entry)} and \{@link
> CacheInterceptor#onAfterRemove(Cache.Entry)}) will be called, but \{@link
> CacheInterceptor#onGet(Object, Object)}. This can even make DR-update flow
> broken in case of non-idempotent Interceptor and force users to call onGet
> manually as the only workaround. Also, user may want to skip Interceptor to
> avoid redundant entry transformation for DR updates and exchange with
> internal data b/w data centres which is a normal case.}}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10979) Add documentation for control.sh idle_verify --check-crc
Sergey Antonov created IGNITE-10979: --- Summary: Add documentation for control.sh idle_verify --check-crc Key: IGNITE-10979 URL: https://issues.apache.org/jira/browse/IGNITE-10979 Project: Ignite Issue Type: New Feature Components: documentation Reporter: Sergey Antonov Assignee: Artem Budnikov Fix For: 2.8 We should document new option --check-crc in control.sh idle_verify command. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-10978) Remove unused tests marked with unclear todo
[
https://issues.apache.org/jira/browse/IGNITE-10978?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Pavlov reassigned IGNITE-10978:
---
Assignee: (was: Dmitriy Pavlov)
> Remove unused tests marked with unclear todo
>
>
> Key: IGNITE-10978
> URL: https://issues.apache.org/jira/browse/IGNITE-10978
> Project: Ignite
> Issue Type: Task
>Reporter: Dmitriy Pavlov
>Priority: Major
> Labels: newbie
>
> {noformat}
> IgniteCacheTestSuite3
> // TODO GG-11141.
> //
> GridTestUtils.addTestIfNeeded(suite,GridCacheDeploymentSelfTest.class,
> ignoredTests);
> //
> GridTestUtils.addTestIfNeeded(suite,GridCacheDeploymentOffHeapSelfTest.class,
> ignoredTests);
> //
> GridTestUtils.addTestIfNeeded(suite,GridCacheDeploymentOffHeapValuesSelfTest.class,
> ignoredTests);
> IgniteCacheInterceptorSelfTestSuite
> // TODO GG-11141.
> //
> GridTestUtils.addTestIfNeeded(suite,GridCacheOnCopyFlagTxPartitionedSelfTest.class,
> ignoredTests);
> //
> GridTestUtils.addTestIfNeeded(suite,GridCacheOnCopyFlagReplicatedSelfTest.class,
> ignoredTests);
> //
> GridTestUtils.addTestIfNeeded(suite,GridCacheOnCopyFlagLocalSelfTest.class,
> ignoredTests);
> //
> GridTestUtils.addTestIfNeeded(suite,GridCacheOnCopyFlagAtomicSelfTest.class,
> ignoredTests);
> {noformat}
> Test classes not used, so there is no reason to keep it
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10978) Remove unused tests marked with unclear todo
[
https://issues.apache.org/jira/browse/IGNITE-10978?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Pavlov updated IGNITE-10978:
Description:
{noformat}
IgniteCacheTestSuite3
// TODO GG-11141.
//
GridTestUtils.addTestIfNeeded(suite,GridCacheDeploymentSelfTest.class,
ignoredTests);
//
GridTestUtils.addTestIfNeeded(suite,GridCacheDeploymentOffHeapSelfTest.class,
ignoredTests);
//
GridTestUtils.addTestIfNeeded(suite,GridCacheDeploymentOffHeapValuesSelfTest.class,
ignoredTests);
IgniteCacheInterceptorSelfTestSuite
// TODO GG-11141.
//
GridTestUtils.addTestIfNeeded(suite,GridCacheOnCopyFlagTxPartitionedSelfTest.class,
ignoredTests);
//
GridTestUtils.addTestIfNeeded(suite,GridCacheOnCopyFlagReplicatedSelfTest.class,
ignoredTests);
//
GridTestUtils.addTestIfNeeded(suite,GridCacheOnCopyFlagLocalSelfTest.class,
ignoredTests);
//
GridTestUtils.addTestIfNeeded(suite,GridCacheOnCopyFlagAtomicSelfTest.class,
ignoredTests);
{noformat}
Test classes not used, so there is no reason to keep it
was:
{noformat}
// TODO GG-11141.
//
GridTestUtils.addTestIfNeeded(suite,GridCacheOnCopyFlagTxPartitionedSelfTest.class,
ignoredTests);
//
GridTestUtils.addTestIfNeeded(suite,GridCacheOnCopyFlagReplicatedSelfTest.class,
ignoredTests);
//
GridTestUtils.addTestIfNeeded(suite,GridCacheOnCopyFlagLocalSelfTest.class,
ignoredTests);
//
GridTestUtils.addTestIfNeeded(suite,GridCacheOnCopyFlagAtomicSelfTest.class,
ignoredTests);
{noformat}
Test classes not used, so there is no reason to keep it
> Remove unused tests marked with unclear todo
>
>
> Key: IGNITE-10978
> URL: https://issues.apache.org/jira/browse/IGNITE-10978
> Project: Ignite
> Issue Type: Task
>Reporter: Dmitriy Pavlov
>Assignee: Dmitriy Pavlov
>Priority: Major
> Labels: newbie
>
> {noformat}
> IgniteCacheTestSuite3
> // TODO GG-11141.
> //
> GridTestUtils.addTestIfNeeded(suite,GridCacheDeploymentSelfTest.class,
> ignoredTests);
> //
> GridTestUtils.addTestIfNeeded(suite,GridCacheDeploymentOffHeapSelfTest.class,
> ignoredTests);
> //
> GridTestUtils.addTestIfNeeded(suite,GridCacheDeploymentOffHeapValuesSelfTest.class,
> ignoredTests);
> IgniteCacheInterceptorSelfTestSuite
> // TODO GG-11141.
> //
> GridTestUtils.addTestIfNeeded(suite,GridCacheOnCopyFlagTxPartitionedSelfTest.class,
> ignoredTests);
> //
> GridTestUtils.addTestIfNeeded(suite,GridCacheOnCopyFlagReplicatedSelfTest.class,
> ignoredTests);
> //
> GridTestUtils.addTestIfNeeded(suite,GridCacheOnCopyFlagLocalSelfTest.class,
> ignoredTests);
> //
> GridTestUtils.addTestIfNeeded(suite,GridCacheOnCopyFlagAtomicSelfTest.class,
> ignoredTests);
> {noformat}
> Test classes not used, so there is no reason to keep it
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10978) Remove unused tests marked with unclear todo
[
https://issues.apache.org/jira/browse/IGNITE-10978?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Pavlov updated IGNITE-10978:
Labels: newbie (was: )
> Remove unused tests marked with unclear todo
>
>
> Key: IGNITE-10978
> URL: https://issues.apache.org/jira/browse/IGNITE-10978
> Project: Ignite
> Issue Type: Task
>Reporter: Dmitriy Pavlov
>Assignee: Dmitriy Pavlov
>Priority: Major
> Labels: newbie
>
> {noformat}
> // TODO GG-11141.
> //
> GridTestUtils.addTestIfNeeded(suite,GridCacheOnCopyFlagTxPartitionedSelfTest.class,
> ignoredTests);
> //
> GridTestUtils.addTestIfNeeded(suite,GridCacheOnCopyFlagReplicatedSelfTest.class,
> ignoredTests);
> //
> GridTestUtils.addTestIfNeeded(suite,GridCacheOnCopyFlagLocalSelfTest.class,
> ignoredTests);
> //
> GridTestUtils.addTestIfNeeded(suite,GridCacheOnCopyFlagAtomicSelfTest.class,
> ignoredTests);
> {noformat}
> Test classes not used, so there is no reason to keep it
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10978) Remove unused tests marked with unclear todo
Dmitriy Pavlov created IGNITE-10978:
---
Summary: Remove unused tests marked with unclear todo
Key: IGNITE-10978
URL: https://issues.apache.org/jira/browse/IGNITE-10978
Project: Ignite
Issue Type: Task
Reporter: Dmitriy Pavlov
Assignee: Dmitriy Pavlov
{noformat}
// TODO GG-11141.
//
GridTestUtils.addTestIfNeeded(suite,GridCacheOnCopyFlagTxPartitionedSelfTest.class,
ignoredTests);
//
GridTestUtils.addTestIfNeeded(suite,GridCacheOnCopyFlagReplicatedSelfTest.class,
ignoredTests);
//
GridTestUtils.addTestIfNeeded(suite,GridCacheOnCopyFlagLocalSelfTest.class,
ignoredTests);
//
GridTestUtils.addTestIfNeeded(suite,GridCacheOnCopyFlagAtomicSelfTest.class,
ignoredTests);
{noformat}
Test classes not used, so there is no reason to keep it
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-6564) Incorrect calculation size and keySize for cluster cache metrics
[ https://issues.apache.org/jira/browse/IGNITE-6564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16746250#comment-16746250 ] Sergey Kosarev commented on IGNITE-6564: [~a-polyakov], don't you mind If I fix isssues mentioned by Ilya? > Incorrect calculation size and keySize for cluster cache metrics > > > Key: IGNITE-6564 > URL: https://issues.apache.org/jira/browse/IGNITE-6564 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.2 >Reporter: Ilya Kasnacheev >Assignee: Alexand Polyakov >Priority: Minor > Labels: iep-6 > Time Spent: 40m > Remaining Estimate: 0h > > They are currently not passed by ring and therefore only taken from current > node, which returns incorrect (local) value. > See CacheMetricsSnapshot class. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10648) Ignite hang to stop if node wasn't started completely. GridTcpRestNioListener hangs on latch.
[ https://issues.apache.org/jira/browse/IGNITE-10648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16746248#comment-16746248 ] Alexey Goncharuk commented on IGNITE-10648: --- [~v.pyatkov], thanks, ok with me now. Will merge the ticket shortly. > Ignite hang to stop if node wasn't started completely. GridTcpRestNioListener > hangs on latch. > - > > Key: IGNITE-10648 > URL: https://issues.apache.org/jira/browse/IGNITE-10648 > Project: Ignite > Issue Type: Bug >Reporter: Pavel Voronkin >Assignee: Vladislav Pyatkov >Priority: Major > Fix For: 2.8 > > > If Ignition.start waits on rebalance then GridRestProcessor is not started > yet then we call Ingition.stop and > GridTcpRestNioListener hangs on > if (marshMapLatch.getCount() > 0) > U.awaitQuiet(marshMapLatch); > cause wasn't counted down on start. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10648) Ignite hang to stop if node wasn't started completely. GridTcpRestNioListener hangs on latch.
[ https://issues.apache.org/jira/browse/IGNITE-10648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16746245#comment-16746245 ] Vladislav Pyatkov commented on IGNITE-10648: Test passed on TC - Ok https://ci.ignite.apache.org/viewLog.html?buildId=2834713=IgniteTests24Java8_Cache1=testsInfo_IgniteTests24Java8=pull%2F5710%2Fhead > Ignite hang to stop if node wasn't started completely. GridTcpRestNioListener > hangs on latch. > - > > Key: IGNITE-10648 > URL: https://issues.apache.org/jira/browse/IGNITE-10648 > Project: Ignite > Issue Type: Bug >Reporter: Pavel Voronkin >Assignee: Vladislav Pyatkov >Priority: Major > Fix For: 2.8 > > > If Ignition.start waits on rebalance then GridRestProcessor is not started > yet then we call Ingition.stop and > GridTcpRestNioListener hangs on > if (marshMapLatch.getCount() > 0) > U.awaitQuiet(marshMapLatch); > cause wasn't counted down on start. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10740) Add documentation for IGNITE_DISABLE_TRIGGERING_CACHE_INTERCEPTOR_ON_CONFLICT
[
https://issues.apache.org/jira/browse/IGNITE-10740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16746236#comment-16746236
]
Artem Budnikov commented on IGNITE-10740:
-
[~antonovsergey93]
I'm not sure I understand what this option does from the end user standpoint.
Why would one want to configure interceptors and then disable them using this
option?
What does DR stand for in this context?
> Add documentation for IGNITE_DISABLE_TRIGGERING_CACHE_INTERCEPTOR_ON_CONFLICT
> -
>
> Key: IGNITE-10740
> URL: https://issues.apache.org/jira/browse/IGNITE-10740
> Project: Ignite
> Issue Type: Task
> Components: documentation
>Reporter: Sergey Antonov
>Assignee: Artem Budnikov
>Priority: Major
> Fix For: 2.8
>
>
> We should add to documentation
> IGNITE_DISABLE_TRIGGERING_CACHE_INTERCEPTOR_ON_CONFLICT option.
> As a reference you could get javadoc from skipInterceptor() :
> {{Checks, that cache interceptor should be skipped. It is expects by default
> behavior that Interceptor methods (\{@link
> CacheInterceptor#onBeforePut(Cache.Entry, Object)}, \{@link
> CacheInterceptor#onAfterPut(Cache.Entry)}, \{@link
> CacheInterceptor#onBeforeRemove(Cache.Entry)} and \{@link
> CacheInterceptor#onAfterRemove(Cache.Entry)}) will be called, but \{@link
> CacheInterceptor#onGet(Object, Object)}. This can even make DR-update flow
> broken in case of non-idempotent Interceptor and force users to call onGet
> manually as the only workaround. Also, user may want to skip Interceptor to
> avoid redundant entry transformation for DR updates and exchange with
> internal data b/w data centres which is a normal case.}}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10977) Document unsupported clear() call for MVCC caches
[
https://issues.apache.org/jira/browse/IGNITE-10977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Pavlukhin updated IGNITE-10977:
Description: Now MVCC caches don't support {{cache.clear()}} by design. So
let's document it as a known limitations (I suppose we should have such page on
readme.io) (was: Now MVCC caches don't support {{cache.clean()}} by design. So
let's document it as a known limitations (I suppose we should have such page on
readme.io))
> Document unsupported clear() call for MVCC caches
> -
>
> Key: IGNITE-10977
> URL: https://issues.apache.org/jira/browse/IGNITE-10977
> Project: Ignite
> Issue Type: Task
> Components: documentation
>Affects Versions: 2.7
>Reporter: Sergey Kozlov
>Priority: Major
> Fix For: 2.8
>
>
> Now MVCC caches don't support {{cache.clear()}} by design. So let's document
> it as a known limitations (I suppose we should have such page on readme.io)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10977) Document unsupported clear() call for MVCC caches
[
https://issues.apache.org/jira/browse/IGNITE-10977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Pavlukhin updated IGNITE-10977:
Summary: Document unsupported clear() call for MVCC caches (was: Document
unsupported clean() call for MVCC caches)
> Document unsupported clear() call for MVCC caches
> -
>
> Key: IGNITE-10977
> URL: https://issues.apache.org/jira/browse/IGNITE-10977
> Project: Ignite
> Issue Type: Task
> Components: documentation
>Affects Versions: 2.7
>Reporter: Sergey Kozlov
>Priority: Major
> Fix For: 2.8
>
>
> Now MVCC caches don't support {{cache.clean()}} by design. So let's document
> it as a known limitations (I suppose we should have such page on readme.io)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (IGNITE-10942) [TC Bot] Optimize background JIRA tickets sync
[ https://issues.apache.org/jira/browse/IGNITE-10942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov resolved IGNITE-10942. - Resolution: Fixed Done in V190118 > [TC Bot] Optimize background JIRA tickets sync > -- > > Key: IGNITE-10942 > URL: https://issues.apache.org/jira/browse/IGNITE-10942 > Project: Ignite > Issue Type: Task >Reporter: Dmitriy Pavlov >Assignee: Dmitriy Pavlov >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > JIRA sync is now performed in not an efficient manner. > All project data is reloaded every 15 minutes, and this may create additional > pressure for 3rd party services. > Introduce incremental updates (update is running only until the first > non-modified element found) and full updates. > Check ticket data modification before saving into Ignite DB (will safe WAL & > page store pressure). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10977) Document unsupported clean() call for MVCC caches
Sergey Kozlov created IGNITE-10977:
--
Summary: Document unsupported clean() call for MVCC caches
Key: IGNITE-10977
URL: https://issues.apache.org/jira/browse/IGNITE-10977
Project: Ignite
Issue Type: Task
Components: documentation
Affects Versions: 2.7
Reporter: Sergey Kozlov
Fix For: 2.8
Now MVCC caches don't support {{cache.clean()}} by design. So let's document it
as a known limitations (I suppose we should have such page on readme.io)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10648) Ignite hang to stop if node wasn't started completely. GridTcpRestNioListener hangs on latch.
[
https://issues.apache.org/jira/browse/IGNITE-10648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16746222#comment-16746222
]
Vladislav Pyatkov commented on IGNITE-10648:
[~agoncharuk], thank for the comment.
I have reduced test execution time four times.
About a lot of warning: Yes, this is supposed behavior, because it the test
blocks rebalancing procedure, until {{GirdClient}} has not connected.
I modified timeout ({{SystemWorkerBlockedTimeout}}) for to hid warnings.
Look at rerun Cache1 suit:
https://ci.ignite.apache.org/viewLog.html?buildId=2834713=IgniteTests24Java8_Cache1
> Ignite hang to stop if node wasn't started completely. GridTcpRestNioListener
> hangs on latch.
> -
>
> Key: IGNITE-10648
> URL: https://issues.apache.org/jira/browse/IGNITE-10648
> Project: Ignite
> Issue Type: Bug
>Reporter: Pavel Voronkin
>Assignee: Vladislav Pyatkov
>Priority: Major
> Fix For: 2.8
>
>
> If Ignition.start waits on rebalance then GridRestProcessor is not started
> yet then we call Ingition.stop and
> GridTcpRestNioListener hangs on
> if (marshMapLatch.getCount() > 0)
> U.awaitQuiet(marshMapLatch);
> cause wasn't counted down on start.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10183) [Test Failed] IgniteClientReconnectCacheTest.testReconnectOperationInProgress flaky fails on TC.
[
https://issues.apache.org/jira/browse/IGNITE-10183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16746183#comment-16746183
]
Roman Kondakov commented on IGNITE-10183:
-
[~gvvinblade], please review the patch. TC looks good.
> [Test Failed] IgniteClientReconnectCacheTest.testReconnectOperationInProgress
> flaky fails on TC.
>
>
> Key: IGNITE-10183
> URL: https://issues.apache.org/jira/browse/IGNITE-10183
> Project: Ignite
> Issue Type: Bug
> Components: cache, mvcc
>Affects Versions: 2.7
>Reporter: Pavel Pereslegin
>Assignee: Roman Kondakov
>Priority: Major
> Labels: MakeTeamcityGreenAgain, failover,
> mvcc_stabilization_stage_1
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> IgniteClientReconnectCacheTest.testReconnectOperationInProgress fails
> sometimes in master (see [recent failures on
> TC|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8==testDetails=-1285534571845460301=TEST_STATUS_DESC_IgniteTests24Java8=%3Cdefault%3E=50]).
> Test fails only for cache with {{TRANSACTIONAL_SNAPSHOT}} atomicity mode.
> Typical output:
> {noformat}
> [2018-11-07 23:13:00,579][ERROR][main][root] Test failed.
> class org.apache.ignite.IgniteCheckedException: class
> org.apache.ignite.transactions.TransactionRollbackException: Transaction has
> been rolled back: 2e10370f661--0920-4f4e--0026
> at org.apache.ignite.internal.util.IgniteUtils.cast(IgniteUtils.java:7425)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.resolve(GridFutureAdapter.java:261)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:191)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:141)
> at
> org.apache.ignite.internal.IgniteClientReconnectCacheTest.checkOperationInProgressFails(IgniteClientReconnectCacheTest.java:1421)
> at
> org.apache.ignite.internal.IgniteClientReconnectCacheTest.testReconnectOperationInProgress(IgniteClientReconnectCacheTest.java:869)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2208)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:144)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:2124)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: javax.cache.CacheException: class
> org.apache.ignite.transactions.TransactionRollbackException: Transaction has
> been rolled back: 2e10370f661--0920-4f4e--0026
> at
> org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1337)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.cacheException(IgniteCacheProxyImpl.java:1756)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.put(IgniteCacheProxyImpl.java:1108)
> at
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.put(GatewayProtectedCacheProxy.java:820)
> at
> org.apache.ignite.internal.IgniteClientReconnectCacheTest$10.apply(IgniteClientReconnectCacheTest.java:834)
> at
> org.apache.ignite.internal.IgniteClientReconnectCacheTest$10.apply(IgniteClientReconnectCacheTest.java:832)
> at
> org.apache.ignite.internal.IgniteClientReconnectCacheTest$25.call(IgniteClientReconnectCacheTest.java:1406)
> at
> org.apache.ignite.testframework.GridTestUtils.lambda$runAsync$2(GridTestUtils.java:1003)
> at
> org.apache.ignite.testframework.GridTestUtils$7.call(GridTestUtils.java:1299)
> at
> org.apache.ignite.testframework.GridTestThread.run(GridTestThread.java:84)
> Caused by: class org.apache.ignite.transactions.TransactionRollbackException:
> Transaction has been rolled back:
> 2e10370f661--0920-4f4e--0026
> at
> org.apache.ignite.internal.util.IgniteUtils$11.apply(IgniteUtils.java:922)
> at
> org.apache.ignite.internal.util.IgniteUtils$11.apply(IgniteUtils.java:920)
> ... 10 more
> Caused by: class
> org.apache.ignite.internal.transactions.IgniteTxRollbackCheckedException:
> Transaction has been rolled back:
> 2e10370f661--0920-4f4e--0026
> at
>
[jira] [Created] (IGNITE-10976) MVCC: Sql API methods should throws proper TransactionExceptions in case of tx failure.
Andrew Mashenkov created IGNITE-10976: - Summary: MVCC: Sql API methods should throws proper TransactionExceptions in case of tx failure. Key: IGNITE-10976 URL: https://issues.apache.org/jira/browse/IGNITE-10976 Project: Ignite Issue Type: Bug Components: mvcc, sql Reporter: Andrew Mashenkov Fix For: 2.8 For now Sql API can throws SqlException (without any actual Tx failure cause) or TransactionException wrapped into CacheException. Also, I've found we convert unchecked exceptions into checked ones and then back without any obvious reason. Let's make TransactionException thows properly and add it to Sql Api contract. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10087) IgniteClientReconnectMassiveShutdownTest.testMassiveServersShutdown1 is flaky in master
[
https://issues.apache.org/jira/browse/IGNITE-10087?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16746187#comment-16746187
]
Amelchev Nikita commented on IGNITE-10087:
--
One of a problem was resolved in IGNITE-5115 (coordinator failing).
I have fixed the test issues:
1. Client node disconnected issue. Getting retry future can throw
{{IgniteClientDisconnectedException}}. I wrote the {{getRetryFuture}} method
and use it in the client future.
2. the {{awaitPartitionMapExchange()}} can throw "Grid is in invalid state -
node stopping). I added additional checks for servers stopped.
3. Redundant code cleanup.
I have tested the test locally and [on
TC|https://ci.ignite.apache.org/viewLog.html?buildId=2825701=testsInfo=IgniteTests24Java8_Spi]
more than 100 times.
The test can fail with a problem that described in IGNITE-1758 (less 5% fail
rate).
Can anyone review the test changes?
> IgniteClientReconnectMassiveShutdownTest.testMassiveServersShutdown1 is flaky
> in master
> ---
>
> Key: IGNITE-10087
> URL: https://issues.apache.org/jira/browse/IGNITE-10087
> Project: Ignite
> Issue Type: Bug
>Reporter: Amelchev Nikita
>Assignee: Amelchev Nikita
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.8
>
>
> The IgniteClientReconnectMassiveShutdownTest.testMassiveServersShutdown1 test
> is flaky in master. Sometimes the test fails on test timeout (5 min).
> [Test
> history.|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-6728945354254258306==testDetails]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-10768) MVCC: CacheMvccBasicContinuousQueryTest.testUpdateCountersGapClosedSimplePartitioned may hang
[
https://issues.apache.org/jira/browse/IGNITE-10768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roman Kondakov reassigned IGNITE-10768:
---
Assignee: Roman Kondakov
> MVCC:
> CacheMvccBasicContinuousQueryTest.testUpdateCountersGapClosedSimplePartitioned
> may hang
> -
>
> Key: IGNITE-10768
> URL: https://issues.apache.org/jira/browse/IGNITE-10768
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Reporter: Roman Kondakov
>Assignee: Roman Kondakov
>Priority: Major
> Labels: CQ, mvcc_stabilization_stage_1
> Fix For: 2.8
>
>
> Test
> {{CacheMvccBasicContinuousQueryTest.testUpdateCountersGapClosedSimplePartitioned}}
> may hang sometimes.
>
> {noformat}
> Thread [name="test-runner-#209301%mvcc.CacheMvccBasicContinuousQueryTest%",
> id=228123, state=WAITING, blockCnt=5, waitCnt=89]
> at sun.misc.Unsafe.park(Native Method)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
> at
> o.a.i.i.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:179)
> at
> o.a.i.i.util.future.GridFutureAdapter.get(GridFutureAdapter.java:142)
> at
> o.a.i.i.processors.cache.mvcc.CacheMvccBasicContinuousQueryTest.checkUpdateCountersGapIsProcessedSimple(CacheMvccBasicContinuousQueryTest.java:346)
> at
> o.a.i.i.processors.cache.mvcc.CacheMvccBasicContinuousQueryTest.testUpdateCountersGapClosedSimplePartitioned(CacheMvccBasicContinuousQueryTest.java:257)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
> at
> o.a.i.testframework.junits.GridAbstractTest$7.run(GridAbstractTest.java:2121)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-10769) MVCC: CacheMvccContinuousQueryClientTest.testNodeJoinsRestartQuery fails sometimes
[
https://issues.apache.org/jira/browse/IGNITE-10769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roman Kondakov reassigned IGNITE-10769:
---
Assignee: Roman Kondakov
> MVCC: CacheMvccContinuousQueryClientTest.testNodeJoinsRestartQuery fails
> sometimes
> --
>
> Key: IGNITE-10769
> URL: https://issues.apache.org/jira/browse/IGNITE-10769
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Reporter: Roman Kondakov
>Assignee: Roman Kondakov
>Priority: Major
> Labels: CQ, mvcc_stabilization_stage_1
> Fix For: 2.8
>
>
> Test {{CacheMvccContinuousQueryClientTest.testNodeJoinsRestartQuery}} fails
> sometimes.
> {noformat}
> class org.apache.ignite.IgniteException: Unable to find 1 requied keys.
> at
> org.apache.ignite.testframework.junits.common.GridCommonAbstractTest.findKeys(GridCommonAbstractTest.java:1128)
> at
> org.apache.ignite.testframework.junits.common.GridCommonAbstractTest.primaryKeys(GridCommonAbstractTest.java:1071)
> at
> org.apache.ignite.testframework.junits.common.GridCommonAbstractTest.primaryKey(GridCommonAbstractTest.java:1343)
> at
> org.apache.ignite.internal.processors.cache.query.continuous.IgniteCacheContinuousQueryClientTest.testNodeJoinsRestartQuery(IgniteCacheContinuousQueryClientTest.java:185)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.access$001(GridAbstractTest.java:149)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$6.evaluate(GridAbstractTest.java:2106)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$7.run(GridAbstractTest.java:2123)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10976) MVCC: Sql API methods should throws proper TransactionExceptions in case of tx failure.
[ https://issues.apache.org/jira/browse/IGNITE-10976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Mashenkov updated IGNITE-10976: -- Ignite Flags: (was: Docs Required) > MVCC: Sql API methods should throws proper TransactionExceptions in case of > tx failure. > --- > > Key: IGNITE-10976 > URL: https://issues.apache.org/jira/browse/IGNITE-10976 > Project: Ignite > Issue Type: Bug > Components: mvcc, sql >Reporter: Andrew Mashenkov >Priority: Major > Fix For: 2.8 > > > For now Sql API can throws SqlException (without any actual Tx failure cause) > or TransactionException wrapped into CacheException. > Also, I've found we convert unchecked exceptions into checked ones and then > back without any obvious reason. > Let's make TransactionException thows properly and add it to Sql Api contract. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-10976) MVCC: Sql API methods should throws proper TransactionExceptions in case of tx failure.
[ https://issues.apache.org/jira/browse/IGNITE-10976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Mashenkov reassigned IGNITE-10976: - Assignee: Andrew Mashenkov > MVCC: Sql API methods should throws proper TransactionExceptions in case of > tx failure. > --- > > Key: IGNITE-10976 > URL: https://issues.apache.org/jira/browse/IGNITE-10976 > Project: Ignite > Issue Type: Bug > Components: mvcc, sql >Reporter: Andrew Mashenkov >Assignee: Andrew Mashenkov >Priority: Major > Fix For: 2.8 > > > For now Sql API can throws SqlException (without any actual Tx failure cause) > or TransactionException wrapped into CacheException. > Also, I've found we convert unchecked exceptions into checked ones and then > back without any obvious reason. > Let's make TransactionException thows properly and add it to Sql Api contract. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10753) MVCC: Sometimes vacuum does not cleanup all outdated versions
[
https://issues.apache.org/jira/browse/IGNITE-10753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16746182#comment-16746182
]
Roman Kondakov commented on IGNITE-10753:
-
[~gvvinblade], the patch is ready for review. Tests look good. Mvcc cache suite
has the same fails in the master branch.
> MVCC: Sometimes vacuum does not cleanup all outdated versions
> -
>
> Key: IGNITE-10753
> URL: https://issues.apache.org/jira/browse/IGNITE-10753
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Reporter: Roman Kondakov
>Assignee: Roman Kondakov
>Priority: Major
> Labels: MakeTeamcityGreenAgain, mvcc_stabilization_stage_1,
> transactions
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When mvcc test is finished, we check if there any outdated versions are left
> in cache and not cleaned by vacuum. If so, an exception is thrown. There are
> some tests with this problem:
> * {{CacheMvccTransactionsTest.testCleanupWaitsForGet1}}
> * {{CacheMvccTransactionsTest.testCleanupWaitsForGet3}}
> *
> {{CacheMvccReplicatedSqlCoordinatorFailoverTest.testAccountsTxSql_SingleNode_CoordinatorFails_Persistence}}
> *
> {{CacheMvccReplicatedSqlCoordinatorFailoverTest.testPutAllGetAll_ClientServer_Backups0_RestartCoordinator_SqlDml}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10183) [Test Failed] IgniteClientReconnectCacheTest.testReconnectOperationInProgress flaky fails on TC.
[
https://issues.apache.org/jira/browse/IGNITE-10183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16746180#comment-16746180
]
Ignite TC Bot commented on IGNITE-10183:
{panel:title=-- Run :: All: No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=2825119buildTypeId=IgniteTests24Java8_RunAll]
> [Test Failed] IgniteClientReconnectCacheTest.testReconnectOperationInProgress
> flaky fails on TC.
>
>
> Key: IGNITE-10183
> URL: https://issues.apache.org/jira/browse/IGNITE-10183
> Project: Ignite
> Issue Type: Bug
> Components: cache, mvcc
>Affects Versions: 2.7
>Reporter: Pavel Pereslegin
>Assignee: Roman Kondakov
>Priority: Major
> Labels: MakeTeamcityGreenAgain, failover,
> mvcc_stabilization_stage_1
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> IgniteClientReconnectCacheTest.testReconnectOperationInProgress fails
> sometimes in master (see [recent failures on
> TC|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8==testDetails=-1285534571845460301=TEST_STATUS_DESC_IgniteTests24Java8=%3Cdefault%3E=50]).
> Test fails only for cache with {{TRANSACTIONAL_SNAPSHOT}} atomicity mode.
> Typical output:
> {noformat}
> [2018-11-07 23:13:00,579][ERROR][main][root] Test failed.
> class org.apache.ignite.IgniteCheckedException: class
> org.apache.ignite.transactions.TransactionRollbackException: Transaction has
> been rolled back: 2e10370f661--0920-4f4e--0026
> at org.apache.ignite.internal.util.IgniteUtils.cast(IgniteUtils.java:7425)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.resolve(GridFutureAdapter.java:261)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:191)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:141)
> at
> org.apache.ignite.internal.IgniteClientReconnectCacheTest.checkOperationInProgressFails(IgniteClientReconnectCacheTest.java:1421)
> at
> org.apache.ignite.internal.IgniteClientReconnectCacheTest.testReconnectOperationInProgress(IgniteClientReconnectCacheTest.java:869)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2208)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:144)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:2124)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: javax.cache.CacheException: class
> org.apache.ignite.transactions.TransactionRollbackException: Transaction has
> been rolled back: 2e10370f661--0920-4f4e--0026
> at
> org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1337)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.cacheException(IgniteCacheProxyImpl.java:1756)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.put(IgniteCacheProxyImpl.java:1108)
> at
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.put(GatewayProtectedCacheProxy.java:820)
> at
> org.apache.ignite.internal.IgniteClientReconnectCacheTest$10.apply(IgniteClientReconnectCacheTest.java:834)
> at
> org.apache.ignite.internal.IgniteClientReconnectCacheTest$10.apply(IgniteClientReconnectCacheTest.java:832)
> at
> org.apache.ignite.internal.IgniteClientReconnectCacheTest$25.call(IgniteClientReconnectCacheTest.java:1406)
> at
> org.apache.ignite.testframework.GridTestUtils.lambda$runAsync$2(GridTestUtils.java:1003)
> at
> org.apache.ignite.testframework.GridTestUtils$7.call(GridTestUtils.java:1299)
> at
> org.apache.ignite.testframework.GridTestThread.run(GridTestThread.java:84)
> Caused by: class org.apache.ignite.transactions.TransactionRollbackException:
> Transaction has been rolled back:
> 2e10370f661--0920-4f4e--0026
> at
> org.apache.ignite.internal.util.IgniteUtils$11.apply(IgniteUtils.java:922)
> at
> org.apache.ignite.internal.util.IgniteUtils$11.apply(IgniteUtils.java:920)
> ... 10 more
> Caused by: class
>
[jira] [Commented] (IGNITE-10877) GridAffinityAssignment.initPrimaryBackupMaps memory pressure
[ https://issues.apache.org/jira/browse/IGNITE-10877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16746171#comment-16746171 ] Alexei Scherbakov commented on IGNITE-10877: [~voropava], My comments: # I do not like IGNITE_AFFINITY_BACKUPS_THRESHOLD property. You already know number of nodes in assignment and should automatically choose most optimal way to store assignements depending on benchmark results. # In addition to 1 please introduce new system property like IGNITE_DISABLE_AFFINITY_MEMORY_OPTIMIZATION to force old implementation. # Please introduce test which automatically compares heap occupation with enabled and disabled optimization with various topology/partitions/caches sizes. Optimized mode must always be better than previous implementation. You can use techniques like ObjectGraphMeasurer for estimating object graph size from application. # I do not like class BitSetIntSet. It's better to introduce interface GridIntSet implementing Set and providing primitive(batch) iterators/getters API. In future where might be other implementations, on example compressed bit sets (see IGNITE-4554). I think this might be done in separate ticket and not crucial for this contribution. > GridAffinityAssignment.initPrimaryBackupMaps memory pressure > > > Key: IGNITE-10877 > URL: https://issues.apache.org/jira/browse/IGNITE-10877 > Project: Ignite > Issue Type: Improvement >Reporter: Pavel Voronkin >Assignee: Pavel Voronkin >Priority: Major > Attachments: grid.srv.node.1.0-29.12.2018-12.50.15.jfr, > image-2019-01-17-12-58-07-382.png, image-2019-01-17-12-59-52-137.png, > image-2019-01-17-15-45-49-561.png, image-2019-01-17-15-45-53-043.png, > image-2019-01-17-15-46-32-872.png, image-2019-01-18-11-36-57-451.png, > image-2019-01-18-11-38-39-410.png, image-2019-01-18-11-55-39-496.png, > image-2019-01-18-11-56-10-339.png, image-2019-01-18-11-56-18-040.png, > image-2019-01-18-12-09-04-835.png, image-2019-01-18-12-09-32-876.png > > Time Spent: 1.5h > Remaining Estimate: 0h > > 1) While running tests with JFR we observe huge memory allocation pressure > produced by: > *Stack Trace TLABs Total TLAB Size(bytes) Pressure(%)* > java.util.HashMap.newNode(int, Object, Object, HashMap$Node) 481 298 044 784 > 100 > java.util.HashMap.putVal(int, Object, Object, boolean, boolean) 481 298 044 > 784 100 > java.util.HashMap.put(Object, Object) 481 298 044 784 100 > java.util.HashSet.add(Object) 480 297 221 040 99,724 > > org.apache.ignite.internal.processors.affinity.GridAffinityAssignment.initPrimaryBackupMaps() > 1 823 744 0,276 > org.apache.ignite.internal.processors.affinity.GridAffinityAssignment.(AffinityTopologyVersion, > List, List) 1 823 744 0,276 > *Allocation stats* > Class Average Object Size(bytes) Total Object Size(bytes) TLABs Average TLAB > Size(bytes) Total TLAB Size(bytes) Pressure(%) > java.util.HashMap$Node 32 15 392 481 619 635,726 298 044 784 32,876 > java.lang.Object[] 1 470,115 461 616 314 655 019,236 205 676 040 22,687 > java.util.HashMap$Node[] 41 268,617 6 149 024 149 690 046,067 102 816 864 > 11,341 > java.lang.Integer 16 1 456 91 662 911,385 60 324 936 6,654 > java.util.ArrayList 24 1 608 67 703 389,97 47 127 128 5,198 > 2) Also another hot place found > Stack Trace TLABs Total TLAB Size(bytes) Pressure(%) > java.util.ArrayList.grow(int) 7 5 766 448 9,554 > java.util.ArrayList.ensureExplicitCapacity(int) 7 5 766 448 9,554 > java.util.ArrayList.ensureCapacityInternal(int) 7 5 766 448 9,554 > java.util.ArrayList.add(Object) 7 5 766 448 9,554 > > org.apache.ignite.internal.processors.cache.distributed.dht.topology.GridDhtPartitionTopologyImpl.nodes(int, > AffinityTopologyVersion, GridDhtPartitionState, GridDhtPartitionState[]) 7 5 > 766 448 9,554 > The reason of that is defail > I think we need to improve memory efficiency by switching from from Sets to > BitSets > > JFR attached, see Allocations in 12:50:28 - 12:50:29 > > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10645) SQL properties ownership flag should be set at configuration parsing, not query execution.
[ https://issues.apache.org/jira/browse/IGNITE-10645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16746170#comment-16746170 ] Pavel Kuznetsov commented on IGNITE-10645: -- [~vozerov] This check was added because I've simplified condition (https://github.com/apache/ignite/pull/5657/commits/bed7b76ade5990f4392e1169b060ef82dc67f3fe but note that comment would change one more time). If key is of sql type, we put it itself into the cache. As we discussed, key itself is not a key field, so isKeyField value in this case should be false. We relied on this fact in the jdbc metadata for example. If we duplicate keyFieldName in the list of keyFields then isKeyField value of the binary property will be true. Keeping in mind that configuration, having both keyFieldName and keyFields is contradictory, I forbid it. Other options: 1) Return old condition 2) Start thinking that key object itself is a keyField. Even more - start building KeyValueProperty for this field instead of BinaryProperty. > SQL properties ownership flag should be set at configuration parsing, not > query execution. > -- > > Key: IGNITE-10645 > URL: https://issues.apache.org/jira/browse/IGNITE-10645 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Pavel Kuznetsov >Assignee: Pavel Kuznetsov >Priority: Major > Fix For: 2.8 > > > At processing time, query entities are transformed and validated, table > descriptors with properties are created. > Now in some case (thre's no keyFields and key is of complex non-sql type), > ownership flag of query property is calculated at execution time (for example > at first put()): > https://github.com/apache/ignite/blob/dcdb27a24a450f63487290360b265e1570534629/modules/core/src/main/java/org/apache/ignite/internal/processors/query/property/QueryBinaryProperty.java#L132 > So we can't access metadata, that uses this not-yet-initialized field before > we put the data. > But we already have all necessary info to set this field at processing time. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10975) when ssl not correct configurate make cu error more undestandable
[ https://issues.apache.org/jira/browse/IGNITE-10975?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ARomantsov updated IGNITE-10975: Affects Version/s: 2.5 > when ssl not correct configurate make cu error more undestandable > - > > Key: IGNITE-10975 > URL: https://issues.apache.org/jira/browse/IGNITE-10975 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.5 >Reporter: ARomantsov >Priority: Major > > Now CU return > Connection to cluster failed. > Error: Latest topology update failed > this error also appear when you try to connect on unexist cluster , at that > point gain it with bad ssl that add little bit confusion -- This message was sent by Atlassian JIRA (v7.6.3#76005)
