[jira] [Commented] (IGNITE-11534) Partition loss policy is not handled properly for implicit single key transactions
[
https://issues.apache.org/jira/browse/IGNITE-11534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16791375#comment-16791375
]
Ivan Pavlukhin commented on IGNITE-11534:
-
[~DmitriyGovorukhin], TC results are ready. Also, I ignored some test methods
which fail in MVCC suites, attention will be taken in separate ticket related
to MVCC. Please take a look.
> Partition loss policy is not handled properly for implicit single key
> transactions
> --
>
> Key: IGNITE-11534
> URL: https://issues.apache.org/jira/browse/IGNITE-11534
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.7
>Reporter: Ivan Pavlukhin
>Assignee: Ivan Pavlukhin
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> There is a bug in handling partition loss policies for single put operations
> over {{TRANSACTIONAL}} cache (implicit transaction). Key values are passed
> improperly for validation.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11534) Partition loss policy is not handled properly for implicit single key transactions
[
https://issues.apache.org/jira/browse/IGNITE-11534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16791373#comment-16791373
]
Ignite TC Bot commented on IGNITE-11534:
{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=3298002&buildTypeId=IgniteTests24Java8_RunAll]
> Partition loss policy is not handled properly for implicit single key
> transactions
> --
>
> Key: IGNITE-11534
> URL: https://issues.apache.org/jira/browse/IGNITE-11534
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.7
>Reporter: Ivan Pavlukhin
>Assignee: Ivan Pavlukhin
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> There is a bug in handling partition loss policies for single put operations
> over {{TRANSACTIONAL}} cache (implicit transaction). Key values are passed
> improperly for validation.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-7139) SQL: Implement a lazy execution for the local queries.
[
https://issues.apache.org/jira/browse/IGNITE-7139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Taras Ledkov updated IGNITE-7139:
-
Fix Version/s: 2.8
> SQL: Implement a lazy execution for the local queries.
> --
>
> Key: IGNITE-7139
> URL: https://issues.apache.org/jira/browse/IGNITE-7139
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Affects Versions: 2.3
>Reporter: Roman Kondakov
>Assignee: Taras Ledkov
>Priority: Major
> Labels: sql-stability
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> At the moment a lazy execution is implemented for the distributed queries
> only (see {{GridMapQueryExecutor}}). We need to add this feature for the
> local queries too.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11435) SQL: Create a view with query history
[
https://issues.apache.org/jira/browse/IGNITE-11435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16791345#comment-16791345
]
Ignite TC Bot commented on IGNITE-11435:
{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=3296639&buildTypeId=IgniteTests24Java8_RunAll]
> SQL: Create a view with query history
> -
>
> Key: IGNITE-11435
> URL: https://issues.apache.org/jira/browse/IGNITE-11435
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Yury Gerzhedovich
>Assignee: Yury Gerzhedovich
>Priority: Major
> Labels: iep-29
> Fix For: 1.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Need to expose Query History view - LOCAL_SQL_QUERY_HISTORY
> List of columns:
> SCHEMA_NAME - name of schema
> QUERY - query text
> LOCAL - flag of local query
> CALLS - number of execution of the query
> FAILURES - number of failures for the query
> DURATION_MIN - minimum duration of execution
> DURATION_MAX - maximum duration of execution
> LAST_QUERY_START - time of the last start of execution
>
> see QueryHistoryMetrics class.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11535) AtomicLong cannot be found after creation
Vyacheslav Koptilin created IGNITE-11535: Summary: AtomicLong cannot be found after creation Key: IGNITE-11535 URL: https://issues.apache.org/jira/browse/IGNITE-11535 Project: Ignite Issue Type: Bug Affects Versions: 2.7 Reporter: Vyacheslav Koptilin Assignee: Vyacheslav Koptilin -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-11079) MVCC: IgniteCacheContinuousQueryBackupQueueTest is flacky.
[
https://issues.apache.org/jira/browse/IGNITE-11079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16790866#comment-16790866
]
Roman Kondakov edited comment on IGNITE-11079 at 3/12/19 7:43 PM:
--
Problem: The problem was that [implemented
optimization|https://github.com/gridgain/apache-ignite/commit/42293fac88c29544b7c55c0340224afbf474a301]
of storing filtered events in the backup queues was not taken into account for
this test. After this optimization backups do not store all filtered events and
instead storing they use {{filtered}} counter. In this case the expectation of
the large size of backup queues is wrong.
Fix: fixed the expectation of backup queues total size - it should be small or
even zero.
Since the only test code was changed, the RunAll visa from the TC Bot is not
necessary. I've runned two relevant suites (mvcc and non-mvcc). Waiting for
results:
[https://ci.ignite.apache.org/viewQueued.html?itemId=3299122&tab=queuedBuildOverviewTab]
[https://ci.ignite.apache.org/viewQueued.html?itemId=3299120&tab=queuedBuildOverviewTab]
was (Author: rkondakov):
Problem: The problem was that [implemented
optimization|https://github.com/gridgain/apache-ignite/commit/42293fac88c29544b7c55c0340224afbf474a301]
of storing filtered events in the backup queues was not taken into account for
this test. After this optimization backups do not store all filtered events and
instead storing they use {{filtered}} counter. In this case the expectation of
the large size of backup queues is wrong.
Fix: fixed the expectation of backup queues total size - it should be small or
even zero.
Since the only test code was changed, the RunAll visa from the TC Bot is not
necessary. I've runned two relevant suites (mvcc and non-mvcc). Waiting for
results:
[https://ci.ignite.apache.org/viewLog.html?buildId=3298494&tab=queuedBuildOverviewTab]
[https://ci.ignite.apache.org/viewLog.html?buildId=3298496&buildTypeId=IgniteTests24Java8_ContinuousQuery3]
> MVCC: IgniteCacheContinuousQueryBackupQueueTest is flacky.
> --
>
> Key: IGNITE-11079
> URL: https://issues.apache.org/jira/browse/IGNITE-11079
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Reporter: Andrew Mashenkov
>Assignee: Roman Kondakov
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Time Spent: 10m
> Remaining Estimate: 0h
>
> See Tc run
>
> [https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=925274886589214180&tab=testDetails]
> Test fails after series of long JVM pauses with stacktrace:
> {code:java}
> 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.internal.processors.cache.query.continuous.IgniteCacheContinuousQueryBackupQueueTest.testManyQueryBackupQueue(IgniteCacheContinuousQueryBackupQueueTest.java:175)
> 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){code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11079) MVCC: IgniteCacheContinuousQueryBackupQueueTest is flacky.
[
https://issues.apache.org/jira/browse/IGNITE-11079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16790866#comment-16790866
]
Roman Kondakov commented on IGNITE-11079:
-
Problem: The problem was that [implemented
optimization|https://github.com/gridgain/apache-ignite/commit/42293fac88c29544b7c55c0340224afbf474a301]
of storing filtered events in the backup queues was not taken into account for
this test. After this optimization backups do not store all filtered events and
instead storing they use {{filtered}} counter. In this case the expectation of
the large size of backup queues is wrong.
Fix: fixed the expectation of backup queues total size - it should be small or
even zero.
Since the only test code was changed, the RunAll visa from the TC Bot is not
necessary. I've runned two relevant suites (mvcc and non-mvcc). Waiting for
results:
[https://ci.ignite.apache.org/viewLog.html?buildId=3298494&tab=queuedBuildOverviewTab]
[https://ci.ignite.apache.org/viewLog.html?buildId=3298496&buildTypeId=IgniteTests24Java8_ContinuousQuery3]
> MVCC: IgniteCacheContinuousQueryBackupQueueTest is flacky.
> --
>
> Key: IGNITE-11079
> URL: https://issues.apache.org/jira/browse/IGNITE-11079
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Reporter: Andrew Mashenkov
>Assignee: Roman Kondakov
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Time Spent: 10m
> Remaining Estimate: 0h
>
> See Tc run
>
> [https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=925274886589214180&tab=testDetails]
> Test fails after series of long JVM pauses with stacktrace:
> {code:java}
> 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.internal.processors.cache.query.continuous.IgniteCacheContinuousQueryBackupQueueTest.testManyQueryBackupQueue(IgniteCacheContinuousQueryBackupQueueTest.java:175)
> 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){code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-7384) MVCC TX: Support historical rebalance
[ https://issues.apache.org/jira/browse/IGNITE-7384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-7384: Labels: rebalance (was: ) > MVCC TX: Support historical rebalance > - > > Key: IGNITE-7384 > URL: https://issues.apache.org/jira/browse/IGNITE-7384 > Project: Ignite > Issue Type: Task > Components: mvcc >Reporter: Igor Seliverstov >Priority: Major > Labels: rebalance > Fix For: 2.8 > > > Currently MVCC doesn't support historical (delta) rebalance. > The main difficulty is that MVCC writes changes on tx active phase while > partition update version, aka update counter, is being applied on tx finish. > This means we cannot start iteration over WAL right from the pointer where > the update counter updated, but should include updates, which the transaction > that updated the counter did. > Currently proposed approach: > * Maintain a list of active TXs with update counter (UC) which was actual at > the time before TX did its first update (on per partition basis) > * on each checkpoint save two counters - update counter (UC) and back > counter (BC) which is earliest UC mapped to a tx from active list at > checkpoint time. > * during local restore move UC and BC forward as far as possible. > * send BC instead of update counter in demand message. > * start iteration from a first checkpoint having UC less or equal received BC > See [linked dev list > thread|http://apache-ignite-developers.2346864.n4.nabble.com/Historical-rebalance-td38380.html] > for details -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10082) MVCC TX: Partition sizes become inconsistent after rebalance.
[ https://issues.apache.org/jira/browse/IGNITE-10082?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-10082: - Labels: mvcc_stability rebalance (was: mvcc_stability) > MVCC TX: Partition sizes become inconsistent after rebalance. > - > > Key: IGNITE-10082 > URL: https://issues.apache.org/jira/browse/IGNITE-10082 > Project: Ignite > Issue Type: Bug > Components: cache, mvcc >Reporter: Igor Seliverstov >Priority: Major > Labels: mvcc_stability, rebalance > Fix For: 2.8 > > > While rebalance partition size increments on each put operation; since > several versions of one key may be rebalanced, partition sizes become > inconsistent after rebalance finished. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11377) Display time to baseline auto-adjust event in console.sh
[
https://issues.apache.org/jira/browse/IGNITE-11377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16790721#comment-16790721
]
Ignite TC Bot commented on IGNITE-11377:
{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=3295482&buildTypeId=IgniteTests24Java8_RunAll]
> Display time to baseline auto-adjust event in console.sh
>
>
> Key: IGNITE-11377
> URL: https://issues.apache.org/jira/browse/IGNITE-11377
> Project: Ignite
> Issue Type: Improvement
>Reporter: Anton Kalashnikov
>Assignee: Anton Kalashnikov
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> It required to add information about next auto-adjust.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11107) MVCC: Various failures in IgniteCachePartitionLossPolicySelfTest
[
https://issues.apache.org/jira/browse/IGNITE-11107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Pavlukhin updated IGNITE-11107:
Description: Multiples tests in {{IgniteCachePartitionLossPolicySelfTest}}
fail in force MVCC mode. (was: Multiples tests in )
> MVCC: Various failures in IgniteCachePartitionLossPolicySelfTest
>
>
> Key: IGNITE-11107
> URL: https://issues.apache.org/jira/browse/IGNITE-11107
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Reporter: Roman Kondakov
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Multiples tests in {{IgniteCachePartitionLossPolicySelfTest}} fail in force
> MVCC mode.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11107) MVCC: Various failures in IgniteCachePartitionLossPolicySelfTest
[
https://issues.apache.org/jira/browse/IGNITE-11107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Pavlukhin updated IGNITE-11107:
Description: Multiples tests in {{IgniteCachePartitionLossPolicySelfTest}}
fail in forced MVCC mode. (was: Multiples tests in
{{IgniteCachePartitionLossPolicySelfTest}} fail in force MVCC mode.)
> MVCC: Various failures in IgniteCachePartitionLossPolicySelfTest
>
>
> Key: IGNITE-11107
> URL: https://issues.apache.org/jira/browse/IGNITE-11107
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Reporter: Roman Kondakov
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Multiples tests in {{IgniteCachePartitionLossPolicySelfTest}} fail in forced
> MVCC mode.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11107) MVCC: Various failures in IgniteCachePartitionLossPolicySelfTest
[
https://issues.apache.org/jira/browse/IGNITE-11107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Pavlukhin updated IGNITE-11107:
Description: Multiples tests in (was: Sometimes
IgniteCachePartitionLossPolicySelfTest.testReadWriteSafeAfterKillTwoNodes hangs
on PME. Some partitions have not changed their state from {{RENTING}} to
{{OWNING}}.
{noformat}
[2019-01-27 07:20:23,420][WARN
][test-runner-#32729%distributed.IgniteCachePartitionLossPolicySelfTest%][root]
Finished waiting for topology map update
[igniteInstanceName=distributed.IgniteCachePartitionLossPolicySelfTest4, p=0,
duration=1415ms]
[2019-01-27 07:20:23,421][WARN
][test-runner-#32729%distributed.IgniteCachePartitionLossPolicySelfTest%][root]
Waiting for correct partition state part=2, should be OWNING [state=RENTING],
node=distributed.IgniteCachePartitionLossPolicySelfTest4, cache=default
[2019-01-27 07:20:25,023][WARN
][test-runner-#32729%distributed.IgniteCachePartitionLossPolicySelfTest%][root]
Waiting for correct partition state part=13, should be OWNING [state=RENTING],
node=distributed.IgniteCachePartitionLossPolicySelfTest4, cache=default
Thread
[name="test-runner-#32729%distributed.IgniteCachePartitionLossPolicySelfTest%",
id=35714, state=RUNNABLE, blockCnt=93, waitCnt=1033]
at sun.management.ThreadImpl.dumpThreads0(Native Method)
at sun.management.ThreadImpl.dumpAllThreads(ThreadImpl.java:454)
at o.a.i.i.util.IgniteUtils.dumpThreads(IgniteUtils.java:1370)
at
o.a.i.testframework.junits.common.GridCommonAbstractTest.awaitPartitionMapExchange(GridCommonAbstractTest.java:792)
at
o.a.i.testframework.junits.common.GridCommonAbstractTest.awaitPartitionMapExchange(GridCommonAbstractTest.java:569)
at
o.a.i.i.processors.cache.distributed.IgniteCachePartitionLossPolicySelfTest.checkLostPartition(IgniteCachePartitionLossPolicySelfTest.java:560)
at
o.a.i.i.processors.cache.distributed.IgniteCachePartitionLossPolicySelfTest.testReadWriteSafeAfterKillTwoNodes(IgniteCachePartitionLossPolicySelfTest.java:258)
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
o.a.i.testframework.junits.GridAbstractTest$6.run(GridAbstractTest.java:2088)
at java.lang.Thread.run(Thread.java:748)
{noformat}
)
> MVCC: Various failures in IgniteCachePartitionLossPolicySelfTest
>
>
> Key: IGNITE-11107
> URL: https://issues.apache.org/jira/browse/IGNITE-11107
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Reporter: Roman Kondakov
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Multiples tests in
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11107) MVCC: Various failures in IgniteCachePartitionLossPolicySelfTest
[
https://issues.apache.org/jira/browse/IGNITE-11107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Pavlukhin updated IGNITE-11107:
Summary: MVCC: Various failures in IgniteCachePartitionLossPolicySelfTest
(was: MVCC:
IgniteCachePartitionLossPolicySelfTest.testReadWriteSafeAfterKillTwoNodes fails)
> MVCC: Various failures in IgniteCachePartitionLossPolicySelfTest
>
>
> Key: IGNITE-11107
> URL: https://issues.apache.org/jira/browse/IGNITE-11107
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Reporter: Roman Kondakov
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Sometimes
> IgniteCachePartitionLossPolicySelfTest.testReadWriteSafeAfterKillTwoNodes
> hangs on PME. Some partitions have not changed their state from {{RENTING}}
> to {{OWNING}}.
> {noformat}
> [2019-01-27 07:20:23,420][WARN
> ][test-runner-#32729%distributed.IgniteCachePartitionLossPolicySelfTest%][root]
> Finished waiting for topology map update
> [igniteInstanceName=distributed.IgniteCachePartitionLossPolicySelfTest4, p=0,
> duration=1415ms]
> [2019-01-27 07:20:23,421][WARN
> ][test-runner-#32729%distributed.IgniteCachePartitionLossPolicySelfTest%][root]
> Waiting for correct partition state part=2, should be OWNING
> [state=RENTING], node=distributed.IgniteCachePartitionLossPolicySelfTest4,
> cache=default
> [2019-01-27 07:20:25,023][WARN
> ][test-runner-#32729%distributed.IgniteCachePartitionLossPolicySelfTest%][root]
> Waiting for correct partition state part=13, should be OWNING
> [state=RENTING], node=distributed.IgniteCachePartitionLossPolicySelfTest4,
> cache=default
> Thread
> [name="test-runner-#32729%distributed.IgniteCachePartitionLossPolicySelfTest%",
> id=35714, state=RUNNABLE, blockCnt=93, waitCnt=1033]
> at sun.management.ThreadImpl.dumpThreads0(Native Method)
> at sun.management.ThreadImpl.dumpAllThreads(ThreadImpl.java:454)
> at o.a.i.i.util.IgniteUtils.dumpThreads(IgniteUtils.java:1370)
> at
> o.a.i.testframework.junits.common.GridCommonAbstractTest.awaitPartitionMapExchange(GridCommonAbstractTest.java:792)
> at
> o.a.i.testframework.junits.common.GridCommonAbstractTest.awaitPartitionMapExchange(GridCommonAbstractTest.java:569)
> at
> o.a.i.i.processors.cache.distributed.IgniteCachePartitionLossPolicySelfTest.checkLostPartition(IgniteCachePartitionLossPolicySelfTest.java:560)
> at
> o.a.i.i.processors.cache.distributed.IgniteCachePartitionLossPolicySelfTest.testReadWriteSafeAfterKillTwoNodes(IgniteCachePartitionLossPolicySelfTest.java:258)
> 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
> o.a.i.testframework.junits.GridAbstractTest$6.run(GridAbstractTest.java:2088)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11233) Ignite Build for Java 11 does not reuse ignite-tools from Build Apache Ignite for some configurations, Compilation error
[
https://issues.apache.org/jira/browse/IGNITE-11233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16790684#comment-16790684
]
Dmitriy Pavlov commented on IGNITE-11233:
-
[~vveider] [~ptupitsyn] I see that PR is merged. Can we resolve this issue for
now?
> Ignite Build for Java 11 does not reuse ignite-tools from Build Apache Ignite
> for some configurations, Compilation error
>
>
> Key: IGNITE-11233
> URL: https://issues.apache.org/jira/browse/IGNITE-11233
> Project: Ignite
> Issue Type: Bug
>Reporter: Dmitriy Pavlov
>Assignee: Peter Ivanov
>Priority: Critical
> Fix For: 2.8
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> _Javadoc_ [ tests 0 Exit Code , Compilation Error ]
> https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_Javadoc&branch=ignite-11213&tab=buildTypeStatusDiv
> SPI (URI Deploy) [ tests 0 Exit Code , Compilation Error ]
> https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_SpiUriDeploy&branch=ignite-11213&tab=buildTypeStatusDiv
> RDD* [ tests 0 Exit Code , Compilation Error ]
> https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_Rdd&branch=ignite-11213&tab=buildTypeStatusDiv
> JCache TCK 1.1 [ tests 0 Exit Code , Compilation Error ]
> https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_JCacheTck11&branch=ignite-11213&tab=buildTypeStatusDiv
> Platform .NET (NuGet)* [ tests 0 Exit Code ]
> https://ci.ignite.apache.org/viewLog.html?tab=buildLog&logTab=tree&filter=debug&expand=all&buildId=3007897&_focus=904
> {noformat}
> [21:28:31][Step 1/1] [INFO] Compiling 9 source files to
> /data/teamcity/work/9198da4c51c3e112/modules/tools/target/classes
> [21:28:32][Step 1/1] [INFO]
> /data/teamcity/work/9198da4c51c3e112/modules/tools/src/main/java/org/apache/ignite/tools/javadoc/IgniteLinkTaglet.java:
>
> /data/teamcity/work/9198da4c51c3e112/modules/tools/src/main/java/org/apache/ignite/tools/javadoc/IgniteLinkTaglet.java
> uses or overrides a deprecated API that is marked for removal.
> [21:28:32][Step 1/1] [INFO]
> /data/teamcity/work/9198da4c51c3e112/modules/tools/src/main/java/org/apache/ignite/tools/javadoc/IgniteLinkTaglet.java:
> Recompile with -Xlint:removal for details.
> [21:28:32][Step 1/1] [INFO]
> /data/teamcity/work/9198da4c51c3e112/modules/tools/src/main/java/org/apache/ignite/tools/classgen/ClassesGenerator.java:
>
> /data/teamcity/work/9198da4c51c3e112/modules/tools/src/main/java/org/apache/ignite/tools/classgen/ClassesGenerator.java
> uses unchecked or unsafe operations.
> [21:28:32][Step 1/1] [INFO]
> /data/teamcity/work/9198da4c51c3e112/modules/tools/src/main/java/org/apache/ignite/tools/classgen/ClassesGenerator.java:
> Recompile with -Xlint:unchecked for details.
> [21:28:32][Step 1/1] [INFO]
> -
> [21:28:32][Step 1/1] [ERROR] COMPILATION ERROR :
> [21:28:32][Step 1/1] [INFO]
> -
> [21:28:32][Step 1/1] [ERROR]
> /data/teamcity/work/9198da4c51c3e112/modules/tools/src/main/java/org/apache/ignite/tools/javadoc/IgniteLinkTaglet.java:[21,29]
> package com.sun.tools.doclets does not exist
> [21:28:32][Step 1/1] [ERROR]
> /data/teamcity/work/9198da4c51c3e112/modules/tools/src/main/java/org/apache/ignite/tools/javadoc/IgniteLinkTaglet.java:[30,42]
> cannot find symbol
> [21:28:32][Step 1/1] symbol: class Taglet
> [21:28:32][Step 1/1] [ERROR]
> /data/teamcity/work/9198da4c51c3e112/modules/tools/src/main/java/org/apache/ignite/tools/javadoc/IgniteLinkTaglet.java:[37,5]
> method does not override or implement a method from a supertype
> [21:28:32][Step 1/1] [ERROR]
> /data/teamcity/work/9198da4c51c3e112/modules/tools/src/main/java/org/apache/ignite/tools/javadoc/IgniteLinkTaglet.java:[44,5]
> method does not override or implement a method from a supertype
> [21:28:32][Step 1/1] [ERROR]
> /data/teamcity/work/9198da4c51c3e112/modules/tools/src/main/java/org/apache/ignite/tools/javadoc/IgniteLinkTaglet.java:[51,5]
> method does not override or implement a method from a supertype
> [21:28:32][Step 1/1] [ERROR]
> /data/teamcity/work/9198da4c51c3e112/modules/tools/src/main/java/org/apache/ignite/tools/javadoc/IgniteLinkTaglet.java:[58,5]
> method does not override or implement a method from a supertype
> [21:28:32][Step 1/1] [ERROR]
> /data/teamcity/work/9198da4c51c3e112/modules/tools/src/main/java/org/apache/ignite/tools/javadoc/IgniteLinkTaglet.java:[65,5]
> method does not override or implement a method from a supertype
> [21:28:32][Step 1/1] [ERROR]
> /data/teamcity/work/9198da4c51c3e112/modules/tools/src/main/java/org/apac
[jira] [Commented] (IGNITE-11391) Test on free list is freezes sometimes
[
https://issues.apache.org/jira/browse/IGNITE-11391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16790653#comment-16790653
]
Ignite TC Bot commented on IGNITE-11391:
{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=3294999&buildTypeId=IgniteTests24Java8_RunAll]
> Test on free list is freezes sometimes
> --
>
> Key: IGNITE-11391
> URL: https://issues.apache.org/jira/browse/IGNITE-11391
> Project: Ignite
> Issue Type: Bug
>Reporter: Anton Kalashnikov
>Assignee: Anton Kalashnikov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> CheckpointFreeListTest#testRestoreFreeListCorrectlyAfterRandomStop - freezed
> sometimes
> CheckpointFreeListTest.testFreeListRestoredCorrectly - flaky
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-11531) Merge concurrent registrations of the same binary type
[
https://issues.apache.org/jira/browse/IGNITE-11531?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton Kalashnikov reassigned IGNITE-11531:
--
Assignee: Anton Kalashnikov
> Merge concurrent registrations of the same binary type
> --
>
> Key: IGNITE-11531
> URL: https://issues.apache.org/jira/browse/IGNITE-11531
> Project: Ignite
> Issue Type: Improvement
> Components: binary
>Reporter: Denis Mekhanikov
>Assignee: Anton Kalashnikov
>Priority: Major
>
> When a binary type is registered multiple times simultaneously, then a lot of
> type versions are generated with the same schema. It leads to long binary
> type registration especially on big topologies.
> The following code sample demonstrates the problem:
> {code:java}
> public class LongRegistration {
> public static void main(String[] args) throws InterruptedException {
> Ignite ignite = Ignition.start(igniteConfig());
> int threadsNum = 50;
> ExecutorService exec = Executors.newFixedThreadPool(threadsNum);
> CyclicBarrier barrier = new CyclicBarrier(threadsNum);
> long startTime = System.currentTimeMillis();
> // register(ignite);
> for (int i = 0; i < threadsNum; i++)
> exec.submit(new TypeRegistrator(ignite, barrier));
> exec.shutdown();
> exec.awaitTermination(Long.MAX_VALUE, TimeUnit.SECONDS);
> System.out.println("Total registration time: " +
> (System.currentTimeMillis() - startTime));
> }
> private static IgniteConfiguration igniteConfig() {
> IgniteConfiguration igniteCfg = new IgniteConfiguration();
> TcpDiscoveryVmIpFinder ipFinder = new TcpDiscoveryVmIpFinder();
>
> ipFinder.setAddresses(Collections.singletonList("127.0.0.1:47500..47509"));
> TcpDiscoverySpi discoverySpi = new TcpDiscoverySpi();
> discoverySpi.setLocalAddress("127.0.0.1");
> discoverySpi.setLocalPort(47500);
> discoverySpi.setIpFinder(ipFinder);
> igniteCfg.setDiscoverySpi(discoverySpi);
> return igniteCfg;
> }
> private static void register(Ignite ignite) {
> long startTime = System.currentTimeMillis();
> IgniteBinary binary = ignite.binary();
> BinaryObjectBuilder builder = binary.builder("TestType");
> builder.setField("intField", 1);
> builder.build();
> System.out.println("Registration time: " +
> (System.currentTimeMillis() - startTime));
> }
> private static class TypeRegistrator implements Runnable {
> private Ignite ignite;
> private CyclicBarrier cyclicBarrier;
> TypeRegistrator(Ignite ignite, CyclicBarrier cyclicBarrier) {
> this.ignite = ignite;
> this.cyclicBarrier = cyclicBarrier;
> }
> @Override public void run() {
> try {
> cyclicBarrier.await();
> register(ignite);
> } catch (InterruptedException | BrokenBarrierException e) {
> e.printStackTrace();
> }
> }
> }
> }
> {code}
> This code sample leads to registration of 50 versions of the same type. The
> effect is more noticeable if a cluster contains a lot of nodes.
> If you uncomment the call to {{register()}} method, then overall registration
> becomes 10 times faster on topology of 5 nodes.
> Registration of matching types should be merged to avoid long processing of
> such cases.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11534) Partition loss policy is not handled properly for implicit single key transactions
[
https://issues.apache.org/jira/browse/IGNITE-11534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16790650#comment-16790650
]
Dmitriy Govorukhin commented on IGNITE-11534:
-
[~Pavlukhin] Looks good to me, please run TC and proceed to merge if status
will be ok.
> Partition loss policy is not handled properly for implicit single key
> transactions
> --
>
> Key: IGNITE-11534
> URL: https://issues.apache.org/jira/browse/IGNITE-11534
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.7
>Reporter: Ivan Pavlukhin
>Assignee: Ivan Pavlukhin
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> There is a bug in handling partition loss policies for single put operations
> over {{TRANSACTIONAL}} cache (implicit transaction). Key values are passed
> improperly for validation.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11523) Can't cast null value from Cassandra table primitive column to primitive value used in domain object model
[
https://issues.apache.org/jira/browse/IGNITE-11523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16790646#comment-16790646
]
Ilya Kasnacheev commented on IGNITE-11523:
--
[~irudyak] can you look into it?
> Can't cast null value from Cassandra table primitive column to primitive
> value used in domain object model
> --
>
> Key: IGNITE-11523
> URL: https://issues.apache.org/jira/browse/IGNITE-11523
> Project: Ignite
> Issue Type: Bug
> Components: cache, cassandra
>Affects Versions: 2.7
>Reporter: Xinmin Wang
>Priority: Major
>
> *Issue*
> Adding new primitive type columns to the existing tables which have data
> existed in
> Cassandra causes Ignite to raise an exception (see below) in Ignite 2.7.0 or
> 2.8.0 nightly build when loading the data from Cassandra into Ignite Cache
> store. This works before Ignite 2.6, and even
> apache-ignite-fabric-2.7.0.20180918 nightly build.
> The assumption seems not correct because both Ignite and Cassandra are (key,
> value) store. In fact, SQLLINE tool, we don't need to insert into primitive
> value, see the example blow -
> CREATE TABLE aa (col1 int PRIMARY KEY, col2 double );
> INSERT INTO aa(col1) VALUES (1);
> SELECT * FROM aa;
> *Root Cause*
> This issue is related to the implementation of public static Object
> getCassandraColumnValue(Row row, String col, Class clazz, Serializer
> serializer) in PropertyMappingHelper.java
> ([https://github.com/apache/ignite/blob/master/modules/cassandra/store/src/main/java/org/apache/ignite/cache/store/cassandra/common/PropertyMappingHelper.java]).
> This class has been changed since 2.7.0. For primitive java type, I don't
> think we need to check null value. The assumption is that every row for
> primitive types in Cassandra table must have value is not correct.
> {panel:title=getCassandraColumnValue(Row row, String col, Class clazz,
> Serializer serializer)}
> public static Object getCassandraColumnValue(Row row, String col, Class
> clazz, Serializer serializer) {
> ...
> if (Long.class.equals(clazz))
> return row.isNull(col) ? null : row.getLong(col);
> // why needs to check the primitive null. NoSql is a pair of (key, value).
> // there is no pair in this case
> // all databases (relational databases and NoSql databases support null
> colum values)
> if (long.class.equals(clazz)) {
> if (row.isNull(col)) {
> throw new IllegalArgumentException("Can't cast null value from Cassandra
> table column '" + col +
> "' to " + "long value used in domain object model");
> }
> return row.getLong(col);
> }
> }
> {panel}
>
> *Detailed Exception*
> [2019-03-11
> 09:44:34,352][ERROR][cassandra-cache-loader-#61%ignite-procurant-purchase-order-cluster%][CassandraCacheStore]
>
> Failed to build Ignite value object from provided Cassandra row
> java.lang.IllegalArgumentException: Can't cast null value from Cassandra
> table column 'suppliertotamt' to double value used in domain object model
> at
> org.apache.ignite.cache.store.cassandra.common.PropertyMappingHelper.getCassandraColumnValue(PropertyMappingHelper.java:169)
>
> at
> org.apache.ignite.cache.store.cassandra.persistence.PojoField.setValueFromRow(PojoField.java:205)
>
> at
> org.apache.ignite.cache.store.cassandra.persistence.PersistenceController.buildObject(PersistenceController.java:405)
>
> at
> org.apache.ignite.cache.store.cassandra.persistence.PersistenceController.buildValueObject(PersistenceController.java:227)
>
> at
> org.apache.ignite.cache.store.cassandra.session.LoadCacheCustomQueryWorker$1.process(LoadCacheCustomQueryWorker.java:107)
>
> at
> org.apache.ignite.cache.store.cassandra.session.CassandraSessionImpl.execute(CassandraSessionImpl.java:402)
>
> at
> org.apache.ignite.cache.store.cassandra.session.LoadCacheCustomQueryWorker.call(LoadCacheCustomQueryWorker.java:81)
>
> at
> org.apache.ignite.cache.store.cassandra.session.LoadCacheCustomQueryWorker.call(LoadCacheCustomQueryWorker.java:35)
>
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> 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)
> [2019-03-11
> 09:44:34,360][ERROR][cassandra-cache-loader-#61%ignite-procurant-purchase-order-cluster%][CassandraCacheStore]
>
> Failed to execute Cassandra loadCache operation
> class org.apache.ignite.IgniteException: Failed to execute Cassandra
> loadCache operation
> at
> org.apache.ignite.cache.store.cassandra.session.Ca
[jira] [Updated] (IGNITE-11107) MVCC: IgniteCachePartitionLossPolicySelfTest.testReadWriteSafeAfterKillTwoNodes fails
[
https://issues.apache.org/jira/browse/IGNITE-11107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Pavlukhin updated IGNITE-11107:
Summary: MVCC:
IgniteCachePartitionLossPolicySelfTest.testReadWriteSafeAfterKillTwoNodes fails
(was: MVCC:
IgniteCachePartitionLossPolicySelfTest.testReadWriteSafeAfterKillTwoNodes hangs
sometimes)
> MVCC:
> IgniteCachePartitionLossPolicySelfTest.testReadWriteSafeAfterKillTwoNodes
> fails
> -
>
> Key: IGNITE-11107
> URL: https://issues.apache.org/jira/browse/IGNITE-11107
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Reporter: Roman Kondakov
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Sometimes
> IgniteCachePartitionLossPolicySelfTest.testReadWriteSafeAfterKillTwoNodes
> hangs on PME. Some partitions have not changed their state from {{RENTING}}
> to {{OWNING}}.
> {noformat}
> [2019-01-27 07:20:23,420][WARN
> ][test-runner-#32729%distributed.IgniteCachePartitionLossPolicySelfTest%][root]
> Finished waiting for topology map update
> [igniteInstanceName=distributed.IgniteCachePartitionLossPolicySelfTest4, p=0,
> duration=1415ms]
> [2019-01-27 07:20:23,421][WARN
> ][test-runner-#32729%distributed.IgniteCachePartitionLossPolicySelfTest%][root]
> Waiting for correct partition state part=2, should be OWNING
> [state=RENTING], node=distributed.IgniteCachePartitionLossPolicySelfTest4,
> cache=default
> [2019-01-27 07:20:25,023][WARN
> ][test-runner-#32729%distributed.IgniteCachePartitionLossPolicySelfTest%][root]
> Waiting for correct partition state part=13, should be OWNING
> [state=RENTING], node=distributed.IgniteCachePartitionLossPolicySelfTest4,
> cache=default
> Thread
> [name="test-runner-#32729%distributed.IgniteCachePartitionLossPolicySelfTest%",
> id=35714, state=RUNNABLE, blockCnt=93, waitCnt=1033]
> at sun.management.ThreadImpl.dumpThreads0(Native Method)
> at sun.management.ThreadImpl.dumpAllThreads(ThreadImpl.java:454)
> at o.a.i.i.util.IgniteUtils.dumpThreads(IgniteUtils.java:1370)
> at
> o.a.i.testframework.junits.common.GridCommonAbstractTest.awaitPartitionMapExchange(GridCommonAbstractTest.java:792)
> at
> o.a.i.testframework.junits.common.GridCommonAbstractTest.awaitPartitionMapExchange(GridCommonAbstractTest.java:569)
> at
> o.a.i.i.processors.cache.distributed.IgniteCachePartitionLossPolicySelfTest.checkLostPartition(IgniteCachePartitionLossPolicySelfTest.java:560)
> at
> o.a.i.i.processors.cache.distributed.IgniteCachePartitionLossPolicySelfTest.testReadWriteSafeAfterKillTwoNodes(IgniteCachePartitionLossPolicySelfTest.java:258)
> 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
> o.a.i.testframework.junits.GridAbstractTest$6.run(GridAbstractTest.java:2088)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11107) MVCC: IgniteCachePartitionLossPolicySelfTest.testReadWriteSafeAfterKillTwoNodes hangs sometimes
[
https://issues.apache.org/jira/browse/IGNITE-11107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Pavlukhin updated IGNITE-11107:
Labels: (was: Hanging)
> MVCC:
> IgniteCachePartitionLossPolicySelfTest.testReadWriteSafeAfterKillTwoNodes
> hangs sometimes
> ---
>
> Key: IGNITE-11107
> URL: https://issues.apache.org/jira/browse/IGNITE-11107
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Reporter: Roman Kondakov
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Sometimes
> IgniteCachePartitionLossPolicySelfTest.testReadWriteSafeAfterKillTwoNodes
> hangs on PME. Some partitions have not changed their state from {{RENTING}}
> to {{OWNING}}.
> {noformat}
> [2019-01-27 07:20:23,420][WARN
> ][test-runner-#32729%distributed.IgniteCachePartitionLossPolicySelfTest%][root]
> Finished waiting for topology map update
> [igniteInstanceName=distributed.IgniteCachePartitionLossPolicySelfTest4, p=0,
> duration=1415ms]
> [2019-01-27 07:20:23,421][WARN
> ][test-runner-#32729%distributed.IgniteCachePartitionLossPolicySelfTest%][root]
> Waiting for correct partition state part=2, should be OWNING
> [state=RENTING], node=distributed.IgniteCachePartitionLossPolicySelfTest4,
> cache=default
> [2019-01-27 07:20:25,023][WARN
> ][test-runner-#32729%distributed.IgniteCachePartitionLossPolicySelfTest%][root]
> Waiting for correct partition state part=13, should be OWNING
> [state=RENTING], node=distributed.IgniteCachePartitionLossPolicySelfTest4,
> cache=default
> Thread
> [name="test-runner-#32729%distributed.IgniteCachePartitionLossPolicySelfTest%",
> id=35714, state=RUNNABLE, blockCnt=93, waitCnt=1033]
> at sun.management.ThreadImpl.dumpThreads0(Native Method)
> at sun.management.ThreadImpl.dumpAllThreads(ThreadImpl.java:454)
> at o.a.i.i.util.IgniteUtils.dumpThreads(IgniteUtils.java:1370)
> at
> o.a.i.testframework.junits.common.GridCommonAbstractTest.awaitPartitionMapExchange(GridCommonAbstractTest.java:792)
> at
> o.a.i.testframework.junits.common.GridCommonAbstractTest.awaitPartitionMapExchange(GridCommonAbstractTest.java:569)
> at
> o.a.i.i.processors.cache.distributed.IgniteCachePartitionLossPolicySelfTest.checkLostPartition(IgniteCachePartitionLossPolicySelfTest.java:560)
> at
> o.a.i.i.processors.cache.distributed.IgniteCachePartitionLossPolicySelfTest.testReadWriteSafeAfterKillTwoNodes(IgniteCachePartitionLossPolicySelfTest.java:258)
> 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
> o.a.i.testframework.junits.GridAbstractTest$6.run(GridAbstractTest.java:2088)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9160) FindBugs: NPE and CCE on equals() methods
[
https://issues.apache.org/jira/browse/IGNITE-9160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16790641#comment-16790641
]
Ignite TC Bot commented on IGNITE-9160:
---
{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=3294124&buildTypeId=IgniteTests24Java8_RunAll]
> FindBugs: NPE and CCE on equals() methods
> -
>
> Key: IGNITE-9160
> URL: https://issues.apache.org/jira/browse/IGNITE-9160
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.6
>Reporter: Nikolai Kulagin
>Assignee: Nikolai Kulagin
>Priority: Minor
> Labels: newbie
> Fix For: 2.8
>
>
> Some classes have Incorrect equals() method:
> {code:java}
> // GridDhtPartitionMap.java
> @Override public boolean equals(Object o) {
> if (this == o)
> return true;
> GridDhtPartitionMap other = (GridDhtPartitionMap)o;
> return other.nodeId.equals(nodeId) && other.updateSeq == updateSeq;
> }{code}
> In this case, we can get CCE
> {code:java}
> GridDhtPartitionMap gridDhtPartMap = new GridDhtPartitionMap();
> gridDhtPartMap.equals(new Object());
> --
> Exception in thread "main" java.lang.ClassCastException: java.lang.Object
> cannot be cast to
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionMap
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionMap.equals(GridDhtPartitionMap.java:319)
> at ru.zzzadruga.Ignite.main(Ignite.java:9){code}
> Or NPE
> {code:java}
> GridDhtPartitionMap gridDhtPartMap = new GridDhtPartitionMap();
> gridDhtPartMap.equals(null);
> --
> Exception in thread "main" java.lang.NullPointerException
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionMap.equals(GridDhtPartitionMap.java:321)
> at ru.zzzadruga.Ignite.main(Ignite.java:9){code}
> The following code will prevent this
> {code:java}
> if (o == null || getClass() != o.getClass())
> return false;{code}
> + List of classes with similar problems: +
> * *GridTopic$T1-T8* - NPE
> * *GridCachePreloadLifecycleAbstractTest -* NPE
> * *GridDhtPartitionFullMap -* NPE and CCE
> * *GridDhtPartitionMap -* NPE and CCE
> * *OptimizedMarshallerSelfTest -* NPE and CCE
> * *GatewayProtectedCacheProxy -* NPE and CCE
> * *GridNearOptimisticTxPrepareFuture -* NPE and CCE
> * *GridCacheDistributedQueryManager -* NPE and CCE
> * *GridServiceMethodReflectKey -* NPE and CCE
> * *GridListSetSelfTest -* NPE and CCE
> * *GridTestKey -* NPE and CCE
> * *GridCacheMvccCandidate -* CCE
> * *GridDhtPartitionExchangeId -* CCE
> * *GridTuple6 -* CCE
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-7139) SQL: Implement a lazy execution for the local queries.
[
https://issues.apache.org/jira/browse/IGNITE-7139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Taras Ledkov reassigned IGNITE-7139:
Assignee: Taras Ledkov
> SQL: Implement a lazy execution for the local queries.
> --
>
> Key: IGNITE-7139
> URL: https://issues.apache.org/jira/browse/IGNITE-7139
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Affects Versions: 2.3
>Reporter: Roman Kondakov
>Assignee: Taras Ledkov
>Priority: Major
> Labels: sql-stability
>
> At the moment a lazy execution is implemented for the distributed queries
> only (see {{GridMapQueryExecutor}}). We need to add this feature for the
> local queries too.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11469) Support Automatic modules for ignite-rest-http: resolve package inference between Jetty & Tomcat
[
https://issues.apache.org/jira/browse/IGNITE-11469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16790521#comment-16790521
]
Dmitriy Pavlov commented on IGNITE-11469:
-
[~Jokser], could you take a brief look at PR
https://github.com/apache/ignite/pull/6256 ? It is actually very simple, but
process is process :)
> Support Automatic modules for ignite-rest-http: resolve package inference
> between Jetty & Tomcat
>
>
> Key: IGNITE-11469
> URL: https://issues.apache.org/jira/browse/IGNITE-11469
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Dmitriy Pavlov
>Assignee: Dmitriy Pavlov
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> {noformat}
> error: the unnamed module reads package javax.servlet.http from both
> javax.servlet.api and tomcat.servlet.api
> error: the unnamed module reads package javax.servlet.descriptor from both
> javax.servlet.api and tomcat.servlet.api
> error: the unnamed module reads package javax.servlet.annotation from both
> javax.servlet.api and tomcat.servlet.api
> error: the unnamed module reads package javax.servlet from both
> javax.servlet.api and tomcat.servlet.api
> {noformat}
> Exclude of tomcat dependency solves the problem
> {code}
> compile(group: 'org.apache.ignite', name: 'ignite-rest-http', version:
> ignVer) {
> exclude group: 'org.apache.tomcat'
> // to remove "javax.servlet.http, javax.servlet.descriptor,
> javax.servlet.annotation, javax.servlet" package conflicts.
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-11469) Support Automatic modules for ignite-rest-http: resolve package inference between Jetty & Tomcat
[
https://issues.apache.org/jira/browse/IGNITE-11469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16790477#comment-16790477
]
Dmitriy Pavlov edited comment on IGNITE-11469 at 3/12/19 1:40 PM:
--
This issue fix consists of 2 commits
-
https://github.com/apache/ignite/commit/526871860526bd674fced26813910904fda1be2b
-
https://github.com/apache/ignite/commit/84c458283e01b4f93ca4d29d3844f663a1c124b1
was (Author: dpavlov):
This issue fix consists of 2 commits
-
https://github.com/apache/ignite/commit/526871860526bd674fced26813910904fda1be2b
- https://github.com/apache/ignite/pull/6256
> Support Automatic modules for ignite-rest-http: resolve package inference
> between Jetty & Tomcat
>
>
> Key: IGNITE-11469
> URL: https://issues.apache.org/jira/browse/IGNITE-11469
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Dmitriy Pavlov
>Assignee: Dmitriy Pavlov
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> {noformat}
> error: the unnamed module reads package javax.servlet.http from both
> javax.servlet.api and tomcat.servlet.api
> error: the unnamed module reads package javax.servlet.descriptor from both
> javax.servlet.api and tomcat.servlet.api
> error: the unnamed module reads package javax.servlet.annotation from both
> javax.servlet.api and tomcat.servlet.api
> error: the unnamed module reads package javax.servlet from both
> javax.servlet.api and tomcat.servlet.api
> {noformat}
> Exclude of tomcat dependency solves the problem
> {code}
> compile(group: 'org.apache.ignite', name: 'ignite-rest-http', version:
> ignVer) {
> exclude group: 'org.apache.tomcat'
> // to remove "javax.servlet.http, javax.servlet.descriptor,
> javax.servlet.annotation, javax.servlet" package conflicts.
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-11460) MVCC: Possible race on coordinator changing on client reconnection.
[
https://issues.apache.org/jira/browse/IGNITE-11460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16790551#comment-16790551
]
Amelchev Nikita edited comment on IGNITE-11460 at 3/12/19 1:43 PM:
---
[~amashenkov], At first I did it with this flag. But it doesn't solve the
problem correctly. In such case we can get the next situation:
client's event queue has some events that can change coordinator. Client
disconnect from cluster and reconnect again.
Notifier thread sets kernalContext.clientDisconnected=false. The client
continues processing events from the queue with previous cluster events and set
the wrong coordinator.
We should guarantee that no one event will be processed after disconnect +until
processed reconnect event+.
The order of processing events in discovery threads (event, notifier) is fine.
was (Author: nsamelchev):
[~amashenkov], At first I did it with this flag. But it doesn't solve the
problem correctly. In such case we can get the next situation:
client's event queue has some events that can change coordinator. Client
disconnect from cluster and reconnect again.
Notifier thread sets kernalContext.clientDisconnected=false. The client
continues processing events from the queue with previous cluster events and set
the wrong coordinator.
We should guarantee that no one event will be processed after disconnect +until
processed reconnect event+.
> MVCC: Possible race on coordinator changing on client reconnection.
> ---
>
> Key: IGNITE-11460
> URL: https://issues.apache.org/jira/browse/IGNITE-11460
> Project: Ignite
> Issue Type: Bug
>Reporter: Amelchev Nikita
>Assignee: Amelchev Nikita
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I found that the wrong coordinator can be set in case of client reconnect:
> {noformat}
> assert newCrd.topologyVersion().compareTo(curCrd.topologyVersion()) > 0;
> java.lang.AssertionError
> at
> org.apache.ignite.internal.processors.cache.mvcc.MvccProcessorImpl.onCoordinatorChanged(MvccProcessorImpl.java:541)
> at
> org.apache.ignite.internal.processors.cache.mvcc.MvccProcessorImpl.onLocalJoin(MvccProcessorImpl.java:416)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery0(GridDiscoveryManager.java:851)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.lambda$onDiscovery$0(GridDiscoveryManager.java:601)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryMessageNotifierWorker.body0(GridDiscoveryManager.java:2681)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryMessageNotifierWorker.body(GridDiscoveryManager.java:2719)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> I have attached reproducer in PR.
> The main reason is that coordinator can be changed from discovery event
> thread when the client already disconnect (disconnection processed in
> notifier thread and change coordinator on onDisconnected method).
> Coordinator can be changed in cases:
> 1. notifier disco thread: onDisconnected method
> 2. event disco thread: onDiscovery listener.
> and events can be processed with some delay and override coordinator that set
> in notifier thread.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11460) MVCC: Possible race on coordinator changing on client reconnection.
[
https://issues.apache.org/jira/browse/IGNITE-11460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16790551#comment-16790551
]
Amelchev Nikita commented on IGNITE-11460:
--
[~amashenkov], At first I did it with this flag. But it doesn't solve the
problem correctly. In such case we can get the next situation:
client's event queue has some events that can change coordinator. Client
disconnect from cluster and reconnect again.
Notifier thread sets kernalContext.clientDisconnected=false. The client
continues processing events from the queue with previous cluster events and set
the wrong coordinator.
We should guarantee that no one event will be processed after disconnect +until
processed reconnect event+.
> MVCC: Possible race on coordinator changing on client reconnection.
> ---
>
> Key: IGNITE-11460
> URL: https://issues.apache.org/jira/browse/IGNITE-11460
> Project: Ignite
> Issue Type: Bug
>Reporter: Amelchev Nikita
>Assignee: Amelchev Nikita
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I found that the wrong coordinator can be set in case of client reconnect:
> {noformat}
> assert newCrd.topologyVersion().compareTo(curCrd.topologyVersion()) > 0;
> java.lang.AssertionError
> at
> org.apache.ignite.internal.processors.cache.mvcc.MvccProcessorImpl.onCoordinatorChanged(MvccProcessorImpl.java:541)
> at
> org.apache.ignite.internal.processors.cache.mvcc.MvccProcessorImpl.onLocalJoin(MvccProcessorImpl.java:416)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery0(GridDiscoveryManager.java:851)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.lambda$onDiscovery$0(GridDiscoveryManager.java:601)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryMessageNotifierWorker.body0(GridDiscoveryManager.java:2681)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryMessageNotifierWorker.body(GridDiscoveryManager.java:2719)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> I have attached reproducer in PR.
> The main reason is that coordinator can be changed from discovery event
> thread when the client already disconnect (disconnection processed in
> notifier thread and change coordinator on onDisconnected method).
> Coordinator can be changed in cases:
> 1. notifier disco thread: onDisconnected method
> 2. event disco thread: onDiscovery listener.
> and events can be processed with some delay and override coordinator that set
> in notifier thread.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11469) Support Automatic modules for ignite-rest-http: resolve package inference between Jetty & Tomcat
[
https://issues.apache.org/jira/browse/IGNITE-11469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16790537#comment-16790537
]
Ignite TC Bot commented on IGNITE-11469:
{panel:title=--> Run :: Basic Tests: No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *--> Run :: Basic Tests*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=3296401&buildTypeId=IgniteTests24Java8_RunBasicTests]
> Support Automatic modules for ignite-rest-http: resolve package inference
> between Jetty & Tomcat
>
>
> Key: IGNITE-11469
> URL: https://issues.apache.org/jira/browse/IGNITE-11469
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Dmitriy Pavlov
>Assignee: Dmitriy Pavlov
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> {noformat}
> error: the unnamed module reads package javax.servlet.http from both
> javax.servlet.api and tomcat.servlet.api
> error: the unnamed module reads package javax.servlet.descriptor from both
> javax.servlet.api and tomcat.servlet.api
> error: the unnamed module reads package javax.servlet.annotation from both
> javax.servlet.api and tomcat.servlet.api
> error: the unnamed module reads package javax.servlet from both
> javax.servlet.api and tomcat.servlet.api
> {noformat}
> Exclude of tomcat dependency solves the problem
> {code}
> compile(group: 'org.apache.ignite', name: 'ignite-rest-http', version:
> ignVer) {
> exclude group: 'org.apache.tomcat'
> // to remove "javax.servlet.http, javax.servlet.descriptor,
> javax.servlet.annotation, javax.servlet" package conflicts.
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11534) Partition loss policy is not handled properly for implicit single key transactions
Ivan Pavlukhin created IGNITE-11534:
---
Summary: Partition loss policy is not handled properly for
implicit single key transactions
Key: IGNITE-11534
URL: https://issues.apache.org/jira/browse/IGNITE-11534
Project: Ignite
Issue Type: Bug
Components: cache
Affects Versions: 2.7
Reporter: Ivan Pavlukhin
Assignee: Ivan Pavlukhin
Fix For: 2.8
There is a bug in handling partition loss policies for single put operations
over {{TRANSACTIONAL}} cache (implicit transaction). Key values are passed
improperly for validation.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11226) SQL: Remove GridQueryIndexing.prepareNativeStatement
[ https://issues.apache.org/jira/browse/IGNITE-11226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16790543#comment-16790543 ] Pavel Kuznetsov commented on IGNITE-11226: -- [~vozerov] Ready for the prelementary review! > SQL: Remove GridQueryIndexing.prepareNativeStatement > > > Key: IGNITE-11226 > URL: https://issues.apache.org/jira/browse/IGNITE-11226 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Vladimir Ozerov >Assignee: Pavel Kuznetsov >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > This method is the only leak of H2 internals to the outer code. Close > analysis of code reveals that the only reason we have it is *JDBC metadata*. > Need to create a method which will prepare metadata for a statement and > return it as a detached object. Most probably we already have all necessary > mechanics. This is more about refactoring. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11460) MVCC: Possible race on coordinator changing on client reconnection.
[
https://issues.apache.org/jira/browse/IGNITE-11460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16790530#comment-16790530
]
Andrew Mashenkov commented on IGNITE-11460:
---
[~NSAmelchev], got it.
Seems, the root of issue is that we process NODE_FAILED events after
CLIENT_DISCONNECT happens.
To resolve this, we should ignore all topology change events between
onDisconected() and next onLocalJoin(), that is what your fix do.
I've found kernalContext.clientDisconnected flag is set to 'true' in
onDisconnected() and is set to 'false' in onLocalJoin() methods.
I'd think we can use this flag and skip all topology change events in
onDicovery() method via simple check "if (ctx.clientDisconnected) return".
If any reordering between all those events are possible (e.g. due to event
processing from different threads) than it look like bug in discovery.
> MVCC: Possible race on coordinator changing on client reconnection.
> ---
>
> Key: IGNITE-11460
> URL: https://issues.apache.org/jira/browse/IGNITE-11460
> Project: Ignite
> Issue Type: Bug
>Reporter: Amelchev Nikita
>Assignee: Amelchev Nikita
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I found that the wrong coordinator can be set in case of client reconnect:
> {noformat}
> assert newCrd.topologyVersion().compareTo(curCrd.topologyVersion()) > 0;
> java.lang.AssertionError
> at
> org.apache.ignite.internal.processors.cache.mvcc.MvccProcessorImpl.onCoordinatorChanged(MvccProcessorImpl.java:541)
> at
> org.apache.ignite.internal.processors.cache.mvcc.MvccProcessorImpl.onLocalJoin(MvccProcessorImpl.java:416)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery0(GridDiscoveryManager.java:851)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.lambda$onDiscovery$0(GridDiscoveryManager.java:601)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryMessageNotifierWorker.body0(GridDiscoveryManager.java:2681)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryMessageNotifierWorker.body(GridDiscoveryManager.java:2719)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> I have attached reproducer in PR.
> The main reason is that coordinator can be changed from discovery event
> thread when the client already disconnect (disconnection processed in
> notifier thread and change coordinator on onDisconnected method).
> Coordinator can be changed in cases:
> 1. notifier disco thread: onDisconnected method
> 2. event disco thread: onDiscovery listener.
> and events can be processed with some delay and override coordinator that set
> in notifier thread.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-11460) MVCC: Possible race on coordinator changing on client reconnection.
[
https://issues.apache.org/jira/browse/IGNITE-11460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16790530#comment-16790530
]
Andrew Mashenkov edited comment on IGNITE-11460 at 3/12/19 1:15 PM:
[~NSAmelchev], got it.
Seems, the root of issue is that we process NODE_FAILED events after
CLIENT_DISCONNECT happens.
To resolve this, we should ignore all topology change events between
onDisconected() and next onLocalJoin(), that is what your fix do.
I've found kernalContext.clientDisconnected flag is set to 'true' in
onDisconnected() and is set to 'false' in onLocalJoin() methods.
I'd think we can use this flag and skip all topology change events in
onDicovery() method via simple check "if (ctx.clientDisconnected) return". This
fix works for me and makes your test passed.
If any reordering between all those events are possible (e.g. due to event
processing from different threads) than it look like bug in discovery.
was (Author: amashenkov):
[~NSAmelchev], got it.
Seems, the root of issue is that we process NODE_FAILED events after
CLIENT_DISCONNECT happens.
To resolve this, we should ignore all topology change events between
onDisconected() and next onLocalJoin(), that is what your fix do.
I've found kernalContext.clientDisconnected flag is set to 'true' in
onDisconnected() and is set to 'false' in onLocalJoin() methods.
I'd think we can use this flag and skip all topology change events in
onDicovery() method via simple check "if (ctx.clientDisconnected) return".
If any reordering between all those events are possible (e.g. due to event
processing from different threads) than it look like bug in discovery.
> MVCC: Possible race on coordinator changing on client reconnection.
> ---
>
> Key: IGNITE-11460
> URL: https://issues.apache.org/jira/browse/IGNITE-11460
> Project: Ignite
> Issue Type: Bug
>Reporter: Amelchev Nikita
>Assignee: Amelchev Nikita
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I found that the wrong coordinator can be set in case of client reconnect:
> {noformat}
> assert newCrd.topologyVersion().compareTo(curCrd.topologyVersion()) > 0;
> java.lang.AssertionError
> at
> org.apache.ignite.internal.processors.cache.mvcc.MvccProcessorImpl.onCoordinatorChanged(MvccProcessorImpl.java:541)
> at
> org.apache.ignite.internal.processors.cache.mvcc.MvccProcessorImpl.onLocalJoin(MvccProcessorImpl.java:416)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery0(GridDiscoveryManager.java:851)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.lambda$onDiscovery$0(GridDiscoveryManager.java:601)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryMessageNotifierWorker.body0(GridDiscoveryManager.java:2681)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryMessageNotifierWorker.body(GridDiscoveryManager.java:2719)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> I have attached reproducer in PR.
> The main reason is that coordinator can be changed from discovery event
> thread when the client already disconnect (disconnection processed in
> notifier thread and change coordinator on onDisconnected method).
> Coordinator can be changed in cases:
> 1. notifier disco thread: onDisconnected method
> 2. event disco thread: onDiscovery listener.
> and events can be processed with some delay and override coordinator that set
> in notifier thread.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Issue Comment Deleted] (IGNITE-11469) Support Automatic modules for ignite-rest-http: resolve package inference between Jetty & Tomcat
[
https://issues.apache.org/jira/browse/IGNITE-11469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Pavlov updated IGNITE-11469:
Comment: was deleted
(was: _)
> Support Automatic modules for ignite-rest-http: resolve package inference
> between Jetty & Tomcat
>
>
> Key: IGNITE-11469
> URL: https://issues.apache.org/jira/browse/IGNITE-11469
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Dmitriy Pavlov
>Assignee: Dmitriy Pavlov
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> {noformat}
> error: the unnamed module reads package javax.servlet.http from both
> javax.servlet.api and tomcat.servlet.api
> error: the unnamed module reads package javax.servlet.descriptor from both
> javax.servlet.api and tomcat.servlet.api
> error: the unnamed module reads package javax.servlet.annotation from both
> javax.servlet.api and tomcat.servlet.api
> error: the unnamed module reads package javax.servlet from both
> javax.servlet.api and tomcat.servlet.api
> {noformat}
> Exclude of tomcat dependency solves the problem
> {code}
> compile(group: 'org.apache.ignite', name: 'ignite-rest-http', version:
> ignVer) {
> exclude group: 'org.apache.tomcat'
> // to remove "javax.servlet.http, javax.servlet.descriptor,
> javax.servlet.annotation, javax.servlet" package conflicts.
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11469) Support Automatic modules for ignite-rest-http: resolve package inference between Jetty & Tomcat
[
https://issues.apache.org/jira/browse/IGNITE-11469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16790477#comment-16790477
]
Dmitriy Pavlov commented on IGNITE-11469:
-
This issue fix consists of 2 commits
-
https://github.com/apache/ignite/commit/526871860526bd674fced26813910904fda1be2b
- https://github.com/apache/ignite/pull/6256
> Support Automatic modules for ignite-rest-http: resolve package inference
> between Jetty & Tomcat
>
>
> Key: IGNITE-11469
> URL: https://issues.apache.org/jira/browse/IGNITE-11469
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Dmitriy Pavlov
>Assignee: Dmitriy Pavlov
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> {noformat}
> error: the unnamed module reads package javax.servlet.http from both
> javax.servlet.api and tomcat.servlet.api
> error: the unnamed module reads package javax.servlet.descriptor from both
> javax.servlet.api and tomcat.servlet.api
> error: the unnamed module reads package javax.servlet.annotation from both
> javax.servlet.api and tomcat.servlet.api
> error: the unnamed module reads package javax.servlet from both
> javax.servlet.api and tomcat.servlet.api
> {noformat}
> Exclude of tomcat dependency solves the problem
> {code}
> compile(group: 'org.apache.ignite', name: 'ignite-rest-http', version:
> ignVer) {
> exclude group: 'org.apache.tomcat'
> // to remove "javax.servlet.http, javax.servlet.descriptor,
> javax.servlet.annotation, javax.servlet" package conflicts.
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-11469) Support Automatic modules for ignite-rest-http: resolve package inference between Jetty & Tomcat
[
https://issues.apache.org/jira/browse/IGNITE-11469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16790473#comment-16790473
]
Dmitriy Pavlov edited comment on IGNITE-11469 at 3/12/19 12:12 PM:
---
_
was (Author: dpavlov):
This issue fix consists of 2 commits
-
https://github.com/apache/ignite/commit/526871860526bd674fced26813910904fda1be2b
-
> Support Automatic modules for ignite-rest-http: resolve package inference
> between Jetty & Tomcat
>
>
> Key: IGNITE-11469
> URL: https://issues.apache.org/jira/browse/IGNITE-11469
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Dmitriy Pavlov
>Assignee: Dmitriy Pavlov
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> {noformat}
> error: the unnamed module reads package javax.servlet.http from both
> javax.servlet.api and tomcat.servlet.api
> error: the unnamed module reads package javax.servlet.descriptor from both
> javax.servlet.api and tomcat.servlet.api
> error: the unnamed module reads package javax.servlet.annotation from both
> javax.servlet.api and tomcat.servlet.api
> error: the unnamed module reads package javax.servlet from both
> javax.servlet.api and tomcat.servlet.api
> {noformat}
> Exclude of tomcat dependency solves the problem
> {code}
> compile(group: 'org.apache.ignite', name: 'ignite-rest-http', version:
> ignVer) {
> exclude group: 'org.apache.tomcat'
> // to remove "javax.servlet.http, javax.servlet.descriptor,
> javax.servlet.annotation, javax.servlet" package conflicts.
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11469) Support Automatic modules for ignite-rest-http: resolve package inference between Jetty & Tomcat
[
https://issues.apache.org/jira/browse/IGNITE-11469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16790474#comment-16790474
]
Alex Volkov commented on IGNITE-11469:
--
Now build from master fails on start when rest is enabled with error:
{code:java}
Exception during start processors, node will be stopped and close connections
java.lang.NoClassDefFoundError: javax/servlet/ServletRequest
at
org.apache.ignite.internal.processors.rest.protocols.http.jetty.GridJettyRestProtocol.start(GridJettyRestProtocol.java:127)
at
org.apache.ignite.internal.processors.rest.GridRestProcessor.startProtocol(GridRestProcessor.java:1013)
at
org.apache.ignite.internal.processors.rest.GridRestProcessor.startHttpProtocol(GridRestProcessor.java:984)
at
org.apache.ignite.internal.processors.rest.GridRestProcessor.start(GridRestProcessor.java:541)
at
org.apache.ignite.internal.IgniteKernal.startProcessor(IgniteKernal.java:1759)
at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1035)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1992)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1683)
at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1109)
at
org.apache.ignite.internal.IgnitionEx.startConfigurations(IgnitionEx.java:1027)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:913)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:812)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:682)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:651)
at org.apache.ignite.Ignition.start(Ignition.java:346)
at
org.apache.ignite.startup.cmdline.CommandLineStartup.main(CommandLineStartup.java:300)
Caused by: java.lang.ClassNotFoundException: javax.servlet.ServletRequest
at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:349)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
... 16 more
{code}
on Java 8.
> Support Automatic modules for ignite-rest-http: resolve package inference
> between Jetty & Tomcat
>
>
> Key: IGNITE-11469
> URL: https://issues.apache.org/jira/browse/IGNITE-11469
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Dmitriy Pavlov
>Assignee: Dmitriy Pavlov
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {noformat}
> error: the unnamed module reads package javax.servlet.http from both
> javax.servlet.api and tomcat.servlet.api
> error: the unnamed module reads package javax.servlet.descriptor from both
> javax.servlet.api and tomcat.servlet.api
> error: the unnamed module reads package javax.servlet.annotation from both
> javax.servlet.api and tomcat.servlet.api
> error: the unnamed module reads package javax.servlet from both
> javax.servlet.api and tomcat.servlet.api
> {noformat}
> Exclude of tomcat dependency solves the problem
> {code}
> compile(group: 'org.apache.ignite', name: 'ignite-rest-http', version:
> ignVer) {
> exclude group: 'org.apache.tomcat'
> // to remove "javax.servlet.http, javax.servlet.descriptor,
> javax.servlet.annotation, javax.servlet" package conflicts.
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11460) MVCC: Possible race on coordinator changing on client reconnection.
[
https://issues.apache.org/jira/browse/IGNITE-11460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16790472#comment-16790472
]
Amelchev Nikita commented on IGNITE-11460:
--
[~amashenkov], In such case we can get a situation when the client already
joined to topology (will receive mvcc requests) but the current coordinator is
in a disconnected state until processed discovery event.
And possible another situation when the client already disconnected but the
coordinator wasn't disconnected until processed client disconnect discovery
event.
Also, it seems there is no event for local node join in the discovery event
thread.
With my changes coordinator will be set correctly on local join/on disconnected
and will not process unnecessary events that happen(will be processed) after
the client leave topology. When the client join topology again it will be set a
correct coordinator and events will be processed only after get a client
reconnect event.
> MVCC: Possible race on coordinator changing on client reconnection.
> ---
>
> Key: IGNITE-11460
> URL: https://issues.apache.org/jira/browse/IGNITE-11460
> Project: Ignite
> Issue Type: Bug
>Reporter: Amelchev Nikita
>Assignee: Amelchev Nikita
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I found that the wrong coordinator can be set in case of client reconnect:
> {noformat}
> assert newCrd.topologyVersion().compareTo(curCrd.topologyVersion()) > 0;
> java.lang.AssertionError
> at
> org.apache.ignite.internal.processors.cache.mvcc.MvccProcessorImpl.onCoordinatorChanged(MvccProcessorImpl.java:541)
> at
> org.apache.ignite.internal.processors.cache.mvcc.MvccProcessorImpl.onLocalJoin(MvccProcessorImpl.java:416)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery0(GridDiscoveryManager.java:851)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.lambda$onDiscovery$0(GridDiscoveryManager.java:601)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryMessageNotifierWorker.body0(GridDiscoveryManager.java:2681)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryMessageNotifierWorker.body(GridDiscoveryManager.java:2719)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> I have attached reproducer in PR.
> The main reason is that coordinator can be changed from discovery event
> thread when the client already disconnect (disconnection processed in
> notifier thread and change coordinator on onDisconnected method).
> Coordinator can be changed in cases:
> 1. notifier disco thread: onDisconnected method
> 2. event disco thread: onDiscovery listener.
> and events can be processed with some delay and override coordinator that set
> in notifier thread.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11469) Support Automatic modules for ignite-rest-http: resolve package inference between Jetty & Tomcat
[
https://issues.apache.org/jira/browse/IGNITE-11469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16790473#comment-16790473
]
Dmitriy Pavlov commented on IGNITE-11469:
-
This issue fix consists of 2 commits
-
https://github.com/apache/ignite/commit/526871860526bd674fced26813910904fda1be2b
-
> Support Automatic modules for ignite-rest-http: resolve package inference
> between Jetty & Tomcat
>
>
> Key: IGNITE-11469
> URL: https://issues.apache.org/jira/browse/IGNITE-11469
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Dmitriy Pavlov
>Assignee: Dmitriy Pavlov
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {noformat}
> error: the unnamed module reads package javax.servlet.http from both
> javax.servlet.api and tomcat.servlet.api
> error: the unnamed module reads package javax.servlet.descriptor from both
> javax.servlet.api and tomcat.servlet.api
> error: the unnamed module reads package javax.servlet.annotation from both
> javax.servlet.api and tomcat.servlet.api
> error: the unnamed module reads package javax.servlet from both
> javax.servlet.api and tomcat.servlet.api
> {noformat}
> Exclude of tomcat dependency solves the problem
> {code}
> compile(group: 'org.apache.ignite', name: 'ignite-rest-http', version:
> ignVer) {
> exclude group: 'org.apache.tomcat'
> // to remove "javax.servlet.http, javax.servlet.descriptor,
> javax.servlet.annotation, javax.servlet" package conflicts.
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Reopened] (IGNITE-11469) Support Automatic modules for ignite-rest-http: resolve package inference between Jetty & Tomcat
[
https://issues.apache.org/jira/browse/IGNITE-11469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Pavlov reopened IGNITE-11469:
-
> Support Automatic modules for ignite-rest-http: resolve package inference
> between Jetty & Tomcat
>
>
> Key: IGNITE-11469
> URL: https://issues.apache.org/jira/browse/IGNITE-11469
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Dmitriy Pavlov
>Assignee: Dmitriy Pavlov
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {noformat}
> error: the unnamed module reads package javax.servlet.http from both
> javax.servlet.api and tomcat.servlet.api
> error: the unnamed module reads package javax.servlet.descriptor from both
> javax.servlet.api and tomcat.servlet.api
> error: the unnamed module reads package javax.servlet.annotation from both
> javax.servlet.api and tomcat.servlet.api
> error: the unnamed module reads package javax.servlet from both
> javax.servlet.api and tomcat.servlet.api
> {noformat}
> Exclude of tomcat dependency solves the problem
> {code}
> compile(group: 'org.apache.ignite', name: 'ignite-rest-http', version:
> ignVer) {
> exclude group: 'org.apache.tomcat'
> // to remove "javax.servlet.http, javax.servlet.descriptor,
> javax.servlet.annotation, javax.servlet" package conflicts.
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11533) Improve memory usage reporting in the logs
Stanislav Lukyanov created IGNITE-11533:
---
Summary: Improve memory usage reporting in the logs
Key: IGNITE-11533
URL: https://issues.apache.org/jira/browse/IGNITE-11533
Project: Ignite
Issue Type: Improvement
Reporter: Stanislav Lukyanov
Currently node's memory usage is reported in the log like this
{code}
^-- PageMemory [pages=66407]
^-- Heap [used=303MB, free=91,6%, comm=849MB]
^-- Off-heap [used=260MB, free=62,73%, comm=580MB]
^-- sysMemPlc region [used=0MB, free=99,21%, comm=40MB]
^-- TxLog region [used=0MB, free=100%, comm=40MB]
^-- Default_Region region [used=260MB, free=47,97%, comm=500MB]
{code}
And it also used to report "Non heap" metrics which were removed in IGNITE-9305.
This has several issues
1. "PageMemory" line alone doesn't help to understand the Ignite off-heap
memory usage - page size is needed to calculated the used size, and maxSize of
the data regions are needed to calculate the amount of the memory left.
2. "Non heap" could actually be useful. The line used to show "free=-1%" in
most setups. This is because metaspace pool of the JVM is not limited by
default which makes the total size unlimited. In general, it would be good to
see distribution among the non-heap pools (metaspace, direct buffers) to be
able to tune JVM settings accordingly.
Let's do the following:
- Don't print "PageMemory" line - it's cryptic and adds little value to the
"Off-heap" section
- Bring "Non heap" back in some way
-- Don't print "free=-1%" - either print "N/A" or don't print "free" at all
-- Add a suggestion to limit metaspace (same as we do for direct memory) -
which will enable correct "free" calculation
-- Look into possibility of showing distinct metrics for direct memory and
metaspace, so that the user can tell which to tune
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9981) Web Console: We need to update the counters on the tables.
[ https://issues.apache.org/jira/browse/IGNITE-9981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Kalinin updated IGNITE-9981: -- Remaining Estimate: 12h Original Estimate: 12h > Web Console: We need to update the counters on the tables. > -- > > Key: IGNITE-9981 > URL: https://issues.apache.org/jira/browse/IGNITE-9981 > Project: Ignite > Issue Type: Improvement > Components: UI, wizards >Reporter: Vica Abramova >Assignee: Alexander Kalinin >Priority: Major > Attachments: Renew Table.png > > Original Estimate: 12h > Remaining Estimate: 12h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11530) SQL Index performance monitoring
[ https://issues.apache.org/jira/browse/IGNITE-11530?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Gerzhedovich updated IGNITE-11530: --- Description: We need to gather performance statistics for all types SQL indexes. It should be at least number of look up, scans, inline miss. Also need to investigate which statistics can be added here. After the ticket will be done we should expose it through JMX and SQL system view. was: We need to gather performance statistics for SQL indexes. Consider at least BTREE indexes, however may be we can also do it for all other types of indexes. It should be at least number of look up, scans, inline miss. Also need to investigate which statistics can be added here. After the ticket will be done we should expose it through JMX and SQL system view. > SQL Index performance monitoring > > > Key: IGNITE-11530 > URL: https://issues.apache.org/jira/browse/IGNITE-11530 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Yury Gerzhedovich >Priority: Major > Labels: iep-29 > Fix For: 2.8 > > > We need to gather performance statistics for all types SQL indexes. > It should be at least number of look up, scans, inline miss. > Also need to investigate which statistics can be added here. > > After the ticket will be done we should expose it through JMX and SQL system > view. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11521) Register listeners before joining the cluster
[
https://issues.apache.org/jira/browse/IGNITE-11521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16790439#comment-16790439
]
Ignite TC Bot commented on IGNITE-11521:
{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=3288739&buildTypeId=IgniteTests24Java8_RunAll]
> Register listeners before joining the cluster
> -
>
> Key: IGNITE-11521
> URL: https://issues.apache.org/jira/browse/IGNITE-11521
> Project: Ignite
> Issue Type: New Feature
>Reporter: Lukas Polacek
>Priority: Major
>
> The documentation says to register local listeners through
> "ignite.events().localListen(...)", however that can only be done once e.g.
> "ignite = Ignition.start(cfg)" has been called. At that point, the node has
> already joined the cluster, so we might have missed events in the meantime.
> See also the discussion [in
> apache-ignite-users|http://apache-ignite-users.70518.x6.nabble.com/Register-listeners-before-joining-the-cluster-td25944.html#none].
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-9520) Investigate fuzzy free lists
[ https://issues.apache.org/jira/browse/IGNITE-9520?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vitaliy Biryukov reassigned IGNITE-9520: Assignee: Vitaliy Biryukov > Investigate fuzzy free lists > > > Key: IGNITE-9520 > URL: https://issues.apache.org/jira/browse/IGNITE-9520 > Project: Ignite > Issue Type: Task >Reporter: Alexey Goncharuk >Assignee: Vitaliy Biryukov >Priority: Major > > We have several data structures (free list, reuse list) associated with each > partition. For these structures a major part of their state is maintained > on-heap and persisted during checkpoints. > This yields a lot of random disk accesses during checkpoints which > significantly increases checkpoint mark phase (done under checkpoint write > lock and essentially blocks all tx ops on the node). > Need to investigate if we can implement some sort of a data structure which > is updated lazily and may be out-of date, then we can update these data > structures outside of checkpoint mark phases. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11532) Performance trace of executed query
Yury Gerzhedovich created IGNITE-11532: -- Summary: Performance trace of executed query Key: IGNITE-11532 URL: https://issues.apache.org/jira/browse/IGNITE-11532 Project: Ignite Issue Type: Task Reporter: Yury Gerzhedovich Need to add ability to trace and view performance of execution of SQL query with splitting by sql fragments. Additional details will be added after more deep investigate what exists in products another DB vendors. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-10693) MVCC TX: Random server restart tests became failed
[ https://issues.apache.org/jira/browse/IGNITE-10693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Mashenkov reassigned IGNITE-10693: - Assignee: (was: Andrew Mashenkov) > MVCC TX: Random server restart tests became failed > -- > > Key: IGNITE-10693 > URL: https://issues.apache.org/jira/browse/IGNITE-10693 > Project: Ignite > Issue Type: Bug > Components: mvcc >Reporter: Igor Seliverstov >Priority: Major > Labels: failover, mvcc_stability > Fix For: 2.8 > > Time Spent: 20m > Remaining Estimate: 0h > > [one|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=7945125576049372508&branch=%3Cdefault%3E&tab=testDetails], > > [two|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=8412476034648229784&branch=%3Cdefault%3E&tab=testDetails], > > [three|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=254244004184327163&branch=%3Cdefault%3E&tab=testDetails], > all these tests became failed after IGNITE-9630 has been merged to master. > Seems there is an issue in partition calculating mechanism on unstable > topology. I suppose the algorithm uses partitions on nodes just become > primary while the partitions are in moving state. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10693) MVCC TX: Random server restart tests became failed
[ https://issues.apache.org/jira/browse/IGNITE-10693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16790425#comment-16790425 ] Andrew Mashenkov commented on IGNITE-10693: --- Looks like issues wasn't fixed as TC tests still fails sporadically after merge with IGNITE-10561. Possibly, mapping is not (the only) issue that causes test failures. I've fixed few collection usage issues and revert unrelated changes in tests in my PR. We have to verify mapping logic (correctness) and benchmark this changes (performance), then the PR can be merged if logic is correct and performance improved, otherwise the PR should be declined. > MVCC TX: Random server restart tests became failed > -- > > Key: IGNITE-10693 > URL: https://issues.apache.org/jira/browse/IGNITE-10693 > Project: Ignite > Issue Type: Bug > Components: mvcc >Reporter: Igor Seliverstov >Assignee: Andrew Mashenkov >Priority: Major > Labels: failover, mvcc_stability > Fix For: 2.8 > > Time Spent: 20m > Remaining Estimate: 0h > > [one|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=7945125576049372508&branch=%3Cdefault%3E&tab=testDetails], > > [two|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=8412476034648229784&branch=%3Cdefault%3E&tab=testDetails], > > [three|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=254244004184327163&branch=%3Cdefault%3E&tab=testDetails], > all these tests became failed after IGNITE-9630 has been merged to master. > Seems there is an issue in partition calculating mechanism on unstable > topology. I suppose the algorithm uses partitions on nodes just become > primary while the partitions are in moving state. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11524) Memory leak caused by executing a jdbc prepared statement
[ https://issues.apache.org/jira/browse/IGNITE-11524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-11524: - Priority: Blocker (was: Major) > Memory leak caused by executing a jdbc prepared statement > - > > Key: IGNITE-11524 > URL: https://issues.apache.org/jira/browse/IGNITE-11524 > Project: Ignite > Issue Type: Bug > Components: sql, thin client >Reporter: Pavel Vinokurov >Priority: Blocker > Fix For: 2.7 > > Attachments: PreparedStatementOOMReproducer.java > > > Executing a prepared statement multiple times lead to OOM. > VisualVM indicates that heap contains a lot of JdbcThinPreparedStatament > objects. > The reproducer is attached. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11524) Memory leak caused by executing a jdbc prepared statement
[ https://issues.apache.org/jira/browse/IGNITE-11524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-11524: - Fix Version/s: (was: 2.7) 2.8 > Memory leak caused by executing a jdbc prepared statement > - > > Key: IGNITE-11524 > URL: https://issues.apache.org/jira/browse/IGNITE-11524 > Project: Ignite > Issue Type: Bug > Components: sql, thin client >Reporter: Pavel Vinokurov >Priority: Blocker > Fix For: 2.8 > > Attachments: PreparedStatementOOMReproducer.java > > > Executing a prepared statement multiple times lead to OOM. > VisualVM indicates that heap contains a lot of JdbcThinPreparedStatament > objects. > The reproducer is attached. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11531) Merge concurrent registrations of the same binary type
Denis Mekhanikov created IGNITE-11531:
-
Summary: Merge concurrent registrations of the same binary type
Key: IGNITE-11531
URL: https://issues.apache.org/jira/browse/IGNITE-11531
Project: Ignite
Issue Type: Improvement
Components: binary
Reporter: Denis Mekhanikov
When a binary type is registered multiple times simultaneously, then a lot of
type versions are generated with the same schema. It leads to long binary type
registration especially on big topologies.
The following code sample demonstrates the problem:
{code:java}
public class LongRegistration {
public static void main(String[] args) throws InterruptedException {
Ignite ignite = Ignition.start(igniteConfig());
int threadsNum = 50;
ExecutorService exec = Executors.newFixedThreadPool(threadsNum);
CyclicBarrier barrier = new CyclicBarrier(threadsNum);
long startTime = System.currentTimeMillis();
// register(ignite);
for (int i = 0; i < threadsNum; i++)
exec.submit(new TypeRegistrator(ignite, barrier));
exec.shutdown();
exec.awaitTermination(Long.MAX_VALUE, TimeUnit.SECONDS);
System.out.println("Total registration time: " +
(System.currentTimeMillis() - startTime));
}
private static IgniteConfiguration igniteConfig() {
IgniteConfiguration igniteCfg = new IgniteConfiguration();
TcpDiscoveryVmIpFinder ipFinder = new TcpDiscoveryVmIpFinder();
ipFinder.setAddresses(Collections.singletonList("127.0.0.1:47500..47509"));
TcpDiscoverySpi discoverySpi = new TcpDiscoverySpi();
discoverySpi.setLocalAddress("127.0.0.1");
discoverySpi.setLocalPort(47500);
discoverySpi.setIpFinder(ipFinder);
igniteCfg.setDiscoverySpi(discoverySpi);
return igniteCfg;
}
private static void register(Ignite ignite) {
long startTime = System.currentTimeMillis();
IgniteBinary binary = ignite.binary();
BinaryObjectBuilder builder = binary.builder("TestType");
builder.setField("intField", 1);
builder.build();
System.out.println("Registration time: " + (System.currentTimeMillis()
- startTime));
}
private static class TypeRegistrator implements Runnable {
private Ignite ignite;
private CyclicBarrier cyclicBarrier;
TypeRegistrator(Ignite ignite, CyclicBarrier cyclicBarrier) {
this.ignite = ignite;
this.cyclicBarrier = cyclicBarrier;
}
@Override public void run() {
try {
cyclicBarrier.await();
register(ignite);
} catch (InterruptedException | BrokenBarrierException e) {
e.printStackTrace();
}
}
}
}
{code}
This code sample leads to registration of 50 versions of the same type. The
effect is more noticeable if a cluster contains a lot of nodes.
If you uncomment the call to {{register()}} method, then overall registration
becomes 10 times faster on topology of 5 nodes.
Registration of matching types should be merged to avoid long processing of
such cases.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11460) MVCC: Possible race on coordinator changing on client reconnection.
[
https://issues.apache.org/jira/browse/IGNITE-11460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16790415#comment-16790415
]
Andrew Mashenkov commented on IGNITE-11460:
---
[~NSAmelchev], Thanks for clarification.
I've found a place where Ignite handle {{onDisconnected}}, {{onLocalJoin
}}events in separate thread.
You are right, serializability is lost here and method semantic looks broken or
methods are not documented well.
{{}}What if we remove these handlers from MvccProcessor and move all their
logic into onDiscovery method?
> MVCC: Possible race on coordinator changing on client reconnection.
> ---
>
> Key: IGNITE-11460
> URL: https://issues.apache.org/jira/browse/IGNITE-11460
> Project: Ignite
> Issue Type: Bug
>Reporter: Amelchev Nikita
>Assignee: Amelchev Nikita
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I found that the wrong coordinator can be set in case of client reconnect:
> {noformat}
> assert newCrd.topologyVersion().compareTo(curCrd.topologyVersion()) > 0;
> java.lang.AssertionError
> at
> org.apache.ignite.internal.processors.cache.mvcc.MvccProcessorImpl.onCoordinatorChanged(MvccProcessorImpl.java:541)
> at
> org.apache.ignite.internal.processors.cache.mvcc.MvccProcessorImpl.onLocalJoin(MvccProcessorImpl.java:416)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery0(GridDiscoveryManager.java:851)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.lambda$onDiscovery$0(GridDiscoveryManager.java:601)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryMessageNotifierWorker.body0(GridDiscoveryManager.java:2681)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryMessageNotifierWorker.body(GridDiscoveryManager.java:2719)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> I have attached reproducer in PR.
> The main reason is that coordinator can be changed from discovery event
> thread when the client already disconnect (disconnection processed in
> notifier thread and change coordinator on onDisconnected method).
> Coordinator can be changed in cases:
> 1. notifier disco thread: onDisconnected method
> 2. event disco thread: onDiscovery listener.
> and events can be processed with some delay and override coordinator that set
> in notifier thread.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11435) SQL: Create a view with query history
[ https://issues.apache.org/jira/browse/IGNITE-11435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Gerzhedovich updated IGNITE-11435: --- Description: Need to expose Query History view - LOCAL_SQL_QUERY_HISTORY List of columns: SCHEMA_NAME - name of schema QUERY - query text LOCAL - flag of local query CALLS - number of execution of the query FAILURES - number of failures for the query DURATION_MIN - minimum duration of execution DURATION_MAX - maximum duration of execution LAST_QUERY_START - time of the last start of execution see QueryHistoryMetrics class. was: Need to expose Query History view - LOCAL_SQL_QUERY_HISTORY List of columns: SCHEMA_NAME QUERY LOCAL CALLS FAILURES DURATION_MIN DURATION_MAX LAST_QUERY_START see QueryHistoryMetrics class. > SQL: Create a view with query history > - > > Key: IGNITE-11435 > URL: https://issues.apache.org/jira/browse/IGNITE-11435 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Yury Gerzhedovich >Assignee: Yury Gerzhedovich >Priority: Major > Labels: iep-29 > Fix For: 1.8 > > > Need to expose Query History view - LOCAL_SQL_QUERY_HISTORY > List of columns: > SCHEMA_NAME - name of schema > QUERY - query text > LOCAL - flag of local query > CALLS - number of execution of the query > FAILURES - number of failures for the query > DURATION_MIN - minimum duration of execution > DURATION_MAX - maximum duration of execution > LAST_QUERY_START - time of the last start of execution > > see QueryHistoryMetrics class. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11435) SQL: Create a view with query history
[ https://issues.apache.org/jira/browse/IGNITE-11435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Gerzhedovich updated IGNITE-11435: --- Description: Need to expose Query History view - LOCAL_SQL_QUERY_HISTORY List of columns: SCHEMA_NAME QUERY LOCAL CALLS FAILURES DURATION_MIN DURATION_MAX LAST_QUERY_START see QueryHistoryMetrics class. was: Need to expose Query History view - LOCAL_SQL_QUERY_HISTORY see QueryHistoryMetrics class. > SQL: Create a view with query history > - > > Key: IGNITE-11435 > URL: https://issues.apache.org/jira/browse/IGNITE-11435 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Yury Gerzhedovich >Assignee: Yury Gerzhedovich >Priority: Major > Labels: iep-29 > Fix For: 1.8 > > > Need to expose Query History view - LOCAL_SQL_QUERY_HISTORY > List of columns: > SCHEMA_NAME > QUERY > LOCAL > CALLS > FAILURES > DURATION_MIN > DURATION_MAX > LAST_QUERY_START > > see QueryHistoryMetrics class. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11530) SQL Index performance monitoring
Yury Gerzhedovich created IGNITE-11530: -- Summary: SQL Index performance monitoring Key: IGNITE-11530 URL: https://issues.apache.org/jira/browse/IGNITE-11530 Project: Ignite Issue Type: Task Components: sql Reporter: Yury Gerzhedovich Fix For: 2.8 We need to gather performance statistics for SQL indexes. Consider at least BTREE indexes, however may be we can also do it for all other types of indexes. It should be at least number of look up, scans, inline miss. Also need to investigate which statistics can be added here. After the ticket will be done we should expose it through JMX and SQL system view. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-11451) SQL system view for IO indexes statistics
[ https://issues.apache.org/jira/browse/IGNITE-11451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Gerzhedovich reassigned IGNITE-11451: -- Assignee: Yury Gerzhedovich > SQL system view for IO indexes statistics > - > > Key: IGNITE-11451 > URL: https://issues.apache.org/jira/browse/IGNITE-11451 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Yury Gerzhedovich >Assignee: Yury Gerzhedovich >Priority: Major > Labels: iep-29 > Fix For: 1.8 > > > Need to expose system SQL views to be able view IO statistics for SQL indexes. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11525) SQL: Deprecate SqlQuery for .NET platform
[ https://issues.apache.org/jira/browse/IGNITE-11525?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Taras Ledkov updated IGNITE-11525: -- Description: This API is very limited comparing to SqlFieldsQuery. Let's deprecate it with proper links to SqlFieldsQuery. This should be not only deprecation on public API, but removal from examples as well. Also please remove hidden columns _key, _val from examples. Parent ticket: IGNITE-11334 Ticket for documentation: IGNITE-11370 was: This API is very limited comparing to SqlFieldsQuery. Let's deprecate it with proper links to SqlFieldsQuery. This should be not only deprecation on public API, but removal from examples as well. Parent ticket: IGNITE-11334 Ticket for documentation: IGNITE-11370 > SQL: Deprecate SqlQuery for .NET platform > - > > Key: IGNITE-11525 > URL: https://issues.apache.org/jira/browse/IGNITE-11525 > Project: Ignite > Issue Type: Task > Components: platforms >Reporter: Taras Ledkov >Priority: Major > > This API is very limited comparing to SqlFieldsQuery. Let's deprecate it with > proper links to SqlFieldsQuery. This should be not only deprecation on public > API, but removal from examples as well. > Also please remove hidden columns _key, _val from examples. > Parent ticket: IGNITE-11334 > Ticket for documentation: IGNITE-11370 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10104) MVCC TX: client SFU doesn't work on replicated caches
[
https://issues.apache.org/jira/browse/IGNITE-10104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16790372#comment-16790372
]
Roman Kondakov commented on IGNITE-10104:
-
[~amashenkov], regarding your comments:
# Done.
# Added explanation to javadoc.
# May be you are right about nested select. But since the nested selects are
not supported by "SELECT FOR UPDATE" statements, it is not an issue now,
Branch is merged with the latest master. Tests look good. Patch is ready for
review.
> MVCC TX: client SFU doesn't work on replicated caches
> -
>
> Key: IGNITE-10104
> URL: https://issues.apache.org/jira/browse/IGNITE-10104
> Project: Ignite
> Issue Type: Bug
> Components: mvcc, sql
>Reporter: Igor Seliverstov
>Assignee: Roman Kondakov
>Priority: Major
> Labels: transactions
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When select for update executes from client node the execution is sent to
> random owning node. On that node dht enlist operation is started what causes
> an assertion error because dht enlist operation implies that the node is
> primary for all processed keys.
> see
> {{CacheMvccReplicatedBackupsTest.testBackupsCoherenceWithLargeOperations}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8376) Add cluster (de)activation events
[
https://issues.apache.org/jira/browse/IGNITE-8376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16790366#comment-16790366
]
Ignite TC Bot commented on IGNITE-8376:
---
{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=3288856&buildTypeId=IgniteTests24Java8_RunAll]
> Add cluster (de)activation events
> -
>
> Key: IGNITE-8376
> URL: https://issues.apache.org/jira/browse/IGNITE-8376
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexey Goncharuk
>Assignee: Igor Belyakov
>Priority: Major
> Labels: newbie
> Fix For: 2.8
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Currently, we do not have any way to detect that a cluster got activated,
> which results in busy-loops polling {{cluster().active()}}.
> I suggest to add new events, {{EVT_CLUSTER_ACTIVATED}},
> {{EVT_CLUSTER_DEACTIVATED}}, {{EVT_CLUSTER_ACTIVATION_FAILED}} which will be
> fired when corresponding steps are completed. The event should contain, if
> possible, information about the activation source (public API or
> auto-activation), topology version on which activation was performed. The
> fail event should contain information about the cause of the failure. If
> needed, a new class for this event should be introduced.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-11035) Web console: Implemement improvements for query page controller.
[
https://issues.apache.org/jira/browse/IGNITE-11035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vasiliy Sisko reassigned IGNITE-11035:
--
Assignee: Andrey Novikov (was: Vasiliy Sisko)
> Web console: Implemement improvements for query page controller.
>
>
> Key: IGNITE-11035
> URL: https://issues.apache.org/jira/browse/IGNITE-11035
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vasiliy Sisko
>Assignee: Andrey Novikov
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 5h 35m
> Remaining Estimate: 0h
>
> # Implement processing of query result task without one level recursion.
> # Explicit serialization to JSON of Paragraph object. Possible
> {{Paragraph.prototype.toJSON should be implemented.}}
> # {{Try to use RXJS operator chain instead of direct usage of subscription
> object.}}
> # {{On query cancel task unlock UI in Promise.prototype.finally.}}
> # {{Check initialization of queryId and resultNodeId on execute of refresh
> in auto refresh mode.}}
> # {{Some paragraph manipulation methods should be moved into Paragraph
> class: _initQueryResult}}{{{color:#00}_, _showLoading._
> {color}}}{{{color:#00}Check other methods with paragraph as
> argument.{color}}}
> # {{{color:#00}Check clearing of data in _initQueryResult method.
> {color}}}{{{color:#00}Try to not use direct calling of grid
> API{color}}}{{{color:#00}. Possible we should show
> “{color}}}{{{color:#00}Query execution{color}}}{{{color:#00}” stub
> {color}}}{{{color:#00}instead.{color}}}
> # {{{color:#00}Remove “beforeunload” listener on leave of Queries
> page.{color}}}
> # {{{color:#00}Possible we should cancel queries when client session is
> over.{color}}}
> # {{{color:#00}Add docs for return values of queries task in agent
> manager. F.e:{color}}}
> {code:java}
> /*
> @returns {Promise}
> */{code}
> # Confirm on leaving of Queries page when running queries exist:
> {code:java}
> You have running queries. Are you sure you want to cancel them?
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10104) MVCC TX: client SFU doesn't work on replicated caches
[
https://issues.apache.org/jira/browse/IGNITE-10104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16790367#comment-16790367
]
Ignite TC Bot commented on IGNITE-10104:
{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=3290813&buildTypeId=IgniteTests24Java8_RunAll]
> MVCC TX: client SFU doesn't work on replicated caches
> -
>
> Key: IGNITE-10104
> URL: https://issues.apache.org/jira/browse/IGNITE-10104
> Project: Ignite
> Issue Type: Bug
> Components: mvcc, sql
>Reporter: Igor Seliverstov
>Assignee: Roman Kondakov
>Priority: Major
> Labels: transactions
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When select for update executes from client node the execution is sent to
> random owning node. On that node dht enlist operation is started what causes
> an assertion error because dht enlist operation implies that the node is
> primary for all processed keys.
> see
> {{CacheMvccReplicatedBackupsTest.testBackupsCoherenceWithLargeOperations}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10768) MVCC: CacheMvccBasicContinuousQueryTest.testUpdateCountersGapClosedSimplePartitioned may hang
[
https://issues.apache.org/jira/browse/IGNITE-10768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16790365#comment-16790365
]
Roman Kondakov commented on IGNITE-10768:
-
[~amashenkov], test looks good on TC:
[https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=4342993177608979203&tab=testDetails&branch_IgniteTests24Java8=pull%2F5859%2Fhead|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=4342993177608979203&tab=testDetails&branch_IgniteTests24Java8=pull%2F5859%2Fhead]
> 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_stability
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> 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] [Commented] (IGNITE-11509) Remove DistributedBaselineConfiguration and replace to methods on IgniteCluster
[
https://issues.apache.org/jira/browse/IGNITE-11509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16790342#comment-16790342
]
Alexey Goncharuk commented on IGNITE-11509:
---
[~DmitriyGovorukhin] Looks good to me.
> Remove DistributedBaselineConfiguration and replace to methods on
> IgniteCluster
> ---
>
> Key: IGNITE-11509
> URL: https://issues.apache.org/jira/browse/IGNITE-11509
> Project: Ignite
> Issue Type: Bug
>Reporter: Dmitriy Govorukhin
>Assignee: Dmitriy Govorukhin
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The new methods on the IgniteCluster for manage baseline auto-adjust options.
> {code}
> /**
> * @return Value of manual baseline control or auto adjusting baseline.
> {@code True} If cluster in auto-adjust.
> * {@code False} If cluster in manuale.
> */
> public boolean isBaselineAutoAdjustEnabled();
> /**
> * @param baselineAutoAdjustEnabled Value of manual baseline control or
> auto adjusting baseline. {@code True} If
> * cluster in auto-adjust. {@code False} If cluster in manuale.
> * @throws IgniteException If operation failed.
> */
> public void baselineAutoAdjustEnabled(boolean baselineAutoAdjustEnabled)
> throws IgniteException;
> /**
> * @return Value of time which we would wait before the actual topology
> change since last server topology change
> * (node join/left/fail).
> * @throws IgniteException If operation failed.
> */
> public long baselineAutoAdjustTimeout();
> /**
> * @param baselineAutoAdjustTimeout Value of time which we would wait
> before the actual topology change since last
> * server topology change (node join/left/fail).
> * @throws IgniteException If failed.
> */
> public void baselineAutoAdjustTimeout(long baselineAutoAdjustTimeout)
> throws IgniteException;
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11526) SQL: Deprecate SqlQuery for c++ platform
Taras Ledkov created IGNITE-11526: - Summary: SQL: Deprecate SqlQuery for c++ platform Key: IGNITE-11526 URL: https://issues.apache.org/jira/browse/IGNITE-11526 Project: Ignite Issue Type: Task Components: platforms Reporter: Taras Ledkov Fix For: 2.8 This API is very limited comparing to SqlFieldsQuery. Let's deprecate it with proper links to SqlFieldsQuery. This should be not only deprecation on public API, but removal from examples as well. Parent ticket: IGNITE-11334 Ticket for documentation: IGNITE-11370 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10078) Node failure during concurrent partition updates may cause partition desync between primary and backup.
[
https://issues.apache.org/jira/browse/IGNITE-10078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16790325#comment-16790325
]
Ignite TC Bot commented on IGNITE-10078:
{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=3282000&buildTypeId=IgniteTests24Java8_RunAll]
> Node failure during concurrent partition updates may cause partition desync
> between primary and backup.
> ---
>
> Key: IGNITE-10078
> URL: https://issues.apache.org/jira/browse/IGNITE-10078
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexei Scherbakov
>Assignee: Alexei Scherbakov
>Priority: Major
> Fix For: 2.8
>
>
> This is possible if some updates are not written to WAL before node failure.
> They will be not applied by rebalancing due to same partition counters in
> certain scenario:
> 1. Start grid with 3 nodes, 2 backups.
> 2. Preload some data to partition P.
> 3. Start two concurrent transactions writing single key to the same partition
> P, keys are different
> {noformat}
> try(Transaction tx = client.transactions().txStart(PESSIMISTIC,
> REPEATABLE_READ, 0, 1)) {
> client.cache(DEFAULT_CACHE_NAME).put(k, v);
> tx.commit();
> }
> {noformat}
> 4. Order updates on backup in the way such update with max partition counter
> is written to WAL and update with lesser partition counter failed due to
> triggering of FH before it's added to WAL
> 5. Return failed node to grid, observe no rebalancing due to same partition
> counters.
> Possible solution: detect gaps in update counters on recovery and force
> rebalance from a node without gaps if detected.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11529) SQL: Deprecate SqlQuery for nodejs platform
Taras Ledkov created IGNITE-11529: - Summary: SQL: Deprecate SqlQuery for nodejs platform Key: IGNITE-11529 URL: https://issues.apache.org/jira/browse/IGNITE-11529 Project: Ignite Issue Type: Task Components: platforms Affects Versions: 2.7 Reporter: Taras Ledkov Fix For: 2.8 This API is very limited comparing to SqlFieldsQuery. Let's deprecate it with proper links to SqlFieldsQuery. This should be not only deprecation on public API, but removal from examples as well. Parent ticket: IGNITE-11334 Ticket for documentation: IGNITE-11370 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11528) SQL: Deprecate SqlQuery for python platform
Taras Ledkov created IGNITE-11528: - Summary: SQL: Deprecate SqlQuery for python platform Key: IGNITE-11528 URL: https://issues.apache.org/jira/browse/IGNITE-11528 Project: Ignite Issue Type: Task Components: platforms Affects Versions: 2.7 Reporter: Taras Ledkov Fix For: 2.8 This API is very limited comparing to SqlFieldsQuery. Let's deprecate it with proper links to SqlFieldsQuery. This should be not only deprecation on public API, but removal from examples as well. Parent ticket: IGNITE-11334 Ticket for documentation: IGNITE-11370 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11527) SQL: Deprecate SqlQuery for php platform
[ https://issues.apache.org/jira/browse/IGNITE-11527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Taras Ledkov updated IGNITE-11527: -- Affects Version/s: 2.7 > SQL: Deprecate SqlQuery for php platform > > > Key: IGNITE-11527 > URL: https://issues.apache.org/jira/browse/IGNITE-11527 > Project: Ignite > Issue Type: Task > Components: platforms >Affects Versions: 2.7 >Reporter: Taras Ledkov >Priority: Major > > This API is very limited comparing to SqlFieldsQuery. Let's deprecate it with > proper links to SqlFieldsQuery. This should be not only deprecation on public > API, but removal from examples as well. > Parent ticket: IGNITE-11334 > Ticket for documentation: IGNITE-11370 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11527) SQL: Deprecate SqlQuery for php platform
[ https://issues.apache.org/jira/browse/IGNITE-11527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Taras Ledkov updated IGNITE-11527: -- Fix Version/s: 2.8 > SQL: Deprecate SqlQuery for php platform > > > Key: IGNITE-11527 > URL: https://issues.apache.org/jira/browse/IGNITE-11527 > Project: Ignite > Issue Type: Task > Components: platforms >Affects Versions: 2.7 >Reporter: Taras Ledkov >Priority: Major > Fix For: 2.8 > > > This API is very limited comparing to SqlFieldsQuery. Let's deprecate it with > proper links to SqlFieldsQuery. This should be not only deprecation on public > API, but removal from examples as well. > Parent ticket: IGNITE-11334 > Ticket for documentation: IGNITE-11370 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11526) SQL: Deprecate SqlQuery for c++ platform
[ https://issues.apache.org/jira/browse/IGNITE-11526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Taras Ledkov updated IGNITE-11526: -- Affects Version/s: 2.7 > SQL: Deprecate SqlQuery for c++ platform > > > Key: IGNITE-11526 > URL: https://issues.apache.org/jira/browse/IGNITE-11526 > Project: Ignite > Issue Type: Task > Components: platforms >Affects Versions: 2.7 >Reporter: Taras Ledkov >Priority: Major > Fix For: 2.8 > > > This API is very limited comparing to SqlFieldsQuery. Let's deprecate it with > proper links to SqlFieldsQuery. This should be not only deprecation on public > API, but removal from examples as well. > Parent ticket: IGNITE-11334 > Ticket for documentation: IGNITE-11370 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11527) SQL: Deprecate SqlQuery for php platform
Taras Ledkov created IGNITE-11527: - Summary: SQL: Deprecate SqlQuery for php platform Key: IGNITE-11527 URL: https://issues.apache.org/jira/browse/IGNITE-11527 Project: Ignite Issue Type: Task Components: platforms Reporter: Taras Ledkov This API is very limited comparing to SqlFieldsQuery. Let's deprecate it with proper links to SqlFieldsQuery. This should be not only deprecation on public API, but removal from examples as well. Parent ticket: IGNITE-11334 Ticket for documentation: IGNITE-11370 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11526) SQL: Deprecate SqlQuery for c++ platform
[ https://issues.apache.org/jira/browse/IGNITE-11526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Taras Ledkov updated IGNITE-11526: -- Ignite Flags: (was: Docs Required) > SQL: Deprecate SqlQuery for c++ platform > > > Key: IGNITE-11526 > URL: https://issues.apache.org/jira/browse/IGNITE-11526 > Project: Ignite > Issue Type: Task > Components: platforms >Reporter: Taras Ledkov >Priority: Major > Fix For: 2.8 > > > This API is very limited comparing to SqlFieldsQuery. Let's deprecate it with > proper links to SqlFieldsQuery. This should be not only deprecation on public > API, but removal from examples as well. > Parent ticket: IGNITE-11334 > Ticket for documentation: IGNITE-11370 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11524) Memory leak caused by executing a jdbc prepared statement
[ https://issues.apache.org/jira/browse/IGNITE-11524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Pudov updated IGNITE-11524: - Summary: Memory leak caused by executing a jdbc prepared statement (was: Memory leak caused by executing an jdbc prepared statement) > Memory leak caused by executing a jdbc prepared statement > - > > Key: IGNITE-11524 > URL: https://issues.apache.org/jira/browse/IGNITE-11524 > Project: Ignite > Issue Type: Bug > Components: sql, thin client >Reporter: Pavel Vinokurov >Priority: Major > Fix For: 2.7 > > Attachments: PreparedStatementOOMReproducer.java > > > Executing a prepared statement multiple times lead to OOM. > VisualVM indicates that heap contains a lot of JdbcThinPreparedStatament > objects. > The reproducer is attached. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11370) Doc: remove SqlQuery documentation
[ https://issues.apache.org/jira/browse/IGNITE-11370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Taras Ledkov updated IGNITE-11370: -- Description: Please remove [SqlQuery section|https://apacheignite-sql.readme.io/docs/java-sql-api#section-sqlquery] from documentation. (was: Please remove [SqlQuery section|https://apacheignite-sql.readme.io/docs/java-sql-api#section-sqlquery} from documentation.) > Doc: remove SqlQuery documentation > -- > > Key: IGNITE-11370 > URL: https://issues.apache.org/jira/browse/IGNITE-11370 > Project: Ignite > Issue Type: Task > Components: documentation >Affects Versions: 2.7 >Reporter: Taras Ledkov >Assignee: Artem Budnikov >Priority: Major > Fix For: 2.8 > > > Please remove [SqlQuery > section|https://apacheignite-sql.readme.io/docs/java-sql-api#section-sqlquery] > from documentation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11525) SQL: Deprecate SqlQuery for .NET platform
Taras Ledkov created IGNITE-11525: - Summary: SQL: Deprecate SqlQuery for .NET platform Key: IGNITE-11525 URL: https://issues.apache.org/jira/browse/IGNITE-11525 Project: Ignite Issue Type: Task Components: platforms Reporter: Taras Ledkov This API is very limited comparing to SqlFieldsQuery. Let's deprecate it with proper links to SqlFieldsQuery. This should be not only deprecation on public API, but removal from examples as well. Parent ticket: IGNITE-11334 Ticket for documentation: IGNITE-11370 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11521) Register listeners before joining the cluster
[
https://issues.apache.org/jira/browse/IGNITE-11521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16790295#comment-16790295
]
Ignite TC Bot commented on IGNITE-11521:
{panel:title=--> Run :: All: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Platform .NET{color} [[tests
6|https://ci.ignite.apache.org/viewLog.html?buildId=3288709]]
* exe: LifecycleTest.TestWithoutBeans - 0,0% fails in last 332 master runs.
* exe: LifecycleTest.TestWithBeans - 0,0% fails in last 332 master runs.
{color:#d04437}MVCC PDS 4{color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=3288737]]
* IgnitePdsPageEvictionDuringPartitionClearTest.testPageEvictionOnNodeStart
(last started)
{color:#d04437}Platform C++ (Win x64 | Release){color} [[tests 1
BuildFailureOnMessage
|https://ci.ignite.apache.org/viewLog.html?buildId=3288664]]
* IgniteOdbcTest: SslQueriesTestSuite: TestConnectionSslSuccess - 0,9% fails in
last 422 master runs.
{panel}
[TeamCity *--> Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=3288739&buildTypeId=IgniteTests24Java8_RunAll]
> Register listeners before joining the cluster
> -
>
> Key: IGNITE-11521
> URL: https://issues.apache.org/jira/browse/IGNITE-11521
> Project: Ignite
> Issue Type: New Feature
>Reporter: Lukas Polacek
>Priority: Major
>
> The documentation says to register local listeners through
> "ignite.events().localListen(...)", however that can only be done once e.g.
> "ignite = Ignition.start(cfg)" has been called. At that point, the node has
> already joined the cluster, so we might have missed events in the meantime.
> See also the discussion [in
> apache-ignite-users|http://apache-ignite-users.70518.x6.nabble.com/Register-listeners-before-joining-the-cluster-td25944.html#none].
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11524) Memory leak caused by executing an jdbc prepared statement
Pavel Vinokurov created IGNITE-11524: Summary: Memory leak caused by executing an jdbc prepared statement Key: IGNITE-11524 URL: https://issues.apache.org/jira/browse/IGNITE-11524 Project: Ignite Issue Type: Bug Components: sql, thin client Reporter: Pavel Vinokurov Fix For: 2.7 Attachments: PreparedStatementOOMReproducer.java Executing a prepared statement multiple times lead to OOM. VisualVM indicates that heap contains a lot of JdbcThinPreparedStatament objects. The reproducer is attached. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
