[jira] [Assigned] (IGNITE-10448) MVCC: NPE on data page eviction.
[
https://issues.apache.org/jira/browse/IGNITE-10448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Seliverstov reassigned IGNITE-10448:
-
Assignee: Roman Kondakov
> MVCC: NPE on data page eviction.
>
>
> Key: IGNITE-10448
> URL: https://issues.apache.org/jira/browse/IGNITE-10448
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Reporter: Roman Kondakov
>Assignee: Roman Kondakov
>Priority: Major
>
> NPE occurred during page eviction process.
> Reproducer: {{PageEvictionMultinodeMixedRegionsTest}}.
> StackTrace:
>
> {noformat}
> javax.cache.CacheException: class
> org.apache.ignite.transactions.TransactionRollbackException: Transaction has
> been rolled back: 83e7f9a5761--093b-7d30--0005
> at
> org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1337)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.cacheException(IgniteCacheProxyImpl.java:1756)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.put(IgniteCacheProxyImpl.java:1108)
> at
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.put(GatewayProtectedCacheProxy.java:820)
> at
> org.apache.ignite.internal.processors.cache.eviction.paged.PageEvictionMultinodeAbstractTest.createCacheAndTestEvcition(PageEvictionMultinodeAbstractTest.java:101)
> at
> org.apache.ignite.internal.processors.cache.eviction.paged.PageEvictionMultinodeAbstractTest.testPageEviction(PageEvictionMultinodeAbstractTest.java:81)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.access$001(GridAbstractTest.java:150)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$6.evaluate(GridAbstractTest.java:2104)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$7.run(GridAbstractTest.java:2119)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: class org.apache.ignite.transactions.TransactionRollbackException:
> Transaction has been rolled back:
> 83e7f9a5761--093b-7d30--0005
> at
> org.apache.ignite.internal.util.IgniteUtils$11.apply(IgniteUtils.java:923)
> at
> org.apache.ignite.internal.util.IgniteUtils$11.apply(IgniteUtils.java:921)
> ... 15 more
> Caused by: class
> org.apache.ignite.internal.transactions.IgniteTxRollbackCheckedException:
> Transaction has been rolled back:
> 83e7f9a5761--093b-7d30--0005
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.syncOp(GridCacheAdapter.java:4299)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.put0(GridCacheAdapter.java:2520)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2501)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2478)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.put(IgniteCacheProxyImpl.java:1105)
> ... 12 more
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to update
> backup node: [localNodeId=0d817370-17fe-46f1-85ef-ea74b6f1,
> remoteNodeId=ebab34f3-abbc-47e9-90fa-a48a8260]
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxAbstractEnlistFuture.onResult(GridDhtTxAbstractEnlistFuture.java:1012)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter.processDhtTxQueryEnlistResponse(GridDhtTransactionalCacheAdapter.java:2340)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter.access$1200(GridDhtTransactionalCacheAdapter.java:112)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter$18.apply(GridDhtTransactionalCacheAdapter.java:257)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter$18.apply(GridDhtTransactionalCacheAdapter.java:255)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1059)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:584)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(Grid
[jira] [Created] (IGNITE-10693) MVCC TX: Random server restart tests became failed
Igor Seliverstov created IGNITE-10693: - Summary: 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, sql Reporter: Igor Seliverstov Fix For: 2.8 [one|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=254244004184327163&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-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 ] Igor Seliverstov updated IGNITE-10693: -- Description: [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. was: [one|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=254244004184327163&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. > 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, sql >Reporter: Igor Seliverstov >Priority: Major > Fix For: 2.8 > > > [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-9426) IgniteAtomicSequence benchmarks
[ https://issues.apache.org/jira/browse/IGNITE-9426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16610704#comment-16610704 ] Igor Seliverstov commented on IGNITE-9426: -- [~DmitriyGovorukhin], at now looks way better. I'm OK with the changes. > IgniteAtomicSequence benchmarks > --- > > Key: IGNITE-9426 > URL: https://issues.apache.org/jira/browse/IGNITE-9426 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.6 >Reporter: Dmitriy Govorukhin >Assignee: Dmitriy Govorukhin >Priority: Major > Fix For: 2.7 > > > Need to create JMH and Yardstick benchmarks for the atomic sequence in order > to be able to measure performance improvements. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-9749) MVCC: Assertion error in JdbcThinTransactionsServerAutoCommitComplexSelfTest leading to JDBC MVCC suite hang
[
https://issues.apache.org/jira/browse/IGNITE-9749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Seliverstov reassigned IGNITE-9749:
Assignee: Igor Seliverstov
> MVCC: Assertion error in JdbcThinTransactionsServerAutoCommitComplexSelfTest
> leading to JDBC MVCC suite hang
>
>
> Key: IGNITE-9749
> URL: https://issues.apache.org/jira/browse/IGNITE-9749
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Reporter: Alexey Goncharuk
>Assignee: Igor Seliverstov
>Priority: Critical
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.7
>
>
> The following assertion can be observed in master
> {code}
> [10:34:12]W: [org.apache.ignite:ignite-clients] [07:34:12] (err)
> Failed to notify listener:
> o.a.i.i.util.future.GridEmbeddedFuture$2...@4e56da7bjava.lang.AssertionError:
> localNode = 14353600-ea43-42ae-bf7c-4b467800, dhtNodes =
> [TcpDiscoveryNode [id=04134719-3eb1-4969-99dc-f520f982, addrs=ArrayList
> [127.0.0.1], sockAddrs=HashSet [/127.0.0.1:47501], discPort=47501, order=3,
> intOrder=3, lastExchangeTime=1538379249752, loc=false,
> ver=2.7.0#20181001-sha1:9ab8ebd7, isClient=false]]
> [10:34:12]W: [org.apache.ignite:ignite-clients] at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxAbstractEnlistFuture.backupNodes(GridDhtTxAbstractEnlistFuture.java:867)
> [10:34:12]W: [org.apache.ignite:ignite-clients] at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxAbstractEnlistFuture.addToBatch(GridDhtTxAbstractEnlistFuture.java:627)
> [10:34:12]W: [org.apache.ignite:ignite-clients] at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxAbstractEnlistFuture.processEntry(GridDhtTxAbstractEnlistFuture.java:614)
> [10:34:12]W: [org.apache.ignite:ignite-clients] at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxAbstractEnlistFuture.continueLoop(GridDhtTxAbstractEnlistFuture.java:501)
> [10:34:12]W: [org.apache.ignite:ignite-clients] at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxAbstractEnlistFuture.init(GridDhtTxAbstractEnlistFuture.java:363)
> [10:34:12]W: [org.apache.ignite:ignite-clients] at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxQueryEnlistFuture.map(GridNearTxQueryEnlistFuture.java:212)
> [10:34:12]W: [org.apache.ignite:ignite-clients] at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxAbstractEnlistFuture.mapOnTopology(GridNearTxAbstractEnlistFuture.java:332)
> [10:34:12] : [Step 4/5] [2018-10-01 07:34:12,762][INFO
> ][exchange-worker-#2510%thin.JdbcThinTransactionsServerAutoCommitComplexSelfTest2%][GridCachePartitionExchangeManager]
> Skipping rebalancing (nothing scheduled) [top=AffinityTopologyVersion
> [topVer=4, minorTopVer=16], force=false, evt=DISCOVERY_CUSTOM_EVT,
> node=14353600-ea43-42ae-bf7c-4b467800]
> [10:34:12]W: [org.apache.ignite:ignite-clients] at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxAbstractEnlistFuture.access$000(GridNearTxAbstractEnlistFuture.java:56)
> [10:34:12]W: [org.apache.ignite:ignite-clients] at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxAbstractEnlistFuture$2.apply(GridNearTxAbstractEnlistFuture.java:340)
> [10:34:12]W: [org.apache.ignite:ignite-clients] at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxAbstractEnlistFuture$2.apply(GridNearTxAbstractEnlistFuture.java:335)
> [10:34:12]W: [org.apache.ignite:ignite-clients] at
> org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:385)
> [10:34:12]W: [org.apache.ignite:ignite-clients] at
> org.apache.ignite.internal.util.future.GridFutureAdapter.unblock(GridFutureAdapter.java:349)
> [10:34:12]W: [org.apache.ignite:ignite-clients] at
> org.apache.ignite.internal.util.future.GridFutureAdapter.unblockAll(GridFutureAdapter.java:337)
> [10:34:12]W: [org.apache.ignite:ignite-clients] at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:497)
> [10:34:12]W: [org.apache.ignite:ignite-clients] at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:476)
> [10:34:12]W: [org.apache.ignite:ignite-clients] at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onDone(GridDhtPartitionsExchangeFuture.java:1947)
> [10:34:12]W: [org.apache.ign
[jira] [Commented] (IGNITE-9234) Wrong javadocs about null value for cache name.
[ https://issues.apache.org/jira/browse/IGNITE-9234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16651460#comment-16651460 ] Igor Seliverstov commented on IGNITE-9234: -- [~oleg-ostanin], [~kuaw26], looks good to me. > Wrong javadocs about null value for cache name. > --- > > Key: IGNITE-9234 > URL: https://issues.apache.org/jira/browse/IGNITE-9234 > Project: Ignite > Issue Type: Task > Components: documentation >Affects Versions: 2.6 >Reporter: Alexey Kuznetsov >Assignee: Oleg Ostanin >Priority: Minor > Labels: newbie > > Since Ignite 2.0 cache name can not be null (see IGNITE-3488). > javadocs for the following methods are not correct: > org.apache.ignite.configuration.CacheConfiguration#getName > org.apache.ignite.Ignite#cacheNames > They should be fixed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9911) CacheMvccSelectForUpdateQueryAbstractTest#testSelectForUpdateAfterAbortedTx periodically hangs
Igor Seliverstov created IGNITE-9911: Summary: CacheMvccSelectForUpdateQueryAbstractTest#testSelectForUpdateAfterAbortedTx periodically hangs Key: IGNITE-9911 URL: https://issues.apache.org/jira/browse/IGNITE-9911 Project: Ignite Issue Type: Task Components: mvcc Reporter: Igor Seliverstov Assignee: Igor Seliverstov Fix For: 2.7 See [TC history|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=7394250566319069846&tab=testDetails] for details -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-9928) MVCC TX: Bug in SQL query mapping.
[
https://issues.apache.org/jira/browse/IGNITE-9928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Seliverstov reassigned IGNITE-9928:
Assignee: Igor Seliverstov (was: Roman Kondakov)
> MVCC TX: Bug in SQL query mapping.
> ---
>
> Key: IGNITE-9928
> URL: https://issues.apache.org/jira/browse/IGNITE-9928
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Reporter: Roman Kondakov
>Assignee: Igor Seliverstov
>Priority: Major
> Fix For: 2.7
>
>
> SQL query can return wrong results during rebalancing. Reproducer:
> {{CacheMvccPartitionedSqlCoordinatorFailoverTest#testPutAllGetAll_ClientServer_Backups1_Restart_Scan}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (IGNITE-8445) SQL TX: Fast finish for transactions.
[
https://issues.apache.org/jira/browse/IGNITE-8445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Seliverstov resolved IGNITE-8445.
--
Resolution: Done
Already done.
> SQL TX: Fast finish for transactions.
> -
>
> Key: IGNITE-8445
> URL: https://issues.apache.org/jira/browse/IGNITE-8445
> Project: Ignite
> Issue Type: Task
> Components: mvcc, sql
>Reporter: Roman Kondakov
>Priority: Major
>
> Need to implement fast finish path for MVCC transactions. See
> {{org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal#fastFinish}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9928) MVCC TX: Late affinity assignment support.
[
https://issues.apache.org/jira/browse/IGNITE-9928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Seliverstov updated IGNITE-9928:
-
Summary: MVCC TX: Late affinity assignment support. (was: MVCC TX: Bug in
SQL query mapping. )
> MVCC TX: Late affinity assignment support.
> --
>
> Key: IGNITE-9928
> URL: https://issues.apache.org/jira/browse/IGNITE-9928
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Reporter: Roman Kondakov
>Assignee: Igor Seliverstov
>Priority: Major
> Fix For: 2.7
>
>
> SQL query can return wrong results during rebalancing. Reproducer:
> {{CacheMvccPartitionedSqlCoordinatorFailoverTest#testPutAllGetAll_ClientServer_Backups1_Restart_Scan}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9928) MVCC TX: Late affinity assignment support.
[
https://issues.apache.org/jira/browse/IGNITE-9928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Seliverstov updated IGNITE-9928:
-
Description: On unstable topology SQL queries are mapped to random
partitions in OWNED state (regardless whether it's going to be evicted or not)
but updates take into consideration current ideal affinity assignment only (in
other words updates are sent to current backups only and don't touch partitions
which are going to be evicted) what causes a situation when subsequent reads
may not see previous updates. (was: SQL query can return wrong results during
rebalancing. Reproducer:
{{CacheMvccPartitionedSqlCoordinatorFailoverTest#testPutAllGetAll_ClientServer_Backups1_Restart_Scan}})
> MVCC TX: Late affinity assignment support.
> --
>
> Key: IGNITE-9928
> URL: https://issues.apache.org/jira/browse/IGNITE-9928
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Reporter: Roman Kondakov
>Assignee: Igor Seliverstov
>Priority: Major
> Fix For: 2.7
>
>
> On unstable topology SQL queries are mapped to random partitions in OWNED
> state (regardless whether it's going to be evicted or not) but updates take
> into consideration current ideal affinity assignment only (in other words
> updates are sent to current backups only and don't touch partitions which are
> going to be evicted) what causes a situation when subsequent reads may not
> see previous updates.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9928) MVCC TX: Late affinity assignment support.
[ https://issues.apache.org/jira/browse/IGNITE-9928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16661996#comment-16661996 ] Igor Seliverstov commented on IGNITE-9928: -- Another important point is what we also should support partitions invalidations. That means remote transactions: # should track touched partitions and evict CQ/DR caches as soon as corresponding partitions are evicted, # should rollback themselves as soon as all involved partitions become invalid # notify DHT transactions about partitions invalidations, recalculated mappings and rollbacks of needless transactions > MVCC TX: Late affinity assignment support. > -- > > Key: IGNITE-9928 > URL: https://issues.apache.org/jira/browse/IGNITE-9928 > Project: Ignite > Issue Type: Bug > Components: mvcc >Reporter: Roman Kondakov >Assignee: Igor Seliverstov >Priority: Major > Fix For: 2.7 > > > On unstable topology SQL queries are mapped to random partitions in OWNED > state (regardless whether it's going to be evicted or not) but updates take > into consideration current ideal affinity assignment only (in other words > updates are sent to current backups only and don't touch partitions which are > going to be evicted) what causes a situation when subsequent reads may not > see previous updates. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9985) MVCC TX: fix backup mappings
Igor Seliverstov created IGNITE-9985: Summary: MVCC TX: fix backup mappings Key: IGNITE-9985 URL: https://issues.apache.org/jira/browse/IGNITE-9985 Project: Ignite Issue Type: Task Components: mvcc Reporter: Igor Seliverstov Assignee: Igor Seliverstov Fix mappings to update going to be evicted partitions as well to maintain consistency during rebalance -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9985) MVCC TX: fix backup mappings
[ https://issues.apache.org/jira/browse/IGNITE-9985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Seliverstov updated IGNITE-9985: - Fix Version/s: 2.7 > MVCC TX: fix backup mappings > > > Key: IGNITE-9985 > URL: https://issues.apache.org/jira/browse/IGNITE-9985 > Project: Ignite > Issue Type: Task > Components: mvcc >Reporter: Igor Seliverstov >Assignee: Igor Seliverstov >Priority: Major > Fix For: 2.7 > > > Fix mappings to update going to be evicted partitions as well to maintain > consistency during rebalance -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9435) Document MVCC
[
https://issues.apache.org/jira/browse/IGNITE-9435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1330#comment-1330
]
Igor Seliverstov commented on IGNITE-9435:
--
[~Artem Budnikov], several comments from me:
There are several mistakes in implementation description:
{noformat}
When a transaction requests a specific data item to work on, it does not work
with the item directly, but obtains a version of that item (a copy of the
current value). This version is confined to the context of the transaction and
cannot be modified by other users. If another transaction accesses the same
item, it obtains yet another version and works with it. Thus, multiple versions
of the same item can coexist, by they are isolated from each other and confined
to the transactions they were generated for. Each transaction, as it were, sees
a snapshot of data at the time the transaction starts and can only modify the
data within that snapshot. The snapshot is always consistent and guaranteed not
to be modified by other transactions.{noformat}
a version of item isn't a copy of current value - it's a version of value at
the specific time.
Transactions don't copy items while requesting them - they read already existed
entries applying a special filter not to see too old or too new versions but
see the most actual (at the time the transaction have been started) ones, to do
that we use *snapshots* - a kind of point at the global timeline having an
information about finished and active transactions at this specific time.
Modifying an entry a transaction doesn't made any modifications in existed
values - it makes a new version of entry with modified fields/columns values.
That means all versions are mutable and can be easily shared between several
transactions/queries - that's why we don't need any locks to read an entry.
Before modifying a transaction has to acquire a write lock on an entry, all the
locks will be released as soon as the transaction is finished. That means what
*we allow non-blocking reads but blocking writes*.
Versions aren't put (copied) into any context, we just restrict cleaning
versions, which may be visible for any query or transaction and share them
between active transactions.
After the version become invisible (when there is a later version of entry
which is visible for any query/transaction or the version is a result of rolled
back transaction) it will be cleaned by the first writer who modified the entry
or by vacuum worker in background.
Another comment - the article has 2.6 version, isn't it a mistake? We don't
have such feature in Ignite 2.6
> Document MVCC
> -
>
> Key: IGNITE-9435
> URL: https://issues.apache.org/jira/browse/IGNITE-9435
> Project: Ignite
> Issue Type: Task
> Components: documentation, mvcc
>Reporter: Vladimir Ozerov
>Assignee: Igor Seliverstov
>Priority: Major
> Fix For: 2.7
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-12692) Calcite integration. DML. Skip reducer optimization.
Igor Seliverstov created IGNITE-12692: - Summary: Calcite integration. DML. Skip reducer optimization. Key: IGNITE-12692 URL: https://issues.apache.org/jira/browse/IGNITE-12692 Project: Ignite Issue Type: Improvement Reporter: Igor Seliverstov Having plan tree we easily can check whether a final modification may be executed on data nodes directly or not. We should implement such kind of optimization. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12692) Calcite integration. DML. Skip reducer optimization.
[ https://issues.apache.org/jira/browse/IGNITE-12692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17039027#comment-17039027 ] Igor Seliverstov commented on IGNITE-12692: --- UPD seems it's more efficient and natural to request from a modify node underlying table distribution and add a single distributed SUM aggregation node before it - this way a planner will try to collocate modification and source select. Adding a single distributed table modify to search scope as an alternative will cover a case when collecting phase required. This way we'll get desired behavior automatically. > Calcite integration. DML. Skip reducer optimization. > > > Key: IGNITE-12692 > URL: https://issues.apache.org/jira/browse/IGNITE-12692 > Project: Ignite > Issue Type: Improvement >Reporter: Igor Seliverstov >Priority: Major > > Having plan tree we easily can check whether a final modification may be > executed on data nodes directly or not. We should implement such kind of > optimization. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12695) Calcite integration. DML support. MERGE support
Igor Seliverstov created IGNITE-12695: - Summary: Calcite integration. DML support. MERGE support Key: IGNITE-12695 URL: https://issues.apache.org/jira/browse/IGNITE-12695 Project: Ignite Issue Type: New Feature Reporter: Igor Seliverstov -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12700) Calcite integration. Aggregates support.
Igor Seliverstov created IGNITE-12700: - Summary: Calcite integration. Aggregates support. Key: IGNITE-12700 URL: https://issues.apache.org/jira/browse/IGNITE-12700 Project: Ignite Issue Type: New Feature Components: sql Reporter: Igor Seliverstov Assignee: Igor Seliverstov -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-12566) Calcite integration. Expressions evaluation.
[ https://issues.apache.org/jira/browse/IGNITE-12566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Seliverstov reassigned IGNITE-12566: - Assignee: Igor Seliverstov > Calcite integration. Expressions evaluation. > > > Key: IGNITE-12566 > URL: https://issues.apache.org/jira/browse/IGNITE-12566 > Project: Ignite > Issue Type: Task >Reporter: Igor Seliverstov >Assignee: Igor Seliverstov >Priority: Major > > Currently we use a part of Calcite "Bindables" to evaluate expressions at the > execution time. Using it we > * lose a control on how expressions are evaluated > * cannot implement several important optimizations, like "keepBinary" > * can use only Object[] as a row, which causes a lot of array copy > operations and unnecessary allocations at the execution time > * suffer from delays, which go from expressions compilation process when > it's more efficient to start from interpretation and compile an expression on > repeatable execution only > We need to implement expressions interpreter and our own expression compiler > taking Ignite specifics in consideration. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12708) Calcite integration. Expressions factory base implementation.
Igor Seliverstov created IGNITE-12708: - Summary: Calcite integration. Expressions factory base implementation. Key: IGNITE-12708 URL: https://issues.apache.org/jira/browse/IGNITE-12708 Project: Ignite Issue Type: New Feature Components: sql Reporter: Igor Seliverstov Assignee: Igor Seliverstov We need to implement basic environment for expressions evaluation. Expressions should exist in two types - compiled and interpreted. Expressions should be compiled in dedicated thread pull and eventually replace interpreted ones. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12747) Calcite integration. Correlated queries support.
Igor Seliverstov created IGNITE-12747: - Summary: Calcite integration. Correlated queries support. Key: IGNITE-12747 URL: https://issues.apache.org/jira/browse/IGNITE-12747 Project: Ignite Issue Type: New Feature Reporter: Igor Seliverstov -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12776) Calcite integration. An exception occurred when a replicated cache is used in a query.
Igor Seliverstov created IGNITE-12776: - Summary: Calcite integration. An exception occurred when a replicated cache is used in a query. Key: IGNITE-12776 URL: https://issues.apache.org/jira/browse/IGNITE-12776 Project: Ignite Issue Type: Bug Reporter: Igor Seliverstov Assignee: Igor Seliverstov -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12792) Calcite integration. Update Calcite version to 1.22.0
Igor Seliverstov created IGNITE-12792: - Summary: Calcite integration. Update Calcite version to 1.22.0 Key: IGNITE-12792 URL: https://issues.apache.org/jira/browse/IGNITE-12792 Project: Ignite Issue Type: Improvement Reporter: Igor Seliverstov Assignee: Igor Seliverstov -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12819) Calcite integration. Cost system.
Igor Seliverstov created IGNITE-12819: - Summary: Calcite integration. Cost system. Key: IGNITE-12819 URL: https://issues.apache.org/jira/browse/IGNITE-12819 Project: Ignite Issue Type: Task Reporter: Igor Seliverstov Current implementation doesn't suit our needs for particular reasons. We need to introduce our own one taking into account such parameters as IO operations, memory usage, CPU usage, disk usage etc. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12820) Calcite integration. Do not use AbstarctConverter while planning.
Igor Seliverstov created IGNITE-12820: - Summary: Calcite integration. Do not use AbstarctConverter while planning. Key: IGNITE-12820 URL: https://issues.apache.org/jira/browse/IGNITE-12820 Project: Ignite Issue Type: Improvement Reporter: Igor Seliverstov We need to change traits explicitly without AbstractConverter's and appropriate rules. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-12820) Calcite integration. Do not use AbstarctConverter while planning.
[ https://issues.apache.org/jira/browse/IGNITE-12820?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Seliverstov reassigned IGNITE-12820: - Assignee: Igor Seliverstov > Calcite integration. Do not use AbstarctConverter while planning. > - > > Key: IGNITE-12820 > URL: https://issues.apache.org/jira/browse/IGNITE-12820 > Project: Ignite > Issue Type: Improvement >Reporter: Igor Seliverstov >Assignee: Igor Seliverstov >Priority: Major > > We need to change traits explicitly without AbstractConverter's and > appropriate rules. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12864) Calcite integration. UNION support.
Igor Seliverstov created IGNITE-12864: - Summary: Calcite integration. UNION support. Key: IGNITE-12864 URL: https://issues.apache.org/jira/browse/IGNITE-12864 Project: Ignite Issue Type: New Feature Reporter: Igor Seliverstov -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12868) Calcite integration. LEFT, RIGHT join support.
Igor Seliverstov created IGNITE-12868: - Summary: Calcite integration. LEFT, RIGHT join support. Key: IGNITE-12868 URL: https://issues.apache.org/jira/browse/IGNITE-12868 Project: Ignite Issue Type: New Feature Reporter: Igor Seliverstov -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12871) Calcite integration. Broadcast to hash conversion without exchange.
Igor Seliverstov created IGNITE-12871: - Summary: Calcite integration. Broadcast to hash conversion without exchange. Key: IGNITE-12871 URL: https://issues.apache.org/jira/browse/IGNITE-12871 Project: Ignite Issue Type: Improvement Reporter: Igor Seliverstov Use a partition filter instead of network communications -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-12871) Calcite integration. Broadcast to hash conversion without exchange.
[ https://issues.apache.org/jira/browse/IGNITE-12871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Seliverstov reassigned IGNITE-12871: - Assignee: Igor Seliverstov > Calcite integration. Broadcast to hash conversion without exchange. > --- > > Key: IGNITE-12871 > URL: https://issues.apache.org/jira/browse/IGNITE-12871 > Project: Ignite > Issue Type: Improvement >Reporter: Igor Seliverstov >Assignee: Igor Seliverstov >Priority: Major > > Use a partition filter instead of network communications -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-12864) Calcite integration. UNION support.
[ https://issues.apache.org/jira/browse/IGNITE-12864?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Seliverstov reassigned IGNITE-12864: - Assignee: Igor Seliverstov > Calcite integration. UNION support. > --- > > Key: IGNITE-12864 > URL: https://issues.apache.org/jira/browse/IGNITE-12864 > Project: Ignite > Issue Type: New Feature >Reporter: Igor Seliverstov >Assignee: Igor Seliverstov >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12899) Calcite integration. Distribution multitrait
Igor Seliverstov created IGNITE-12899: - Summary: Calcite integration. Distribution multitrait Key: IGNITE-12899 URL: https://issues.apache.org/jira/browse/IGNITE-12899 Project: Ignite Issue Type: Task Reporter: Igor Seliverstov Currently Ignite nodes have single distribution value which isn't true in several cases like: # a partitioned table with a key alias should have 2 distribution traits: by _key and by key alias (id for example) - without distribution by _key column almost impossible to implement IGNITE-12692 # After inner / cross join the result should have several hash distributions (by left and by right keys) - it may be important on join transpose optimization -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12566) Calcite integration. Expressions evaluation.
[ https://issues.apache.org/jira/browse/IGNITE-12566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17083931#comment-17083931 ] Igor Seliverstov commented on IGNITE-12566: --- List of needed operations implementations: AND OR ABS ACOS AND ANY_VALUE ASCII ASIN ATAN ATAN2 BIT_AND BIT_OR BIT_XOR CARDINALITY CASE CAST CBRT CEIL CHARACTER_LENGTH CHAR_LENGTH CLASSIFIER COALESCE COLLECT CONCAT COS COT COUNT CURRENT_CATALOG CURRENT_DATE CURRENT_PATH CURRENT_ROLE CURRENT_TIME CURRENT_TIMESTAMP CURRENT_USER CURRENT_VALUE DATETIME_PLUS DEFAULT DEGREES DENSE_RANK DIVIDE DIVIDE_INTEGER ELEMENT EQUALS EXP EXTRACT FIRST_VALUE FLOOR FUSION GREATER_THAN GREATER_THAN_OR_EQUAL GROUPING GROUPING_ID INITCAP IS_A_SET IS_EMPTY IS_FALSE IS_JSON_ARRAY IS_JSON_OBJECT IS_JSON_SCALAR IS_JSON_VALUE IS_NOT_A_SET IS_NOT_EMPTY IS_NOT_FALSE IS_NOT_JSON_ARRAY IS_NOT_JSON_OBJECT IS_NOT_JSON_SCALAR IS_NOT_JSON_VALUE IS_NOT_NULL IS_NOT_TRUE IS_NULL IS_TRUE ITEM JSON_ARRAY JSON_ARRAYAGG JSON_EXISTS JSON_OBJECT JSON_OBJECTAGG JSON_QUERY JSON_VALUE_ANY JSON_VALUE_EXPRESSION LAG LAST LAST_DAY LAST_VALUE LEAD LESS_THAN LESS_THAN_OR_EQUAL LIKE LISTAGG LN LOCALTIME LOCALTIMESTAMP LOG10 LOWER MAP_VALUE_CONSTRUCTOR MAX MEMBER_OF MIN MINUS MINUS_DATE MOD MULTIPLY MULTISET_EXCEPT MULTISET_EXCEPT_DISTINCT MULTISET_INTERSECT MULTISET_INTERSECT_DISTINCT MULTISET_UNION MULTISET_UNION_DISTINCT NEXT_VALUE NOT NOT_EQUALS NOT_LIKE NOT_SIMILAR_TO NOT_SUBMULTISET_OF NTH_VALUE NTILE OR OVERLAY PI PLUS POSITION POWER PREV RADIANS RAND RAND_INTEGER RANK REGR_COUNT REINTERPRET REPLACE ROUND ROW ROW_NUMBER SESSION_USER SIGN SIMILAR_TO SIN SINGLE_VALUE SLICE STRUCT_ACCESS SUBMULTISET_OF SUBSTRING SUM SUM0 SYSTEM_USER TAN TRIM TRUNCATE TUMBLE_TVF UNARY_MINUS UNARY_PLUS UPPER USER Also we have to take into consideration types and types inference on different types are passed as function parameters (for example for math operations: DOUBLE + INTEGER = DOUBLE; INTEGER + BIG_INT = BIG_INT etc) > Calcite integration. Expressions evaluation. > > > Key: IGNITE-12566 > URL: https://issues.apache.org/jira/browse/IGNITE-12566 > Project: Ignite > Issue Type: Task >Reporter: Igor Seliverstov >Assignee: Igor Seliverstov >Priority: Major > > Currently we use a part of Calcite "Bindables" to evaluate expressions at the > execution time. Using it we > * lose a control on how expressions are evaluated > * cannot implement several important optimizations, like "keepBinary" > * can use only Object[] as a row, which causes a lot of array copy > operations and unnecessary allocations at the execution time > * suffer from delays, which go from expressions compilation process when > it's more efficient to start from interpretation and compile an expression on > repeatable execution only > We need to implement expressions interpreter and our own expression compiler > taking Ignite specifics in consideration. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-12566) Calcite integration. Expressions evaluation.
[ https://issues.apache.org/jira/browse/IGNITE-12566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17083931#comment-17083931 ] Igor Seliverstov edited comment on IGNITE-12566 at 4/15/20, 9:00 AM: - List of needed operations implementations: AND OR ABS ACOS AND ANY_VALUE ASCII ASIN ATAN ATAN2 BIT_AND BIT_OR BIT_XOR CARDINALITY CASE CAST CBRT CEIL CHARACTER_LENGTH CHAR_LENGTH CLASSIFIER COALESCE COLLECT CONCAT COS COT COUNT CURRENT_CATALOG CURRENT_DATE CURRENT_PATH CURRENT_ROLE CURRENT_TIME CURRENT_TIMESTAMP CURRENT_USER CURRENT_VALUE DATETIME_PLUS DEFAULT DEGREES DENSE_RANK DIVIDE DIVIDE_INTEGER ELEMENT EQUALS EXP EXTRACT FIRST_VALUE FLOOR FUSION GREATER_THAN GREATER_THAN_OR_EQUAL GROUPING GROUPING_ID INITCAP IS_A_SET IS_EMPTY IS_FALSE IS_JSON_ARRAY IS_JSON_OBJECT IS_JSON_SCALAR IS_JSON_VALUE IS_NOT_A_SET IS_NOT_EMPTY IS_NOT_FALSE IS_NOT_JSON_ARRAY IS_NOT_JSON_OBJECT IS_NOT_JSON_SCALAR IS_NOT_JSON_VALUE IS_NOT_NULL IS_NOT_TRUE IS_NULL IS_TRUE ITEM JSON_ARRAY JSON_ARRAYAGG JSON_EXISTS JSON_OBJECT JSON_OBJECTAGG JSON_QUERY JSON_VALUE_ANY JSON_VALUE_EXPRESSION LAG LAST LAST_DAY LAST_VALUE LEAD LESS_THAN LESS_THAN_OR_EQUAL LIKE LISTAGG LN LOCALTIME LOCALTIMESTAMP LOG10 LOWER MAP_VALUE_CONSTRUCTOR MAX MEMBER_OF MIN MINUS MINUS_DATE MOD MULTIPLY MULTISET_EXCEPT MULTISET_EXCEPT_DISTINCT MULTISET_INTERSECT MULTISET_INTERSECT_DISTINCT MULTISET_UNION MULTISET_UNION_DISTINCT NEXT_VALUE NOT NOT_EQUALS NOT_LIKE NOT_SIMILAR_TO NOT_SUBMULTISET_OF NTH_VALUE NTILE OR OVERLAY PI PLUS POSITION POWER PREV RADIANS RAND RAND_INTEGER RANK REGR_COUNT REINTERPRET REPLACE ROUND ROW ROW_NUMBER SESSION_USER SIGN SIMILAR_TO SIN SINGLE_VALUE SLICE STRUCT_ACCESS SUBMULTISET_OF SUBSTRING SUM SUM0 SYSTEM_USER TAN TRIM TRUNCATE TUMBLE_TVF UNARY_MINUS UNARY_PLUS UPPER USER Also we have to take into consideration types and types inference on different types are passed as function parameters (for example for math operations: DOUBLE + INTEGER = DOUBLE; INTEGER + BIG_INT = BIG_INT etc) Calcite uses code generation to generate functions for each passed types combinations at runtime, it's possible to act the same way, but having classes cache to bind logical operation to already generated implementation (not to compile code each time) was (Author: gvvinblade): List of needed operations implementations: AND OR ABS ACOS AND ANY_VALUE ASCII ASIN ATAN ATAN2 BIT_AND BIT_OR BIT_XOR CARDINALITY CASE CAST CBRT CEIL CHARACTER_LENGTH CHAR_LENGTH CLASSIFIER COALESCE COLLECT CONCAT COS COT COUNT CURRENT_CATALOG CURRENT_DATE CURRENT_PATH CURRENT_ROLE CURRENT_TIME CURRENT_TIMESTAMP CURRENT_USER CURRENT_VALUE DATETIME_PLUS DEFAULT DEGREES DENSE_RANK DIVIDE DIVIDE_INTEGER ELEMENT EQUALS EXP EXTRACT FIRST_VALUE FLOOR FUSION GREATER_THAN GREATER_THAN_OR_EQUAL GROUPING GROUPING_ID INITCAP IS_A_SET IS_EMPTY IS_FALSE IS_JSON_ARRAY IS_JSON_OBJECT IS_JSON_SCALAR IS_JSON_VALUE IS_NOT_A_SET IS_NOT_EMPTY IS_NOT_FALSE IS_NOT_JSON_ARRAY IS_NOT_JSON_OBJECT IS_NOT_JSON_SCALAR IS_NOT_JSON_VALUE IS_NOT_NULL IS_NOT_TRUE IS_NULL IS_TRUE ITEM JSON_ARRAY JSON_ARRAYAGG JSON_EXISTS JSON_OBJECT JSON_OBJECTAGG JSON_QUERY JSON_VALUE_ANY JSON_VALUE_EXPRESSION LAG LAST LAST_DAY LAST_VALUE LEAD LESS_THAN LESS_THAN_OR_EQUAL LIKE LISTAGG LN LOCALTIME LOCALTIMESTAMP LOG10 LOWER MAP_VALUE_CONSTRUCTOR MAX MEMBER_OF MIN MINUS MINUS_DATE MOD MULTIPLY MULTISET_EXCEPT MULTISET_EXCEPT_DISTINCT MULTISET_INTERSECT MULTISET_INTERSECT_DISTINCT MULTISET_UNION MULTISET_UNION_DISTINCT NEXT_VALUE NOT NOT_EQUALS NOT_LIKE NOT_SIMILAR_TO NOT_SUBMULTISET_OF NTH_VALUE NTILE OR OVERLAY PI PLUS POSITION POWER PREV RADIANS RAND RAND_INTEGER RANK REGR_COUNT REINTERPRET REPLACE ROUND ROW ROW_NUMBER SESSION_USER SIGN SIMILAR_TO SIN SINGLE_VALUE SLICE STRUCT_ACCESS SUBMULTISET_OF SUBSTRING SUM SUM0 SYSTEM_USER TAN TRIM TRUNCATE TUMBLE_TVF UNARY_MINUS UNARY_PLUS UPPER USER Also we have to take into consideration types and types inference on different types are passed as function parameters (for example for math operations: DOUBLE + INTEGER = DOUBLE; INTEGER + BIG_INT = BIG_INT etc) > Calcite integration. Expressions evaluation. > > > Key: IGNITE-12566 > URL: https://issues.apache.org/jira/browse/IGNITE-12566 > Project: Ignite > Issue Type: Task >Reporter: Igor Seliverstov >Assignee: Igor Seliverstov >Priority: Major > > Currently we use a part of Calcite "Bindables" to evaluate expressions at the > execution time. Using it we > * lose a control on how expressions are evaluated > * cannot implement several important optimizations, like "keepBinary" > * can use only Object[] as a row, which causes a
[jira] [Updated] (IGNITE-12899) Calcite integration. Distribution multitrait
[ https://issues.apache.org/jira/browse/IGNITE-12899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Seliverstov updated IGNITE-12899: -- Description: Currently Ignite nodes have single distribution value which isn't true in several cases like: # a partitioned table with a key alias should have 2 distribution traits: by _key and by key alias (id for example) - without distribution by _key column almost impossible to implement IGNITE-12692 # After inner / cross join the result should have several hash distributions (by left and by right keys) - it may be important on join transpose optimization # On project a source distribution key may appear more than once, so the result should contain a distribution for each distribution key position. was: Currently Ignite nodes have single distribution value which isn't true in several cases like: # a partitioned table with a key alias should have 2 distribution traits: by _key and by key alias (id for example) - without distribution by _key column almost impossible to implement IGNITE-12692 # After inner / cross join the result should have several hash distributions (by left and by right keys) - it may be important on join transpose optimization > Calcite integration. Distribution multitrait > > > Key: IGNITE-12899 > URL: https://issues.apache.org/jira/browse/IGNITE-12899 > Project: Ignite > Issue Type: Task >Reporter: Igor Seliverstov >Priority: Major > > Currently Ignite nodes have single distribution value which isn't true in > several cases like: > # a partitioned table with a key alias should have 2 distribution traits: by > _key and by key alias (id for example) - without distribution by _key column > almost impossible to implement IGNITE-12692 > # After inner / cross join the result should have several hash distributions > (by left and by right keys) - it may be important on join transpose > optimization > # On project a source distribution key may appear more than once, so the > result should contain a distribution for each distribution key position. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12900) Calcite integration. Use RowHandler to access fields.
Igor Seliverstov created IGNITE-12900: - Summary: Calcite integration. Use RowHandler to access fields. Key: IGNITE-12900 URL: https://issues.apache.org/jira/browse/IGNITE-12900 Project: Ignite Issue Type: Task Reporter: Igor Seliverstov Currently only Object[] can be used as a row because most of execution nodes require Object[] as a row type. Let's use generic row types with appropriate RowHandler in execution nodes and compiled expressions to get more flexibility. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12909) Calcite integration. Explain command support
Igor Seliverstov created IGNITE-12909: - Summary: Calcite integration. Explain command support Key: IGNITE-12909 URL: https://issues.apache.org/jira/browse/IGNITE-12909 Project: Ignite Issue Type: Task Reporter: Igor Seliverstov Support EXPLAIN command -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12972) Calcite integration. Serialization refactoring
Igor Seliverstov created IGNITE-12972: - Summary: Calcite integration. Serialization refactoring Key: IGNITE-12972 URL: https://issues.apache.org/jira/browse/IGNITE-12972 Project: Ignite Issue Type: Improvement Reporter: Igor Seliverstov Assignee: Igor Seliverstov Currently we need quite a lot of classes to serialize, send and deserialize a prepared plan (in scope of node-to-node communications). It's better to do that by analogy with Calcite's RelJsonReader/RelJsonWriter. This way we may omit necessity to maintain lots of classes preserving functionality. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (IGNITE-12592) Calcite integration. Query load balancing.
[
https://issues.apache.org/jira/browse/IGNITE-12592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Seliverstov resolved IGNITE-12592.
---
Resolution: Fixed
Already done in scope of other issues.
> Calcite integration. Query load balancing.
> --
>
> Key: IGNITE-12592
> URL: https://issues.apache.org/jira/browse/IGNITE-12592
> Project: Ignite
> Issue Type: Task
>Reporter: Igor Seliverstov
>Priority: Major
>
> Currently all query tasks execute in a query pool. The pool contains a
> limited number of threads, so, in case of long running scan operation other
> query tasks will starve.
> We need to limit time a thread spends inside {{ScanNode#requestInternal
> method}}.
> See appropriate TODO
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-12991) Calcite integration. Pass cancel flag to VolcanoPlanner
Igor Seliverstov created IGNITE-12991:
-
Summary: Calcite integration. Pass cancel flag to VolcanoPlanner
Key: IGNITE-12991
URL: https://issues.apache.org/jira/browse/IGNITE-12991
Project: Ignite
Issue Type: Improvement
Reporter: Igor Seliverstov
see {{AbstractRelOptPlanner.java:91}}, here {{CancelFlag}} is used to cancel
planning loop. We need to pass it into a newly created context and bind its
state with {{PlanningContext#queryCancel}} to break possible infinite planning
loop. See also {{PlanningContext#unwrap}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (IGNITE-12900) Calcite integration. Use RowHandler to access fields.
[ https://issues.apache.org/jira/browse/IGNITE-12900?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Seliverstov resolved IGNITE-12900. --- Release Note: Done in scope of IGNITE-12715 Resolution: Done > Calcite integration. Use RowHandler to access fields. > - > > Key: IGNITE-12900 > URL: https://issues.apache.org/jira/browse/IGNITE-12900 > Project: Ignite > Issue Type: Task >Reporter: Igor Seliverstov >Priority: Major > > Currently only Object[] can be used as a row because most of execution nodes > require Object[] as a row type. Let's use generic row types with appropriate > RowHandler in execution nodes and compiled expressions to get more > flexibility. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-12620) Calcite integration. Index Nested Loop Join/Hash Join
[ https://issues.apache.org/jira/browse/IGNITE-12620?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Seliverstov reassigned IGNITE-12620: - Assignee: Igor Seliverstov > Calcite integration. Index Nested Loop Join/Hash Join > - > > Key: IGNITE-12620 > URL: https://issues.apache.org/jira/browse/IGNITE-12620 > Project: Ignite > Issue Type: New Feature >Reporter: Igor Seliverstov >Assignee: Igor Seliverstov >Priority: Major > > We may implement the feature the next way: > # For each row from left node consume whole dataset from right node > # Pass join condition as an argument of request() method of the right node > # In case a data source at right is an index scan > ## If there is no cursor opened - create a new cursor using bounds from > request > ## If there is an existing cursor - just check the cursor was opened using > the same condition as passed one. > ## After the right node signals EOD consume a next row from left and repeat > from p 2. > # In case a data source at right is a table scan with huge amount of rows > ## If there is no cursor opened - create a new cursor ignoring passed > condition > ## If there is an existing cursor - just check the cursor was opened using > the same condition as passed one. > ## After the right node signals EOD consume a next row from left and repeat > from p 2. > # In case a data source at right is remote / is a table scan with small > number of rows/ is a filter node with good enough selectivity > ## Create a hash index for a data source > ## If there is no cursor opened - create a new cursor using bounds from > request > ## If there is an existing cursor - just check the cursor was opened using > the same condition as passed one. > ## After the right node signals EOD consume a next row from left and repeat > from p 2. > Consider implementation specifics at optimization time, choose the cheapest > variant -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13051) Optimized affinity switch on baseline node left is broken for client topology and MVCC
[ https://issues.apache.org/jira/browse/IGNITE-13051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17119368#comment-17119368 ] Igor Seliverstov commented on IGNITE-13051: --- [~timonin.maksim], Looks good to me, at least I see no issues. > Optimized affinity switch on baseline node left is broken for client topology > and MVCC > -- > > Key: IGNITE-13051 > URL: https://issues.apache.org/jira/browse/IGNITE-13051 > Project: Ignite > Issue Type: Bug >Reporter: Alexey Scherbakov >Assignee: Maksim Timonin >Priority: Critical > Fix For: 2.9 > > Time Spent: 10m > Remaining Estimate: 0h > > If a node contains only client cache topology with MVCC enabled, PME will > hang after changes introduced in IGNITE-12617. > Reproduced by > CachePartitionLossWithRestartsTest.testPartitionLossDetectionOnClientTopology[0 > false false -1] and enabled MVCC. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13117) Calcite integration. Update Calcite version to 1.23.0
Igor Seliverstov created IGNITE-13117: - Summary: Calcite integration. Update Calcite version to 1.23.0 Key: IGNITE-13117 URL: https://issues.apache.org/jira/browse/IGNITE-13117 Project: Ignite Issue Type: Improvement Reporter: Igor Seliverstov Assignee: Igor Seliverstov There are two important features in the new Calcite release what we need to solve current planner issues: top-down traits propagation and bottom-up traits derivation -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13117) Calcite integration. Update Calcite version to 1.23.0
[ https://issues.apache.org/jira/browse/IGNITE-13117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Seliverstov updated IGNITE-13117: -- Description: There are two important features in the new Calcite release that we need to solve current planner issues: top-down traits propagation and bottom-up traits derivation (was: There are two important features in the new Calcite release what we need to solve current planner issues: top-down traits propagation and bottom-up traits derivation) > Calcite integration. Update Calcite version to 1.23.0 > - > > Key: IGNITE-13117 > URL: https://issues.apache.org/jira/browse/IGNITE-13117 > Project: Ignite > Issue Type: Improvement >Reporter: Igor Seliverstov >Assignee: Igor Seliverstov >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > There are two important features in the new Calcite release that we need to > solve current planner issues: top-down traits propagation and bottom-up > traits derivation -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12620) Calcite integration. Index Nested Loop Join/Hash Join
[ https://issues.apache.org/jira/browse/IGNITE-12620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17148795#comment-17148795 ] Igor Seliverstov commented on IGNITE-12620: --- [~agoncharuk],[~amashenkov],[~korlov],[~tledkov-gridgain], guys, please look at > Calcite integration. Index Nested Loop Join/Hash Join > - > > Key: IGNITE-12620 > URL: https://issues.apache.org/jira/browse/IGNITE-12620 > Project: Ignite > Issue Type: New Feature >Reporter: Igor Seliverstov >Assignee: Igor Seliverstov >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > We may implement the feature the next way: > # For each row from left node consume whole dataset from right node > # Pass join condition as an argument of request() method of the right node > # In case a data source at right is an index scan > ## If there is no cursor opened - create a new cursor using bounds from > request > ## If there is an existing cursor - just check the cursor was opened using > the same condition as passed one. > ## After the right node signals EOD consume a next row from left and repeat > from p 2. > # In case a data source at right is a table scan with huge amount of rows > ## If there is no cursor opened - create a new cursor ignoring passed > condition > ## If there is an existing cursor - just check the cursor was opened using > the same condition as passed one. > ## After the right node signals EOD consume a next row from left and repeat > from p 2. > # In case a data source at right is remote / is a table scan with small > number of rows/ is a filter node with good enough selectivity > ## Create a hash index for a data source > ## If there is no cursor opened - create a new cursor using bounds from > request > ## If there is an existing cursor - just check the cursor was opened using > the same condition as passed one. > ## After the right node signals EOD consume a next row from left and repeat > from p 2. > Consider implementation specifics at optimization time, choose the cheapest > variant -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13247) Calcite integration. Move QueryCursorEx.isQuery() flag to a proper place.
Igor Seliverstov created IGNITE-13247: - Summary: Calcite integration. Move QueryCursorEx.isQuery() flag to a proper place. Key: IGNITE-13247 URL: https://issues.apache.org/jira/browse/IGNITE-13247 Project: Ignite Issue Type: Improvement Reporter: Igor Seliverstov Since QueryCursorEx is used in continuous queries, we should move SQL query related flag to another place. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-4003) Slow or faulty client can stall the whole cluster.
[
https://issues.apache.org/jira/browse/IGNITE-4003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Seliverstov reassigned IGNITE-4003:
Assignee: Igor Seliverstov
> Slow or faulty client can stall the whole cluster.
> --
>
> Key: IGNITE-4003
> URL: https://issues.apache.org/jira/browse/IGNITE-4003
> Project: Ignite
> Issue Type: Bug
> Components: cache, general
>Affects Versions: 1.7
>Reporter: Vladimir Ozerov
>Assignee: Igor Seliverstov
>Priority: Critical
>
> Steps to reproduce:
> 1) Start two server nodes and some data to cache.
> 2) Start a client from Docker subnet, which is not visible from the outside.
> Client will join the cluster.
> 3) Try to put something to cache or start another node to force rabalance.
> Cluster is stuck at this moment. Root cause - servers are constantly trying
> to establish outgoing connection to the client, but fail as Docker subnet is
> not visible from the outside. It may stop virtually all cluster operations.
> Typical thread dump:
> {code}
> org.apache.ignite.IgniteCheckedException: Failed to send message (node may
> have left the grid or TCP connection cannot be established due to firewall
> issues) [node=TcpDiscoveryNode [id=a15d74c2-1ec2-4349-9640-aeacd70d8714,
> addrs=[127.0.0.1, 172.17.0.6], sockAddrs=[/127.0.0.1:0, /127.0.0.1:0,
> /172.17.0.6:0], discPort=0, order=7241, intOrder=3707,
> lastExchangeTime=1474096941045, loc=false, ver=1.5.23#20160526-sha1:259146da,
> isClient=true], topic=T4 [topic=TOPIC_CACHE,
> id1=949732fd-1360-3a58-8d9e-0ff6ea6182cc,
> id2=a15d74c2-1ec2-4349-9640-aeacd70d8714, id3=2], msg=GridContinuousMessage
> [type=MSG_EVT_NOTIFICATION, routineId=7e13c48e-6933-48b2-9f15-8d92007930db,
> data=null, futId=null], policy=2]
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:1129)
> [ignite-core-1.5.23.jar:1.5.23]
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.sendOrderedMessage(GridIoManager.java:1347)
> [ignite-core-1.5.23.jar:1.5.23]
> at
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.sendWithRetries(GridContinuousProcessor.java:1227)
> ~[ignite-core-1.5.23.jar:1.5.23]
> at
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.sendWithRetries(GridContinuousProcessor.java:1198)
> ~[ignite-core-1.5.23.jar:1.5.23]
> at
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.sendWithRetries(GridContinuousProcessor.java:1180)
> ~[ignite-core-1.5.23.jar:1.5.23]
> at
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.sendNotification(GridContinuousProcessor.java:841)
> ~[ignite-core-1.5.23.jar:1.5.23]
> at
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.addNotification(GridContinuousProcessor.java:800)
> ~[ignite-core-1.5.23.jar:1.5.23]
> at
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler.onEntryUpdate(CacheContinuousQueryHandler.java:787)
> [ignite-core-1.5.23.jar:1.5.23]
> at
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler.access$700(CacheContinuousQueryHandler.java:91)
> [ignite-core-1.5.23.jar:1.5.23]
> at
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler$1.onEntryUpdated(CacheContinuousQueryHandler.java:412)
> [ignite-core-1.5.23.jar:1.5.23]
> at
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryManager.onEntryUpdated(CacheContinuousQueryManager.java:343)
> [ignite-core-1.5.23.jar:1.5.23]
> at
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryManager.onEntryUpdated(CacheContinuousQueryManager.java:250)
> [ignite-core-1.5.23.jar:1.5.23]
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.initialValue(GridCacheMapEntry.java:3476)
> [ignite-core-1.5.23.jar:1.5.23]
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtForceKeysFuture$MiniFuture.onResult(GridDhtForceKeysFuture.java:548)
> [ignite-core-1.5.23.jar:1.5.23]
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtForceKeysFuture.onResult(GridDhtForceKeysFuture.java:207)
> [ignite-core-1.5.23.jar:1.5.23]
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPreloader.processForceKeyResponse(GridDhtPreloader.java:636)
> [ignite-core-1.5.23.jar:1.5.23]
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPreloader.access$1000(GridDhtPreloader.java:81)
> [ignite-core-1.5.23.jar:1.5.23]
> at
> org.apache.ig
[jira] [Updated] (IGNITE-10714) MVCC TX: JTA transaction manager.
[ https://issues.apache.org/jira/browse/IGNITE-10714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Seliverstov updated IGNITE-10714: -- Component/s: mvcc > MVCC TX: JTA transaction manager. > - > > Key: IGNITE-10714 > URL: https://issues.apache.org/jira/browse/IGNITE-10714 > Project: Ignite > Issue Type: Bug > Components: mvcc >Reporter: Igor Seliverstov >Priority: Major > Fix For: 2.8 > > > Add JTA transactions support for MVCC transactions -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10714) MVCC TX: JTA transaction manager.
Igor Seliverstov created IGNITE-10714: - Summary: MVCC TX: JTA transaction manager. Key: IGNITE-10714 URL: https://issues.apache.org/jira/browse/IGNITE-10714 Project: Ignite Issue Type: Bug Reporter: Igor Seliverstov Add JTA transactions support for MVCC transactions -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10714) MVCC TX: JTA transaction manager.
[ https://issues.apache.org/jira/browse/IGNITE-10714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Seliverstov updated IGNITE-10714: -- Ignite Flags: (was: Docs Required) > MVCC TX: JTA transaction manager. > - > > Key: IGNITE-10714 > URL: https://issues.apache.org/jira/browse/IGNITE-10714 > Project: Ignite > Issue Type: Bug > Components: mvcc >Reporter: Igor Seliverstov >Priority: Major > Fix For: 2.8 > > > Add JTA transactions support for MVCC transactions -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10714) MVCC TX: JTA transaction manager.
[ https://issues.apache.org/jira/browse/IGNITE-10714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Seliverstov updated IGNITE-10714: -- Fix Version/s: 2.8 > MVCC TX: JTA transaction manager. > - > > Key: IGNITE-10714 > URL: https://issues.apache.org/jira/browse/IGNITE-10714 > Project: Ignite > Issue Type: Bug > Components: mvcc >Reporter: Igor Seliverstov >Priority: Major > Fix For: 2.8 > > > Add JTA transactions support for MVCC transactions -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9322) MVCC: implement deadlock detector
[ https://issues.apache.org/jira/browse/IGNITE-9322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16723063#comment-16723063 ] Igor Seliverstov commented on IGNITE-9322: -- [~Pavlukhin], see my comments below: 1) Why you use MvccMessage as an interface for deadlock messages? 2) Make DdCollaborator a separate manager and put it into cache shared context at the last place. 3) Put all listeners and corresponding logic into this new manager. 4) I think request-reply logic is redundant, we can use only one message type and send it to all wait graph participants one by one, rolling back a tx as soon as we get an previously sent message back. > MVCC: implement deadlock detector > - > > Key: IGNITE-9322 > URL: https://issues.apache.org/jira/browse/IGNITE-9322 > Project: Ignite > Issue Type: Task > Components: mvcc >Reporter: Vladimir Ozerov >Assignee: Ivan Pavlukhin >Priority: Major > Labels: MakeTeamcityGreenAgain > > Deadlocks are not uncommon during SQL execution. > We need to implement distributed deadlock detection protocol for MVCC. > Essentially, nodes should exchange some map of tx wait lists, and try to find > a loop. If loop is found, then one of problematic transactions should be > rolled back. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10434) MVCC: Transaction asynchronous rollback bug.
[
https://issues.apache.org/jira/browse/IGNITE-10434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16723952#comment-16723952
]
Igor Seliverstov commented on IGNITE-10434:
---
[~vozerov], please look at.
> MVCC: Transaction asynchronous rollback bug.
>
>
> Key: IGNITE-10434
> URL: https://issues.apache.org/jira/browse/IGNITE-10434
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Reporter: Roman Kondakov
>Assignee: Igor Seliverstov
>Priority: Major
>
> There is some bug in mvcc tx asynchronous rollback flow. Sometimes
> transaction is not rolled back completely: Remote transactions remain alive
> while Near and Dht transactions are terminated locally and on MVCC
> coordinator.
> Reproducer: {{MvccTxRollbackAsyncTest#testMixedAsyncRollbackTypes}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10729) MVCC TX: Improvements.
Igor Seliverstov created IGNITE-10729: - Summary: MVCC TX: Improvements. Key: IGNITE-10729 URL: https://issues.apache.org/jira/browse/IGNITE-10729 Project: Ignite Issue Type: Improvement Components: mvcc Reporter: Igor Seliverstov Currently there are several problems: 1) vacuum doesn't have change set, this means it travers all data to find invisible entries; hanse it breaks read statistics and make all data set "hot" - we should travers data entries instead, and only those entries, which was updated (linked to newer versions), moreover, vacuum should travers only those data pages, which were updated after last successful vacuum (at least one entry on the data page was linked to a never one) 2) vacuum travers over partitions instead of data entries, so, there possible some races like: reader checks an entry; updater removes this entry from partition; vacuum doesn't see the entry and clean TxLog -> reader cannot check the entry state with TxLog and gets an exception. This race prevents an optimization when all entries, older than last successful vacuum version, are considered as COMMITTED (see previous suggestion) 3) all entry versions are placed in BTrees, so, we cannot do updates like PG - just adding a new version and linking the old one to it. Having only one unversioned item per row in all indexes making possible fast invoke operations on such indexes in MVCC mode. Also it let us not to update all indexes on each update operation (partition index isn't updated at all, only SQL indexes, built over changed fields need to be updated) - this dramatically reduces write operations, hence it reduces amount of pages to be "checkpointed" and reduces checkpoint mark phase. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10730) MVCC TX: Batch WAL datarecords
Igor Seliverstov created IGNITE-10730: - Summary: MVCC TX: Batch WAL datarecords Key: IGNITE-10730 URL: https://issues.apache.org/jira/browse/IGNITE-10730 Project: Ignite Issue Type: Improvement Components: mvcc Reporter: Igor Seliverstov on MVCC updates we make changes one by one and WAL records are written straight after successful update under the same checkpoint lock. This produces contention on wal flush operations and harm overall performance. But we need only one guarantee - all the records have to be written into the log before prepare start. That means we free to batch such writes (for example 10 rows in one data record) it shouldn't cause memory issues but will resolve contention. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10474) MVCC: IgniteCacheConnectionRecovery10ConnectionsTest.testConnectionRecovery fails.
[ https://issues.apache.org/jira/browse/IGNITE-10474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16724980#comment-16724980 ] Igor Seliverstov commented on IGNITE-10474: --- [~rkondakov], could you trigger TC run to proof there is no issue anymore? > MVCC: IgniteCacheConnectionRecovery10ConnectionsTest.testConnectionRecovery > fails. > -- > > Key: IGNITE-10474 > URL: https://issues.apache.org/jira/browse/IGNITE-10474 > Project: Ignite > Issue Type: Bug > Components: mvcc >Reporter: Andrew Mashenkov >Assignee: Roman Kondakov >Priority: Major > Labels: Hanging > > IgniteCacheConnectionRecovery10ConnectionsTest.testConnectionRecovery fails > due to hanging. > We have to investigate and fix this. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9303) PageSnapshot can contain wrong pageId tag when not dirty page is recycling
[
https://issues.apache.org/jira/browse/IGNITE-9303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Seliverstov updated IGNITE-9303:
-
Description:
# When page is recycling (for example in {{BPlusTree.Remove#freePage()}} ->
{{DataStructure#recyclePage()}}) tag of {{pageId}} is modified, but original
{{pageId}} is passed to {{writeUnlock()}} method and this passed {{pageId}} is
stored to PageSnapshot WAL record.
This bug may lead to errors in WAL applying during crash recovery.
Reproducer (ignite-indexing module must be in classpath):
{code:java}
public class WalFailReproducer extends AbstractWalDeltaConsistencyTest {
@Override protected boolean checkPagesOnCheckpoint() {
return true;
}
public final void testPutRemoveCacheDestroy() throws Exception {
CacheConfiguration ccfg = new
CacheConfiguration<>("cache0");
ccfg.setIndexedTypes(Integer.class, Integer.class);
IgniteEx ignite = startGrid(0);
ignite.cluster().active(true);
IgniteCache cache0 = ignite.getOrCreateCache(ccfg);
for (int i = 0; i < 5_000; i++)
cache0.put(i, i);
forceCheckpoint();
for (int i = 1_000; i < 4_000; i++)
cache0.remove(i);
forceCheckpoint();
stopAllGrids();
}
}
{code}
was:
When page is recycling (for example in {{BPlusTree.Remove#freePage()}} ->
{{DataStructure#recyclePage()}}) tag of {{pageId}} is modified, but original
{{pageId}} is passed to {{writeUnlock()}} method and this passed {{pageId}} is
stored to PageSnapshot WAL record.
This bug may lead to errors in WAL applying during crash recovery.
Reproducer (ignite-indexing module must be in classpath):
{code:java}
public class WalFailReproducer extends AbstractWalDeltaConsistencyTest {
@Override protected boolean checkPagesOnCheckpoint() {
return true;
}
public final void testPutRemoveCacheDestroy() throws Exception {
CacheConfiguration ccfg = new
CacheConfiguration<>("cache0");
ccfg.setIndexedTypes(Integer.class, Integer.class);
IgniteEx ignite = startGrid(0);
ignite.cluster().active(true);
IgniteCache cache0 = ignite.getOrCreateCache(ccfg);
for (int i = 0; i < 5_000; i++)
cache0.put(i, i);
forceCheckpoint();
for (int i = 1_000; i < 4_000; i++)
cache0.remove(i);
forceCheckpoint();
stopAllGrids();
}
}
{code}
> PageSnapshot can contain wrong pageId tag when not dirty page is recycling
> --
>
> Key: IGNITE-9303
> URL: https://issues.apache.org/jira/browse/IGNITE-9303
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.6
>Reporter: Aleksey Plekhanov
>Assignee: Ilya Lantukh
>Priority: Major
> Fix For: 2.8
>
>
> # When page is recycling (for example in {{BPlusTree.Remove#freePage()}} ->
> {{DataStructure#recyclePage()}}) tag of {{pageId}} is modified, but original
> {{pageId}} is passed to {{writeUnlock()}} method and this passed {{pageId}}
> is stored to PageSnapshot WAL record.
> This bug may lead to errors in WAL applying during crash recovery.
> Reproducer (ignite-indexing module must be in classpath):
> {code:java}
> public class WalFailReproducer extends AbstractWalDeltaConsistencyTest {
> @Override protected boolean checkPagesOnCheckpoint() {
> return true;
> }
> public final void testPutRemoveCacheDestroy() throws Exception {
> CacheConfiguration ccfg = new
> CacheConfiguration<>("cache0");
> ccfg.setIndexedTypes(Integer.class, Integer.class);
> IgniteEx ignite = startGrid(0);
> ignite.cluster().active(true);
> IgniteCache cache0 = ignite.getOrCreateCache(ccfg);
> for (int i = 0; i < 5_000; i++)
> cache0.put(i, i);
> forceCheckpoint();
> for (int i = 1_000; i < 4_000; i++)
> cache0.remove(i);
> forceCheckpoint();
> stopAllGrids();
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9303) PageSnapshot can contain wrong pageId tag when not dirty page is recycling
[
https://issues.apache.org/jira/browse/IGNITE-9303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Seliverstov updated IGNITE-9303:
-
Description:
When page is recycling (for example in {{BPlusTree.Remove#freePage()}} ->
{{DataStructure#recyclePage()}}) tag of {{pageId}} is modified, but original
{{pageId}} is passed to {{writeUnlock()}} method and this passed {{pageId}} is
stored to PageSnapshot WAL record.
This bug may lead to errors in WAL applying during crash recovery.
Reproducer (ignite-indexing module must be in classpath):
{code:java}
public class WalFailReproducer extends AbstractWalDeltaConsistencyTest {
@Override protected boolean checkPagesOnCheckpoint() {
return true;
}
public final void testPutRemoveCacheDestroy() throws Exception {
CacheConfiguration ccfg = new
CacheConfiguration<>("cache0");
ccfg.setIndexedTypes(Integer.class, Integer.class);
IgniteEx ignite = startGrid(0);
ignite.cluster().active(true);
IgniteCache cache0 = ignite.getOrCreateCache(ccfg);
for (int i = 0; i < 5_000; i++)
cache0.put(i, i);
forceCheckpoint();
for (int i = 1_000; i < 4_000; i++)
cache0.remove(i);
forceCheckpoint();
stopAllGrids();
}
}
{code}
was:
# When page is recycling (for example in {{BPlusTree.Remove#freePage()}} ->
{{DataStructure#recyclePage()}}) tag of {{pageId}} is modified, but original
{{pageId}} is passed to {{writeUnlock()}} method and this passed {{pageId}} is
stored to PageSnapshot WAL record.
This bug may lead to errors in WAL applying during crash recovery.
Reproducer (ignite-indexing module must be in classpath):
{code:java}
public class WalFailReproducer extends AbstractWalDeltaConsistencyTest {
@Override protected boolean checkPagesOnCheckpoint() {
return true;
}
public final void testPutRemoveCacheDestroy() throws Exception {
CacheConfiguration ccfg = new
CacheConfiguration<>("cache0");
ccfg.setIndexedTypes(Integer.class, Integer.class);
IgniteEx ignite = startGrid(0);
ignite.cluster().active(true);
IgniteCache cache0 = ignite.getOrCreateCache(ccfg);
for (int i = 0; i < 5_000; i++)
cache0.put(i, i);
forceCheckpoint();
for (int i = 1_000; i < 4_000; i++)
cache0.remove(i);
forceCheckpoint();
stopAllGrids();
}
}
{code}
> PageSnapshot can contain wrong pageId tag when not dirty page is recycling
> --
>
> Key: IGNITE-9303
> URL: https://issues.apache.org/jira/browse/IGNITE-9303
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.6
>Reporter: Aleksey Plekhanov
>Assignee: Ilya Lantukh
>Priority: Major
> Fix For: 2.8
>
>
> When page is recycling (for example in {{BPlusTree.Remove#freePage()}} ->
> {{DataStructure#recyclePage()}}) tag of {{pageId}} is modified, but original
> {{pageId}} is passed to {{writeUnlock()}} method and this passed {{pageId}}
> is stored to PageSnapshot WAL record.
> This bug may lead to errors in WAL applying during crash recovery.
> Reproducer (ignite-indexing module must be in classpath):
> {code:java}
> public class WalFailReproducer extends AbstractWalDeltaConsistencyTest {
> @Override protected boolean checkPagesOnCheckpoint() {
> return true;
> }
> public final void testPutRemoveCacheDestroy() throws Exception {
> CacheConfiguration ccfg = new
> CacheConfiguration<>("cache0");
> ccfg.setIndexedTypes(Integer.class, Integer.class);
> IgniteEx ignite = startGrid(0);
> ignite.cluster().active(true);
> IgniteCache cache0 = ignite.getOrCreateCache(ccfg);
> for (int i = 0; i < 5_000; i++)
> cache0.put(i, i);
> forceCheckpoint();
> for (int i = 1_000; i < 4_000; i++)
> cache0.remove(i);
> forceCheckpoint();
> stopAllGrids();
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-10752) MVCC: Tests invariants are violated sometimes
[
https://issues.apache.org/jira/browse/IGNITE-10752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Seliverstov reassigned IGNITE-10752:
-
Assignee: Igor Seliverstov
> MVCC: Tests invariants are violated sometimes
> -
>
> Key: IGNITE-10752
> URL: https://issues.apache.org/jira/browse/IGNITE-10752
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Reporter: Roman Kondakov
>Assignee: Igor Seliverstov
>Priority: Major
> Labels: mvcc_stabilization_stage_1, transactions
>
> Sometimes tests are failed by violated invariants errors. For example, when
> total sum on accounts is not as expected.
> Muted tests:
> * {{CacheMvccPartitionedCoordinatorFailoverTest}}
> **
> {{testUpdate_N_Objects_Servers_Backups0__PutGet_CoordinatorFails_Persistence}}
> ** {{testUpdate_N_Objects_SingleNode__PutGet_CoordinatorFails}}
> **
> {{testUpdate_N_Objects_ClientServer_Backups1_PutGet_CoordinatorFails_Persistence}}
> ** {{testAccountsTxGet_SingleNode_CoordinatorFails}}
> ** {{testAccountsTxGet_Server_Backups1_CoordinatorFails}}
> ** {{testAccountsTxGet_ClientServer_Backups2_CoordinatorFails_Persistence}}
> ** {{testAccountsTxScan_Server_Backups1_CoordinatorFails_Persistence}}
> ** {{testAccountsTxScan_Server_Backups0_CoordinatorFails}}
> ** {{testGetReadInProgressCoordinatorFails}}
> ** {{testGetReadInsideTxInProgressCoordinatorFails_ReadDelay}}
> * {{CacheMvccReplicatedCoordinatorFailoverTest}}
> ** {{testAccountsTxGet_SingleNode_CoordinatorFails}}
> ** {{testAccountsTxGet_Server_Backups0_CoordinatorFails_Persistence}}
> ** {{testUpdate_N_Objects_SingleNode__PutGet_CoordinatorFails}}
> * {{CacheMvccTransactionsTest.testMvccCoordinatorChangeSimple}}
> * {{DataStreamProcessorMvccPersistenceSelfTest.testTryFlush}}
> * {{IgniteCacheGroupsTest.testCreateDestroyCachesMvccTxReplicated}}
> *
> {{CacheMvccReplicatedSqlCoordinatorFailoverTest.testUpdate_N_Objects_ClientServer_Backups0_Sql_Persistence}}
> * {{CacheMvccPartitionedSqlCoordinatorFailoverTest}}
> ** {{testUpdate_N_Objects_ClientServer_Backups2_Sql}}
> ** {{testUpdate_N_Objects_ClientServer_Backups1_Sql_Persistence}}
> ** {{testUpdate_N_Objects_SingleNode_Sql_Persistence}}
> ** {{testUpdate_N_Objects_ClientServer_Backups0_Sql_Persistence}}
> **
> {{testPutAllGetAll_ClientServer_Backups1_SinglePartition_RestartRandomSrv_SqlDml}}
> **
> {{testPutAllGetAll_Server_Backups1_SinglePartition_RestartRandomSrv_SqlDml}}
> ** {{testPutAllGetAll_ClientServer_Backups3_RestartCoordinator_ScanDml}}
> ** {{testAccountsTxSql_Server_Backups0_CoordinatorFails}}
> ** {{testAccountsTxSql_Server_Backups1_CoordinatorFails_Persistence}}
> {noformat}
> junit.framework.AssertionFailedError: Unexpected error:
> junit.framework.AssertionFailedError: expected:<0> but was:<4>
> at junit.framework.Assert.fail(Assert.java:57)
> at junit.framework.TestCase.fail(TestCase.java:227)
> at
> org.apache.ignite.internal.processors.cache.mvcc.CacheMvccAbstractTest$10.call(CacheMvccAbstractTest.java:1362)
> at
> org.apache.ignite.internal.processors.cache.mvcc.CacheMvccAbstractTest$10.call(CacheMvccAbstractTest.java:1350)
> at
> org.apache.ignite.testframework.GridTestThread.run(GridTestThread.java:84)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10537) MVCC: Client reconnect tests became unstable after mvcc coordinator reassign fix.
[ https://issues.apache.org/jira/browse/IGNITE-10537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16726587#comment-16726587 ] Igor Seliverstov commented on IGNITE-10537: --- [~vozerov], could you look at? > MVCC: Client reconnect tests became unstable after mvcc coordinator reassign > fix. > - > > Key: IGNITE-10537 > URL: https://issues.apache.org/jira/browse/IGNITE-10537 > Project: Ignite > Issue Type: Bug > Components: mvcc >Reporter: Roman Kondakov >Assignee: Igor Seliverstov >Priority: Major > Labels: CQ, mvcc_stabilization_stage_1 > > It looks like tests > [CacheMvccContinuousQueryClientReconnectTest.testReconnectClient|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=7778544852295951300&tab=testDetails] > and > [CacheMvccContinuousQueryClientReconnectTest.testReconnectClientAndLeftRouter|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=-8370258276605466922&tab=testDetails] > became flaky after commit _5477048 rkondakov on > 22.11.18 at 14:35_. Weshould investigate and fix this problem. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10829) MVCC TX: Lazy query execution for query enlists.
Igor Seliverstov created IGNITE-10829: - Summary: MVCC TX: Lazy query execution for query enlists. Key: IGNITE-10829 URL: https://issues.apache.org/jira/browse/IGNITE-10829 Project: Ignite Issue Type: Improvement Components: mvcc Affects Versions: 2.7 Reporter: Igor Seliverstov Fix For: 2.8 Implement lazy query execution using semantic goes from IGNITE-9171. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10434) MVCC: Transaction asynchronous rollback bug.
[
https://issues.apache.org/jira/browse/IGNITE-10434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16729454#comment-16729454
]
Igor Seliverstov commented on IGNITE-10434:
---
[~vozerov], The answer on both questions - currently lazy=false forces for such
DML requests, initially there were dozens of problems with H2 cursors and
connections, so, we weren't able to detach and reattach query processes from
one to another thread gracefully. As first implementation lazy=false just was
forced.
this means:
1) only first call is time consuming, which executes the query and prepares
full set of rows, each subsequent call is non blocking, so, it executes in the
cache pool.
2) as far as there is no lazy execution there is no lock related problems at
now. A fair lazy execution implementation is addressed for further releases.
IGNITE-10829 is raised for this activity.
> MVCC: Transaction asynchronous rollback bug.
>
>
> Key: IGNITE-10434
> URL: https://issues.apache.org/jira/browse/IGNITE-10434
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Reporter: Roman Kondakov
>Assignee: Igor Seliverstov
>Priority: Major
> Labels: mvcc_stabilization_stage_1, transactions
> Fix For: 2.8
>
>
> There is some bug in mvcc tx asynchronous rollback flow. Sometimes
> transaction is not rolled back completely: Remote transactions remain alive
> while Near and Dht transactions are terminated locally and on MVCC
> coordinator.
> Reproducer: {{MvccTxRollbackAsyncTest#testMixedAsyncRollbackTypes}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10434) MVCC: Transaction asynchronous rollback bug.
[
https://issues.apache.org/jira/browse/IGNITE-10434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16729462#comment-16729462
]
Igor Seliverstov commented on IGNITE-10434:
---
[~vozerov] full set of rows is stored in ResultSet, which wrapped by
QueryCursor, which wrapped by UpdateSourceIterator and stored in an appropriate
field of an enlist future.
> MVCC: Transaction asynchronous rollback bug.
>
>
> Key: IGNITE-10434
> URL: https://issues.apache.org/jira/browse/IGNITE-10434
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Reporter: Roman Kondakov
>Assignee: Igor Seliverstov
>Priority: Major
> Labels: mvcc_stabilization_stage_1, transactions
> Fix For: 2.8
>
>
> There is some bug in mvcc tx asynchronous rollback flow. Sometimes
> transaction is not rolled back completely: Remote transactions remain alive
> while Near and Dht transactions are terminated locally and on MVCC
> coordinator.
> Reproducer: {{MvccTxRollbackAsyncTest#testMixedAsyncRollbackTypes}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10829) MVCC TX: Lazy query execution for query enlists.
[ https://issues.apache.org/jira/browse/IGNITE-10829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Seliverstov updated IGNITE-10829: -- Description: Running query enlist operations (GridNearTxQueryEnlistFuture) we put query execution to data nodes, such execution runs a local select (GridDhtTxQueryEnlistFuture), gets a cursor and executes write operation for each select result row. The main difficult starts when we cannot execute whole operation at once (due to lock conflict or backup message queue overflow). Such case we break iteration and save a context (detach H2 connection for further exclusive usage and save current position in cursor). There is no issue since in non-lazy mode the cursor internally have a list of all needed entries and doesn't hold any resources but in lazy mode we may face two issues: 1) Schema change in between of iteration 2) Possible starvation because of heavy time consuming operations in cache pool, which used by default for operation continuation. As soon as IGNITE-9171 is implemented, possible lazy execution is had to be taken into consideration. This mean: 1) before braking iteration we need to release all holding shared locks on on being iterated tables. 2) before continue iteration we need to acquire shared locks on all needed tables and check the schema wasn't changed in between locks were acquired. 3) the operation should be continued in the same pool it was started to prevent possible starvation of concurrent cache operations. was:Implement lazy query execution using semantic goes from IGNITE-9171. > MVCC TX: Lazy query execution for query enlists. > > > Key: IGNITE-10829 > URL: https://issues.apache.org/jira/browse/IGNITE-10829 > Project: Ignite > Issue Type: Improvement > Components: mvcc >Affects Versions: 2.7 >Reporter: Igor Seliverstov >Priority: Major > Fix For: 2.8 > > > Running query enlist operations (GridNearTxQueryEnlistFuture) we put query > execution to data nodes, such execution runs a local select > (GridDhtTxQueryEnlistFuture), gets a cursor and executes write operation for > each select result row. > The main difficult starts when we cannot execute whole operation at once (due > to lock conflict or backup message queue overflow). Such case we break > iteration and save a context (detach H2 connection for further exclusive > usage and save current position in cursor). There is no issue since in > non-lazy mode the cursor internally have a list of all needed entries and > doesn't hold any resources but in lazy mode we may face two issues: > 1) Schema change in between of iteration > 2) Possible starvation because of heavy time consuming operations in cache > pool, which used by default for operation continuation. > As soon as IGNITE-9171 is implemented, possible lazy execution is had to be > taken into consideration. This mean: > 1) before braking iteration we need to release all holding shared locks on on > being iterated tables. > 2) before continue iteration we need to acquire shared locks on all needed > tables and check the schema wasn't changed in between locks were acquired. > 3) the operation should be continued in the same pool it was started to > prevent possible starvation of concurrent cache operations. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-10434) MVCC: Transaction asynchronous rollback bug.
[
https://issues.apache.org/jira/browse/IGNITE-10434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Seliverstov resolved IGNITE-10434.
---
Resolution: Fixed
Merged to master.
> MVCC: Transaction asynchronous rollback bug.
>
>
> Key: IGNITE-10434
> URL: https://issues.apache.org/jira/browse/IGNITE-10434
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Reporter: Roman Kondakov
>Assignee: Igor Seliverstov
>Priority: Major
> Labels: mvcc_stabilization_stage_1, transactions
> Fix For: 2.8
>
>
> There is some bug in mvcc tx asynchronous rollback flow. Sometimes
> transaction is not rolled back completely: Remote transactions remain alive
> while Near and Dht transactions are terminated locally and on MVCC
> coordinator.
> Reproducer: {{MvccTxRollbackAsyncTest#testMixedAsyncRollbackTypes}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10763) MVCC: Transaction already completed error in some tests
[
https://issues.apache.org/jira/browse/IGNITE-10763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16738297#comment-16738297
]
Igor Seliverstov commented on IGNITE-10763:
---
[~Pavlukhin], could you move context reset into SFU future {{onDone()}} and
{{GridNearTxLocal#updateAsync()}} methods?
> MVCC: Transaction already completed error in some tests
> ---
>
> Key: IGNITE-10763
> URL: https://issues.apache.org/jira/browse/IGNITE-10763
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Reporter: Roman Kondakov
>Assignee: Ivan Pavlukhin
>Priority: Major
> Labels: MakeTeamcityGreenAgain, mvcc_stabilization_stage_1,
> transactions
> Fix For: 2.8
>
>
> "Transaction is already completed" error occurs time to time in some tests.
> Reproducer:
> {{CacheMvccReplicatedSqlTxQueriesTest.testReplicatedAndPartitionedUpdateSingleTransaction}}
> {{CacheMvccPartitionedSqlTxQueriesWithReducerTest.testQueryReducerDeadlockInsertWithTxTimeout}}
>
> {noformat}
> class org.apache.ignite.internal.processors.query.IgniteSQLException:
> Transaction is already completed.
> at
> org.apache.ignite.internal.processors.cache.mvcc.MvccUtils.checkActive(MvccUtils.java:660)
> at
> org.apache.ignite.internal.processors.cache.mvcc.MvccUtils.requestSnapshot(MvccUtils.java:832)
> at
> org.apache.ignite.internal.processors.cache.mvcc.MvccUtils.mvccTracker(MvccUtils.java:813)
> at
> org.apache.ignite.internal.processors.cache.mvcc.MvccUtils.mvccTracker(MvccUtils.java:796)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.runQueryTwoStep(IgniteH2Indexing.java:1131)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.doRunDistributedQuery(IgniteH2Indexing.java:1990)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.doRunPrepared(IgniteH2Indexing.java:1636)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.querySqlFields(IgniteH2Indexing.java:1526)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$3.applyx(GridQueryProcessor.java:2167)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$3.applyx(GridQueryProcessor.java:2162)
> at
> org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2670)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.lambda$querySqlFields$1(GridQueryProcessor.java:2176)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuerySafe(GridQueryProcessor.java:2196)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2157)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2118)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2091)
> at
> org.apache.ignite.internal.processors.cache.mvcc.CacheMvccReplicatedSqlTxQueriesTest.runSql(CacheMvccReplicatedSqlTxQueriesTest.java:234)
> at
> org.apache.ignite.internal.processors.cache.mvcc.CacheMvccReplicatedSqlTxQueriesTest.testReplicatedAndPartitionedUpdateSingleTransaction(CacheMvccReplicatedSqlTxQueriesTest.java:202)
> 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
> org.apache.ignite.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-10778) MVCC: Invoke request may hang sometimes
[
https://issues.apache.org/jira/browse/IGNITE-10778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16738306#comment-16738306
]
Igor Seliverstov commented on IGNITE-10778:
---
[~rkondakov], Timeout increasing doesn't look like good fix from my point of
view. In case there is a kind of load testing here, lets just turn it into time
based test instead of counting iterations - this should be more predictable
> MVCC: Invoke request may hang sometimes
> ---
>
> Key: IGNITE-10778
> URL: https://issues.apache.org/jira/browse/IGNITE-10778
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Reporter: Roman Kondakov
>Assignee: Roman Kondakov
>Priority: Major
> Labels: Hanging, mvcc_stabilization_stage_1
> Fix For: 2.8
>
>
> Invoke request may hang sometimes. Reproducer:
> {{GridCacheMultinodeUpdateSelfTest.testInvoke}} with enabled MVCC.
> Stacktrace:
> {noformat}
> Thread [name="invoke-3", id=447, state=WAITING, blockCnt=0, waitCnt=1745]
> 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:178)
> at
> o.a.i.i.util.future.GridFutureAdapter.get(GridFutureAdapter.java:141)
> at
> o.a.i.i.processors.cache.distributed.near.GridNearTxLocal.rollback(GridNearTxLocal.java:3792)
> at
> o.a.i.i.processors.cache.GridCacheAdapter.syncOp(GridCacheAdapter.java:4256)
> at
> o.a.i.i.processors.cache.GridCacheAdapter.invoke0(GridCacheAdapter.java:2608)
> at
> o.a.i.i.processors.cache.GridCacheAdapter.invoke(GridCacheAdapter.java:2586)
> at
> o.a.i.i.processors.cache.IgniteCacheProxyImpl.invoke(IgniteCacheProxyImpl.java:1437)
> at
> o.a.i.i.processors.cache.GatewayProtectedCacheProxy.invoke(GatewayProtectedCacheProxy.java:1204)
> at
> o.a.i.i.processors.cache.GridCacheMultinodeUpdateAbstractSelfTest$1.call(GridCacheMultinodeUpdateAbstractSelfTest.java:111)
> at
> o.a.i.i.processors.cache.GridCacheMultinodeUpdateAbstractSelfTest$1.call(GridCacheMultinodeUpdateAbstractSelfTest.java:100)
> at o.a.i.testframework.GridTestThread.run(GridTestThread.java:84)
> Thread [name="invoke-2", id=446, state=WAITING, blockCnt=0, waitCnt=1738]
> 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:178)
> at
> o.a.i.i.util.future.GridFutureAdapter.get(GridFutureAdapter.java:141)
> at
> o.a.i.i.processors.cache.mvcc.MvccUtils.requestSnapshot(MvccUtils.java:841)
> at
> o.a.i.i.processors.cache.distributed.near.GridNearTxLocal.mvccPutAllAsync0(GridNearTxLocal.java:723)
> at
> o.a.i.i.processors.cache.distributed.near.GridNearTxLocal.putAsync0(GridNearTxLocal.java:578)
> at
> o.a.i.i.processors.cache.distributed.near.GridNearTxLocal.invokeAsync(GridNearTxLocal.java:467)
> at
> o.a.i.i.processors.cache.GridCacheAdapter$25.op(GridCacheAdapter.java:2620)
> at
> o.a.i.i.processors.cache.GridCacheAdapter$25.op(GridCacheAdapter.java:2608)
> at
> o.a.i.i.processors.cache.GridCacheAdapter.syncOp(GridCacheAdapter.java:4244)
> at
> o.a.i.i.processors.cache.GridCacheAdapter.invoke0(GridCacheAdapter.java:2608)
> at
> o.a.i.i.processors.cache.GridCacheAdapter.invoke(GridCacheAdapter.java:2586)
> at
> o.a.i.i.processors.cache.IgniteCacheProxyImpl.invoke(IgniteCacheProxyImpl.java:1437)
> at
> o.a.i.i.processors.cache.GatewayProtectedCacheProxy.invoke(GatewayProtectedCacheProxy.java:1204)
> at
> o.a.i.i.processors.cache.GridCacheMultinodeUpdateAbstractSelfTest$1.call(GridCacheMultinodeUpdateAbstractSelfTest.java:111)
> at
> o.a.i.i.processors.cache.GridCacheMultinodeUpdateAbstractSelfTest$1.call(GridCacheMultinodeUpdateAbstractSelfTest.java:100)
> at o.a.i.testframework.GridTestThread.run(GridTestThread.java:84)
> Thread [name="invoke-1", id=445, state=WAITING, blockCnt=0, waitCnt=1916]
> 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:178)
> at
> o.a.i.i.util.future.GridFutureAdapter.get(GridFutureAdapter.java:141)
> at
> o.a.i.i.processors.cache.GridCacheAdapter$25.op(GridCacheAdapter.java:2626)
> at
> o.a.i.i.processors.cache.GridCacheAdapter$25.op(GridCacheAdapter.java:2608)
> at
> o.a.i.i.processors.cache.GridCacheAdapter.syncOp(GridCacheAdapter.java:4244)
> at
> o.a.i.i.processors.cache.
[jira] [Commented] (IGNITE-10794) MVCC: RemoveAll is broken on unstable topology
[
https://issues.apache.org/jira/browse/IGNITE-10794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16740383#comment-16740383
]
Igor Seliverstov commented on IGNITE-10794:
---
Merged to master.
> MVCC: RemoveAll is broken on unstable topology
> --
>
> Key: IGNITE-10794
> URL: https://issues.apache.org/jira/browse/IGNITE-10794
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Reporter: Andrew Mashenkov
>Assignee: Andrew Mashenkov
>Priority: Critical
> Labels: Hanging, mvcc_stabilization_stage_1, transaction
> Fix For: 2.8
>
>
> Enlist batch holds key and values in arrays structures. This implies that
> keys and vals arrays sizes should be equals.
> Also, we have an optimization and do not save 'null' vals for 'remove'
> operation.
> This invariant can become broken on removeAll operation for 2 entries
> belonging to partitions in different states (moving and owning). For the
> first one, it's 'mvcc history' will be added to 'vals' array, but nothing
> will be added for the second one.
> Reproducer IgniteCacheEntryProcessorNodeJoinTest.testEntryProcessorNodeLeave
> See stacktrace:
> {noformat}
> java.lang.AssertionError:
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxAbstractEnlistFuture$Batch.add(GridDhtTxAbstractEnlistFuture.java:1156)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxAbstractEnlistFuture.addToBatch(GridDhtTxAbstractEnlistFuture.java:705)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxAbstractEnlistFuture.processEntry(GridDhtTxAbstractEnlistFuture.java:650)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxAbstractEnlistFuture.continueLoop(GridDhtTxAbstractEnlistFuture.java:533)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxAbstractEnlistFuture.init(GridDhtTxAbstractEnlistFuture.java:362)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxEnlistFuture.enlistLocal(GridNearTxEnlistFuture.java:531)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxEnlistFuture.sendBatch(GridNearTxEnlistFuture.java:426)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxEnlistFuture.sendNextBatches(GridNearTxEnlistFuture.java:173)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxEnlistFuture.map(GridNearTxEnlistFuture.java:149)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxAbstractEnlistFuture.mapOnTopology(GridNearTxAbstractEnlistFuture.java:342)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxAbstractEnlistFuture.init(GridNearTxAbstractEnlistFuture.java:257)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.updateAsync(GridNearTxLocal.java:2074)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.mvccRemoveAllAsync0(GridNearTxLocal.java:1951)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.removeAllAsync0(GridNearTxLocal.java:1670)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.removeAllAsync(GridNearTxLocal.java:550)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10956) MVCC TX: Move queryEnlisted flag from IgniteTxLocalAdapter to IgniteTxState
Igor Seliverstov created IGNITE-10956: - Summary: MVCC TX: Move queryEnlisted flag from IgniteTxLocalAdapter to IgniteTxState Key: IGNITE-10956 URL: https://issues.apache.org/jira/browse/IGNITE-10956 Project: Ignite Issue Type: Improvement Components: mvcc Reporter: Igor Seliverstov queryEnlisted flag represents a transaction state (like txState.empty(), in other words shows whether there were some updates on MVCC caches or not). It makes sense to move such flag to IgniteTxState. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-10798) Data page scan for ScanQuery, SqlQuery and SqlFieldsQuery
[ https://issues.apache.org/jira/browse/IGNITE-10798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16744972#comment-16744972 ] Igor Seliverstov edited comment on IGNITE-10798 at 1/17/19 12:18 PM: - [~vozerov],[~sergi.vladykin], the main cause is a deadlock. There is no tx timeout and account ids are random and unsorted. Until IGNITE-9322 is not done you need to resolve deadlocks manually (using timeouts or sorting) was (Author: gvvinblade): [~vozerov],[~sergi.vladykin], the main cause is a deadlock. There is no tx timeout and account ids are random and unsorted. > Data page scan for ScanQuery, SqlQuery and SqlFieldsQuery > - > > Key: IGNITE-10798 > URL: https://issues.apache.org/jira/browse/IGNITE-10798 > Project: Ignite > Issue Type: Improvement > Components: cache, sql >Reporter: Sergi Vladykin >Assignee: Sergi Vladykin >Priority: Major > Fix For: 2.8 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10798) Data page scan for ScanQuery, SqlQuery and SqlFieldsQuery
[ https://issues.apache.org/jira/browse/IGNITE-10798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16744972#comment-16744972 ] Igor Seliverstov commented on IGNITE-10798: --- [~vozerov],[~sergi.vladykin], the main cause is a deadlock. There is no tx timeout and account ids are random and unsorted. > Data page scan for ScanQuery, SqlQuery and SqlFieldsQuery > - > > Key: IGNITE-10798 > URL: https://issues.apache.org/jira/browse/IGNITE-10798 > Project: Ignite > Issue Type: Improvement > Components: cache, sql >Reporter: Sergi Vladykin >Assignee: Sergi Vladykin >Priority: Major > Fix For: 2.8 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10798) Data page scan for ScanQuery, SqlQuery and SqlFieldsQuery
[ https://issues.apache.org/jira/browse/IGNITE-10798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16745067#comment-16745067 ] Igor Seliverstov commented on IGNITE-10798: --- [~sergi.vladykin], from MVCC perspective looks OK, at least I see no issues. > Data page scan for ScanQuery, SqlQuery and SqlFieldsQuery > - > > Key: IGNITE-10798 > URL: https://issues.apache.org/jira/browse/IGNITE-10798 > Project: Ignite > Issue Type: Improvement > Components: cache, sql >Reporter: Sergi Vladykin >Assignee: Sergi Vladykin >Priority: Major > Fix For: 2.8 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-7307) H2DynamicIndexingComplexServerTransactionalReplicatedTest.testOperations fails with assertion
[
https://issues.apache.org/jira/browse/IGNITE-7307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Seliverstov reassigned IGNITE-7307:
Assignee: Igor Seliverstov
> H2DynamicIndexingComplexServerTransactionalReplicatedTest.testOperations
> fails with assertion
> -
>
> Key: IGNITE-7307
> URL: https://issues.apache.org/jira/browse/IGNITE-7307
> Project: Ignite
> Issue Type: Bug
> Components: mvcc, sql
>Reporter: Vladimir Ozerov
>Assignee: Igor Seliverstov
>Priority: Major
> Labels: mvcc_stabilization_stage_1, transactions
> Fix For: 2.8
>
>
> {code}
> [2017-12-26 11:40:53,187][ERROR][main][root] Test failed.
> java.lang.AssertionError: localNode = cde0ed21-5bfa-48ee-8e47-53d85880,
> dhtNodes = [TcpDiscoveryNode [id=49318149-4b22-40d1-b68f-8b6b2d52,
> addrs=[127.0.0.1], sockAddrs=[/127.0.0.1:47501], discPort=47501, order=3,
> intOrder=3, lastExchangeTime=1514277649002, loc=false,
> ver=2.4.0#19700101-sha1:, isClient=false], TcpDiscoveryNode
> [id=cde0ed21-5bfa-48ee-8e47-53d85880, addrs=[127.0.0.1],
> sockAddrs=[/127.0.0.1:47500], discPort=47500, order=1, intOrder=1,
> lastExchangeTime=1514277652494, loc=true, ver=2.4.0#19700101-sha1:,
> isClient=false], TcpDiscoveryNode [id=7530f231-3bd4-4cc0-b295-0e2f11b3,
> addrs=[127.0.0.1], sockAddrs=[/127.0.0.1:47502], discPort=47502, order=4,
> intOrder=4, lastExchangeTime=1514277649456, loc=false,
> ver=2.4.0#19700101-sha1:, isClient=false]]
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.map(GridDhtTxPrepareFuture.java:1608)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.prepare0(GridDhtTxPrepareFuture.java:1274)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.mapIfLocked(GridDhtTxPrepareFuture.java:678)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.prepare(GridDhtTxPrepareFuture.java:1056)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.prepareAsyncLocal(GridNearTxLocal.java:3619)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.prepareColocatedTx(IgniteTxHandler.java:257)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearPessimisticTxPrepareFuture.prepareLocal(GridNearPessimisticTxPrepareFuture.java:256)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearPessimisticTxPrepareFuture.preparePessimistic(GridNearPessimisticTxPrepareFuture.java:406)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearPessimisticTxPrepareFuture.prepare(GridNearPessimisticTxPrepareFuture.java:190)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.prepareNearTxLocal(GridNearTxLocal.java:3323)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.commitNearTxLocalAsync(GridNearTxLocal.java:3390)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.commit(GridNearTxLocal.java:3350)
> at
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.executeUpdateStatement(DmlStatementsProcessor.java:429)
> at
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.updateSqlFields(DmlStatementsProcessor.java:177)
> at
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.updateSqlFieldsDistributed(DmlStatementsProcessor.java:212)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryDistributedSqlFields(IgniteH2Indexing.java:1809)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryDistributedSqlFields(IgniteH2Indexing.java:1645)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$6.applyx(GridQueryProcessor.java:2034)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$6.applyx(GridQueryProcessor.java:2030)
> at
> org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2527)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFieldsNoCache(GridQueryProcessor.java:2039)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFieldsNoCache(GridQueryProcessor.java:1995)
> at
> org.apache.ignite.internal.processors.cache.index.H2DynamicIndexingComplexTest.executeSql(H2DynamicIndexingCo
[jira] [Updated] (IGNITE-8841) MVCC TX: Read transactions remap when coordinator fails.
[ https://issues.apache.org/jira/browse/IGNITE-8841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Seliverstov updated IGNITE-8841: - Issue Type: Bug (was: Improvement) > MVCC TX: Read transactions remap when coordinator fails. > > > Key: IGNITE-8841 > URL: https://issues.apache.org/jira/browse/IGNITE-8841 > Project: Ignite > Issue Type: Bug > Components: mvcc, sql >Reporter: Roman Kondakov >Priority: Major > Labels: failover > > At the moment read transactions that don't acquire topology lock will be > forcibly rolled back on topology change as read tx can be in fly while > topology being change. > This is done to prevent having active transaction with stale snapshots on > new topology in cases of TX coordinator or Near node were lost. > > It would be nice to remap it somehow until they locked a topology or at least > throw some meaningful exception to user. > For example, it is possible to obtain a new "write" mvcc version from the > new coordinator and use this version for all further writes while using "old" > version for reads. In this case we need to change visibility rules a little: > "old" version should see "own" updates made by "new" "write" version. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8841) MVCC TX: Read transactions remap when coordinator fails.
[ https://issues.apache.org/jira/browse/IGNITE-8841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Seliverstov updated IGNITE-8841: - Description: # At the moment read transactions that don't acquire topology lock will be forcibly rolled back on topology change as read tx can be in fly while topology being change. This is done to prevent having active transaction with stale snapshots on new topology in cases of TX coordinator or Near node were lost. It would be nice to remap it somehow until they locked a topology or at least throw some meaningful exception to user. For example, it is possible to obtain a new "write" mvcc version from the new coordinator and use this version for all further writes while using "old" version for reads. In this case we need to change visibility rules a little: "old" version should see "own" updates made by "new" "write" version. was: At the moment read transactions that don't acquire topology lock will be forcibly rolled back on topology change as read tx can be in fly while topology being change. This is done to prevent having active transaction with stale snapshots on new topology in cases of TX coordinator or Near node were lost. It would be nice to remap it somehow until they locked a topology or at least throw some meaningful exception to user. For example, it is possible to obtain a new "write" mvcc version from the new coordinator and use this version for all further writes while using "old" version for reads. In this case we need to change visibility rules a little: "old" version should see "own" updates made by "new" "write" version. > MVCC TX: Read transactions remap when coordinator fails. > > > Key: IGNITE-8841 > URL: https://issues.apache.org/jira/browse/IGNITE-8841 > Project: Ignite > Issue Type: Bug > Components: mvcc, sql >Reporter: Roman Kondakov >Priority: Major > Labels: failover > > # At the moment read transactions that don't acquire topology lock will be > forcibly rolled back on topology change as read tx can be in fly while > topology being change. > This is done to prevent having active transaction with stale snapshots on > new topology in cases of TX coordinator or Near node were lost. > > It would be nice to remap it somehow until they locked a topology or at least > throw some meaningful exception to user. > For example, it is possible to obtain a new "write" mvcc version from the > new coordinator and use this version for all further writes while using "old" > version for reads. In this case we need to change visibility rules a little: > "old" version should see "own" updates made by "new" "write" version. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8841) MVCC TX: Read transactions remap when coordinator fails.
[ https://issues.apache.org/jira/browse/IGNITE-8841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16746136#comment-16746136 ] Igor Seliverstov commented on IGNITE-8841: -- Actually the main problem is: a tx which obtained a snapshot but didn't do any updates isn't holding a topology lock, so nothing prevents a topology change. In case the topology change is caused by a coordinator failure, there is no info about such tx anymore, so, nothing prevents cleaning rows, which are still visible for such transaction. We need to track such txs like we do for query trackers and, after topology lock, acquire a new "write" snapshot as write version and continue reads using existed "read" snapshot but write using newly acquired write version. This way we meet consistency guaranties. > MVCC TX: Read transactions remap when coordinator fails. > > > Key: IGNITE-8841 > URL: https://issues.apache.org/jira/browse/IGNITE-8841 > Project: Ignite > Issue Type: Bug > Components: mvcc, sql >Reporter: Roman Kondakov >Priority: Major > Labels: failover > > At the moment read transactions that don't acquire topology lock will be > forcibly rolled back on topology change as read tx can be in fly while > topology being change. > This is done to prevent having active transaction with stale snapshots on > new topology in cases of TX coordinator or Near node were lost. > > It would be nice to remap it somehow until they locked a topology or at least > throw some meaningful exception to user. > For example, it is possible to obtain a new "write" mvcc version from the > new coordinator and use this version for all further writes while using "old" > version for reads. In this case we need to change visibility rules a little: > "old" version should see "own" updates made by "new" "write" version. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8841) MVCC TX: Read transactions remap when coordinator fails.
[ https://issues.apache.org/jira/browse/IGNITE-8841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Seliverstov updated IGNITE-8841: - Description: At the moment read transactions that don't acquire topology lock will be forcibly rolled back on topology change as read tx can be in fly while topology being change. This is done to prevent having active transaction with stale snapshots on new topology in cases of TX coordinator or Near node were lost. It would be nice to remap it somehow until they locked a topology or at least throw some meaningful exception to user. For example, it is possible to obtain a new "write" mvcc version from the new coordinator and use this version for all further writes while using "old" version for reads. In this case we need to change visibility rules a little: "old" version should see "own" updates made by "new" "write" version. was: # At the moment read transactions that don't acquire topology lock will be forcibly rolled back on topology change as read tx can be in fly while topology being change. This is done to prevent having active transaction with stale snapshots on new topology in cases of TX coordinator or Near node were lost. It would be nice to remap it somehow until they locked a topology or at least throw some meaningful exception to user. For example, it is possible to obtain a new "write" mvcc version from the new coordinator and use this version for all further writes while using "old" version for reads. In this case we need to change visibility rules a little: "old" version should see "own" updates made by "new" "write" version. > MVCC TX: Read transactions remap when coordinator fails. > > > Key: IGNITE-8841 > URL: https://issues.apache.org/jira/browse/IGNITE-8841 > Project: Ignite > Issue Type: Bug > Components: mvcc, sql >Reporter: Roman Kondakov >Priority: Major > Labels: failover > > At the moment read transactions that don't acquire topology lock will be > forcibly rolled back on topology change as read tx can be in fly while > topology being change. > This is done to prevent having active transaction with stale snapshots on > new topology in cases of TX coordinator or Near node were lost. > > It would be nice to remap it somehow until they locked a topology or at least > throw some meaningful exception to user. > For example, it is possible to obtain a new "write" mvcc version from the > new coordinator and use this version for all further writes while using "old" > version for reads. In this case we need to change visibility rules a little: > "old" version should see "own" updates made by "new" "write" version. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-8841) MVCC TX: Read transactions remap when coordinator fails.
[ https://issues.apache.org/jira/browse/IGNITE-8841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16746136#comment-16746136 ] Igor Seliverstov edited comment on IGNITE-8841 at 1/18/19 10:31 AM: Actually the main problem is: a tx which obtained a snapshot but didn't do any updates isn't holding a topology lock, so nothing prevents a topology change. In case the topology change is caused by a coordinator failure, there is no info about such tx anymore, so, nothing prevents cleaning rows, which are still visible for such transaction. We need to track such txs like we do for query trackers and, after topology lock, acquire a new "write" snapshot as write version and continue reads using existed "read" snapshot but write using newly acquired write version. This way we'll meet consistency guaranties. was (Author: gvvinblade): Actually the main problem is: a tx which obtained a snapshot but didn't do any updates isn't holding a topology lock, so nothing prevents a topology change. In case the topology change is caused by a coordinator failure, there is no info about such tx anymore, so, nothing prevents cleaning rows, which are still visible for such transaction. We need to track such txs like we do for query trackers and, after topology lock, acquire a new "write" snapshot as write version and continue reads using existed "read" snapshot but write using newly acquired write version. This way we meet consistency guaranties. > MVCC TX: Read transactions remap when coordinator fails. > > > Key: IGNITE-8841 > URL: https://issues.apache.org/jira/browse/IGNITE-8841 > Project: Ignite > Issue Type: Bug > Components: mvcc, sql >Reporter: Roman Kondakov >Priority: Major > Labels: failover > > At the moment read transactions that don't acquire topology lock will be > forcibly rolled back on topology change as read tx can be in fly while > topology being change. > This is done to prevent having active transaction with stale snapshots on > new topology in cases of TX coordinator or Near node were lost. > > It would be nice to remap it somehow until they locked a topology or at least > throw some meaningful exception to user. > For example, it is possible to obtain a new "write" mvcc version from the > new coordinator and use this version for all further writes while using "old" > version for reads. In this case we need to change visibility rules a little: > "old" version should see "own" updates made by "new" "write" version. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10757) Refactoring: split MvccProcessor into multiple components
[ https://issues.apache.org/jira/browse/IGNITE-10757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16747891#comment-16747891 ] Igor Seliverstov commented on IGNITE-10757: --- I'd like to extract TxLog related logic into a separate manager too. > Refactoring: split MvccProcessor into multiple components > - > > Key: IGNITE-10757 > URL: https://issues.apache.org/jira/browse/IGNITE-10757 > Project: Ignite > Issue Type: Improvement > Components: mvcc >Reporter: Ivan Pavlukhin >Priority: Major > Fix For: 2.8 > > > In current implementation MvccProcessor has multiple responsibilities which > can be extracted into separate components. Also it looks like that we do not > need an independent processor here because all logic is bound to > CacheProcessor. At least 3 components could be created: > 1. ShapshotManager responsible for granting MVCC snapshots and handling > related messages. > 2. LockManager implementing (exclusive) locking for write operations and > associated wait queues. Deadlock detection facilities could be also placed > here. > 3. VacuumManager responsible for scavenging not needed anymore row versions. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10755) MVCC: Flaky continuous query tests
[
https://issues.apache.org/jira/browse/IGNITE-10755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16747983#comment-16747983
]
Igor Seliverstov commented on IGNITE-10755:
---
[~rkondakov], please merge last master and rerun tests.
> MVCC: Flaky continuous query tests
> --
>
> Key: IGNITE-10755
> URL: https://issues.apache.org/jira/browse/IGNITE-10755
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Reporter: Roman Kondakov
>Assignee: Roman Kondakov
>Priority: Major
> Labels: CQ, MakeTeamcityGreenAgain, mvcc_stabilization_stage_1
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Some continuous query tests are flaky when MVCC is enabled:
> * {{CacheContinuousQueryConcurrentPartitionUpdateTest}}
> ** {{testConcurrentUpdatesAndQueryStartMvccTxCacheGroup}}
> ** {{testConcurrentUpdatesAndQueryStartMvccTx}}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10559) MVCC TX: Use extracted partitions to reduce target nodes for Query Update
[
https://issues.apache.org/jira/browse/IGNITE-10559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16748001#comment-16748001
]
Igor Seliverstov commented on IGNITE-10559:
---
[~tledkov-gridgain], see my comments below:
1) {{PartitionResult#calculatePartitions}} - in case a user has provided an
explicit partitions list it's makes sense do not use it as is, but calculate an
intersection with partitions going from {{PartitionResult}}
2) {{UpdatePlanBuilder.java:856}} {{qry.derivedPartitions() != null ?
qry.derivedPartitions() : null}} - looks like it may be simplified.
3) Imports + visa required.
> MVCC TX: Use extracted partitions to reduce target nodes for Query Update
> -
>
> Key: IGNITE-10559
> URL: https://issues.apache.org/jira/browse/IGNITE-10559
> Project: Ignite
> Issue Type: Task
> Components: mvcc
>Reporter: Igor Seliverstov
>Assignee: Taras Ledkov
>Priority: Minor
> Labels: iep-24
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We may avoid "query reduce" step on update queries without sorting/grouping
> by simply sending them to all data nodes and executing update operation
> locally. Using extracted from SQL partitions will reduce target nodes count
> and save resources.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (IGNITE-9428) MVCC TX: MvccQueryTrackerImpl.onDone() semantic is broken.
[
https://issues.apache.org/jira/browse/IGNITE-9428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Seliverstov resolved IGNITE-9428.
--
Resolution: Duplicate
> MVCC TX: MvccQueryTrackerImpl.onDone() semantic is broken.
> --
>
> Key: IGNITE-9428
> URL: https://issues.apache.org/jira/browse/IGNITE-9428
> Project: Ignite
> Issue Type: Bug
> Components: mvcc, sql
>Reporter: Roman Kondakov
>Priority: Major
> Labels: mvcc_stabilization_stage_1, transactions
> Fix For: 2.8
>
>
> Due to IGNITE-9256 patch, multiple {{H2ResultSetIterator#onClose}} invocation
> becomes possible. This can be considered as a {{Closable}} contract violation
> and should be fixed.
> Also this case revealed a bug in {{MvccQueryTrackerImpl}} when multiple
> {{onDone()}} call leads to multiple query finished acks sent back to the
> {{MvccCoordinator}} which leads to the problems with the query tracking and
> assertion errors.
> Reproducer:
> {{CacheMvccSqlTxQueriesAbstractTest#testAccountsTxDmlSumSql_WithRemoves_SingleNode}}
>
>
> Upd: test was fixed in IGNITE-9373. But MvccQueryTrackerImpl.onDone() issue
> is still actual.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (IGNITE-7307) H2DynamicIndexingComplexServerTransactionalReplicatedTest.testOperations fails with assertion
[
https://issues.apache.org/jira/browse/IGNITE-7307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Seliverstov resolved IGNITE-7307.
--
Resolution: Cannot Reproduce
> H2DynamicIndexingComplexServerTransactionalReplicatedTest.testOperations
> fails with assertion
> -
>
> Key: IGNITE-7307
> URL: https://issues.apache.org/jira/browse/IGNITE-7307
> Project: Ignite
> Issue Type: Bug
> Components: mvcc, sql
>Reporter: Vladimir Ozerov
>Assignee: Igor Seliverstov
>Priority: Major
> Labels: mvcc_stabilization_stage_1, transactions
> Fix For: 2.8
>
>
> {code}
> [2017-12-26 11:40:53,187][ERROR][main][root] Test failed.
> java.lang.AssertionError: localNode = cde0ed21-5bfa-48ee-8e47-53d85880,
> dhtNodes = [TcpDiscoveryNode [id=49318149-4b22-40d1-b68f-8b6b2d52,
> addrs=[127.0.0.1], sockAddrs=[/127.0.0.1:47501], discPort=47501, order=3,
> intOrder=3, lastExchangeTime=1514277649002, loc=false,
> ver=2.4.0#19700101-sha1:, isClient=false], TcpDiscoveryNode
> [id=cde0ed21-5bfa-48ee-8e47-53d85880, addrs=[127.0.0.1],
> sockAddrs=[/127.0.0.1:47500], discPort=47500, order=1, intOrder=1,
> lastExchangeTime=1514277652494, loc=true, ver=2.4.0#19700101-sha1:,
> isClient=false], TcpDiscoveryNode [id=7530f231-3bd4-4cc0-b295-0e2f11b3,
> addrs=[127.0.0.1], sockAddrs=[/127.0.0.1:47502], discPort=47502, order=4,
> intOrder=4, lastExchangeTime=1514277649456, loc=false,
> ver=2.4.0#19700101-sha1:, isClient=false]]
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.map(GridDhtTxPrepareFuture.java:1608)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.prepare0(GridDhtTxPrepareFuture.java:1274)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.mapIfLocked(GridDhtTxPrepareFuture.java:678)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.prepare(GridDhtTxPrepareFuture.java:1056)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.prepareAsyncLocal(GridNearTxLocal.java:3619)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.prepareColocatedTx(IgniteTxHandler.java:257)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearPessimisticTxPrepareFuture.prepareLocal(GridNearPessimisticTxPrepareFuture.java:256)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearPessimisticTxPrepareFuture.preparePessimistic(GridNearPessimisticTxPrepareFuture.java:406)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearPessimisticTxPrepareFuture.prepare(GridNearPessimisticTxPrepareFuture.java:190)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.prepareNearTxLocal(GridNearTxLocal.java:3323)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.commitNearTxLocalAsync(GridNearTxLocal.java:3390)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.commit(GridNearTxLocal.java:3350)
> at
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.executeUpdateStatement(DmlStatementsProcessor.java:429)
> at
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.updateSqlFields(DmlStatementsProcessor.java:177)
> at
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.updateSqlFieldsDistributed(DmlStatementsProcessor.java:212)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryDistributedSqlFields(IgniteH2Indexing.java:1809)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryDistributedSqlFields(IgniteH2Indexing.java:1645)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$6.applyx(GridQueryProcessor.java:2034)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$6.applyx(GridQueryProcessor.java:2030)
> at
> org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2527)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFieldsNoCache(GridQueryProcessor.java:2039)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFieldsNoCache(GridQueryProcessor.java:1995)
> at
> org.apache.ignite.internal.processors.cache.index.H2DynamicIndexingComplexTest.executeSql(H2DynamicIndexingCompl
[jira] [Assigned] (IGNITE-10788) MVCC: Get operation may hang in some cases
[
https://issues.apache.org/jira/browse/IGNITE-10788?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Seliverstov reassigned IGNITE-10788:
-
Assignee: Igor Seliverstov
> MVCC: Get operation may hang in some cases
> --
>
> Key: IGNITE-10788
> URL: https://issues.apache.org/jira/browse/IGNITE-10788
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Reporter: Roman Kondakov
>Assignee: Igor Seliverstov
>Priority: Major
> Labels: Hanging, mvcc_stabilization_stage_1
> Fix For: 2.8
>
>
> Get operation may hang on snapshot acquisition in some cases. Reproducer:
> {{IgniteClusterActivateDeactivateTestWithPersistenceAndMemoryReuse.testDeactivateDuringEvictionAndRebalance}}
> StackTrace:
> {noformat}
> Thread
> [name="test-runner-#4675%cache.IgniteClusterActivateDeactivateTestWithPersistenceAndMemoryReuse%",
> id=5136, state=WAITING, blockCnt=42, waitCnt=382996]
> 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:178)
> at
> o.a.i.i.util.future.GridFutureAdapter.get(GridFutureAdapter.java:141)
> at
> o.a.i.i.processors.cache.mvcc.MvccUtils.mvccTracker(MvccUtils.java:817)
> at
> o.a.i.i.processors.cache.distributed.dht.colocated.GridDhtColocatedCache.getAsync(GridDhtColocatedCache.java:244)
> at
> o.a.i.i.processors.cache.GridCacheAdapter.get0(GridCacheAdapter.java:4725)
> at
> o.a.i.i.processors.cache.GridCacheAdapter.get(GridCacheAdapter.java:4706)
> at
> o.a.i.i.processors.cache.GridCacheAdapter.get(GridCacheAdapter.java:1450)
> at
> o.a.i.i.processors.cache.IgniteCacheProxyImpl.get(IgniteCacheProxyImpl.java:927)
> at
> o.a.i.i.processors.cache.GatewayProtectedCacheProxy.get(GatewayProtectedCacheProxy.java:640)
> at
> o.a.i.i.processors.cache.IgniteClusterActivateDeactivateTestWithPersistence.testDeactivateDuringEvictionAndRebalance(IgniteClusterActivateDeactivateTestWithPersistence.java:415)
> 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:2115)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (IGNITE-10185) TX can hang forever if any runtime exception occurs on txFinish.
[ https://issues.apache.org/jira/browse/IGNITE-10185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Seliverstov resolved IGNITE-10185. --- Resolution: Duplicate > TX can hang forever if any runtime exception occurs on txFinish. > > > Key: IGNITE-10185 > URL: https://issues.apache.org/jira/browse/IGNITE-10185 > Project: Ignite > Issue Type: Bug > Components: cache, mvcc >Reporter: Andrew Mashenkov >Priority: Major > Labels: iep-14, mvcc_stabilization_stage_1, transactions > Fix For: 2.8 > > > The issue relates to incorrect IOOM handling that can occurs on Tx > prepare\commit\rollback and can be reproduced if persistence enabled and Tx > state logging into WAL enabled. > This affects MVCC tx as it always log it's state into WAL and non-MVCC Tx > with enabled WAL logging via setting IGNITE_WAL_LOG_TX_RECORDS system > property. > We have to check and fix if tx finish methods handle RuntimeExceptions in > proper way. > Good start is to force throw RuntimeException from tm().mvccPrepare() and > tm().mvccFinish() methods, and check if DhtFinishFuture done correctly with > exception rather then (re)throwing exception bypassing failure handler. > The goal is to make IoomFailureHandlerTest passed after runtime failures > during Tx commit\prepare\rollback. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-10786) MVCC: Flaky test IgniteClusterActivateDeactivateTestWithPersistence#testDeactivateDuringEvictionAndRebalance
[
https://issues.apache.org/jira/browse/IGNITE-10786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Seliverstov reassigned IGNITE-10786:
-
Assignee: Andrew Mashenkov
> MVCC: Flaky test
> IgniteClusterActivateDeactivateTestWithPersistence#testDeactivateDuringEvictionAndRebalance
>
>
> Key: IGNITE-10786
> URL: https://issues.apache.org/jira/browse/IGNITE-10786
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Reporter: Roman Kondakov
>Assignee: Andrew Mashenkov
>Priority: Major
> Labels: failover, mvcc_stabilization_stage_1
> Fix For: 2.8
>
>
> Test
> {{IgniteClusterActivateDeactivateTestWithPersistence#testDeactivateDuringEvictionAndRebalance}}
> is flaky when MVCC is enabled. We should investigate it.
> {noformat}
> [2018-12-21 02:26:51,592][ERROR][main][root] Test failed.
> java.lang.AssertionError:
> node=cache.IgniteClusterActivateDeactivateTestWithPersistence0, key=12
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at org.junit.Assert.assertNotNull(Assert.java:621)
> at
> org.apache.ignite.internal.processors.cache.IgniteClusterActivateDeactivateTestWithPersistence.testDeactivateDuringEvictionAndRebalance(IgniteClusterActivateDeactivateTestWithPersistence.java:425)
> 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
> org.apache.ignite.testframework.junits.GridAbstractTest$7.run(GridAbstractTest.java:2115)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-10788) MVCC: Get operation may hang in some cases
[
https://issues.apache.org/jira/browse/IGNITE-10788?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Seliverstov reassigned IGNITE-10788:
-
Assignee: Andrew Mashenkov (was: Igor Seliverstov)
> MVCC: Get operation may hang in some cases
> --
>
> Key: IGNITE-10788
> URL: https://issues.apache.org/jira/browse/IGNITE-10788
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Reporter: Roman Kondakov
>Assignee: Andrew Mashenkov
>Priority: Major
> Labels: Hanging, mvcc_stabilization_stage_1
> Fix For: 2.8
>
>
> Get operation may hang on snapshot acquisition in some cases. Reproducer:
> {{IgniteClusterActivateDeactivateTestWithPersistenceAndMemoryReuse.testDeactivateDuringEvictionAndRebalance}}
> StackTrace:
> {noformat}
> Thread
> [name="test-runner-#4675%cache.IgniteClusterActivateDeactivateTestWithPersistenceAndMemoryReuse%",
> id=5136, state=WAITING, blockCnt=42, waitCnt=382996]
> 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:178)
> at
> o.a.i.i.util.future.GridFutureAdapter.get(GridFutureAdapter.java:141)
> at
> o.a.i.i.processors.cache.mvcc.MvccUtils.mvccTracker(MvccUtils.java:817)
> at
> o.a.i.i.processors.cache.distributed.dht.colocated.GridDhtColocatedCache.getAsync(GridDhtColocatedCache.java:244)
> at
> o.a.i.i.processors.cache.GridCacheAdapter.get0(GridCacheAdapter.java:4725)
> at
> o.a.i.i.processors.cache.GridCacheAdapter.get(GridCacheAdapter.java:4706)
> at
> o.a.i.i.processors.cache.GridCacheAdapter.get(GridCacheAdapter.java:1450)
> at
> o.a.i.i.processors.cache.IgniteCacheProxyImpl.get(IgniteCacheProxyImpl.java:927)
> at
> o.a.i.i.processors.cache.GatewayProtectedCacheProxy.get(GatewayProtectedCacheProxy.java:640)
> at
> o.a.i.i.processors.cache.IgniteClusterActivateDeactivateTestWithPersistence.testDeactivateDuringEvictionAndRebalance(IgniteClusterActivateDeactivateTestWithPersistence.java:415)
> 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:2115)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-11007) MVCC: Potential NPE on non-affinity node for mvcc cache.
[ https://issues.apache.org/jira/browse/IGNITE-11007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Seliverstov reassigned IGNITE-11007: - Assignee: Igor Seliverstov > MVCC: Potential NPE on non-affinity node for mvcc cache. > > > Key: IGNITE-11007 > URL: https://issues.apache.org/jira/browse/IGNITE-11007 > Project: Ignite > Issue Type: Bug > Components: mvcc >Reporter: Andrew Mashenkov >Assignee: Igor Seliverstov >Priority: Major > > It is possible, non-affinity node (mvcc coordinator or near node) for any > mvcc cache can try to track tx states and update txLog. > However, txLog may not exists on node if node isn't data node for any mvcc > cache. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-11007) MVCC: Potential NPE on non-affinity node for mvcc cache.
[ https://issues.apache.org/jira/browse/IGNITE-11007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Seliverstov resolved IGNITE-11007. --- Resolution: Not A Problem Actually TxLog creates on each data node regardless the node is affinity node or not. So, the exception cannot be thrown. > MVCC: Potential NPE on non-affinity node for mvcc cache. > > > Key: IGNITE-11007 > URL: https://issues.apache.org/jira/browse/IGNITE-11007 > Project: Ignite > Issue Type: Bug > Components: mvcc >Reporter: Andrew Mashenkov >Assignee: Igor Seliverstov >Priority: Major > > It is possible, non-affinity node (mvcc coordinator or near node) for any > mvcc cache can try to track tx states and update txLog. > However, txLog may not exists on node if node isn't data node for any mvcc > cache. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11068) MVCC TX: Do not create TxLog and do not start vacuum workers in case there are no MVCC caches on the node.
Igor Seliverstov created IGNITE-11068: - Summary: MVCC TX: Do not create TxLog and do not start vacuum workers in case there are no MVCC caches on the node. Key: IGNITE-11068 URL: https://issues.apache.org/jira/browse/IGNITE-11068 Project: Ignite Issue Type: Improvement Reporter: Igor Seliverstov -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11068) MVCC TX: Do not create TxLog and do not start vacuum workers in case there are no MVCC caches on the node.
[ https://issues.apache.org/jira/browse/IGNITE-11068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Seliverstov updated IGNITE-11068: -- Description: Actually TxLog creates on each data node regardless the node is affinity node for any MVCC cache or not. There is no sense to create and maintain Tx log and Vacuum routines in case the node doesn't have any mvcc cache. > MVCC TX: Do not create TxLog and do not start vacuum workers in case there > are no MVCC caches on the node. > -- > > Key: IGNITE-11068 > URL: https://issues.apache.org/jira/browse/IGNITE-11068 > Project: Ignite > Issue Type: Improvement >Reporter: Igor Seliverstov >Priority: Major > > Actually TxLog creates on each data node regardless the node is affinity node > for any MVCC cache or not. There is no sense to create and maintain Tx log > and Vacuum routines in case the node doesn't have any mvcc cache. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11068) MVCC TX: Do not create TxLog and do not start vacuum workers in case there are no MVCC caches on the node.
[ https://issues.apache.org/jira/browse/IGNITE-11068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Seliverstov updated IGNITE-11068: -- Fix Version/s: 2.8 > MVCC TX: Do not create TxLog and do not start vacuum workers in case there > are no MVCC caches on the node. > -- > > Key: IGNITE-11068 > URL: https://issues.apache.org/jira/browse/IGNITE-11068 > Project: Ignite > Issue Type: Improvement > Components: mvcc >Reporter: Igor Seliverstov >Priority: Major > Fix For: 2.8 > > > Actually TxLog creates on each data node regardless the node is affinity node > for any MVCC cache or not. There is no sense to create and maintain Tx log > and Vacuum routines in case the node doesn't have any mvcc cache. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11068) MVCC TX: Do not create TxLog and do not start vacuum workers in case there are no MVCC caches on the node.
[ https://issues.apache.org/jira/browse/IGNITE-11068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Seliverstov updated IGNITE-11068: -- Ignite Flags: (was: Docs Required) > MVCC TX: Do not create TxLog and do not start vacuum workers in case there > are no MVCC caches on the node. > -- > > Key: IGNITE-11068 > URL: https://issues.apache.org/jira/browse/IGNITE-11068 > Project: Ignite > Issue Type: Improvement > Components: mvcc >Reporter: Igor Seliverstov >Priority: Major > > Actually TxLog creates on each data node regardless the node is affinity node > for any MVCC cache or not. There is no sense to create and maintain Tx log > and Vacuum routines in case the node doesn't have any mvcc cache. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11068) MVCC TX: Do not create TxLog and do not start vacuum workers in case there are no MVCC caches on the node.
[ https://issues.apache.org/jira/browse/IGNITE-11068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Seliverstov updated IGNITE-11068: -- Component/s: mvcc > MVCC TX: Do not create TxLog and do not start vacuum workers in case there > are no MVCC caches on the node. > -- > > Key: IGNITE-11068 > URL: https://issues.apache.org/jira/browse/IGNITE-11068 > Project: Ignite > Issue Type: Improvement > Components: mvcc >Reporter: Igor Seliverstov >Priority: Major > > Actually TxLog creates on each data node regardless the node is affinity node > for any MVCC cache or not. There is no sense to create and maintain Tx log > and Vacuum routines in case the node doesn't have any mvcc cache. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-8841) MVCC TX: Read transactions remap when coordinator fails.
[ https://issues.apache.org/jira/browse/IGNITE-8841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Seliverstov reassigned IGNITE-8841: Assignee: Igor Seliverstov > MVCC TX: Read transactions remap when coordinator fails. > > > Key: IGNITE-8841 > URL: https://issues.apache.org/jira/browse/IGNITE-8841 > Project: Ignite > Issue Type: Bug > Components: mvcc, sql >Reporter: Roman Kondakov >Assignee: Igor Seliverstov >Priority: Major > Labels: failover > > At the moment read transactions that don't acquire topology lock will be > forcibly rolled back on topology change as read tx can be in fly while > topology being change. > This is done to prevent having active transaction with stale snapshots on > new topology in cases of TX coordinator or Near node were lost. > > It would be nice to remap it somehow until they locked a topology or at least > throw some meaningful exception to user. > For example, it is possible to obtain a new "write" mvcc version from the > new coordinator and use this version for all further writes while using "old" > version for reads. In this case we need to change visibility rules a little: > "old" version should see "own" updates made by "new" "write" version. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11121) MVCC TX: AssertionError in discovery manager on BLT change.
Igor Seliverstov created IGNITE-11121:
-
Summary: MVCC TX: AssertionError in discovery manager on BLT
change.
Key: IGNITE-11121
URL: https://issues.apache.org/jira/browse/IGNITE-11121
Project: Ignite
Issue Type: Bug
Reporter: Igor Seliverstov
Fix For: 2.8
The next exception occurred in logs on BLT change.
{noformat}
[12:11:36,912][SEVERE][sys-#87][GridClosureProcessor] Closure execution failed
with error.
java.lang.AssertionError
at
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.node(GridDiscoveryManager.java:1794)
at
org.apache.ignite.internal.managers.communication.GridIoManager.sendToGridTopic(GridIoManager.java:1693)
at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxManager$NodeFailureTimeoutObject.lambda$onTimeout0$16553d7$1(IgniteTxManager.java:2592)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:399)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.listen(GridFutureAdapter.java:354)
at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxManager$NodeFailureTimeoutObject.onTimeout0(IgniteTxManager.java:2588)
at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxManager$NodeFailureTimeoutObject.access$3300(IgniteTxManager.java:2505)
at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxManager$NodeFailureTimeoutObject$1.run(IgniteTxManager.java:2623)
at
org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:6874)
at
org.apache.ignite.internal.processors.closure.GridClosureProcessor$1.body(GridClosureProcessor.java:827)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
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)
{noformat}
>From the stack trace I see there is a node failure which causes transactions
>recovery and uninitialized Mvcc coordinator (it means there are no server
>nodes, or there is a coordinatorAssignClosure which returns no result, or a
>recovering node was not activated)
the scenario, where the exception may be observed:
* Start a cluster
* Load some data (from client node, the client node is shut down after that)
* Calculate hash
* Add new server node
* Change BLT
* Wait for rebalance
* Calculate new hash and check it is the same as previously calculated
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11121) MVCC TX: AssertionError in discovery manager on BLT change.
[
https://issues.apache.org/jira/browse/IGNITE-11121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Seliverstov updated IGNITE-11121:
--
Component/s: mvcc
> MVCC TX: AssertionError in discovery manager on BLT change.
> ---
>
> Key: IGNITE-11121
> URL: https://issues.apache.org/jira/browse/IGNITE-11121
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Reporter: Igor Seliverstov
>Priority: Critical
> Fix For: 2.8
>
>
> The next exception occurred in logs on BLT change.
> {noformat}
> [12:11:36,912][SEVERE][sys-#87][GridClosureProcessor] Closure execution
> failed with error.
> java.lang.AssertionError
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.node(GridDiscoveryManager.java:1794)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.sendToGridTopic(GridIoManager.java:1693)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxManager$NodeFailureTimeoutObject.lambda$onTimeout0$16553d7$1(IgniteTxManager.java:2592)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:399)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.listen(GridFutureAdapter.java:354)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxManager$NodeFailureTimeoutObject.onTimeout0(IgniteTxManager.java:2588)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxManager$NodeFailureTimeoutObject.access$3300(IgniteTxManager.java:2505)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxManager$NodeFailureTimeoutObject$1.run(IgniteTxManager.java:2623)
> at
> org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:6874)
> at
> org.apache.ignite.internal.processors.closure.GridClosureProcessor$1.body(GridClosureProcessor.java:827)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> 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)
> {noformat}
> From the stack trace I see there is a node failure which causes transactions
> recovery and uninitialized Mvcc coordinator (it means there are no server
> nodes, or there is a coordinatorAssignClosure which returns no result, or a
> recovering node was not activated)
> the scenario, where the exception may be observed:
> * Start a cluster
> * Load some data (from client node, the client node is shut down after that)
> * Calculate hash
> * Add new server node
> * Change BLT
> * Wait for rebalance
> * Calculate new hash and check it is the same as previously calculated
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10766) MVCC: CacheMvccTxRecoveryTest.testCountersNeighborcastServerFailed fails sporadically
[
https://issues.apache.org/jira/browse/IGNITE-10766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16754907#comment-16754907
]
Igor Seliverstov commented on IGNITE-10766:
---
[~Pavlukhin], looks good, merged to master.
> MVCC: CacheMvccTxRecoveryTest.testCountersNeighborcastServerFailed fails
> sporadically
> -
>
> Key: IGNITE-10766
> URL: https://issues.apache.org/jira/browse/IGNITE-10766
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Reporter: Roman Kondakov
>Assignee: Ivan Pavlukhin
>Priority: Major
> Labels: Hanging, failover, mvcc_stabilization_stage_1
> Fix For: 2.8
>
> Attachments: testCountersNeighborcastServerFailed
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {{CacheMvccTxRecoveryTest.testCountersNeighborcastServerFailed}} sporadically
> hangs on exchange. It should be investigated.
> Looks like the similar problem is in
> {{GridCachePartitionsStateValidationTest#testPartitionCountersConsistencyOnExchange}}
> with enabled MVCC.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
