[jira] [Commented] (IGNITE-12202) Support system function ROWNUM()
[ https://issues.apache.org/jira/browse/IGNITE-12202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16935061#comment-16935061 ] Andrew Mashenkov commented on IGNITE-12202: --- Ignite has no any natural row order. Seems, this can be closed. > Support system function ROWNUM() > > > Key: IGNITE-12202 > URL: https://issues.apache.org/jira/browse/IGNITE-12202 > Project: Ignite > Issue Type: New Feature > Components: sql >Affects Versions: 2.7.5 >Reporter: YuJue Li >Priority: Minor > Fix For: 3.0 > > > H2 database support system function ROWNUM(), which is very common, Ignite > should support its distributed version. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12112) H2TreeIndex should throw CorruptTreeException with cacheId, cacheName and indexName
[
https://issues.apache.org/jira/browse/IGNITE-12112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Mashenkov updated IGNITE-12112:
--
Component/s: sql
> H2TreeIndex should throw CorruptTreeException with cacheId, cacheName and
> indexName
> ---
>
> Key: IGNITE-12112
> URL: https://issues.apache.org/jira/browse/IGNITE-12112
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Denis Chudov
>Assignee: Denis Chudov
>Priority: Major
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> At the moment we can't define problem cache, If we have many caches in one
> cache group and CorruptTreeException was thrown CorruptTreeException.
> For example:
> {code:java}
> org.h2.message.DbException: General error: "class
> org.apache.ignite.internal.processors.cache.persistence.tree.CorruptedTreeException:
> Runtime failure on row: Row@346ba4aa[ key: 29003, val:
> com.sbt.acquiring.processing.entities.dictionaries.TurnoverRange_DPL_PROXY
> [idHash=492721050, hash=-616731792, valueStart=2001, isImmutable=false,
> lastChangeDate=1560917668719, name=Ñâûøå 20, valueEnd=null,
> changeState=null, id=29003, pkey=7c0d0d59-f33e-41d7-a5c9-4d8c7e74b976,
> ownerId=acquiring-processing-replication, base=true], ver: GridCacheVersion
> [topVer=172396060, order=1560917613306, nodeOrder=2] ][ Ñâûøå 20, null,
> 2001, TRUE, null, 29003, 7c0d0d59-f33e-41d7-a5c9-4d8c7e74b976 ]"
> [5-195]
> at org.h2.message.DbException.get(DbException.java:168)
> at org.h2.message.DbException.convert(DbException.java:295)
> at
> org.apache.ignite.internal.processors.query.h2.database.H2TreeIndex.putx(H2TreeIndex.java:251)
> at
> org.apache.ignite.internal.processors.query.h2.opt.GridH2Table.addToIndex(GridH2Table.java:548)
> at
> org.apache.ignite.internal.processors.query.h2.opt.GridH2Table.update(GridH2Table.java:480)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.store(IgniteH2Indexing.java:709)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.store(GridQueryProcessor.java:1863)
> at
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager.store(GridCacheQueryManager.java:403)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.finishUpdate(IgniteCacheOffheapManagerImpl.java:1402)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.invoke(IgniteCacheOffheapManagerImpl.java:1263)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.invoke(GridCacheOffheapManager.java:1625)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.invoke(IgniteCacheOffheapManagerImpl.java:358)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.storeValue(GridCacheMapEntry.java:3629)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.initialValue(GridCacheMapEntry.java:2793)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionDemander.preloadEntry(GridDhtPartitionDemander.java:902)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionDemander.handleSupplyMessage(GridDhtPartitionDemander.java:772)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPreloader.handleSupplyMessage(GridDhtPreloader.java:344)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$5.apply(GridCachePartitionExchangeManager.java:418)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$5.apply(GridCachePartitionExchangeManager.java:408)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1061)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:586)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$700(GridCacheIoManager.java:101)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$OrderedMessageListener.onMessage(GridCacheIoManager.java:1624)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1556)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4100(GridIoManager.java:125)
> at
>
[jira] [Commented] (IGNITE-12133) O(log n) partition exchange
[ https://issues.apache.org/jira/browse/IGNITE-12133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16922349#comment-16922349 ] Andrew Mashenkov commented on IGNITE-12133: --- [~avinogradov], message ordering is important. What if some nodes will got "create cache" and "drop cache" events in different order? > O(log n) partition exchange > --- > > Key: IGNITE-12133 > URL: https://issues.apache.org/jira/browse/IGNITE-12133 > Project: Ignite > Issue Type: Improvement >Reporter: Moti Nisenson-Ken >Priority: Major > > Currently, partition exchange leverages a ring. This means that > communications is O\(n) in number of nodes. It also means that if > non-coordinator nodes hang it can take much longer to successfully resolve > the topology. > Instead, why not use something like a skip-list where the coordinator is > first. The coordinator can notify the first node at each level of the > skip-list. Each node then notifies all of its "near-neighbours" in the > skip-list, where node B is a near-neighbour of node-A, if max-level(nodeB) <= > max-level(nodeA), and nodeB is the first node at its level when traversing > from nodeA in the direction of nodeB, skipping over nodes C which have > max-level(C) > max-level(A). > 1 > 1 . . .3 > 1 3 . . . 5 > 1 . 2 . 3 . 4 . 5 . 6 > In the above 1 would notify 2 and 3, 3 would notify 4 and 5, 2 -> 4, and 4 -> > 6, and 5 -> 6. > One can achieve better redundancy by having each node traverse in both > directions, and having the coordinator also notify the last node in the list > at each level. This way in the above example if 2 and 3 were both down, 4 > would still get notified from 5 and 6 (in the backwards direction). > > The idea is that each individual node has O(log n) nodes to notify - so the > overall time is reduced. Additionally, we can deal well with at least 1 node > failure - if one includes the option of processing backwards, 2 consecutive > node failures can be handled as well. By taking this kind of an approach, > then the coordinator can basically treat any nodes it didn't receive a > message from as not-connected, and update the topology as well (disconnecting > any nodes that it didn't get a notification from). While there are some edge > cases here (e.g. 2 disconnected nodes, then 1 connected node, then 2 > disconnected nodes - the connected node would be wrongly ejected from the > topology), these would generally be too rare to need explicit handling for. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (IGNITE-12112) H2TreeIndex should throw CorruptTreeException with cacheId, cacheName and indexName
[
https://issues.apache.org/jira/browse/IGNITE-12112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16920931#comment-16920931
]
Andrew Mashenkov commented on IGNITE-12112:
---
[~Denis Chudov],
I've left a comment to the PR. Please, take a look.
> H2TreeIndex should throw CorruptTreeException with cacheId, cacheName and
> indexName
> ---
>
> Key: IGNITE-12112
> URL: https://issues.apache.org/jira/browse/IGNITE-12112
> Project: Ignite
> Issue Type: Improvement
>Reporter: Denis Chudov
>Assignee: Denis Chudov
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> At the moment we can't define problem cache, If we have many caches in one
> cache group and CorruptTreeException was thrown CorruptTreeException.
> For example:
> {code:java}
> org.h2.message.DbException: General error: "class
> org.apache.ignite.internal.processors.cache.persistence.tree.CorruptedTreeException:
> Runtime failure on row: Row@346ba4aa[ key: 29003, val:
> com.sbt.acquiring.processing.entities.dictionaries.TurnoverRange_DPL_PROXY
> [idHash=492721050, hash=-616731792, valueStart=2001, isImmutable=false,
> lastChangeDate=1560917668719, name=Ñâûøå 20, valueEnd=null,
> changeState=null, id=29003, pkey=7c0d0d59-f33e-41d7-a5c9-4d8c7e74b976,
> ownerId=acquiring-processing-replication, base=true], ver: GridCacheVersion
> [topVer=172396060, order=1560917613306, nodeOrder=2] ][ Ñâûøå 20, null,
> 2001, TRUE, null, 29003, 7c0d0d59-f33e-41d7-a5c9-4d8c7e74b976 ]"
> [5-195]
> at org.h2.message.DbException.get(DbException.java:168)
> at org.h2.message.DbException.convert(DbException.java:295)
> at
> org.apache.ignite.internal.processors.query.h2.database.H2TreeIndex.putx(H2TreeIndex.java:251)
> at
> org.apache.ignite.internal.processors.query.h2.opt.GridH2Table.addToIndex(GridH2Table.java:548)
> at
> org.apache.ignite.internal.processors.query.h2.opt.GridH2Table.update(GridH2Table.java:480)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.store(IgniteH2Indexing.java:709)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.store(GridQueryProcessor.java:1863)
> at
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager.store(GridCacheQueryManager.java:403)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.finishUpdate(IgniteCacheOffheapManagerImpl.java:1402)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.invoke(IgniteCacheOffheapManagerImpl.java:1263)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.invoke(GridCacheOffheapManager.java:1625)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.invoke(IgniteCacheOffheapManagerImpl.java:358)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.storeValue(GridCacheMapEntry.java:3629)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.initialValue(GridCacheMapEntry.java:2793)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionDemander.preloadEntry(GridDhtPartitionDemander.java:902)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionDemander.handleSupplyMessage(GridDhtPartitionDemander.java:772)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPreloader.handleSupplyMessage(GridDhtPreloader.java:344)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$5.apply(GridCachePartitionExchangeManager.java:418)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$5.apply(GridCachePartitionExchangeManager.java:408)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1061)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:586)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$700(GridCacheIoManager.java:101)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$OrderedMessageListener.onMessage(GridCacheIoManager.java:1624)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1556)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4100(GridIoManager.java:125)
> at
>
[jira] [Updated] (IGNITE-11997) TESTS: investigate long running tests in IgniteCacheQueriesLoadTest1
[ https://issues.apache.org/jira/browse/IGNITE-11997?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Mashenkov updated IGNITE-11997: -- Ignite Flags: (was: Docs Required) > TESTS: investigate long running tests in IgniteCacheQueriesLoadTest1 > > > Key: IGNITE-11997 > URL: https://issues.apache.org/jira/browse/IGNITE-11997 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Pavel Kuznetsov >Assignee: Pavel Kuznetsov >Priority: Major > Labels: tests > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > IgniteCacheQueriesLoadTest1.testQueries have long execution. Need to > investigate the reasons and fix it if possible. > org.apache.ignite.testsuites.IgniteBinaryCacheQueryTestSuite2: > org.apache.ignite.internal.processors.cache.IgniteCacheQueriesLoadTest1.testQueries > 2m 52.81s -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (IGNITE-11979) Add ability to set default parallelizm of rebuild indexes in configuration
[
https://issues.apache.org/jira/browse/IGNITE-11979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16887899#comment-16887899
]
Andrew Mashenkov commented on IGNITE-11979:
---
[~Denis Chudov],
I've left few comments to the PR.
Please, take a look.
> Add ability to set default parallelizm of rebuild indexes in configuration
> --
>
> Key: IGNITE-11979
> URL: https://issues.apache.org/jira/browse/IGNITE-11979
> Project: Ignite
> Issue Type: Improvement
>Reporter: Denis Chudov
>Assignee: Denis Chudov
>Priority: Major
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> We can't change SchemaIndexCacheVisitorImpl#DFLT_PARALLELISM at the moment:
> {code:java}
> /** Default degree of parallelism. */
> private static final int DFLT_PARALLELISM = Math.min(4, Math.max(1,
> Runtime.getRuntime().availableProcessors() / 4));
> {code}
> On huge servers with a lot of cores (such as 56) we will rebuild indexes in 4
> threads. I think we should have ability to set DFLT_PARALLELISM in Ignite
> configuration.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Assigned] (IGNITE-8596) SQL: remove unnecessary index lookups when query parallelism is enabled
[
https://issues.apache.org/jira/browse/IGNITE-8596?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Mashenkov reassigned IGNITE-8596:
Assignee: (was: Andrew Mashenkov)
> SQL: remove unnecessary index lookups when query parallelism is enabled
> ---
>
> Key: IGNITE-8596
> URL: https://issues.apache.org/jira/browse/IGNITE-8596
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Affects Versions: 2.5
>Reporter: Vladimir Ozerov
>Priority: Major
> Labels: performance
> Fix For: 2.8
>
>
> See
> {{org.apache.ignite.internal.processors.query.h2.twostep.GridMapQueryExecutor#onQueryRequest}}
> method. If table is segmented, we will submit as many SQL requests as much
> segments. But consider a case when target cache partition(s) is already
> defined by user or derived through partition pruning. In this case most of
> segments will not contain useful information and return empty result set. At
> the same time these queries may impose index or data page scans, thus
> consuming resources without a reason.
> To mitigate the problem we should not submit SQL requests to segments we are
> not interested in.
> Note that it is not sufficient to simply skip SQL requests on mapper, because
> reducer expects separate response for every message. We should fix both local
> mapper logic as well as protocol.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11919) Change message format for incompatible fields' types changes
[
https://issues.apache.org/jira/browse/IGNITE-11919?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Mashenkov updated IGNITE-11919:
--
Ignite Flags: (was: Docs Required)
> Change message format for incompatible fields' types changes
>
>
> Key: IGNITE-11919
> URL: https://issues.apache.org/jira/browse/IGNITE-11919
> Project: Ignite
> Issue Type: Task
>Reporter: Denis Magda
>Assignee: Pavel Kuznetsov
>Priority: Blocker
> Fix For: 2.8
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Follow this discussion thread to find out the reason for the change:
> http://apache-ignite-developers.2346864.n4.nabble.com/Ignite-stops-working-suddenly-during-dev-td42207.html
> It's suggested to apply the following format:
> {code}
> ERROR: Type 'ClassName/TypeName' has a different/incorrect type
> for field 'FieldName'. Expected 'type1' but 'type2' was provided. Field
> type's modification is unsupported, clean {root_path}/marshaller directory
> if the type change is required.
> {code}
> That's an example of how it will look like:
> {code}
> ERROR: Type 'Person' has a different/incorrect type
> for field 'salary'. Expected 'double' but 'string' was provided. Field
> type's modification is unsupported, clean {root_path}/marshaller directory
> if the type change is required.
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11919) Change message format for incompatible fields' types changes
[
https://issues.apache.org/jira/browse/IGNITE-11919?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Mashenkov updated IGNITE-11919:
--
Component/s: binary
> Change message format for incompatible fields' types changes
>
>
> Key: IGNITE-11919
> URL: https://issues.apache.org/jira/browse/IGNITE-11919
> Project: Ignite
> Issue Type: Task
> Components: binary
>Reporter: Denis Magda
>Assignee: Pavel Kuznetsov
>Priority: Blocker
> Fix For: 2.8
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Follow this discussion thread to find out the reason for the change:
> http://apache-ignite-developers.2346864.n4.nabble.com/Ignite-stops-working-suddenly-during-dev-td42207.html
> It's suggested to apply the following format:
> {code}
> ERROR: Type 'ClassName/TypeName' has a different/incorrect type
> for field 'FieldName'. Expected 'type1' but 'type2' was provided. Field
> type's modification is unsupported, clean {root_path}/marshaller directory
> if the type change is required.
> {code}
> That's an example of how it will look like:
> {code}
> ERROR: Type 'Person' has a different/incorrect type
> for field 'salary'. Expected 'double' but 'string' was provided. Field
> type's modification is unsupported, clean {root_path}/marshaller directory
> if the type change is required.
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11330) Partition demander should skip entries for invalid partition.
[ https://issues.apache.org/jira/browse/IGNITE-11330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16867537#comment-16867537 ] Andrew Mashenkov commented on IGNITE-11330: --- [~xtern], Yes, looks like this was partially fixed in IGNITE-10561. But it looks weird that we update "onRebalanceKeyReceived" metric for all caches in group. We should remove TODOs and either update metric for certain cache only or add a comment with explanation why we do that or may be introduce cache-group metrics and move this metric from cache to cache-group level. What about "estimatedKeysCount". Seems, it is always "-1" due to some bug that should be fixed at first. > Partition demander should skip entries for invalid partition. > - > > Key: IGNITE-11330 > URL: https://issues.apache.org/jira/browse/IGNITE-11330 > Project: Ignite > Issue Type: Bug > Components: cache >Reporter: Andrew Mashenkov >Priority: Major > Labels: performance, rebalance > Fix For: 2.8 > > > For now Partition demander tries to process all entries for invalid partition > instead of switching to the next partition. > Looks like, this was introduced with a fix IGNITE-8955 to make checkpoint > locks fine-grained. > A "for" loop under checkpoint readlock in > GridDhtPartitionDemander.handleSupplyMessage() causes the issue. A flow can > breaks inner "for" loop in case of invalid partition, but seems an outer > "while" loop expected. > > To resolve this we can e.g. move CacheEntryInfo collection processing into > separate method and just exit from it if invalid partition is detected. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11916) SQL: Reorder fields for GridQueryKillResponse and GridQueryKillRequest.
[ https://issues.apache.org/jira/browse/IGNITE-11916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Mashenkov updated IGNITE-11916: -- Summary: SQL: Reorder fields for GridQueryKillResponse and GridQueryKillRequest. (was: reorder fields for GridQueryKillResponse and GridQueryKillRequest) > SQL: Reorder fields for GridQueryKillResponse and GridQueryKillRequest. > --- > > Key: IGNITE-11916 > URL: https://issues.apache.org/jira/browse/IGNITE-11916 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.8 >Reporter: Pavel Kuznetsov >Assignee: Pavel Kuznetsov >Priority: Major > Labels: compatibility > > need to reorder all fields for GridQueryKillResponse and GridQueryKillRequest > messages using MessageCodeGenerator to have right order of fields to avoid > upgrade issues. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11918) SQL: Extend test coverage for KILL QUERY.
[ https://issues.apache.org/jira/browse/IGNITE-11918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Mashenkov updated IGNITE-11918: -- Summary: SQL: Extend test coverage for KILL QUERY. (was: extend test coverage for KILL QUERY) > SQL: Extend test coverage for KILL QUERY. > - > > Key: IGNITE-11918 > URL: https://issues.apache.org/jira/browse/IGNITE-11918 > Project: Ignite > Issue Type: Test > Components: sql >Reporter: Pavel Kuznetsov >Assignee: Pavel Kuznetsov >Priority: Major > Labels: test > Time Spent: 10m > Remaining Estimate: 0h > > Currently we have implemented KILL QUERY COMMAND. However not all cases > covered by tests and probably it doesn't work properly for all cases. > On first look need to add following test scenarios for KILL QUERY command: > 1) not stable topology - when node couldn't reserve partitions. > 2) map and reduce parts > 3) with concrete partition > 4) when partition pruning is work. > 5) local query > 6) distributed joins. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11919) Change message format for incompatible fields' types changes
[
https://issues.apache.org/jira/browse/IGNITE-11919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16867395#comment-16867395
]
Andrew Mashenkov commented on IGNITE-11919:
---
[~pkouznet]
Fix looks ok, but I'd suggest minor improvement for test.
Please find my comment to the PR.
> Change message format for incompatible fields' types changes
>
>
> Key: IGNITE-11919
> URL: https://issues.apache.org/jira/browse/IGNITE-11919
> Project: Ignite
> Issue Type: Task
>Reporter: Denis Magda
>Assignee: Pavel Kuznetsov
>Priority: Blocker
> Fix For: 2.8
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Follow this discussion thread to find out the reason for the change:
> http://apache-ignite-developers.2346864.n4.nabble.com/Ignite-stops-working-suddenly-during-dev-td42207.html
> It's suggested to apply the following format:
> {code}
> ERROR: Type 'ClassName/TypeName' has a different/incorrect type
> for field 'FieldName'. Expected 'type1' but 'type2' was provided. Field
> type's modification is unsupported, clean {root_path}/marshaller directory
> if the type change is required.
> {code}
> That's an example of how it will look like:
> {code}
> ERROR: Type 'Person' has a different/incorrect type
> for field 'salary'. Expected 'double' but 'string' was provided. Field
> type's modification is unsupported, clean {root_path}/marshaller directory
> if the type change is required.
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-9949) MVCC TX: Scan query can return wrong result on unstable topology
[
https://issues.apache.org/jira/browse/IGNITE-9949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Mashenkov reassigned IGNITE-9949:
Assignee: (was: Andrew Mashenkov)
> MVCC TX: Scan query can return wrong result on unstable topology
>
>
> Key: IGNITE-9949
> URL: https://issues.apache.org/jira/browse/IGNITE-9949
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Reporter: Roman Kondakov
>Priority: Major
> Labels: mvcc_stability, transactions
> Fix For: 2.8
>
>
> Scan query map nodes do not take into account topology version when filtering
> primary partitions. See method {{GridCacheQueryManager#scanIterator}} - each
> node takes it's current topology version. This causes wrong partition
> filtering results.
> To fix this problem the single topology version should be taken on reduce
> node propagated to map nodes.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-10550) MVCC: rework IgniteWalFlush* tests for mvcc.
[ https://issues.apache.org/jira/browse/IGNITE-10550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Mashenkov reassigned IGNITE-10550: - Assignee: (was: Andrew Mashenkov) > MVCC: rework IgniteWalFlush* tests for mvcc. > > > Key: IGNITE-10550 > URL: https://issues.apache.org/jira/browse/IGNITE-10550 > Project: Ignite > Issue Type: Bug > Components: cache, mvcc >Reporter: Andrew Mashenkov >Priority: Major > Labels: WAL > Fix For: 2.8 > > Time Spent: 20m > Remaining Estimate: 0h > > Next tests failed in mvcc mode, most likely due to different MVCC tx semantic: > * IgniteWalFlushBackgroundSelfTest > * IgniteWalFlushBackgroundWithMmapBufferSelfTest > * IgniteWalFlushFsyncSelfTest > * IgniteWalFlushFsyncWithDedicatedWorkerSelfTest > * IgniteWalFlushFsyncWithMmapBufferSelfTest > * IgniteWalFlushLogOnlySelfTest > * IgniteWalFlushLogOnlyWithMmapBufferSelfTest > We have to create similar tests for mvcc mode. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11623) MVCC: testRebalancingDuringLoad_N tests are flacky in master
[
https://issues.apache.org/jira/browse/IGNITE-11623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16865448#comment-16865448
]
Andrew Mashenkov commented on IGNITE-11623:
---
Single-threaded tests (like testRebalancingDuringLoad_**_1_1 ) looks ok.
But multi-threaded tests (like testRebalancingDuringLoad_**_8_16) are broken
and fails on master.
Possible reasons:
* Race b/w transactions. New transaction starts before previous one update it's
state in TxLog.
* Race in Mvcc coordinator. Somehow, vacuum get cleanup version too early.
* Missed TxLog WAL record.
* Vacuum didn't clear rolled back version.
> MVCC: testRebalancingDuringLoad_N tests are flacky in master
>
>
> Key: IGNITE-11623
> URL: https://issues.apache.org/jira/browse/IGNITE-11623
> Project: Ignite
> Issue Type: Bug
>Reporter: Amelchev Nikita
>Priority: Major
> Labels: MakeTeamcityGreenAgain
>
> The following tests are flacky in master:
> IgnitePdsMvccTestSuite3:
> IgnitePdsContinuousRestartTest.testRebalancingDuringLoad_10_10_1_1 ( [Test
> history|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-5373044394008664141=%3Cdefault%3E=testDetails]
> )
> testRebalancingDuringLoad_1000_2_8_16 ( [Test
> history|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8==testDetails=8776582252343254845=TEST_STATUS_DESC_IgniteTests24Java8=%3Cdefault%3E=50])
> testRebalancingDuringLoad_1000_500_8_1 ([Test
> history|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=4172157337542230771=%3Cdefault%3E=testDetails])
> IgniteClusterActivateDeactivateTestWithPersistence.testDeactivateDuringEvictionAndRebalance
> ([Test
> history|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=4619901385813836807=%3Cdefault%3E=testDetails])
> According to the logs, the cause of the fall:
> *IgniteTxUnexpectedStateCheckedException: Unexpected state*
> {noformat}
> java.lang.AssertionError: Unexpected exception: javax.cache.CacheException:
> class org.apache.ignite.transactions.TransactionRollbackException:
> Transaction has been rolled back:
> be9b08fa961--09d4-4a7d--0001
> at
> org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1318)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.cacheException(IgniteCacheProxyImpl.java:2064)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.putAll(IgniteCacheProxyImpl.java:1371)
> at
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.putAll(GatewayProtectedCacheProxy.java:866)
> at
> org.apache.ignite.internal.processors.cache.persistence.IgnitePdsContinuousRestartTest$1.call(IgnitePdsContinuousRestartTest.java:280)
> at org.apache.ignite.testframework.GridTestThread.run(GridTestThread.java:84)
> Caused by: class org.apache.ignite.transactions.TransactionRollbackException:
> Transaction has been rolled back:
> be9b08fa961--09d4-4a7d--0001
> at org.apache.ignite.internal.util.IgniteUtils$11.apply(IgniteUtils.java:935)
> at org.apache.ignite.internal.util.IgniteUtils$11.apply(IgniteUtils.java:933)
> ... 6 more
> Caused by: class
> org.apache.ignite.internal.transactions.IgniteTxRollbackCheckedException:
> Transaction has been rolled back:
> be9b08fa961--09d4-4a7d--0001
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.syncOp(GridCacheAdapter.java:4297)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.putAll0(GridCacheAdapter.java:3000)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.putAll(GridCacheAdapter.java:2989)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.putAll(IgniteCacheProxyImpl.java:1368)
> ... 3 more
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to update
> backup node: [localNodeId=44bb5db4-5317-4ab1-8379-16f3b923,
> remoteNodeId=08a44c02-ebe8-46e8-a7ca-890c6251]
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxAbstractEnlistFuture.onResult(GridDhtTxAbstractEnlistFuture.java:999)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter.processDhtTxQueryEnlistResponse(GridDhtTransactionalCacheAdapter.java:2350)
> 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
>
[jira] [Commented] (IGNITE-11910) JDBC v2: adds 'schema' to URL parameters, makes 'cache' parameter is optional for the most cases
[ https://issues.apache.org/jira/browse/IGNITE-11910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16863882#comment-16863882 ] Andrew Mashenkov commented on IGNITE-11910: --- [~tledkov-gridgain] Look good, merged to master. Thanks for contribution! > JDBC v2: adds 'schema' to URL parameters, makes 'cache' parameter is optional > for the most cases > > > Key: IGNITE-11910 > URL: https://issues.apache.org/jira/browse/IGNITE-11910 > Project: Ignite > Issue Type: Bug > Components: jdbc >Reporter: Taras Ledkov >Assignee: Taras Ledkov >Priority: Major > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > We have to do changes for the JDBC v2: > - makes 'cache' parameter is optional. > - add 'schema' parameter to URL. > When cache and schema parameters are not defined 'PUBLIC' schema is used. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10801) Upgrade H2 version up to 1.4.199
[ https://issues.apache.org/jira/browse/IGNITE-10801?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Mashenkov updated IGNITE-10801: -- Ignite Flags: (was: Docs Required) > Upgrade H2 version up to 1.4.199 > > > Key: IGNITE-10801 > URL: https://issues.apache.org/jira/browse/IGNITE-10801 > Project: Ignite > Issue Type: Improvement > Components: sql >Affects Versions: 2.7 >Reporter: Sergey Antonov >Priority: Critical > Labels: sql > Fix For: 2.8 > > > After h2 1.4.199 release we should upgrade h2 version using in AI, because of > important bugs will be fixed there. For example > https://github.com/h2database/h2database/issues/1057 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10801) Upgrade H2 version up to 1.4.199
[ https://issues.apache.org/jira/browse/IGNITE-10801?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Mashenkov updated IGNITE-10801: -- Description: After h2 1.4.199 release we should upgrade h2 version using in AI, because of important bugs will be fixed there. For example https://github.com/h2database/h2database/issues/1057 (was: After h2 1.4.198 release we should upgrade h2 version using in AI, because of important bugs will be fixed there. For example https://github.com/h2database/h2database/issues/1057) > Upgrade H2 version up to 1.4.199 > > > Key: IGNITE-10801 > URL: https://issues.apache.org/jira/browse/IGNITE-10801 > Project: Ignite > Issue Type: Improvement > Components: sql >Affects Versions: 2.7 >Reporter: Sergey Antonov >Priority: Critical > Labels: sql > Fix For: 2.8 > > > After h2 1.4.199 release we should upgrade h2 version using in AI, because of > important bugs will be fixed there. For example > https://github.com/h2database/h2database/issues/1057 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10801) Upgrade H2 version up to 1.4.199
[ https://issues.apache.org/jira/browse/IGNITE-10801?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Mashenkov updated IGNITE-10801: -- Summary: Upgrade H2 version up to 1.4.199 (was: Upgrade H2 version up to 1.4.198) > Upgrade H2 version up to 1.4.199 > > > Key: IGNITE-10801 > URL: https://issues.apache.org/jira/browse/IGNITE-10801 > Project: Ignite > Issue Type: Improvement > Components: sql >Affects Versions: 2.7 >Reporter: Sergey Antonov >Priority: Critical > Labels: sql > Fix For: 2.8 > > > After h2 1.4.198 release we should upgrade h2 version using in AI, because of > important bugs will be fixed there. For example > https://github.com/h2database/h2database/issues/1057 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11891) Multi-column index - query out of memory
[
https://issues.apache.org/jira/browse/IGNITE-11891?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Mashenkov updated IGNITE-11891:
--
Labels: performance (was: )
> Multi-column index - query out of memory
>
>
> Key: IGNITE-11891
> URL: https://issues.apache.org/jira/browse/IGNITE-11891
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.7
>Reporter: João Fonseca
>Priority: Major
> Labels: performance
>
> My application uses a table for logging events. Something like:
>
> {noformat}
> create table event (
> id bigint not null,
> level varchar(8) not null,
> timestamp bigint not null,
> message varchar(4096) not null,
> primary key (id)
> ) ;
> {noformat}
> I have two indexes:
>
> {noformat}
> create index index_event_timestamp on event (timestamp desc)
> create index index_event_level on event (level, timestamp desc)
> {noformat}
> The idea is to support both the following queries:
>
> {noformat}
> select * from event order by timestamp desc limit 25
> select * from event where level = 'WARNING' order by timestamp desc limit 25
> {noformat}
> Once the table size increases to several million records, the second query
> generates OOM on the server. From what I can see (from the explain results),
> the index_event_level is used to fetch records with WARNING level, but the
> timestamp column available with the index is not used in the "order by"
> clause. The server attempts to fetch all records and then sort them by
> timestamp, despite the index already doing this...
> I removed the second index as a work-around, and the query runs faster on the
> first index - it scans index_event_timestamp, and retrieves the records with
> level=WARNING. It's smart to realize that the scan results are already sorted
> correctly.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11891) Multi-column index - query out of memory
[
https://issues.apache.org/jira/browse/IGNITE-11891?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Mashenkov updated IGNITE-11891:
--
Ignite Flags: (was: Docs Required)
> Multi-column index - query out of memory
>
>
> Key: IGNITE-11891
> URL: https://issues.apache.org/jira/browse/IGNITE-11891
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.7
>Reporter: João Fonseca
>Priority: Major
>
> My application uses a table for logging events. Something like:
>
> {noformat}
> create table event (
> id bigint not null,
> level varchar(8) not null,
> timestamp bigint not null,
> message varchar(4096) not null,
> primary key (id)
> ) ;
> {noformat}
> I have two indexes:
>
> {noformat}
> create index index_event_timestamp on event (timestamp desc)
> create index index_event_level on event (level, timestamp desc)
> {noformat}
> The idea is to support both the following queries:
>
> {noformat}
> select * from event order by timestamp desc limit 25
> select * from event where level = 'WARNING' order by timestamp desc limit 25
> {noformat}
> Once the table size increases to several million records, the second query
> generates OOM on the server. From what I can see (from the explain results),
> the index_event_level is used to fetch records with WARNING level, but the
> timestamp column available with the index is not used in the "order by"
> clause. The server attempts to fetch all records and then sort them by
> timestamp, despite the index already doing this...
> I removed the second index as a work-around, and the query runs faster on the
> first index - it scans index_event_timestamp, and retrieves the records with
> level=WARNING. It's smart to realize that the scan results are already sorted
> correctly.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11891) Multi-column index - query out of memory
[
https://issues.apache.org/jira/browse/IGNITE-11891?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Mashenkov updated IGNITE-11891:
--
Issue Type: Improvement (was: Bug)
> Multi-column index - query out of memory
>
>
> Key: IGNITE-11891
> URL: https://issues.apache.org/jira/browse/IGNITE-11891
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Affects Versions: 2.7
>Reporter: João Fonseca
>Priority: Major
> Labels: performance
>
> My application uses a table for logging events. Something like:
>
> {noformat}
> create table event (
> id bigint not null,
> level varchar(8) not null,
> timestamp bigint not null,
> message varchar(4096) not null,
> primary key (id)
> ) ;
> {noformat}
> I have two indexes:
>
> {noformat}
> create index index_event_timestamp on event (timestamp desc)
> create index index_event_level on event (level, timestamp desc)
> {noformat}
> The idea is to support both the following queries:
>
> {noformat}
> select * from event order by timestamp desc limit 25
> select * from event where level = 'WARNING' order by timestamp desc limit 25
> {noformat}
> Once the table size increases to several million records, the second query
> generates OOM on the server. From what I can see (from the explain results),
> the index_event_level is used to fetch records with WARNING level, but the
> timestamp column available with the index is not used in the "order by"
> clause. The server attempts to fetch all records and then sort them by
> timestamp, despite the index already doing this...
> I removed the second index as a work-around, and the query runs faster on the
> first index - it scans index_event_timestamp, and retrieves the records with
> level=WARNING. It's smart to realize that the scan results are already sorted
> correctly.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11891) Multi-column index - query out of memory
[
https://issues.apache.org/jira/browse/IGNITE-11891?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16856747#comment-16856747
]
Andrew Mashenkov commented on IGNITE-11891:
---
[~joao_g_fonseca],
Nice to hear you've found workaroud!
Thanks for the information, we'll keep in mind this use case.
> Multi-column index - query out of memory
>
>
> Key: IGNITE-11891
> URL: https://issues.apache.org/jira/browse/IGNITE-11891
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.7
>Reporter: João Fonseca
>Priority: Major
>
> My application uses a table for logging events. Something like:
>
> {noformat}
> create table event (
> id bigint not null,
> level varchar(8) not null,
> timestamp bigint not null,
> message varchar(4096) not null,
> primary key (id)
> ) ;
> {noformat}
> I have two indexes:
>
> {noformat}
> create index index_event_timestamp on event (timestamp desc)
> create index index_event_level on event (level, timestamp desc)
> {noformat}
> The idea is to support both the following queries:
>
> {noformat}
> select * from event order by timestamp desc limit 25
> select * from event where level = 'WARNING' order by timestamp desc limit 25
> {noformat}
> Once the table size increases to several million records, the second query
> generates OOM on the server. From what I can see (from the explain results),
> the index_event_level is used to fetch records with WARNING level, but the
> timestamp column available with the index is not used in the "order by"
> clause. The server attempts to fetch all records and then sort them by
> timestamp, despite the index already doing this...
> I removed the second index as a work-around, and the query runs faster on the
> first index - it scans index_event_timestamp, and retrieves the records with
> level=WARNING. It's smart to realize that the scan results are already sorted
> correctly.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11891) Multi-column index - query out of memory
[
https://issues.apache.org/jira/browse/IGNITE-11891?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16856678#comment-16856678
]
Andrew Mashenkov commented on IGNITE-11891:
---
[~joao_g_fonseca], have you tried to use index-hints [#1] to force
'index_event_level'?
Ignite relies on H2 query execution pipeline and I'd think it should be fixed
in H2 at first.
Only then this issue can be resolved in Ignite with upgrading H2 dependency.
[1]
https://apacheignite.readme.io/v2.0/docs/sql-performance-and-debugging#index-hints
> Multi-column index - query out of memory
>
>
> Key: IGNITE-11891
> URL: https://issues.apache.org/jira/browse/IGNITE-11891
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.7
>Reporter: João Fonseca
>Priority: Major
>
> My application uses a table for logging events. Something like:
>
> {noformat}
> create table event (
> id bigint not null,
> level varchar(8) not null,
> timestamp bigint not null,
> message varchar(4096) not null,
> primary key (id)
> ) ;
> {noformat}
> I have two indexes:
>
> {noformat}
> create index index_event_timestamp on event (timestamp desc)
> create index index_event_level on event (level, timestamp desc)
> {noformat}
> The idea is to support both the following queries:
>
> {noformat}
> select * from event order by timestamp desc limit 25
> select * from event where level = 'WARNING' order by timestamp desc limit 25
> {noformat}
> Once the table size increases to several million records, the second query
> generates OOM on the server. From what I can see (from the explain results),
> the index_event_level is used to fetch records with WARNING level, but the
> timestamp column available with the index is not used in the "order by"
> clause. The server attempts to fetch all records and then sort them by
> timestamp, despite the index already doing this...
> I removed the second index as a work-around, and the query runs faster on the
> first index - it scans index_event_timestamp, and retrieves the records with
> level=WARNING. It's smart to realize that the scan results are already sorted
> correctly.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10690) Ignite throws exception when storing an object with an Instant field
[
https://issues.apache.org/jira/browse/IGNITE-10690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16841216#comment-16841216
]
Andrew Mashenkov commented on IGNITE-10690:
---
[~pkouznet],
I'm not sure it is correct way and range conditions on Instant column will work
correctly.
Please, take a look how we overcome similar issue with Java8
LocalData\LocalTime types.
It seems we can convert Instant into H2 internal time objects and back in same
way.
> Ignite throws exception when storing an object with an Instant field
>
>
> Key: IGNITE-10690
> URL: https://issues.apache.org/jira/browse/IGNITE-10690
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.7
>Reporter: Benjamin Dunton
>Assignee: Pavel Kuznetsov
>Priority: Blocker
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> This was working fine with Ignite 2.6.0 and H2 version 1.4.196. I upgraded to
> Ignite 2.7 and H2 version 1.4.197, and it is now broken.
> I am using spring-data with a repository defined like this:
> {{@RepositoryConfig(cacheName = "myObjectCache")}}
> {{interface MyObjectRepository extends IgniteRepository
> {}}
> {{ ...}}
> {{}}}
> If SomeObject has a field of type Instant, I get an IgniteCheckedException
> when inserting the object into the repository.
> This broke as a result of the recent H2 upgrade in IGNITE-4150. In H2 version
> 1.4.197, they changed the way Instant fields are mapped to the underlying
> data type. In 1.4.196 and earlier, Instants were mapped to Value.JAVA_OBJECT,
> but now are mapped to Value.TIMESTAMP_TZ (see
> org.h2.value.DataType.getTypeFromClass(Class x)).
> When GridH2RowDescriptor tries to wrap the value, it doesn't recognize
> TIMESTAMP_TZ, and it throws IgniteCheckedException. See
> GridH2RowDescriptor.wrap(Object, int).
>
> Here is the relevant part of the stack trace:
> {code}
> org.h2.message.DbException: General error: "class
> org.apache.ignite.IgniteCheckedException: Failed to wrap value[type=24,
> value=2018-12-14T13:07:30.982Z]" [5-197]
> at org.h2.message.DbException.get(DbException.java:168)
> at org.h2.message.DbException.convert(DbException.java:307)
> at
> org.apache.ignite.internal.processors.query.h2.opt.GridH2KeyValueRowOnheap.getValue0(GridH2KeyValueRowOnheap.java:138)
> at
> org.apache.ignite.internal.processors.query.h2.opt.GridH2KeyValueRowOnheap.getValue(GridH2KeyValueRowOnheap.java:113)
> at
> org.apache.ignite.internal.processors.query.h2.opt.GridH2KeyValueRowOnheap.toString(GridH2KeyValueRowOnheap.java:201)
> at java.lang.String.valueOf(String.java:2994)
> at java.lang.StringBuilder.append(StringBuilder.java:131)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.doRemove(BPlusTree.java:1969)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.removex(BPlusTree.java:1764)
> at
> org.apache.ignite.internal.processors.query.h2.database.H2TreeIndex.removex(H2TreeIndex.java:345)
> at
> org.apache.ignite.internal.processors.query.h2.opt.GridH2Table.remove(GridH2Table.java:521)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.remove(IgniteH2Indexing.java:797)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.remove(GridQueryProcessor.java:2596)
> at
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager.remove(GridCacheQueryManager.java:435)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.finishRemove(IgniteCacheOffheapManagerImpl.java:2709)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.remove(IgniteCacheOffheapManagerImpl.java:2686)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.remove(IgniteCacheOffheapManagerImpl.java:651)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.removeValue(GridCacheMapEntry.java:4362)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.invalidate(GridCacheMapEntry.java:2914)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxAdapter.uncommit(IgniteTxAdapter.java:486)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxLocalAdapter.userCommit(IgniteTxLocalAdapter.java:966)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.localFinish(GridNearTxLocal.java:3646)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxFinishFuture.doFinish(GridNearTxFinishFuture.java:475)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxFinishFuture.finish(GridNearTxFinishFuture.java:425)
> at
>
[jira] [Updated] (IGNITE-11837) Thin client fails to connect to the cluster if one node is down
[
https://issues.apache.org/jira/browse/IGNITE-11837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Mashenkov updated IGNITE-11837:
--
Issue Type: Task (was: Bug)
> Thin client fails to connect to the cluster if one node is down
> ---
>
> Key: IGNITE-11837
> URL: https://issues.apache.org/jira/browse/IGNITE-11837
> Project: Ignite
> Issue Type: Task
> Components: thin client
>Affects Versions: 2.7
>Reporter: Nikola Arnaudov
>Assignee: Pavel Kuznetsov
>Priority: Major
> Labels: javadoc
> Fix For: 2.8
>
>
> According to java doc:
> in org.apache.ignite.Ignition
> {code:java}
> /**
> * Initializes new instance of \{@link IgniteClient}.
> *
> * Server connection will be lazily initialized when first required.
> *
> * @param cfg Thin client configuration.
> * @return Successfully opened thin client connection.
> */
> public static IgniteClient startClient(ClientConfiguration cfg)
> {code}
> but that seems wrong as I get exception:
> {code}
> Exception in thread "main"
> org.apache.ignite.client.ClientConnectionException: Ignite cluster is
> unavailable
> at
> org.apache.ignite.internal.client.thin.TcpClientChannel.(TcpClientChannel.java:114)
> at
> org.apache.ignite.internal.client.thin.TcpIgniteClient.lambda$new$0(TcpIgniteClient.java:79)
> at
> org.apache.ignite.internal.client.thin.ReliableChannel.(ReliableChannel.java:84)
> at
> org.apache.ignite.internal.client.thin.TcpIgniteClient.(TcpIgniteClient.java:86)
> at
> org.apache.ignite.internal.client.thin.TcpIgniteClient.start(TcpIgniteClient.java:205)
> Caused by: java.net.ConnectException: Connection refused: connect
> at java.net.DualStackPlainSocketImpl.connect0(Native Method)
> at
> java.net.DualStackPlainSocketImpl.socketConnect(DualStackPlainSocketImpl.java:79)
> at
> java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350)
> at
> java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
> at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
> at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:172)
> at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
> at java.net.Socket.connect(Socket.java:589)
> at java.net.Socket.connect(Socket.java:538)
> at java.net.Socket.(Socket.java:434)
> at java.net.Socket.(Socket.java:211)
> at
> org.apache.ignite.internal.client.thin.TcpClientChannel.createSocket(TcpClientChannel.java:216)
> at
> org.apache.ignite.internal.client.thin.TcpClientChannel.(TcpClientChannel.java:108)at
> org.apache.ignite.Ignition.startClient(Ignition.java:586)
> {code}
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11837) Thin client fails to connect to the cluster if one node is down
[
https://issues.apache.org/jira/browse/IGNITE-11837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Mashenkov updated IGNITE-11837:
--
Fix Version/s: 2.8
> Thin client fails to connect to the cluster if one node is down
> ---
>
> Key: IGNITE-11837
> URL: https://issues.apache.org/jira/browse/IGNITE-11837
> Project: Ignite
> Issue Type: Bug
> Components: thin client
>Affects Versions: 2.7
>Reporter: Nikola Arnaudov
>Assignee: Pavel Kuznetsov
>Priority: Major
> Labels: javadoc
> Fix For: 2.8
>
>
> According to java doc:
> in org.apache.ignite.Ignition
> {code:java}
> /**
> * Initializes new instance of \{@link IgniteClient}.
> *
> * Server connection will be lazily initialized when first required.
> *
> * @param cfg Thin client configuration.
> * @return Successfully opened thin client connection.
> */
> public static IgniteClient startClient(ClientConfiguration cfg)
> {code}
> but that seems wrong as I get exception:
> {code}
> Exception in thread "main"
> org.apache.ignite.client.ClientConnectionException: Ignite cluster is
> unavailable
> at
> org.apache.ignite.internal.client.thin.TcpClientChannel.(TcpClientChannel.java:114)
> at
> org.apache.ignite.internal.client.thin.TcpIgniteClient.lambda$new$0(TcpIgniteClient.java:79)
> at
> org.apache.ignite.internal.client.thin.ReliableChannel.(ReliableChannel.java:84)
> at
> org.apache.ignite.internal.client.thin.TcpIgniteClient.(TcpIgniteClient.java:86)
> at
> org.apache.ignite.internal.client.thin.TcpIgniteClient.start(TcpIgniteClient.java:205)
> Caused by: java.net.ConnectException: Connection refused: connect
> at java.net.DualStackPlainSocketImpl.connect0(Native Method)
> at
> java.net.DualStackPlainSocketImpl.socketConnect(DualStackPlainSocketImpl.java:79)
> at
> java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350)
> at
> java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
> at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
> at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:172)
> at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
> at java.net.Socket.connect(Socket.java:589)
> at java.net.Socket.connect(Socket.java:538)
> at java.net.Socket.(Socket.java:434)
> at java.net.Socket.(Socket.java:211)
> at
> org.apache.ignite.internal.client.thin.TcpClientChannel.createSocket(TcpClientChannel.java:216)
> at
> org.apache.ignite.internal.client.thin.TcpClientChannel.(TcpClientChannel.java:108)at
> org.apache.ignite.Ignition.startClient(Ignition.java:586)
> {code}
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11756) SQL: implement a table row count statistics for the local queries
[
https://issues.apache.org/jira/browse/IGNITE-11756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16838378#comment-16838378
]
Andrew Mashenkov commented on IGNITE-11756:
---
[~rkondakov],
I've left one comment to the PR. Seems, cache size statistic is calculated
regardless of partition state.
Other changes look good.
> SQL: implement a table row count statistics for the local queries
> -
>
> Key: IGNITE-11756
> URL: https://issues.apache.org/jira/browse/IGNITE-11756
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Roman Kondakov
>Assignee: Roman Kondakov
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Row count statistics should help the H2 optimizer to select the better query
> execution plan. Currently the row count supplied to H2 engine is hardcoded
> value == 1 (see {{org.h2.index.Index#getRowCountApproximation}}). As a
> first step we can provide an actual table size in the case of local query. To
> prevent counting size on each invocation we can cache row count value and
> invalidate it in some cases:
> * Rebalancing
> * Multiple updates (after the initial loading)
> * On timeout (i.e. 1 minute)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (IGNITE-11811) Cache 2 suite test GridCacheDhtPreloadDelayedSelfTest failed on TC.
[
https://issues.apache.org/jira/browse/IGNITE-11811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Mashenkov resolved IGNITE-11811.
---
Resolution: Duplicate
Test prints expected assertion that looks confused.
Should be fixed within https://issues.apache.org/jira/browse/IGNITE-11815
> Cache 2 suite test GridCacheDhtPreloadDelayedSelfTest failed on TC.
> ---
>
> Key: IGNITE-11811
> URL: https://issues.apache.org/jira/browse/IGNITE-11811
> Project: Ignite
> Issue Type: Test
> Components: cache
>Reporter: Andrew Mashenkov
>Priority: Major
> Labels: MakeTeamcityGreenAgain, test-fail
>
> {code:java}
> [2019-04-26 08:00:37,500][WARN
> ][test-runner-#27151%dht.GridCacheDhtPreloadDelayedSelfTest%][root] Check
> failed (will retry in 500ms).
> java.lang.AssertionError
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridCacheDhtPreloadDelayedSelfTest$5.applyx(GridCacheDhtPreloadDelayedSelfTest.java:465)
> at
> org.apache.ignite.internal.util.lang.GridAbsClosureX.apply(GridAbsClosureX.java:34)
> at
> org.apache.ignite.testframework.GridTestUtils.retryAssert(GridTestUtils.java:1608)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridCacheDhtPreloadDelayedSelfTest.checkMaps(GridCacheDhtPreloadDelayedSelfTest.java:442)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridCacheDhtPreloadDelayedSelfTest.testDelayedPreload(GridCacheDhtPreloadDelayedSelfTest.java:235)
> 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.apache.ignite.testframework.junits.GridAbstractTest$6.run(GridAbstractTest.java:2044)
> at java.lang.Thread.run(Thread.java:748)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (IGNITE-11811) Cache 2 suite test GridCacheDhtPreloadDelayedSelfTest failed on TC.
[
https://issues.apache.org/jira/browse/IGNITE-11811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Mashenkov closed IGNITE-11811.
-
> Cache 2 suite test GridCacheDhtPreloadDelayedSelfTest failed on TC.
> ---
>
> Key: IGNITE-11811
> URL: https://issues.apache.org/jira/browse/IGNITE-11811
> Project: Ignite
> Issue Type: Test
> Components: cache
>Reporter: Andrew Mashenkov
>Priority: Major
> Labels: MakeTeamcityGreenAgain, test-fail
>
> {code:java}
> [2019-04-26 08:00:37,500][WARN
> ][test-runner-#27151%dht.GridCacheDhtPreloadDelayedSelfTest%][root] Check
> failed (will retry in 500ms).
> java.lang.AssertionError
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridCacheDhtPreloadDelayedSelfTest$5.applyx(GridCacheDhtPreloadDelayedSelfTest.java:465)
> at
> org.apache.ignite.internal.util.lang.GridAbsClosureX.apply(GridAbsClosureX.java:34)
> at
> org.apache.ignite.testframework.GridTestUtils.retryAssert(GridTestUtils.java:1608)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridCacheDhtPreloadDelayedSelfTest.checkMaps(GridCacheDhtPreloadDelayedSelfTest.java:442)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridCacheDhtPreloadDelayedSelfTest.testDelayedPreload(GridCacheDhtPreloadDelayedSelfTest.java:235)
> 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.apache.ignite.testframework.junits.GridAbstractTest$6.run(GridAbstractTest.java:2044)
> at java.lang.Thread.run(Thread.java:748)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11815) Get rid of GridTestUtils.retryAssert method.
[ https://issues.apache.org/jira/browse/IGNITE-11815?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Mashenkov updated IGNITE-11815: -- Labels: MakeTeamcityGreenAgain newbie (was: MakeTeamcityGreenAgain) > Get rid of GridTestUtils.retryAssert method. > > > Key: IGNITE-11815 > URL: https://issues.apache.org/jira/browse/IGNITE-11815 > Project: Ignite > Issue Type: Test >Reporter: Andrew Mashenkov >Priority: Major > Labels: MakeTeamcityGreenAgain, newbie > > For now we have GridTestUtils.retryAssert() method which runs a closure 'n' > times to check if some invariantes become ok, eventually. > This method catch assertion error (this looks like a very bad idea) and can > print them to log many times even if assertion is acceptable for the moment. > Also, it is possible to miss an assertion is not related to those ones that > closure checks (e.g. assertion error thrown from ignite internals). > Let's replace retryAssert with GridTestUtils.waitForCondition() usage to make > logs clearer and to avoid possible false positive results. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11815) Get rid of GridTestUtils.retryAssert method.
[ https://issues.apache.org/jira/browse/IGNITE-11815?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Mashenkov updated IGNITE-11815: -- Ignite Flags: (was: Docs Required) > Get rid of GridTestUtils.retryAssert method. > > > Key: IGNITE-11815 > URL: https://issues.apache.org/jira/browse/IGNITE-11815 > Project: Ignite > Issue Type: Test >Reporter: Andrew Mashenkov >Priority: Major > Labels: MakeTeamcityGreenAgain > > For now we have GridTestUtils.retryAssert() method which runs a closure 'n' > times to check if some invariantes become ok, eventually. > This method catch assertion error (this looks like a very bad idea) and can > print them to log many times even if assertion is acceptable for the moment. > Also, it is possible to miss an assertion is not related to those ones that > closure checks (e.g. assertion error thrown from ignite internals). > Let's replace retryAssert with GridTestUtils.waitForCondition() usage to make > logs clearer and to avoid possible false positive results. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11815) Get rid of GridTestUtils.retryAssert method.
[ https://issues.apache.org/jira/browse/IGNITE-11815?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Mashenkov updated IGNITE-11815: -- Description: For now we have GridTestUtils.retryAssert() method which runs a closure 'n' times to check if some invariantes become ok, eventually. This method catch assertion error (this looks like a very bad idea) and can print them to log many times even if assertion is acceptable for the moment. Also, it is possible to miss an assertion is not related to those ones that closure checks (e.g. assertion error thrown from ignite internals). Let's replace retryAssert with GridTestUtils.waitForCondition() usage to make logs clearer and to avoid possible false positive results. was: For now we have GridTestUtils.retryAssert() method which runs a closure 'n' times to check if some invariantes become ok, eventually. This method catch assertions and can print them to log many times even if assertion is acceptable for the moment. Also, it is possible to miss an assertion is not related to those ones that closure checks (e.g. assertion error thrown from ignite internals). Let's replace retryAssert with GridTestUtils.waitForCondition() usage to make logs clearer and to avoid possible false positive results. > Get rid of GridTestUtils.retryAssert method. > > > Key: IGNITE-11815 > URL: https://issues.apache.org/jira/browse/IGNITE-11815 > Project: Ignite > Issue Type: Test >Reporter: Andrew Mashenkov >Priority: Major > Labels: MakeTeamcityGreenAgain > > For now we have GridTestUtils.retryAssert() method which runs a closure 'n' > times to check if some invariantes become ok, eventually. > This method catch assertion error (this looks like a very bad idea) and can > print them to log many times even if assertion is acceptable for the moment. > Also, it is possible to miss an assertion is not related to those ones that > closure checks (e.g. assertion error thrown from ignite internals). > Let's replace retryAssert with GridTestUtils.waitForCondition() usage to make > logs clearer and to avoid possible false positive results. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11815) Get rid of GridTestUtils.retryAssert method.
[ https://issues.apache.org/jira/browse/IGNITE-11815?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Mashenkov updated IGNITE-11815: -- Description: For now we have GridTestUtils.retryAssert() method which runs a closure 'n' times to check if some invariantes become ok, eventually. This method catch assertions and can print them to log many times even if assertion is acceptable for the moment. Also, it is possible to miss an assertion is not related to those ones that closure checks (e.g. assertion error thrown from ignite internals). Let's replace retryAssert with GridTestUtils.waitForCondition() usage to make logs clearer and to avoid possible false positive results. was: For now we have GridTestUtils.retryAssert() method which runs a closure 'n' times to check if some invariantes become ok, eventually. This method catch assertions and can print them to log many times even if assertion is acceptable for the moment. Also, it is possible to miss an assertion is not related to those ones that closure checks (e.g. assertion error thrown from ignite internals). Let's replace retryAssert with GridTestUtils.waitForCondition() usage. > Get rid of GridTestUtils.retryAssert method. > > > Key: IGNITE-11815 > URL: https://issues.apache.org/jira/browse/IGNITE-11815 > Project: Ignite > Issue Type: Test >Reporter: Andrew Mashenkov >Priority: Major > Labels: MakeTeamcityGreenAgain > > For now we have GridTestUtils.retryAssert() method which runs a closure 'n' > times to check if some invariantes become ok, eventually. > This method catch assertions and can print them to log many times even if > assertion is acceptable for the moment. > Also, it is possible to miss an assertion is not related to those ones that > closure checks (e.g. assertion error thrown from ignite internals). > Let's replace retryAssert with GridTestUtils.waitForCondition() usage to make > logs clearer and to avoid possible false positive results. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11815) Get rid of GridTestUtils.retryAssert method.
Andrew Mashenkov created IGNITE-11815: - Summary: Get rid of GridTestUtils.retryAssert method. Key: IGNITE-11815 URL: https://issues.apache.org/jira/browse/IGNITE-11815 Project: Ignite Issue Type: Test Reporter: Andrew Mashenkov For now we have GridTestUtils.retryAssert() method which runs a closure 'n' times to check if some invariantes become ok, eventually. This method catch assertions and can print them to log many times even if assertion is acceptable for the moment. Also, it is possible to miss an assertion is not related to those ones that closure checks (e.g. assertion error thrown from ignite internals). Let's replace retryAssert with GridTestUtils.waitForCondition() usage. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11810) Cache2 suite timeouts due to broken IgniteClientCacheStartFailoverTest.
[
https://issues.apache.org/jira/browse/IGNITE-11810?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Mashenkov updated IGNITE-11810:
--
Ignite Flags: (was: Docs Required)
> Cache2 suite timeouts due to broken IgniteClientCacheStartFailoverTest.
> ---
>
> Key: IGNITE-11810
> URL: https://issues.apache.org/jira/browse/IGNITE-11810
> Project: Ignite
> Issue Type: Test
> Components: cache
>Reporter: Andrew Mashenkov
>Priority: Critical
> Labels: MakeTeamcityGreenAgain, hang, test-fail
>
> {code:java}
> java.lang.AssertionError
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxLocalAdapter.calculatePartitionUpdateCounters(IgniteTxLocalAdapter.java:492)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxLocalAdapter.userPrepare(IgniteTxLocalAdapter.java:433)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxLocal.prepareAsync(GridDhtTxLocal.java:402)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.prepareNearTx(IgniteTxHandler.java:569)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.prepareNearTx(IgniteTxHandler.java:366)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processNearTxPrepareRequest0(IgniteTxHandler.java:177)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processNearTxPrepareRequest(IgniteTxHandler.java:155)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.access$000(IgniteTxHandler.java:117)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$1.apply(IgniteTxHandler.java:197)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$1.apply(IgniteTxHandler.java:195)
> 7][INFO
> ][exchange-worker-#71756%cache.IgniteClientCacheStartFailoverTest7%][GridCacheProcessor]
> Started cache [name=tx-1, id=3572520, dataRegionName=null, mode=PARTITIONED,
> atomicity=TRANSACTIONAL, backu
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1140)
> 6][INFO
> ][exchange-worker-#71662%cache.IgniteClientCacheStartFailoverTest5%][GridCacheProcessor]
> Started cache [name=tx-0, id=3572519, dataRegionName=null, mode=PARTITIONED,
> atomicity=TRANSACTIONAL, backu
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:590)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:391)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:317)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:108)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:307)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1560)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1188)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:126)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$8.run(GridIoManager.java:1085)
> at
> org.apache.ignite.internal.util.StripedExecutor$Stripe.body(StripedExecutor.java:549)
> at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:119)
> at java.lang.Thread.run(Thread.java:748)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11810) Cache2 suite timeouts due to broken IgniteClientCacheStartFailoverTest.
[
https://issues.apache.org/jira/browse/IGNITE-11810?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Mashenkov updated IGNITE-11810:
--
Labels: MakeTeamcityGreenAgain hang test-fail (was: MakeTeamcityGreenAgain)
> Cache2 suite timeouts due to broken IgniteClientCacheStartFailoverTest.
> ---
>
> Key: IGNITE-11810
> URL: https://issues.apache.org/jira/browse/IGNITE-11810
> Project: Ignite
> Issue Type: Test
> Components: cache
>Reporter: Andrew Mashenkov
>Priority: Critical
> Labels: MakeTeamcityGreenAgain, hang, test-fail
>
> {code:java}
> java.lang.AssertionError
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxLocalAdapter.calculatePartitionUpdateCounters(IgniteTxLocalAdapter.java:492)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxLocalAdapter.userPrepare(IgniteTxLocalAdapter.java:433)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxLocal.prepareAsync(GridDhtTxLocal.java:402)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.prepareNearTx(IgniteTxHandler.java:569)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.prepareNearTx(IgniteTxHandler.java:366)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processNearTxPrepareRequest0(IgniteTxHandler.java:177)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processNearTxPrepareRequest(IgniteTxHandler.java:155)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.access$000(IgniteTxHandler.java:117)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$1.apply(IgniteTxHandler.java:197)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$1.apply(IgniteTxHandler.java:195)
> 7][INFO
> ][exchange-worker-#71756%cache.IgniteClientCacheStartFailoverTest7%][GridCacheProcessor]
> Started cache [name=tx-1, id=3572520, dataRegionName=null, mode=PARTITIONED,
> atomicity=TRANSACTIONAL, backu
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1140)
> 6][INFO
> ][exchange-worker-#71662%cache.IgniteClientCacheStartFailoverTest5%][GridCacheProcessor]
> Started cache [name=tx-0, id=3572519, dataRegionName=null, mode=PARTITIONED,
> atomicity=TRANSACTIONAL, backu
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:590)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:391)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:317)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:108)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:307)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1560)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1188)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:126)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$8.run(GridIoManager.java:1085)
> at
> org.apache.ignite.internal.util.StripedExecutor$Stripe.body(StripedExecutor.java:549)
> at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:119)
> at java.lang.Thread.run(Thread.java:748)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11811) Cache 2 suite test GridCacheDhtPreloadDelayedSelfTest failed on TC.
[
https://issues.apache.org/jira/browse/IGNITE-11811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Mashenkov updated IGNITE-11811:
--
Labels: MakeTeamcityGreenAgain test-fail (was: MakeTeamcityGreenAgain)
> Cache 2 suite test GridCacheDhtPreloadDelayedSelfTest failed on TC.
> ---
>
> Key: IGNITE-11811
> URL: https://issues.apache.org/jira/browse/IGNITE-11811
> Project: Ignite
> Issue Type: Test
> Components: cache
>Reporter: Andrew Mashenkov
>Priority: Major
> Labels: MakeTeamcityGreenAgain, test-fail
>
> {code:java}
> [2019-04-26 08:00:37,500][WARN
> ][test-runner-#27151%dht.GridCacheDhtPreloadDelayedSelfTest%][root] Check
> failed (will retry in 500ms).
> java.lang.AssertionError
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridCacheDhtPreloadDelayedSelfTest$5.applyx(GridCacheDhtPreloadDelayedSelfTest.java:465)
> at
> org.apache.ignite.internal.util.lang.GridAbsClosureX.apply(GridAbsClosureX.java:34)
> at
> org.apache.ignite.testframework.GridTestUtils.retryAssert(GridTestUtils.java:1608)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridCacheDhtPreloadDelayedSelfTest.checkMaps(GridCacheDhtPreloadDelayedSelfTest.java:442)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridCacheDhtPreloadDelayedSelfTest.testDelayedPreload(GridCacheDhtPreloadDelayedSelfTest.java:235)
> 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.apache.ignite.testframework.junits.GridAbstractTest$6.run(GridAbstractTest.java:2044)
> at java.lang.Thread.run(Thread.java:748)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11811) Cache 2 suite test GridCacheDhtPreloadDelayedSelfTest failed on TC.
Andrew Mashenkov created IGNITE-11811:
-
Summary: Cache 2 suite test GridCacheDhtPreloadDelayedSelfTest
failed on TC.
Key: IGNITE-11811
URL: https://issues.apache.org/jira/browse/IGNITE-11811
Project: Ignite
Issue Type: Test
Components: cache
Reporter: Andrew Mashenkov
{code:java}
[2019-04-26 08:00:37,500][WARN
][test-runner-#27151%dht.GridCacheDhtPreloadDelayedSelfTest%][root] Check
failed (will retry in 500ms).
java.lang.AssertionError
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridCacheDhtPreloadDelayedSelfTest$5.applyx(GridCacheDhtPreloadDelayedSelfTest.java:465)
at
org.apache.ignite.internal.util.lang.GridAbsClosureX.apply(GridAbsClosureX.java:34)
at
org.apache.ignite.testframework.GridTestUtils.retryAssert(GridTestUtils.java:1608)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridCacheDhtPreloadDelayedSelfTest.checkMaps(GridCacheDhtPreloadDelayedSelfTest.java:442)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridCacheDhtPreloadDelayedSelfTest.testDelayedPreload(GridCacheDhtPreloadDelayedSelfTest.java:235)
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.apache.ignite.testframework.junits.GridAbstractTest$6.run(GridAbstractTest.java:2044)
at java.lang.Thread.run(Thread.java:748)
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11810) Cache2 suite timeouts due to broken IgniteClientCacheStartFailoverTest.
Andrew Mashenkov created IGNITE-11810:
-
Summary: Cache2 suite timeouts due to broken
IgniteClientCacheStartFailoverTest.
Key: IGNITE-11810
URL: https://issues.apache.org/jira/browse/IGNITE-11810
Project: Ignite
Issue Type: Test
Components: cache
Reporter: Andrew Mashenkov
{code:java}
java.lang.AssertionError
at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxLocalAdapter.calculatePartitionUpdateCounters(IgniteTxLocalAdapter.java:492)
at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxLocalAdapter.userPrepare(IgniteTxLocalAdapter.java:433)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxLocal.prepareAsync(GridDhtTxLocal.java:402)
at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.prepareNearTx(IgniteTxHandler.java:569)
at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.prepareNearTx(IgniteTxHandler.java:366)
at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processNearTxPrepareRequest0(IgniteTxHandler.java:177)
at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processNearTxPrepareRequest(IgniteTxHandler.java:155)
at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.access$000(IgniteTxHandler.java:117)
at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$1.apply(IgniteTxHandler.java:197)
at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$1.apply(IgniteTxHandler.java:195)
7][INFO
][exchange-worker-#71756%cache.IgniteClientCacheStartFailoverTest7%][GridCacheProcessor]
Started cache [name=tx-1, id=3572520, dataRegionName=null, mode=PARTITIONED,
atomicity=TRANSACTIONAL, backu
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1140)
6][INFO
][exchange-worker-#71662%cache.IgniteClientCacheStartFailoverTest5%][GridCacheProcessor]
Started cache [name=tx-0, id=3572519, dataRegionName=null, mode=PARTITIONED,
atomicity=TRANSACTIONAL, backu
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:590)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:391)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:317)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:108)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:307)
at
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1560)
at
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1188)
at
org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:126)
at
org.apache.ignite.internal.managers.communication.GridIoManager$8.run(GridIoManager.java:1085)
at
org.apache.ignite.internal.util.StripedExecutor$Stripe.body(StripedExecutor.java:549)
at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:119)
at java.lang.Thread.run(Thread.java:748)
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11798) Memory leak on unstable topology caused by partition reservation
[ https://issues.apache.org/jira/browse/IGNITE-11798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Mashenkov updated IGNITE-11798: -- Ignite Flags: (was: Docs Required) > Memory leak on unstable topology caused by partition reservation > > > Key: IGNITE-11798 > URL: https://issues.apache.org/jira/browse/IGNITE-11798 > Project: Ignite > Issue Type: Bug > Components: cache, sql >Affects Versions: 2.7 >Reporter: Pavel Vinokurov >Priority: Major > Attachments: PartitionReservationReproducer.java > > > Executing queries on unstable topology leads to OOM caused by leak of the > partition reservation. > The reproducer is attached. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7285) Add default query timeout
[
https://issues.apache.org/jira/browse/IGNITE-7285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16824241#comment-16824241
]
Andrew Mashenkov commented on IGNITE-7285:
--
[~samaitra], I've left few comments to PR.
> Add default query timeout
> -
>
> Key: IGNITE-7285
> URL: https://issues.apache.org/jira/browse/IGNITE-7285
> Project: Ignite
> Issue Type: Improvement
> Components: cache, sql
>Affects Versions: 2.3
>Reporter: Valentin Kulichenko
>Assignee: Saikat Maitra
>Priority: Major
> Labels: sql-stability
> Fix For: 2.8
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Currently it's possible to provide timeout only on query level. It would be
> very useful to have default timeout value provided on cache startup. Let's
> add {{CacheConfiguration#defaultQueryTimeout}} configuration property.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11489) SQL: merge IO message listener for GridTopic.TOPIC_QUERY into single listener
[ https://issues.apache.org/jira/browse/IGNITE-11489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Mashenkov updated IGNITE-11489: -- Summary: SQL: merge IO message listener for GridTopic.TOPIC_QUERY into single listener (was: merge IO message listener for GridTopic.TOPIC_QUERY into single listener) > SQL: merge IO message listener for GridTopic.TOPIC_QUERY into single listener > - > > Key: IGNITE-11489 > URL: https://issues.apache.org/jira/browse/IGNITE-11489 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Yury Gerzhedovich >Assignee: Andrew Mashenkov >Priority: Major > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > As of now we have few IO listeners for GridTopic.TOPIC_QUERY. It lead to > spread of logic and we can't check that no any not expected messages received. > Need to merge it to single listeners or have different topics. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-11564) SQL: Implement KILL QUERY command
[
https://issues.apache.org/jira/browse/IGNITE-11564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16821096#comment-16821096
]
Andrew Mashenkov edited comment on IGNITE-11564 at 4/18/19 1:26 PM:
All subtasks were merged to master within single commit.
was (Author: amashenkov):
Merged to master.
> SQL: Implement KILL QUERY command
> -
>
> Key: IGNITE-11564
> URL: https://issues.apache.org/jira/browse/IGNITE-11564
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Vladimir Ozerov
>Priority: Major
> Labels: iep-29
> Fix For: 2.8
>
>
> This is an umbrella ticket for {{KILL QUERY}} command implementation.
> Original description could be found in IGNITE-10161.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11456) Use separate pool for KILL QUERY command
[ https://issues.apache.org/jira/browse/IGNITE-11456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16821099#comment-16821099 ] Andrew Mashenkov commented on IGNITE-11456: --- Merged to master as a part of parent task. > Use separate pool for KILL QUERY command > > > Key: IGNITE-11456 > URL: https://issues.apache.org/jira/browse/IGNITE-11456 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Yury Gerzhedovich >Assignee: Yury Gerzhedovich >Priority: Major > Labels: iep-29 > Fix For: 2.8 > > Time Spent: 20m > Remaining Estimate: 0h > > As of now we use QUERY_POOL to process cancellation requests. It can lead to > unable to cancel a queries in case the pool will be overflowed. > So, need to use separate pool or MGMT pool + non-blocking processing through > futures. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11456) Use separate pool for KILL QUERY command
[ https://issues.apache.org/jira/browse/IGNITE-11456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Mashenkov updated IGNITE-11456: -- Ignite Flags: (was: Docs Required) > Use separate pool for KILL QUERY command > > > Key: IGNITE-11456 > URL: https://issues.apache.org/jira/browse/IGNITE-11456 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Yury Gerzhedovich >Assignee: Yury Gerzhedovich >Priority: Major > Labels: iep-29 > Fix For: 2.8 > > Time Spent: 20m > Remaining Estimate: 0h > > As of now we use QUERY_POOL to process cancellation requests. It can lead to > unable to cancel a queries in case the pool will be overflowed. > So, need to use separate pool or MGMT pool + non-blocking processing through > futures. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-11564) SQL: Implement KILL QUERY command
[
https://issues.apache.org/jira/browse/IGNITE-11564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Mashenkov resolved IGNITE-11564.
---
Resolution: Fixed
Merged to master.
> SQL: Implement KILL QUERY command
> -
>
> Key: IGNITE-11564
> URL: https://issues.apache.org/jira/browse/IGNITE-11564
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Vladimir Ozerov
>Priority: Major
> Labels: iep-29
> Fix For: 2.8
>
>
> This is an umbrella ticket for {{KILL QUERY}} command implementation.
> Original description could be found in IGNITE-10161.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11488) GridServiceProcessorBatchDeploySelfTest test fails sporadically
[
https://issues.apache.org/jira/browse/IGNITE-11488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16819889#comment-16819889
]
Andrew Mashenkov commented on IGNITE-11488:
---
[~rykerzhang]
# There is no need to add a new method. Just, let's add synchronization into
toString() method.
# Sync on "this" object will not resolve the issue, because "singleDepsMsgs"
and "remaining" collections are updated with sync on "initCrdMux" object
> GridServiceProcessorBatchDeploySelfTest test fails sporadically
> ---
>
> Key: IGNITE-11488
> URL: https://issues.apache.org/jira/browse/IGNITE-11488
> Project: Ignite
> Issue Type: Test
> Components: managed services
>Reporter: Andrew Mashenkov
>Assignee: Ryker Zhang
>Priority: Major
> Labels: MakeTeamcityGreenAgain, newbie
> Time Spent: 10m
> Remaining Estimate: 0h
>
> GridServiceProcessorBatchDeploySelfTest.testCancelAllTopologyChange test
> fails on TC sporadically with ConcurrentModificationException.
> Let's add synchronization to certain toString method.
>
> {noformat}
> [super=AbstractFailureHandler [ignoredFailureTypes=UnmodifiableSet
> [SYSTEM_WORKER_BLOCKED, SYSTEM_CRITICAL_OPERATION_TIMEOUT]]],
> failureCtx=FailureContext [type=SYSTEM_WORKER_TERMINATION, err=class
> o.a.i.IgniteException: null]]
> class org.apache.ignite.IgniteException: null
> at
> org.apache.ignite.internal.util.tostring.GridToStringBuilder.toStringImpl0(GridToStringBuilder.java:1081)
> at
> org.apache.ignite.internal.util.tostring.GridToStringBuilder.toStringImpl(GridToStringBuilder.java:993)
> at
> org.apache.ignite.internal.util.tostring.GridToStringBuilder.toString(GridToStringBuilder.java:703)
> at
> org.apache.ignite.internal.util.tostring.GridToStringBuilder.toString(GridToStringBuilder.java:662)
> at
> org.apache.ignite.internal.processors.service.ServiceDeploymentTask.toString(ServiceDeploymentTask.java:854)
> at java.lang.String.valueOf(String.java:2994)
> at java.lang.StringBuilder.append(StringBuilder.java:131)
> at
> org.apache.ignite.internal.processors.service.ServiceDeploymentManager$ServicesDeploymentWorker.body(ServiceDeploymentManager.java:502)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.util.ConcurrentModificationException
> at java.util.HashMap$HashIterator.nextNode(HashMap.java:1442)
> at java.util.HashMap$EntryIterator.next(HashMap.java:1476)
> at java.util.HashMap$EntryIterator.next(HashMap.java:1474)
> at
> org.apache.ignite.internal.util.tostring.GridToStringBuilder.addMap(GridToStringBuilder.java:923)
> at
> org.apache.ignite.internal.util.tostring.GridToStringBuilder.toString(GridToStringBuilder.java:846)
> at
> org.apache.ignite.internal.util.tostring.GridToStringBuilder.toStringImpl0(GridToStringBuilder.java:1065)
> ... 9 more{noformat}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11434) SQL: Create a view with list of existing COLUMNS
[
https://issues.apache.org/jira/browse/IGNITE-11434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Mashenkov updated IGNITE-11434:
--
Fix Version/s: 2.8
> SQL: Create a view with list of existing COLUMNS
>
>
> Key: IGNITE-11434
> URL: https://issues.apache.org/jira/browse/IGNITE-11434
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Yury Gerzhedovich
>Assignee: Taras Ledkov
>Priority: Major
> Labels: iep-29
> Fix For: 2.8
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> Need to expose SQL system view with COLUMNS information.
> Need to investigate more deeper which of information should be there.
>
> As start point we can take
> [https://dev.mysql.com/doc/refman/8.0/en/columns-table.html]
> Columns description:
> || Name || Type || Description||
> | SCHEMA_NAME | string | Schema name |
> | TABLE_NAME | string | Table name |
> | COLUMN_NAME | string | Column name |
> | ORDINAL_POSITION | int | Column ordinal. Starts with 1 |
> | DEFAULT VALUE | string | Defaut column's value |
> | IS_NULLABLE | boolean | Nullable flag corresponds to
> {{QueryEntity#setNotNullFields}} |
> | DATA_TYPE | string | SQL data type |
> | CHARACTER_LENGTH | int | Size for char CAHR and VARCHAR types |
> | NUMERIC_PRECISION | int | Precision for numeric types |
> | NUMERIC_SCALE | int | Scale for numeric types |
> | IS_AFFINITY_KEY | boolean | {{true}} whan the column is affinity key |
> | IS_HIDDEN | boolean | {{true}} for hidden _ley nad _val columns. {{false}}
> for all columns available by asterisk mask |
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10855) Performance problems while running SQL query involving JOINS and ORDER BY eventually leading to heap OOME.
[ https://issues.apache.org/jira/browse/IGNITE-10855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Mashenkov updated IGNITE-10855: -- Ignite Flags: (was: Docs Required) > Performance problems while running SQL query involving JOINS and ORDER BY > eventually leading to heap OOME. > -- > > Key: IGNITE-10855 > URL: https://issues.apache.org/jira/browse/IGNITE-10855 > Project: Ignite > Issue Type: Bug > Components: cache, sql >Affects Versions: 2.7 >Reporter: Gourav Agrawal >Priority: Blocker > Fix For: None > > > To simplify our use-case, we created two caches using the SQL query and > loaded data consisting of about 4 million records and 60k records > approximately, in the respective caches with INDEX created on all the > columns. Ignite is set up to run on a single node, meaning all the data is > present on the same node. The query used for testing/the one we are facing > issue with is of the type - > _SELECT * FROM CACHE1 C1, CACHE2 C2 WHERE C1.JOINCol = C2.JOINCol AND > C1.COL1 = 'someValue' ORDER BY C1.COL2_ > The above query execution leads to the Ignite thread memory rising > extensively, eventually leading to heap OOME. When the heap memory was > increased to about 14GB, we were able to get the results back, but the > processing time of the query was too long, about 2-4 minutes ( with CPUs =2). > We ran an EXPLAIN for the above query and found out that INDEX was created on > COL1 for C1 cache and on JOINCol for C2 cache. There was no index on the > sorted column. We think the problem of 'slow querying and huge heap memory > requirement' is because of the absence of an index in the sorted column. > Whenever there is a condition present in the WHERE clause ( in our example > C1.COL1='someValue'), Ignite is using an INDEX for that column and there is > no INDEX being created on the ORDER BY column. > And for our use-case, it is imperative that we have a condition in the where > clause ( to filter out the data) and a join condition apart from the order by > clause. > We tried the multiple column indexing strategy on the COL1, COL2 as per our > use case. > In case of a composite index with the order as (COL1, COL2), INDEX was > created only for the COL1. > While for the composite index order as (COL2, COL1), INDEX was getting > created for both COL1 and COL2 and the results were index sorted. ( But only > in case of the absence of an INDEX for COL1, it looks for the ORDER BY clause > column and uses a composite index). But, if we don't have a separate INDEX > for COL1, it again poses a problem as COL1 is something which is heavily used > for filtering in all other queries. So an INDEX on COL1 is necessary. > To summarize, In case there is a condition present in the WHERE clause, > Ignite uses the WHERE clause column for indexing, and therefore there is no > INDEX in the sorting column, resulting in severe query performance, which can > eventually lead us to our system going down. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11488) GridServiceProcessorBatchDeploySelfTest test fails sporadically
[
https://issues.apache.org/jira/browse/IGNITE-11488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16817809#comment-16817809
]
Andrew Mashenkov commented on IGNITE-11488:
---
Hi [~rykerzhang],
ConcurrentModificationException can be resolved either with adding
synchronization to toString() method or exclude "singleDepsMsgs" and
"remaining" from print.
ServiceDeploymentTask.toString() is called to print a warning from catch block.
So, it looks like abnormal case and it is ok to add some latency here.
If you think it may affect performance when user deploy a lot of services, then
we can exclude Collections from being printed in a warning.
Also, it is ok to split warning message into 2: for normal and debug purposes.
And make warning message much simplere (with no collections and no sync) for
normal case, but use extended output (toString()) with sync and with full
ServiceDeploymentTask description for debug log level only.
> GridServiceProcessorBatchDeploySelfTest test fails sporadically
> ---
>
> Key: IGNITE-11488
> URL: https://issues.apache.org/jira/browse/IGNITE-11488
> Project: Ignite
> Issue Type: Test
> Components: managed services
>Reporter: Andrew Mashenkov
>Assignee: Ryker Zhang
>Priority: Major
> Labels: MakeTeamcityGreenAgain, newbie
>
> GridServiceProcessorBatchDeploySelfTest.testCancelAllTopologyChange test
> fails on TC sporadically with ConcurrentModificationException.
> Let's add synchronization to certain toString method.
>
> {noformat}
> [super=AbstractFailureHandler [ignoredFailureTypes=UnmodifiableSet
> [SYSTEM_WORKER_BLOCKED, SYSTEM_CRITICAL_OPERATION_TIMEOUT]]],
> failureCtx=FailureContext [type=SYSTEM_WORKER_TERMINATION, err=class
> o.a.i.IgniteException: null]]
> class org.apache.ignite.IgniteException: null
> at
> org.apache.ignite.internal.util.tostring.GridToStringBuilder.toStringImpl0(GridToStringBuilder.java:1081)
> at
> org.apache.ignite.internal.util.tostring.GridToStringBuilder.toStringImpl(GridToStringBuilder.java:993)
> at
> org.apache.ignite.internal.util.tostring.GridToStringBuilder.toString(GridToStringBuilder.java:703)
> at
> org.apache.ignite.internal.util.tostring.GridToStringBuilder.toString(GridToStringBuilder.java:662)
> at
> org.apache.ignite.internal.processors.service.ServiceDeploymentTask.toString(ServiceDeploymentTask.java:854)
> at java.lang.String.valueOf(String.java:2994)
> at java.lang.StringBuilder.append(StringBuilder.java:131)
> at
> org.apache.ignite.internal.processors.service.ServiceDeploymentManager$ServicesDeploymentWorker.body(ServiceDeploymentManager.java:502)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.util.ConcurrentModificationException
> at java.util.HashMap$HashIterator.nextNode(HashMap.java:1442)
> at java.util.HashMap$EntryIterator.next(HashMap.java:1476)
> at java.util.HashMap$EntryIterator.next(HashMap.java:1474)
> at
> org.apache.ignite.internal.util.tostring.GridToStringBuilder.addMap(GridToStringBuilder.java:923)
> at
> org.apache.ignite.internal.util.tostring.GridToStringBuilder.toString(GridToStringBuilder.java:846)
> at
> org.apache.ignite.internal.util.tostring.GridToStringBuilder.toStringImpl0(GridToStringBuilder.java:1065)
> ... 9 more{noformat}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11563) DELETE WHERE does not work in prepared statements
[
https://issues.apache.org/jira/browse/IGNITE-11563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16815220#comment-16815220
]
Andrew Mashenkov commented on IGNITE-11563:
---
[~pkouznet],
# Rounding\cast value to column scale-precision by default with an option to
disable this behavior looks acceptable. Let's make this like MsSql goes.
# It seems we can do nothing for cache API for now, but just point to decimal
limitations in Ignite documentation .
We could compare 2 decimals with rounding up to some common scale, but it is
impossible due to key are compares as byte[]. Even if we found a solution to
compare decimal fields without deserialization, comparing key binary objects
field-by-field will hit performance too much.
> DELETE WHERE does not work in prepared statements
> -
>
> Key: IGNITE-11563
> URL: https://issues.apache.org/jira/browse/IGNITE-11563
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.7
>Reporter: Stefan
>Assignee: Pavel Kuznetsov
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> With SQL I cannot delete a row using a prepared statement. The following
> statement is simply ignored:
> {{DELETE}} {{FROM}} {{AnyTable WHERE}} {{id = ?}}
> This happens with JDBC-Thin and with ODBC so I suspect that the cluster gets
> the correct data but handles it wrong. By adding an always-true-condition it
> works as expected:
> {{DELETE}} {{FROM}} {{AnyTable WHERE}} {{id = id AND}} {{id = ?}}
> I tested with a very simple table that was created with:
> {{CREATE TABLE testtable (}}
> {{ "ID" NUMBER(19,0),}}
> {{ "VALUE" VARCHAR2(255 CHAR),}}
> {{ PRIMARY KEY (ID)}}
> {{) WITH "template=replicated,cache_name=testtable"}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11411) Remove tearDown, setUp from JUnit3TestLegacySupport
[ https://issues.apache.org/jira/browse/IGNITE-11411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Mashenkov updated IGNITE-11411: -- Fix Version/s: 2.8 > Remove tearDown, setUp from JUnit3TestLegacySupport > --- > > Key: IGNITE-11411 > URL: https://issues.apache.org/jira/browse/IGNITE-11411 > Project: Ignite > Issue Type: Improvement >Reporter: Ivan Fedotov >Assignee: Ivan Fedotov >Priority: Major > Labels: iep-30 > Fix For: 2.8 > > Time Spent: 20m > Remaining Estimate: 0h > > TearDown and setUp methods are deprecated for JUnit 4+ version. It is > necessary to replace them with appropriate methods, marked by @Before and > @After annotations. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11460) MVCC: Possible race on coordinator changing on client reconnection.
[
https://issues.apache.org/jira/browse/IGNITE-11460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Mashenkov updated IGNITE-11460:
--
Component/s: mvcc
> MVCC: Possible race on coordinator changing on client reconnection.
> ---
>
> Key: IGNITE-11460
> URL: https://issues.apache.org/jira/browse/IGNITE-11460
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Reporter: Amelchev Nikita
>Assignee: Amelchev Nikita
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.8
>
> Attachments: stacktraces.log
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> I found that the wrong coordinator can be set in case of client reconnect:
> {noformat}
> assert newCrd.topologyVersion().compareTo(curCrd.topologyVersion()) > 0;
> java.lang.AssertionError
> at
> org.apache.ignite.internal.processors.cache.mvcc.MvccProcessorImpl.onCoordinatorChanged(MvccProcessorImpl.java:541)
> at
> org.apache.ignite.internal.processors.cache.mvcc.MvccProcessorImpl.onLocalJoin(MvccProcessorImpl.java:416)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery0(GridDiscoveryManager.java:851)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.lambda$onDiscovery$0(GridDiscoveryManager.java:601)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryMessageNotifierWorker.body0(GridDiscoveryManager.java:2681)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryMessageNotifierWorker.body(GridDiscoveryManager.java:2719)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> I have attached reproducer in PR.
> The main reason is that coordinator can be changed from discovery event
> thread when the client already disconnect (disconnection processed in
> notifier thread and change coordinator on onDisconnected method).
> Coordinator can be changed in cases:
> 1. notifier disco thread: onDisconnected method
> 2. event disco thread: onDiscovery listener.
> and events can be processed with some delay and override coordinator that set
> in notifier thread.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11489) merge IO message listener for GridTopic.TOPIC_QUERY into single listener
[ https://issues.apache.org/jira/browse/IGNITE-11489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16813134#comment-16813134 ] Andrew Mashenkov commented on IGNITE-11489: --- Fixed. Now, listeners are removed on "kernal stop" phase. TC look ok. > merge IO message listener for GridTopic.TOPIC_QUERY into single listener > > > Key: IGNITE-11489 > URL: https://issues.apache.org/jira/browse/IGNITE-11489 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Yury Gerzhedovich >Assignee: Andrew Mashenkov >Priority: Major > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > As of now we have few IO listeners for GridTopic.TOPIC_QUERY. It lead to > spread of logic and we can't check that no any not expected messages received. > Need to merge it to single listeners or have different topics. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11686) MVCC: Create separate test for vacuum checks.
Andrew Mashenkov created IGNITE-11686: - Summary: MVCC: Create separate test for vacuum checks. Key: IGNITE-11686 URL: https://issues.apache.org/jira/browse/IGNITE-11686 Project: Ignite Issue Type: Test Components: mvcc Reporter: Andrew Mashenkov Most of tests (inherited from CacheMvccAbstractTest) run vacuum synchronously on afterTest() method and check if vacuum is ok. This hits performance, can cause false negative results and vacuum issues can be hidden if afterTest method will overriden at once. For now we have CacheMvccVacuumTest that just check vacuum workers state, but there is no check if vacuum really cleans all old versions correctly. I'd expect to find it in this class. So, let's mode vacuum verification from afterTest method into CacheMvccVacuumTest as a new separate test. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-11489) merge IO message listener for GridTopic.TOPIC_QUERY into single listener
[ https://issues.apache.org/jira/browse/IGNITE-11489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Mashenkov reassigned IGNITE-11489: - Assignee: Andrew Mashenkov > merge IO message listener for GridTopic.TOPIC_QUERY into single listener > > > Key: IGNITE-11489 > URL: https://issues.apache.org/jira/browse/IGNITE-11489 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Yury Gerzhedovich >Assignee: Andrew Mashenkov >Priority: Major > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > As of now we have few IO listeners for GridTopic.TOPIC_QUERY. It lead to > spread of logic and we can't check that no any not expected messages received. > Need to merge it to single listeners or have different topics. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-11439) MVCC: Error in transaction mode validation.
[
https://issues.apache.org/jira/browse/IGNITE-11439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Mashenkov reassigned IGNITE-11439:
-
Assignee: Andrew Mashenkov
> MVCC: Error in transaction mode validation.
> ---
>
> Key: IGNITE-11439
> URL: https://issues.apache.org/jira/browse/IGNITE-11439
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Reporter: Roman Kondakov
>Assignee: Andrew Mashenkov
>Priority: Blocker
> Fix For: 2.8
>
> Attachments: Reproducer
>
>
> Currently MVCC transaction mode is validated within {{MvccUtils#tx()}}
> method. If this method is called during execution of {{OPTIMISTIC}}
> transaction over non-mvcc cache it can cause {{UnsupportedTxModeException}}
> in the case when at least one mvcc cache is also started in the cluster. This
> happens due to improper use of {{MvccUtils#mvccEnabled}} method which returns
> {{true}} if at least one mvcc cache is started. This is a global
> {{mvccEnabled}} flag, but not a per-cache one.
> A very common pattern of using the combination of these two methods is
> completely wrong:
> {code:java}
> if (MvccUtils.mvccEnabled(kernalCtx)) <- global check of enabled mvcc
> tx = MvccUtils#tx(kernalCtx) <- an attempt to get a transaction with
> wrong assumption of enabled mvcc. Exception is thrown here.
> {code}
> We need to revise mvcc transaction mode validation and using these methods in
> the project. All possible scenarios should be covered by tests.
> See reproducer in attachment. Error stacktrace is below:
> {noformat}
> class
> org.apache.ignite.internal.processors.cache.mvcc.MvccUtils$UnsupportedTxModeException:
> Only pessimistic transactions are supported when MVCC is enabled.
> at
> org.apache.ignite.internal.processors.cache.mvcc.MvccUtils.tx(MvccUtils.java:717)
> at
> org.apache.ignite.internal.processors.cache.mvcc.MvccUtils.tx(MvccUtils.java:696)
> at
> org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.query(GridReduceQueryExecutor.java:488)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing$3.iterator(IgniteH2Indexing.java:1102)
> at
> org.apache.ignite.internal.processors.cache.QueryCursorImpl.iter(QueryCursorImpl.java:102)
> at
> org.apache.ignite.internal.processors.cache.query.RegisteredQueryCursor.iter(RegisteredQueryCursor.java:64)
> at
> org.apache.ignite.internal.processors.cache.QueryCursorImpl.getAll(QueryCursorImpl.java:121)
> at
> org.apache.ignite.internal.processors.cache.mvcc.CacheMvccSqlTxModesTest.testConsequentMvccNonMvccOperations(CacheMvccSqlTxModesTest.java:64)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$7.run(GridAbstractTest.java:2049)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11673) SQL: It looks like security check is missed in h2 indexing.
[
https://issues.apache.org/jira/browse/IGNITE-11673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16808556#comment-16808556
]
Andrew Mashenkov commented on IGNITE-11673:
---
[~rkondakov],
"executeSelect0()" is called from executeSelect() and executeSelectFromDml()
methods.
Security check is present in first one, but missed in second one.
So, before your fix, Dml query execution looks not secured at all and after fix
security checks can be performed twice.
Also, I've found "executeDml()" and "executeCommand()" (see querySqlFields)
also has no security checks.
Do we need to create a separate ticket for this or I've missed smth?
> SQL: It looks like security check is missed in h2 indexing.
> ---
>
> Key: IGNITE-11673
> URL: https://issues.apache.org/jira/browse/IGNITE-11673
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Roman Kondakov
>Assignee: Roman Kondakov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Security check is no longer conducted in {{IgniteH2Indexing#executeSelect0}}
> after IGNITE-10104 having been merged.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11590) NPE during onKernalStop in mvcc processor
[
https://issues.apache.org/jira/browse/IGNITE-11590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16800661#comment-16800661
]
Andrew Mashenkov commented on IGNITE-11590:
---
Can't "resolve" ticket due to some Jira issues.
> NPE during onKernalStop in mvcc processor
> --
>
> Key: IGNITE-11590
> URL: https://issues.apache.org/jira/browse/IGNITE-11590
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Reporter: Anton Kalashnikov
>Assignee: Anton Kalashnikov
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> IgniteProjectionStartStopRestartSelfTest#testStopNodesByIds
> {noformat}
> java.lang.NullPointerException
> at
> java.util.concurrent.ConcurrentHashMap.replaceNode(ConcurrentHashMap.java:1106)
> at
> java.util.concurrent.ConcurrentHashMap.remove(ConcurrentHashMap.java:1097)
> at
> org.apache.ignite.internal.processors.cache.mvcc.MvccProcessorImpl.onCoordinatorFailed(MvccProcessorImpl.java:527)
> at
> org.apache.ignite.internal.processors.cache.mvcc.MvccProcessorImpl.onKernalStop(MvccProcessorImpl.java:459)
> at org.apache.ignite.internal.IgniteKernal.stop0(IgniteKernal.java:2335)
> at org.apache.ignite.internal.IgniteKernal.stop(IgniteKernal.java:2283)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop0(IgnitionEx.java:2570)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop(IgnitionEx.java:2533)
> at org.apache.ignite.internal.IgnitionEx.stop(IgnitionEx.java:330)
> at org.apache.ignite.internal.IgnitionEx.stop(IgnitionEx.java:297)
> at org.apache.ignite.Ignition.stop(Ignition.java:200)
> at
> org.apache.ignite.internal.IgniteProjectionStartStopRestartSelfTest.afterTest(IgniteProjectionStartStopRestartSelfTest.java:190)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.tearDown(GridAbstractTest.java:1804)
> at
> org.apache.ignite.testframework.junits.JUnit3TestLegacySupport.runTestCase(JUnit3TestLegacySupport.java:70)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$2.evaluate(GridAbstractTest.java:185)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.evaluateInsideFixture(GridAbstractTest.java:2579)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.access$500(GridAbstractTest.java:152)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$BeforeFirstAndAfterLastTestRule$1.evaluate(GridAbstractTest.java:2559)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:160)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
> at
> com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47)
> at
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
> at
> com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11590) NPE during onKernalStop in mvcc processor
[
https://issues.apache.org/jira/browse/IGNITE-11590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16800655#comment-16800655
]
Andrew Mashenkov commented on IGNITE-11590:
---
[~akalashnikov], look ok, merged to master.
> NPE during onKernalStop in mvcc processor
> --
>
> Key: IGNITE-11590
> URL: https://issues.apache.org/jira/browse/IGNITE-11590
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Reporter: Anton Kalashnikov
>Assignee: Anton Kalashnikov
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> IgniteProjectionStartStopRestartSelfTest#testStopNodesByIds
> {noformat}
> java.lang.NullPointerException
> at
> java.util.concurrent.ConcurrentHashMap.replaceNode(ConcurrentHashMap.java:1106)
> at
> java.util.concurrent.ConcurrentHashMap.remove(ConcurrentHashMap.java:1097)
> at
> org.apache.ignite.internal.processors.cache.mvcc.MvccProcessorImpl.onCoordinatorFailed(MvccProcessorImpl.java:527)
> at
> org.apache.ignite.internal.processors.cache.mvcc.MvccProcessorImpl.onKernalStop(MvccProcessorImpl.java:459)
> at org.apache.ignite.internal.IgniteKernal.stop0(IgniteKernal.java:2335)
> at org.apache.ignite.internal.IgniteKernal.stop(IgniteKernal.java:2283)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop0(IgnitionEx.java:2570)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop(IgnitionEx.java:2533)
> at org.apache.ignite.internal.IgnitionEx.stop(IgnitionEx.java:330)
> at org.apache.ignite.internal.IgnitionEx.stop(IgnitionEx.java:297)
> at org.apache.ignite.Ignition.stop(Ignition.java:200)
> at
> org.apache.ignite.internal.IgniteProjectionStartStopRestartSelfTest.afterTest(IgniteProjectionStartStopRestartSelfTest.java:190)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.tearDown(GridAbstractTest.java:1804)
> at
> org.apache.ignite.testframework.junits.JUnit3TestLegacySupport.runTestCase(JUnit3TestLegacySupport.java:70)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$2.evaluate(GridAbstractTest.java:185)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.evaluateInsideFixture(GridAbstractTest.java:2579)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.access$500(GridAbstractTest.java:152)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$BeforeFirstAndAfterLastTestRule$1.evaluate(GridAbstractTest.java:2559)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:160)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
> at
> com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47)
> at
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
> at
> com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11590) NPE during onKernalStop in mvcc processor
[
https://issues.apache.org/jira/browse/IGNITE-11590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Mashenkov updated IGNITE-11590:
--
Fix Version/s: 2.8
> NPE during onKernalStop in mvcc processor
> --
>
> Key: IGNITE-11590
> URL: https://issues.apache.org/jira/browse/IGNITE-11590
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Reporter: Anton Kalashnikov
>Assignee: Anton Kalashnikov
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> IgniteProjectionStartStopRestartSelfTest#testStopNodesByIds
> {noformat}
> java.lang.NullPointerException
> at
> java.util.concurrent.ConcurrentHashMap.replaceNode(ConcurrentHashMap.java:1106)
> at
> java.util.concurrent.ConcurrentHashMap.remove(ConcurrentHashMap.java:1097)
> at
> org.apache.ignite.internal.processors.cache.mvcc.MvccProcessorImpl.onCoordinatorFailed(MvccProcessorImpl.java:527)
> at
> org.apache.ignite.internal.processors.cache.mvcc.MvccProcessorImpl.onKernalStop(MvccProcessorImpl.java:459)
> at org.apache.ignite.internal.IgniteKernal.stop0(IgniteKernal.java:2335)
> at org.apache.ignite.internal.IgniteKernal.stop(IgniteKernal.java:2283)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop0(IgnitionEx.java:2570)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop(IgnitionEx.java:2533)
> at org.apache.ignite.internal.IgnitionEx.stop(IgnitionEx.java:330)
> at org.apache.ignite.internal.IgnitionEx.stop(IgnitionEx.java:297)
> at org.apache.ignite.Ignition.stop(Ignition.java:200)
> at
> org.apache.ignite.internal.IgniteProjectionStartStopRestartSelfTest.afterTest(IgniteProjectionStartStopRestartSelfTest.java:190)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.tearDown(GridAbstractTest.java:1804)
> at
> org.apache.ignite.testframework.junits.JUnit3TestLegacySupport.runTestCase(JUnit3TestLegacySupport.java:70)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$2.evaluate(GridAbstractTest.java:185)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.evaluateInsideFixture(GridAbstractTest.java:2579)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.access$500(GridAbstractTest.java:152)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$BeforeFirstAndAfterLastTestRule$1.evaluate(GridAbstractTest.java:2559)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:160)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
> at
> com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47)
> at
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
> at
> com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11590) NPE during onKernalStop in mvcc processor
[
https://issues.apache.org/jira/browse/IGNITE-11590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Mashenkov updated IGNITE-11590:
--
Component/s: mvcc
> NPE during onKernalStop in mvcc processor
> --
>
> Key: IGNITE-11590
> URL: https://issues.apache.org/jira/browse/IGNITE-11590
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Reporter: Anton Kalashnikov
>Assignee: Anton Kalashnikov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> IgniteProjectionStartStopRestartSelfTest#testStopNodesByIds
> {noformat}
> java.lang.NullPointerException
> at
> java.util.concurrent.ConcurrentHashMap.replaceNode(ConcurrentHashMap.java:1106)
> at
> java.util.concurrent.ConcurrentHashMap.remove(ConcurrentHashMap.java:1097)
> at
> org.apache.ignite.internal.processors.cache.mvcc.MvccProcessorImpl.onCoordinatorFailed(MvccProcessorImpl.java:527)
> at
> org.apache.ignite.internal.processors.cache.mvcc.MvccProcessorImpl.onKernalStop(MvccProcessorImpl.java:459)
> at org.apache.ignite.internal.IgniteKernal.stop0(IgniteKernal.java:2335)
> at org.apache.ignite.internal.IgniteKernal.stop(IgniteKernal.java:2283)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop0(IgnitionEx.java:2570)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop(IgnitionEx.java:2533)
> at org.apache.ignite.internal.IgnitionEx.stop(IgnitionEx.java:330)
> at org.apache.ignite.internal.IgnitionEx.stop(IgnitionEx.java:297)
> at org.apache.ignite.Ignition.stop(Ignition.java:200)
> at
> org.apache.ignite.internal.IgniteProjectionStartStopRestartSelfTest.afterTest(IgniteProjectionStartStopRestartSelfTest.java:190)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.tearDown(GridAbstractTest.java:1804)
> at
> org.apache.ignite.testframework.junits.JUnit3TestLegacySupport.runTestCase(JUnit3TestLegacySupport.java:70)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$2.evaluate(GridAbstractTest.java:185)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.evaluateInsideFixture(GridAbstractTest.java:2579)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.access$500(GridAbstractTest.java:152)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$BeforeFirstAndAfterLastTestRule$1.evaluate(GridAbstractTest.java:2559)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:160)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
> at
> com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47)
> at
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
> at
> com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11590) NPE during onKernalStop in mvcc processor
[
https://issues.apache.org/jira/browse/IGNITE-11590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Mashenkov updated IGNITE-11590:
--
Ignite Flags: (was: Docs Required)
> NPE during onKernalStop in mvcc processor
> --
>
> Key: IGNITE-11590
> URL: https://issues.apache.org/jira/browse/IGNITE-11590
> Project: Ignite
> Issue Type: Bug
>Reporter: Anton Kalashnikov
>Assignee: Anton Kalashnikov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> IgniteProjectionStartStopRestartSelfTest#testStopNodesByIds
> {noformat}
> java.lang.NullPointerException
> at
> java.util.concurrent.ConcurrentHashMap.replaceNode(ConcurrentHashMap.java:1106)
> at
> java.util.concurrent.ConcurrentHashMap.remove(ConcurrentHashMap.java:1097)
> at
> org.apache.ignite.internal.processors.cache.mvcc.MvccProcessorImpl.onCoordinatorFailed(MvccProcessorImpl.java:527)
> at
> org.apache.ignite.internal.processors.cache.mvcc.MvccProcessorImpl.onKernalStop(MvccProcessorImpl.java:459)
> at org.apache.ignite.internal.IgniteKernal.stop0(IgniteKernal.java:2335)
> at org.apache.ignite.internal.IgniteKernal.stop(IgniteKernal.java:2283)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop0(IgnitionEx.java:2570)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop(IgnitionEx.java:2533)
> at org.apache.ignite.internal.IgnitionEx.stop(IgnitionEx.java:330)
> at org.apache.ignite.internal.IgnitionEx.stop(IgnitionEx.java:297)
> at org.apache.ignite.Ignition.stop(Ignition.java:200)
> at
> org.apache.ignite.internal.IgniteProjectionStartStopRestartSelfTest.afterTest(IgniteProjectionStartStopRestartSelfTest.java:190)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.tearDown(GridAbstractTest.java:1804)
> at
> org.apache.ignite.testframework.junits.JUnit3TestLegacySupport.runTestCase(JUnit3TestLegacySupport.java:70)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$2.evaluate(GridAbstractTest.java:185)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.evaluateInsideFixture(GridAbstractTest.java:2579)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.access$500(GridAbstractTest.java:152)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$BeforeFirstAndAfterLastTestRule$1.evaluate(GridAbstractTest.java:2559)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:160)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
> at
> com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47)
> at
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
> at
> com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11590) NPE during onKernalStop in mvcc processor
[
https://issues.apache.org/jira/browse/IGNITE-11590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16798036#comment-16798036
]
Andrew Mashenkov commented on IGNITE-11590:
---
There is no need to call onCoordinatorFailed in case of Disconnected or
Unassigned coordinator.
Both of them have 'null' nodeId field.
> NPE during onKernalStop in mvcc processor
> --
>
> Key: IGNITE-11590
> URL: https://issues.apache.org/jira/browse/IGNITE-11590
> Project: Ignite
> Issue Type: Bug
>Reporter: Anton Kalashnikov
>Assignee: Anton Kalashnikov
>Priority: Major
>
> IgniteProjectionStartStopRestartSelfTest#testStopNodesByIds
> {noformat}
> java.lang.NullPointerException
> at
> java.util.concurrent.ConcurrentHashMap.replaceNode(ConcurrentHashMap.java:1106)
> at
> java.util.concurrent.ConcurrentHashMap.remove(ConcurrentHashMap.java:1097)
> at
> org.apache.ignite.internal.processors.cache.mvcc.MvccProcessorImpl.onCoordinatorFailed(MvccProcessorImpl.java:527)
> at
> org.apache.ignite.internal.processors.cache.mvcc.MvccProcessorImpl.onKernalStop(MvccProcessorImpl.java:459)
> at org.apache.ignite.internal.IgniteKernal.stop0(IgniteKernal.java:2335)
> at org.apache.ignite.internal.IgniteKernal.stop(IgniteKernal.java:2283)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop0(IgnitionEx.java:2570)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop(IgnitionEx.java:2533)
> at org.apache.ignite.internal.IgnitionEx.stop(IgnitionEx.java:330)
> at org.apache.ignite.internal.IgnitionEx.stop(IgnitionEx.java:297)
> at org.apache.ignite.Ignition.stop(Ignition.java:200)
> at
> org.apache.ignite.internal.IgniteProjectionStartStopRestartSelfTest.afterTest(IgniteProjectionStartStopRestartSelfTest.java:190)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.tearDown(GridAbstractTest.java:1804)
> at
> org.apache.ignite.testframework.junits.JUnit3TestLegacySupport.runTestCase(JUnit3TestLegacySupport.java:70)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$2.evaluate(GridAbstractTest.java:185)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.evaluateInsideFixture(GridAbstractTest.java:2579)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.access$500(GridAbstractTest.java:152)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$BeforeFirstAndAfterLastTestRule$1.evaluate(GridAbstractTest.java:2559)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:160)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
> at
> com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47)
> at
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
> at
> com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-11587) MVCC: Remote tx determine its type in wrong way.
[ https://issues.apache.org/jira/browse/IGNITE-11587?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Mashenkov reassigned IGNITE-11587: - Assignee: Andrew Mashenkov > MVCC: Remote tx determine its type in wrong way. > - > > Key: IGNITE-11587 > URL: https://issues.apache.org/jira/browse/IGNITE-11587 > Project: Ignite > Issue Type: Bug > Components: mvcc >Reporter: Andrew Mashenkov >Assignee: Andrew Mashenkov >Priority: Major > Fix For: 2.8 > > > Remote tx adapters implements IgniteTxState.mvccEnabled in wrong way. > mvccEnabled() checks if writeMap contains a mvcc-entry, but writeMap is > always empty for mvcc. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11587) MVCC: Remote tx determine its type in wrong way.
[ https://issues.apache.org/jira/browse/IGNITE-11587?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Mashenkov updated IGNITE-11587: -- Ignite Flags: (was: Docs Required) > MVCC: Remote tx determine its type in wrong way. > - > > Key: IGNITE-11587 > URL: https://issues.apache.org/jira/browse/IGNITE-11587 > Project: Ignite > Issue Type: Bug > Components: mvcc >Reporter: Andrew Mashenkov >Priority: Major > Fix For: 2.8 > > > Remote tx adapters implements IgniteTxState.mvccEnabled in wrong way. > mvccEnabled() checks if writeMap contains a mvcc-entry, but writeMap is > always empty for mvcc. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11587) MVCC: Remote tx determine its type in wrong way.
Andrew Mashenkov created IGNITE-11587: - Summary: MVCC: Remote tx determine its type in wrong way. Key: IGNITE-11587 URL: https://issues.apache.org/jira/browse/IGNITE-11587 Project: Ignite Issue Type: Bug Components: mvcc Reporter: Andrew Mashenkov Fix For: 2.8 Remote tx adapters implements IgniteTxState.mvccEnabled in wrong way. mvccEnabled() checks if writeMap contains a mvcc-entry, but writeMap is always empty for mvcc. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10550) MVCC: rework IgniteWalFlush* tests for mvcc.
[ https://issues.apache.org/jira/browse/IGNITE-10550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Mashenkov updated IGNITE-10550: -- Component/s: cache > MVCC: rework IgniteWalFlush* tests for mvcc. > > > Key: IGNITE-10550 > URL: https://issues.apache.org/jira/browse/IGNITE-10550 > Project: Ignite > Issue Type: Bug > Components: cache, mvcc >Reporter: Andrew Mashenkov >Assignee: Andrew Mashenkov >Priority: Major > Labels: WAL > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > Next tests failed in mvcc mode, most likely due to different MVCC tx semantic: > * IgniteWalFlushBackgroundSelfTest > * IgniteWalFlushBackgroundWithMmapBufferSelfTest > * IgniteWalFlushFsyncSelfTest > * IgniteWalFlushFsyncWithDedicatedWorkerSelfTest > * IgniteWalFlushFsyncWithMmapBufferSelfTest > * IgniteWalFlushLogOnlySelfTest > * IgniteWalFlushLogOnlyWithMmapBufferSelfTest > We have to create similar tests for mvcc mode. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-10550) MVCC: rework IgniteWalFlush* tests for mvcc.
[ https://issues.apache.org/jira/browse/IGNITE-10550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16797309#comment-16797309 ] Andrew Mashenkov edited comment on IGNITE-10550 at 3/20/19 4:20 PM: The reason is DhtTxPrepareFuture.onComplete() method fails with exception right before mark the future as completed. Catch exception thrown from tx.state() and tx invalidation resolve the issue. Seems, it is partial fix and we have to add IgniteCheckedException in tx.state() method signature and correctly catch exception in all the places. was (Author: amashenkov): The reason is DhtTxPrepareFuture.onComplete() method fails with exception right before mark the future as completed. Catch exception thrown from tx.state() and tx invalidation resolve the issue. > MVCC: rework IgniteWalFlush* tests for mvcc. > > > Key: IGNITE-10550 > URL: https://issues.apache.org/jira/browse/IGNITE-10550 > Project: Ignite > Issue Type: Bug > Components: mvcc >Reporter: Andrew Mashenkov >Assignee: Andrew Mashenkov >Priority: Major > Labels: WAL > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > Next tests failed in mvcc mode, most likely due to different MVCC tx semantic: > * IgniteWalFlushBackgroundSelfTest > * IgniteWalFlushBackgroundWithMmapBufferSelfTest > * IgniteWalFlushFsyncSelfTest > * IgniteWalFlushFsyncWithDedicatedWorkerSelfTest > * IgniteWalFlushFsyncWithMmapBufferSelfTest > * IgniteWalFlushLogOnlySelfTest > * IgniteWalFlushLogOnlyWithMmapBufferSelfTest > We have to create similar tests for mvcc mode. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10550) MVCC: rework IgniteWalFlush* tests for mvcc.
[ https://issues.apache.org/jira/browse/IGNITE-10550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16797309#comment-16797309 ] Andrew Mashenkov commented on IGNITE-10550: --- The reason is DhtTxPrepareFuture.onComplete() method fails with exception right before mark the future as completed. Catch exception thrown from tx.state() and tx invalidation resolve the issue. > MVCC: rework IgniteWalFlush* tests for mvcc. > > > Key: IGNITE-10550 > URL: https://issues.apache.org/jira/browse/IGNITE-10550 > Project: Ignite > Issue Type: Bug > Components: mvcc >Reporter: Andrew Mashenkov >Assignee: Andrew Mashenkov >Priority: Major > Labels: WAL > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > Next tests failed in mvcc mode, most likely due to different MVCC tx semantic: > * IgniteWalFlushBackgroundSelfTest > * IgniteWalFlushBackgroundWithMmapBufferSelfTest > * IgniteWalFlushFsyncSelfTest > * IgniteWalFlushFsyncWithDedicatedWorkerSelfTest > * IgniteWalFlushFsyncWithMmapBufferSelfTest > * IgniteWalFlushLogOnlySelfTest > * IgniteWalFlushLogOnlyWithMmapBufferSelfTest > We have to create similar tests for mvcc mode. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (IGNITE-10583) MVCC: Assertion on txLog state update when recovering from WAL.
[
https://issues.apache.org/jira/browse/IGNITE-10583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Mashenkov closed IGNITE-10583.
-
> MVCC: Assertion on txLog state update when recovering from WAL.
> ---
>
> Key: IGNITE-10583
> URL: https://issues.apache.org/jira/browse/IGNITE-10583
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Reporter: Roman Kondakov
>Assignee: Andrew Mashenkov
>Priority: Major
> Labels: WAL, mvcc_stability
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Assertion in txLog state update occurs sporadically during recovery from WAL.
> Reproducer:
> {{IgnitePdsContinuousRestartTest#testRebalancingDuringLoad_10_10_1_1}} with
> enabled MVCC.
> Stacktrace:
> {noformat}
> class
> org.apache.ignite.internal.processors.cache.persistence.tree.CorruptedTreeException:
> Runtime failure on search row: TxKey [major=1544121790766, minor=10468]
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.invoke(BPlusTree.java:1812)
> at
> org.apache.ignite.internal.processors.cache.mvcc.txlog.TxLog.put(TxLog.java:245)
> at
> org.apache.ignite.internal.processors.cache.mvcc.MvccProcessorImpl.updateState(MvccProcessorImpl.java:609)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.applyLogicalUpdates(GridCacheDatabaseSharedManager.java:2456)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.startMemoryRestore(GridCacheDatabaseSharedManager.java:1934)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1050)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2040)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1732)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1158)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:656)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:961)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:902)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:890)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:856)
> at
> org.apache.ignite.internal.processors.cache.persistence.IgnitePdsContinuousRestartTest.checkRebalancingDuringLoad(IgnitePdsContinuousRestartTest.java:302)
> at
> org.apache.ignite.internal.processors.cache.persistence.IgnitePdsContinuousRestartTest.testRebalancingDuringLoad_10_10_1_1(IgnitePdsContinuousRestartTest.java:221)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.access$001(GridAbstractTest.java:149)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$6.evaluate(GridAbstractTest.java:2106)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$7.run(GridAbstractTest.java:2123)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.IllegalStateException: Unexpected new transaction state.
> [currState=2, newState=3, cntr=10468]
> at
> org.apache.ignite.internal.processors.cache.mvcc.txlog.TxLog$TxLogUpdateClosure.invalid(TxLog.java:581)
> at
> org.apache.ignite.internal.processors.cache.mvcc.txlog.TxLog$TxLogUpdateClosure.checkAborted(TxLog.java:562)
> at
> org.apache.ignite.internal.processors.cache.mvcc.txlog.TxLog$TxLogUpdateClosure.call(TxLog.java:451)
> at
> org.apache.ignite.internal.processors.cache.mvcc.txlog.TxLog$TxLogUpdateClosure.call(TxLog.java:393)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Invoke.invokeClosure(BPlusTree.java:3755)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Invoke.access$5900(BPlusTree.java:3649)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.invokeDown(BPlusTree.java:1901)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.invoke(BPlusTree.java:1779)
> ... 24 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10583) MVCC: Assertion on txLog state update when recovering from WAL.
[
https://issues.apache.org/jira/browse/IGNITE-10583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Mashenkov updated IGNITE-10583:
--
Fix Version/s: (was: 2.8)
> MVCC: Assertion on txLog state update when recovering from WAL.
> ---
>
> Key: IGNITE-10583
> URL: https://issues.apache.org/jira/browse/IGNITE-10583
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Reporter: Roman Kondakov
>Assignee: Andrew Mashenkov
>Priority: Major
> Labels: WAL, mvcc_stability
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Assertion in txLog state update occurs sporadically during recovery from WAL.
> Reproducer:
> {{IgnitePdsContinuousRestartTest#testRebalancingDuringLoad_10_10_1_1}} with
> enabled MVCC.
> Stacktrace:
> {noformat}
> class
> org.apache.ignite.internal.processors.cache.persistence.tree.CorruptedTreeException:
> Runtime failure on search row: TxKey [major=1544121790766, minor=10468]
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.invoke(BPlusTree.java:1812)
> at
> org.apache.ignite.internal.processors.cache.mvcc.txlog.TxLog.put(TxLog.java:245)
> at
> org.apache.ignite.internal.processors.cache.mvcc.MvccProcessorImpl.updateState(MvccProcessorImpl.java:609)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.applyLogicalUpdates(GridCacheDatabaseSharedManager.java:2456)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.startMemoryRestore(GridCacheDatabaseSharedManager.java:1934)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1050)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2040)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1732)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1158)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:656)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:961)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:902)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:890)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:856)
> at
> org.apache.ignite.internal.processors.cache.persistence.IgnitePdsContinuousRestartTest.checkRebalancingDuringLoad(IgnitePdsContinuousRestartTest.java:302)
> at
> org.apache.ignite.internal.processors.cache.persistence.IgnitePdsContinuousRestartTest.testRebalancingDuringLoad_10_10_1_1(IgnitePdsContinuousRestartTest.java:221)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.access$001(GridAbstractTest.java:149)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$6.evaluate(GridAbstractTest.java:2106)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$7.run(GridAbstractTest.java:2123)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.IllegalStateException: Unexpected new transaction state.
> [currState=2, newState=3, cntr=10468]
> at
> org.apache.ignite.internal.processors.cache.mvcc.txlog.TxLog$TxLogUpdateClosure.invalid(TxLog.java:581)
> at
> org.apache.ignite.internal.processors.cache.mvcc.txlog.TxLog$TxLogUpdateClosure.checkAborted(TxLog.java:562)
> at
> org.apache.ignite.internal.processors.cache.mvcc.txlog.TxLog$TxLogUpdateClosure.call(TxLog.java:451)
> at
> org.apache.ignite.internal.processors.cache.mvcc.txlog.TxLog$TxLogUpdateClosure.call(TxLog.java:393)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Invoke.invokeClosure(BPlusTree.java:3755)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Invoke.access$5900(BPlusTree.java:3649)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.invokeDown(BPlusTree.java:1901)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.invoke(BPlusTree.java:1779)
> ... 24 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11548) MVCC: MVCC PDS 2 suite became unstable after the get operation mapping fix
[
https://issues.apache.org/jira/browse/IGNITE-11548?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16797019#comment-16797019
]
Andrew Mashenkov commented on IGNITE-11548:
---
[~rkondakov], merged to master.
Thanks for contribution!
> MVCC: MVCC PDS 2 suite became unstable after the get operation mapping fix
> --
>
> Key: IGNITE-11548
> URL: https://issues.apache.org/jira/browse/IGNITE-11548
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Reporter: Roman Kondakov
>Assignee: Roman Kondakov
>Priority: Critical
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> It looks like {{MVCC PDS 2}} suite became unstable after IGNITE-10261 is
> merged to master. It should be investigated.
> TC run:
> [https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_MvccPds2_IgniteTests24Java8=%3Cdefault%3E=buildTypeStatusDiv]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10695) MVCC: Fix cache API conditional update operations.
[ https://issues.apache.org/jira/browse/IGNITE-10695?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Mashenkov updated IGNITE-10695: -- Issue Type: Improvement (was: Bug) > MVCC: Fix cache API conditional update operations. > -- > > Key: IGNITE-10695 > URL: https://issues.apache.org/jira/browse/IGNITE-10695 > Project: Ignite > Issue Type: Improvement > Components: mvcc >Affects Versions: 2.7 >Reporter: Andrew Mashenkov >Priority: Major > > Operation like putIfAbsent and replace now tries to transfer Predicate > instance (filter) to remote node. > # Predicates are transferred to remote node with each update. > # Predicate should be transferred only for "replace" operation if certain > entry provided, otherwise we should send a correct operation code and use > corresponding static filter on remote side. > # This change will break protocol compatibility. Should we bother about it? > Let's fix protocol and add tests. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10695) MVCC: Fix cache API conditional update operations.
[ https://issues.apache.org/jira/browse/IGNITE-10695?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Mashenkov updated IGNITE-10695: -- Priority: Minor (was: Major) > MVCC: Fix cache API conditional update operations. > -- > > Key: IGNITE-10695 > URL: https://issues.apache.org/jira/browse/IGNITE-10695 > Project: Ignite > Issue Type: Improvement > Components: mvcc >Affects Versions: 2.7 >Reporter: Andrew Mashenkov >Priority: Minor > > Operation like putIfAbsent and replace now tries to transfer Predicate > instance (filter) to remote node. > # Predicates are transferred to remote node with each update. > # Predicate should be transferred only for "replace" operation if certain > entry provided, otherwise we should send a correct operation code and use > corresponding static filter on remote side. > # This change will break protocol compatibility. Should we bother about it? > Let's fix protocol and add tests. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11548) MVCC: MVCC PDS 2 suite became unstable after the get operation mapping fix
[
https://issues.apache.org/jira/browse/IGNITE-11548?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16795885#comment-16795885
]
Andrew Mashenkov commented on IGNITE-11548:
---
[~rkondakov],
Looks like Mvcc Processor do not disable MvccMessageListener and this fix is
just reduce 'window' size.
Using busy lock in listener and block busy lock right before MvccProcessor
cleanup.
> MVCC: MVCC PDS 2 suite became unstable after the get operation mapping fix
> --
>
> Key: IGNITE-11548
> URL: https://issues.apache.org/jira/browse/IGNITE-11548
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Reporter: Roman Kondakov
>Assignee: Roman Kondakov
>Priority: Critical
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> It looks like {{MVCC PDS 2}} suite became unstable after IGNITE-10261 is
> merged to master. It should be investigated.
> TC run:
> [https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_MvccPds2_IgniteTests24Java8=%3Cdefault%3E=buildTypeStatusDiv]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11382) Stop managers from all caches before caches stop
[ https://issues.apache.org/jira/browse/IGNITE-11382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Mashenkov updated IGNITE-11382: -- Ignite Flags: (was: Docs Required) > Stop managers from all caches before caches stop > > > Key: IGNITE-11382 > URL: https://issues.apache.org/jira/browse/IGNITE-11382 > Project: Ignite > Issue Type: Improvement >Reporter: Anton Kalashnikov >Assignee: Anton Kalashnikov >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > It is required to stop all cache managers before stopping this caches -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7718) Collections.singleton() and Collections.singletonMap() are not properly serialized by binary marshaller
[ https://issues.apache.org/jira/browse/IGNITE-7718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16795199#comment-16795199 ] Andrew Mashenkov commented on IGNITE-7718: -- [~pvinokurov], Please, resolve conflicts against latest master and re-run TC to get Bot's visa. > Collections.singleton() and Collections.singletonMap() are not properly > serialized by binary marshaller > --- > > Key: IGNITE-7718 > URL: https://issues.apache.org/jira/browse/IGNITE-7718 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.3 >Reporter: Pavel Vinokurov >Assignee: Pavel Vinokurov >Priority: Major > > After desialization collections obtained by Collections.singleton() and > Collections.singletonMap() does not return collection of binary objects, but > rather collection of deserialized objects. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11559) MVCC: Tx hangs on finish if StorageException occurs.
[ https://issues.apache.org/jira/browse/IGNITE-11559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Mashenkov updated IGNITE-11559: -- Labels: WAL mvcc_stability transactions (was: hangs mvcc_stability transactions) > MVCC: Tx hangs on finish if StorageException occurs. > > > Key: IGNITE-11559 > URL: https://issues.apache.org/jira/browse/IGNITE-11559 > Project: Ignite > Issue Type: Bug > Components: mvcc, persistence >Reporter: Andrew Mashenkov >Priority: Major > Labels: WAL, mvcc_stability, transactions > > By default non-mvcc transactions don't log their states in WAL log, so tx > rollbacks without hanging as there is nothing to save to WAL or PageMemory. > So, it may be helpful to check case for non-mvcc tx with txState WAL-logging > enabled at first. > When StorageException occurs during any mvcc tx operation enabled, then > storage locks become blocked. Then Ignite try to rollback Tx due to the error > and try to save txState into WAL and TxLog and hangs forever. A thread hangs > awaiting uninterruptibly for next WAL segment or lock released. > Failure handler tries to stop a node and hangs as well. > Looks like we shouldn't wait if kernal context become invalid. > Good startpoint is IgniteWalFlush* tests. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11559) MVCC: Tx hangs on finish if StorageException occurs.
Andrew Mashenkov created IGNITE-11559: - Summary: MVCC: Tx hangs on finish if StorageException occurs. Key: IGNITE-11559 URL: https://issues.apache.org/jira/browse/IGNITE-11559 Project: Ignite Issue Type: Bug Components: mvcc, persistence Reporter: Andrew Mashenkov By default non-mvcc transactions don't log their states in WAL log, so tx rollbacks without hanging as there is nothing to save to WAL or PageMemory. So, it may be helpful to check case for non-mvcc tx with txState WAL-logging enabled at first. When StorageException occurs during any mvcc tx operation enabled, then storage locks become blocked. Then Ignite try to rollback Tx due to the error and try to save txState into WAL and TxLog and hangs forever. A thread hangs awaiting uninterruptibly for next WAL segment or lock released. Failure handler tries to stop a node and hangs as well. Looks like we shouldn't wait if kernal context become invalid. Good startpoint is IgniteWalFlush* tests. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11542) Fix flacky test testGivenCacheWithPojoValueAndPds_WhenPut_ThenNoHangup.
[ https://issues.apache.org/jira/browse/IGNITE-11542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16794876#comment-16794876 ] Andrew Mashenkov commented on IGNITE-11542: --- TC test looks ok. https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=2893288071124380881=testDetails_IgniteTests24Java8=pull%2F6270%2Fhead > Fix flacky test testGivenCacheWithPojoValueAndPds_WhenPut_ThenNoHangup. > --- > > Key: IGNITE-11542 > URL: https://issues.apache.org/jira/browse/IGNITE-11542 > Project: Ignite > Issue Type: Test >Reporter: Andrew Mashenkov >Assignee: Andrew Mashenkov >Priority: Major > Labels: MakeTeamcityGreenAgain > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > IgnitePdsBinarySortObjectFieldsTest.testGivenCacheWithPojoValueAndPds_WhenPut_ThenNoHangup > fails sporadically on TC due to 5 sec timeout may be not enough for grid > startup. > Test checks "put" operation will complete in 5 sec timeout, > but grid initialization is included in this timeout with no reason. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10550) MVCC: rework IgniteWalFlush* tests for mvcc.
[ https://issues.apache.org/jira/browse/IGNITE-10550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16793743#comment-16793743 ] Andrew Mashenkov commented on IGNITE-10550: --- Tests passes locally, but fails on TC due to another reason: tx finish may hangs after StorageException occurs. Most likely, non-mvcc tests passes as non-mvcc transactions never persists their states in TxLog or WAL. > MVCC: rework IgniteWalFlush* tests for mvcc. > > > Key: IGNITE-10550 > URL: https://issues.apache.org/jira/browse/IGNITE-10550 > Project: Ignite > Issue Type: Bug > Components: mvcc >Reporter: Andrew Mashenkov >Assignee: Andrew Mashenkov >Priority: Major > Labels: WAL > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > Next tests failed in mvcc mode, most likely due to different MVCC tx semantic: > * IgniteWalFlushBackgroundSelfTest > * IgniteWalFlushBackgroundWithMmapBufferSelfTest > * IgniteWalFlushFsyncSelfTest > * IgniteWalFlushFsyncWithDedicatedWorkerSelfTest > * IgniteWalFlushFsyncWithMmapBufferSelfTest > * IgniteWalFlushLogOnlySelfTest > * IgniteWalFlushLogOnlyWithMmapBufferSelfTest > We have to create similar tests for mvcc mode. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-10550) MVCC: rework IgniteWalFlush* tests for mvcc.
[ https://issues.apache.org/jira/browse/IGNITE-10550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Mashenkov reassigned IGNITE-10550: - Assignee: Andrew Mashenkov > MVCC: rework IgniteWalFlush* tests for mvcc. > > > Key: IGNITE-10550 > URL: https://issues.apache.org/jira/browse/IGNITE-10550 > Project: Ignite > Issue Type: Bug > Components: mvcc >Reporter: Andrew Mashenkov >Assignee: Andrew Mashenkov >Priority: Major > Labels: WAL > Fix For: 2.8 > > > Next tests failed in mvcc mode, most likely due to different MVCC tx semantic: > * IgniteWalFlushBackgroundSelfTest > * IgniteWalFlushBackgroundWithMmapBufferSelfTest > * IgniteWalFlushFsyncSelfTest > * IgniteWalFlushFsyncWithDedicatedWorkerSelfTest > * IgniteWalFlushFsyncWithMmapBufferSelfTest > * IgniteWalFlushLogOnlySelfTest > * IgniteWalFlushLogOnlyWithMmapBufferSelfTest > We have to create similar tests for mvcc mode. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10550) MVCC: rework IgniteWalFlush* tests for mvcc.
[ https://issues.apache.org/jira/browse/IGNITE-10550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16793643#comment-16793643 ] Andrew Mashenkov commented on IGNITE-10550: --- Looks like remote tx type (mvcc\non-mvcc) is determined in wrong way. IgniteTxRemoteStateAdapter.mvccEnabled() always returns false as writeMap is always false for mvcc transactions. > MVCC: rework IgniteWalFlush* tests for mvcc. > > > Key: IGNITE-10550 > URL: https://issues.apache.org/jira/browse/IGNITE-10550 > Project: Ignite > Issue Type: Bug > Components: mvcc >Reporter: Andrew Mashenkov >Priority: Major > Labels: WAL > Fix For: 2.8 > > > Next tests failed in mvcc mode, most likely due to different MVCC tx semantic: > * IgniteWalFlushBackgroundSelfTest > * IgniteWalFlushBackgroundWithMmapBufferSelfTest > * IgniteWalFlushFsyncSelfTest > * IgniteWalFlushFsyncWithDedicatedWorkerSelfTest > * IgniteWalFlushFsyncWithMmapBufferSelfTest > * IgniteWalFlushLogOnlySelfTest > * IgniteWalFlushLogOnlyWithMmapBufferSelfTest > We have to create similar tests for mvcc mode. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-11088) Flacky LocalWalModeChangeDuringRebalancingSelfTest.testWithExchangesMerge
[
https://issues.apache.org/jira/browse/IGNITE-11088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Mashenkov resolved IGNITE-11088.
---
Resolution: Duplicate
Looks like issue has been fixed already.
> Flacky LocalWalModeChangeDuringRebalancingSelfTest.testWithExchangesMerge
> -
>
> Key: IGNITE-11088
> URL: https://issues.apache.org/jira/browse/IGNITE-11088
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Reporter: Andrew Mashenkov
>Priority: Major
> Labels: MakeTeamcityGreenAgain
>
> [LocalWalModeChangeDuringRebalancingSelfTest.testWithExchangesMerge|https://ci.ignite.apache.org/viewLog.html?buildId=2895774=buildResultsDiv=IgniteTests24Java8_MvccPds2#testNameId-6585115376754732686]
> fails sporadicatlly in MvccPds 2 suite.
> I've found no failures in non-mvcc Pds 2 suite, so, probably it is mvcc issue.
> See stacktraces from 2 failures that may have same reason. We have to
> investigate this.
> {noformat}
> java.lang.AssertionError: nodeIdx=2, key=6606 expected:<13212> but was:
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:743)
> at org.junit.Assert.assertEquals(Assert.java:118)
> at
> org.apache.ignite.internal.processors.cache.persistence.LocalWalModeChangeDuringRebalancingSelfTest.testWithExchangesMerge(LocalWalModeChangeDuringRebalancingSelfTest.java:473)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$6.run(GridAbstractTest.java:2088)
> at java.lang.Thread.run(Thread.java:748) {noformat}
> {noformat}
> [2019-01-23
> 11:26:25,287][ERROR][sys-stripe-5-#6186%persistence.LocalWalModeChangeDuringRebalancingSelfTest3%][GridDhtColocatedCache]
> Failed processing get request: GridNearSingleGetRequest
> [futId=1548243502606, key=KeyCacheObjectImpl [part=381, val=7037,
> hasValBytes=true], flags=1, topVer=AffinityTopologyVersion [topVer=8,
> minorTopVer=1], subjId=f1fbb371-3232-4bfa-a20a-d4cad4b2, taskNameHash=0,
> createTtl=-1, accessTtl=-1, txLbl=null, mvccSnapshot=MvccSnapshotResponse
> [futId=7040, crdVer=1548242747966, cntr=20023, opCntr=1073741823, txs=null,
> cleanupVer=0, tracking=0]] class org.apache.ignite.IgniteCheckedException:
> Runtime failure on bounds: [lower=MvccSnapshotSearchRow [res=null,
> snapshot=MvccSnapshotResponse [futId=7040, crdVer=1548242747966, cntr=20023,
> opCntr=1073741823, txs=null, cleanupVer=0, tracking=0]],
> upper=MvccMinSearchRow []] at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.iterate(BPlusTree.java:1043)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.mvccFind(IgniteCacheOffheapManagerImpl.java:2683)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.mvccFind(GridCacheOffheapManager.java:2141)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.mvccRead(IgniteCacheOffheapManagerImpl.java:666)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.getAllAsync0(GridCacheAdapter.java:2023)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheAdapter.getDhtAllAsync(GridDhtCacheAdapter.java:807)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtGetSingleFuture.getAsync(GridDhtGetSingleFuture.java:399)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtGetSingleFuture.map0(GridDhtGetSingleFuture.java:277)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtGetSingleFuture.map(GridDhtGetSingleFuture.java:259)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtGetSingleFuture.init(GridDhtGetSingleFuture.java:182)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheAdapter.getDhtSingleAsync(GridDhtCacheAdapter.java:918)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheAdapter.processNearSingleGetRequest(GridDhtCacheAdapter.java:933)
> at
>
[jira] [Closed] (IGNITE-11088) Flacky LocalWalModeChangeDuringRebalancingSelfTest.testWithExchangesMerge
[
https://issues.apache.org/jira/browse/IGNITE-11088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Mashenkov closed IGNITE-11088.
-
> Flacky LocalWalModeChangeDuringRebalancingSelfTest.testWithExchangesMerge
> -
>
> Key: IGNITE-11088
> URL: https://issues.apache.org/jira/browse/IGNITE-11088
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Reporter: Andrew Mashenkov
>Priority: Major
> Labels: MakeTeamcityGreenAgain
>
> [LocalWalModeChangeDuringRebalancingSelfTest.testWithExchangesMerge|https://ci.ignite.apache.org/viewLog.html?buildId=2895774=buildResultsDiv=IgniteTests24Java8_MvccPds2#testNameId-6585115376754732686]
> fails sporadicatlly in MvccPds 2 suite.
> I've found no failures in non-mvcc Pds 2 suite, so, probably it is mvcc issue.
> See stacktraces from 2 failures that may have same reason. We have to
> investigate this.
> {noformat}
> java.lang.AssertionError: nodeIdx=2, key=6606 expected:<13212> but was:
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:743)
> at org.junit.Assert.assertEquals(Assert.java:118)
> at
> org.apache.ignite.internal.processors.cache.persistence.LocalWalModeChangeDuringRebalancingSelfTest.testWithExchangesMerge(LocalWalModeChangeDuringRebalancingSelfTest.java:473)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$6.run(GridAbstractTest.java:2088)
> at java.lang.Thread.run(Thread.java:748) {noformat}
> {noformat}
> [2019-01-23
> 11:26:25,287][ERROR][sys-stripe-5-#6186%persistence.LocalWalModeChangeDuringRebalancingSelfTest3%][GridDhtColocatedCache]
> Failed processing get request: GridNearSingleGetRequest
> [futId=1548243502606, key=KeyCacheObjectImpl [part=381, val=7037,
> hasValBytes=true], flags=1, topVer=AffinityTopologyVersion [topVer=8,
> minorTopVer=1], subjId=f1fbb371-3232-4bfa-a20a-d4cad4b2, taskNameHash=0,
> createTtl=-1, accessTtl=-1, txLbl=null, mvccSnapshot=MvccSnapshotResponse
> [futId=7040, crdVer=1548242747966, cntr=20023, opCntr=1073741823, txs=null,
> cleanupVer=0, tracking=0]] class org.apache.ignite.IgniteCheckedException:
> Runtime failure on bounds: [lower=MvccSnapshotSearchRow [res=null,
> snapshot=MvccSnapshotResponse [futId=7040, crdVer=1548242747966, cntr=20023,
> opCntr=1073741823, txs=null, cleanupVer=0, tracking=0]],
> upper=MvccMinSearchRow []] at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.iterate(BPlusTree.java:1043)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.mvccFind(IgniteCacheOffheapManagerImpl.java:2683)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.mvccFind(GridCacheOffheapManager.java:2141)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.mvccRead(IgniteCacheOffheapManagerImpl.java:666)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.getAllAsync0(GridCacheAdapter.java:2023)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheAdapter.getDhtAllAsync(GridDhtCacheAdapter.java:807)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtGetSingleFuture.getAsync(GridDhtGetSingleFuture.java:399)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtGetSingleFuture.map0(GridDhtGetSingleFuture.java:277)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtGetSingleFuture.map(GridDhtGetSingleFuture.java:259)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtGetSingleFuture.init(GridDhtGetSingleFuture.java:182)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheAdapter.getDhtSingleAsync(GridDhtCacheAdapter.java:918)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheAdapter.processNearSingleGetRequest(GridDhtCacheAdapter.java:933)
> at
>
[jira] [Commented] (IGNITE-11460) MVCC: Possible race on coordinator changing on client reconnection.
[
https://issues.apache.org/jira/browse/IGNITE-11460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16793557#comment-16793557
]
Andrew Mashenkov commented on IGNITE-11460:
---
[~NSAmelchev],
I'd think there is a bug in Discovery and onLocalJoin semantic is broken on
client.
Discovery events should be ordered and we should get events from old topology
after 're-connect' event, but no events (node_left\failed) shouldn't be ignored.
So, correct fix is to wait somehow for all discovery events from event storage
being processed before handling onLocalJoin.
Other possible way is to rework 'event' processing to be run in single thread
with preserving event order.
> MVCC: Possible race on coordinator changing on client reconnection.
> ---
>
> Key: IGNITE-11460
> URL: https://issues.apache.org/jira/browse/IGNITE-11460
> Project: Ignite
> Issue Type: Bug
>Reporter: Amelchev Nikita
>Assignee: Amelchev Nikita
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.8
>
> Attachments: stacktraces.log
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I found that the wrong coordinator can be set in case of client reconnect:
> {noformat}
> assert newCrd.topologyVersion().compareTo(curCrd.topologyVersion()) > 0;
> java.lang.AssertionError
> at
> org.apache.ignite.internal.processors.cache.mvcc.MvccProcessorImpl.onCoordinatorChanged(MvccProcessorImpl.java:541)
> at
> org.apache.ignite.internal.processors.cache.mvcc.MvccProcessorImpl.onLocalJoin(MvccProcessorImpl.java:416)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery0(GridDiscoveryManager.java:851)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.lambda$onDiscovery$0(GridDiscoveryManager.java:601)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryMessageNotifierWorker.body0(GridDiscoveryManager.java:2681)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryMessageNotifierWorker.body(GridDiscoveryManager.java:2719)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> I have attached reproducer in PR.
> The main reason is that coordinator can be changed from discovery event
> thread when the client already disconnect (disconnection processed in
> notifier thread and change coordinator on onDisconnected method).
> Coordinator can be changed in cases:
> 1. notifier disco thread: onDisconnected method
> 2. event disco thread: onDiscovery listener.
> and events can be processed with some delay and override coordinator that set
> in notifier thread.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (IGNITE-10966) MVCC: Add scale factor support in Mvcc tests suites.
[ https://issues.apache.org/jira/browse/IGNITE-10966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Mashenkov closed IGNITE-10966. - > MVCC: Add scale factor support in Mvcc tests suites. > > > Key: IGNITE-10966 > URL: https://issues.apache.org/jira/browse/IGNITE-10966 > Project: Ignite > Issue Type: Task > Components: mvcc >Reporter: Andrew Mashenkov >Priority: Minor > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > For now, Mvcc suites do not support "scale factor" and run only on nightly > basis. > We should add "scale factor" for "Mvcc Cache suite" and "Mvcc SQL suite" > tests to save TC time in RunAll. (Full run on nightly basis with no scaling > will not be affected) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-10966) MVCC: Add scale factor support in Mvcc tests suites.
[ https://issues.apache.org/jira/browse/IGNITE-10966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Mashenkov resolved IGNITE-10966. --- Resolution: Not A Problem Looks like it was already fixed in some ticket. > MVCC: Add scale factor support in Mvcc tests suites. > > > Key: IGNITE-10966 > URL: https://issues.apache.org/jira/browse/IGNITE-10966 > Project: Ignite > Issue Type: Task > Components: mvcc >Reporter: Andrew Mashenkov >Priority: Minor > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > For now, Mvcc suites do not support "scale factor" and run only on nightly > basis. > We should add "scale factor" for "Mvcc Cache suite" and "Mvcc SQL suite" > tests to save TC time in RunAll. (Full run on nightly basis with no scaling > will not be affected) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11323) Reduce boilerplate "System.setProperty" code in tests
[
https://issues.apache.org/jira/browse/IGNITE-11323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16793520#comment-16793520
]
Andrew Mashenkov commented on IGNITE-11323:
---
[~ibessonov], just one question.
What is the reason making GridAbstractTest.currTestMtd field non-static?
I see it was marked as 'static' together with 'forceFailure' and
'forceFailureMsg' in IGNITE-10179.
Is IGNITE-10179 changes outdated and forceFailure* can be non-static as well?
or 'currTestMtd' static modifier change should be reverted?
> Reduce boilerplate "System.setProperty" code in tests
> -
>
> Key: IGNITE-11323
> URL: https://issues.apache.org/jira/browse/IGNITE-11323
> Project: Ignite
> Issue Type: Test
>Reporter: Ivan Bessonov
>Assignee: Ivan Bessonov
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> There are many examples in tests where some property gets new value in
> "beforeTestsStarted"/"beforeTest"/"beginning of test method" and then gets
> its previous value in "afterTestsStopped"/"afterTest"/"finally block of test
> method". This approach leads to excessive code that can be avoided.
> I suggest implementing annotation "WithSystemProperty" (name is the subject
> to discussion) that will allow us to write this:
> {code:java}
> @Test
> @WithSystemProperty(key = IGNITE_SKIP_CONFIGURATION_CONSISTENCY_CHECK, value
> = "true")
> public void testSkipCheckConsistencyFlagEnabled() throws Exception {
> ...
> }
> {code}
> instead of this:
> {code:java}
> @Test
> public void testSkipCheckConsistencyFlagEnabled() throws Exception {
> String backup =
> System.setProperty(IGNITE_SKIP_CONFIGURATION_CONSISTENCY_CHECK, "true");
> try {
> ...
> }
> finally {
> if (backup != null)
> System.setProperty(IGNITE_SKIP_CONFIGURATION_CONSISTENCY_CHECK,
> backup);
> else
> System.clearProperty(IGNITE_SKIP_CONFIGURATION_CONSISTENCY_CHECK);
> }
> }
> {code}
>
> There also has to be ability to use this annotation on test class so new
> value of system properties will be used in all of its test methods.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-11215) MVCC: JVM crash in MVCC PDS 1 suite
[
https://issues.apache.org/jira/browse/IGNITE-11215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16792717#comment-16792717
]
Andrew Mashenkov edited comment on IGNITE-11215 at 3/15/19 9:39 AM:
Mass ExplicitWalDeltaConsistencyTest run look ok.
Failed most likely is related to IGNITE-13711
was (Author: amashenkov):
Mass test run look ok.
> MVCC: JVM crash in MVCC PDS 1 suite
> ---
>
> Key: IGNITE-11215
> URL: https://issues.apache.org/jira/browse/IGNITE-11215
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Reporter: Roman Kondakov
>Assignee: Andrew Mashenkov
>Priority: Critical
> Labels: mvcc_stability
> Fix For: 2.8
>
> Attachments: No_C2_opts_hs_err_pid957384.log, hs_err_pid429215.log
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Sometimes JVM crash
> [occurs|https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_MvccPds1_IgniteTests24Java8=%3Cdefault%3E=buildTypeHistoryList=failed]
> in {{vacuum-cleaner}} thread in {{ExplicitWalDeltaConsistencyTest}}.
> See attached crash report.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11323) Reduce boilerplate "System.setProperty" code in tests
[
https://issues.apache.org/jira/browse/IGNITE-11323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Mashenkov updated IGNITE-11323:
--
Labels: MakeTeamcityGreenAgain (was: JUnit)
> Reduce boilerplate "System.setProperty" code in tests
> -
>
> Key: IGNITE-11323
> URL: https://issues.apache.org/jira/browse/IGNITE-11323
> Project: Ignite
> Issue Type: Test
>Reporter: Ivan Bessonov
>Assignee: Ivan Bessonov
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> There are many examples in tests where some property gets new value in
> "beforeTestsStarted"/"beforeTest"/"beginning of test method" and then gets
> its previous value in "afterTestsStopped"/"afterTest"/"finally block of test
> method". This approach leads to excessive code that can be avoided.
> I suggest implementing annotation "WithSystemProperty" (name is the subject
> to discussion) that will allow us to write this:
> {code:java}
> @Test
> @WithSystemProperty(key = IGNITE_SKIP_CONFIGURATION_CONSISTENCY_CHECK, value
> = "true")
> public void testSkipCheckConsistencyFlagEnabled() throws Exception {
> ...
> }
> {code}
> instead of this:
> {code:java}
> @Test
> public void testSkipCheckConsistencyFlagEnabled() throws Exception {
> String backup =
> System.setProperty(IGNITE_SKIP_CONFIGURATION_CONSISTENCY_CHECK, "true");
> try {
> ...
> }
> finally {
> if (backup != null)
> System.setProperty(IGNITE_SKIP_CONFIGURATION_CONSISTENCY_CHECK,
> backup);
> else
> System.clearProperty(IGNITE_SKIP_CONFIGURATION_CONSISTENCY_CHECK);
> }
> }
> {code}
>
> There also has to be ability to use this annotation on test class so new
> value of system properties will be used in all of its test methods.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11323) Reduce boilerplate "System.setProperty" code in tests
[
https://issues.apache.org/jira/browse/IGNITE-11323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Mashenkov updated IGNITE-11323:
--
Labels: JUnit (was: )
> Reduce boilerplate "System.setProperty" code in tests
> -
>
> Key: IGNITE-11323
> URL: https://issues.apache.org/jira/browse/IGNITE-11323
> Project: Ignite
> Issue Type: Test
>Reporter: Ivan Bessonov
>Assignee: Ivan Bessonov
>Priority: Major
> Labels: JUnit
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> There are many examples in tests where some property gets new value in
> "beforeTestsStarted"/"beforeTest"/"beginning of test method" and then gets
> its previous value in "afterTestsStopped"/"afterTest"/"finally block of test
> method". This approach leads to excessive code that can be avoided.
> I suggest implementing annotation "WithSystemProperty" (name is the subject
> to discussion) that will allow us to write this:
> {code:java}
> @Test
> @WithSystemProperty(key = IGNITE_SKIP_CONFIGURATION_CONSISTENCY_CHECK, value
> = "true")
> public void testSkipCheckConsistencyFlagEnabled() throws Exception {
> ...
> }
> {code}
> instead of this:
> {code:java}
> @Test
> public void testSkipCheckConsistencyFlagEnabled() throws Exception {
> String backup =
> System.setProperty(IGNITE_SKIP_CONFIGURATION_CONSISTENCY_CHECK, "true");
> try {
> ...
> }
> finally {
> if (backup != null)
> System.setProperty(IGNITE_SKIP_CONFIGURATION_CONSISTENCY_CHECK,
> backup);
> else
> System.clearProperty(IGNITE_SKIP_CONFIGURATION_CONSISTENCY_CHECK);
> }
> }
> {code}
>
> There also has to be ability to use this annotation on test class so new
> value of system properties will be used in all of its test methods.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11323) Reduce boilerplate "System.setProperty" code in tests
[
https://issues.apache.org/jira/browse/IGNITE-11323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16793480#comment-16793480
]
Andrew Mashenkov commented on IGNITE-11323:
---
[~ibessonov], great idea.
PR look good to me.
> Reduce boilerplate "System.setProperty" code in tests
> -
>
> Key: IGNITE-11323
> URL: https://issues.apache.org/jira/browse/IGNITE-11323
> Project: Ignite
> Issue Type: Test
>Reporter: Ivan Bessonov
>Assignee: Ivan Bessonov
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> There are many examples in tests where some property gets new value in
> "beforeTestsStarted"/"beforeTest"/"beginning of test method" and then gets
> its previous value in "afterTestsStopped"/"afterTest"/"finally block of test
> method". This approach leads to excessive code that can be avoided.
> I suggest implementing annotation "WithSystemProperty" (name is the subject
> to discussion) that will allow us to write this:
> {code:java}
> @Test
> @WithSystemProperty(key = IGNITE_SKIP_CONFIGURATION_CONSISTENCY_CHECK, value
> = "true")
> public void testSkipCheckConsistencyFlagEnabled() throws Exception {
> ...
> }
> {code}
> instead of this:
> {code:java}
> @Test
> public void testSkipCheckConsistencyFlagEnabled() throws Exception {
> String backup =
> System.setProperty(IGNITE_SKIP_CONFIGURATION_CONSISTENCY_CHECK, "true");
> try {
> ...
> }
> finally {
> if (backup != null)
> System.setProperty(IGNITE_SKIP_CONFIGURATION_CONSISTENCY_CHECK,
> backup);
> else
> System.clearProperty(IGNITE_SKIP_CONFIGURATION_CONSISTENCY_CHECK);
> }
> }
> {code}
>
> There also has to be ability to use this annotation on test class so new
> value of system properties will be used in all of its test methods.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11542) Fix flacky test testGivenCacheWithPojoValueAndPds_WhenPut_ThenNoHangup.
[ https://issues.apache.org/jira/browse/IGNITE-11542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Mashenkov updated IGNITE-11542: -- Ignite Flags: (was: Docs Required) > Fix flacky test testGivenCacheWithPojoValueAndPds_WhenPut_ThenNoHangup. > --- > > Key: IGNITE-11542 > URL: https://issues.apache.org/jira/browse/IGNITE-11542 > Project: Ignite > Issue Type: Test >Reporter: Andrew Mashenkov >Priority: Major > Labels: MakeTeamcityGreenAgain > Time Spent: 10m > Remaining Estimate: 0h > > IgnitePdsBinarySortObjectFieldsTest.testGivenCacheWithPojoValueAndPds_WhenPut_ThenNoHangup > fails sporadically on TC due to 5 sec timeout may be not enough for grid > startup. > Test checks "put" operation will complete in 5 sec timeout, > but grid initialization is included in this timeout with no reason. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11542) Fix flacky test testGivenCacheWithPojoValueAndPds_WhenPut_ThenNoHangup.
[ https://issues.apache.org/jira/browse/IGNITE-11542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Mashenkov updated IGNITE-11542: -- Fix Version/s: 2.8 > Fix flacky test testGivenCacheWithPojoValueAndPds_WhenPut_ThenNoHangup. > --- > > Key: IGNITE-11542 > URL: https://issues.apache.org/jira/browse/IGNITE-11542 > Project: Ignite > Issue Type: Test >Reporter: Andrew Mashenkov >Priority: Major > Labels: MakeTeamcityGreenAgain > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > IgnitePdsBinarySortObjectFieldsTest.testGivenCacheWithPojoValueAndPds_WhenPut_ThenNoHangup > fails sporadically on TC due to 5 sec timeout may be not enough for grid > startup. > Test checks "put" operation will complete in 5 sec timeout, > but grid initialization is included in this timeout with no reason. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-11542) Fix flacky test testGivenCacheWithPojoValueAndPds_WhenPut_ThenNoHangup.
[ https://issues.apache.org/jira/browse/IGNITE-11542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Mashenkov reassigned IGNITE-11542: - Assignee: Andrew Mashenkov > Fix flacky test testGivenCacheWithPojoValueAndPds_WhenPut_ThenNoHangup. > --- > > Key: IGNITE-11542 > URL: https://issues.apache.org/jira/browse/IGNITE-11542 > Project: Ignite > Issue Type: Test >Reporter: Andrew Mashenkov >Assignee: Andrew Mashenkov >Priority: Major > Labels: MakeTeamcityGreenAgain > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > IgnitePdsBinarySortObjectFieldsTest.testGivenCacheWithPojoValueAndPds_WhenPut_ThenNoHangup > fails sporadically on TC due to 5 sec timeout may be not enough for grid > startup. > Test checks "put" operation will complete in 5 sec timeout, > but grid initialization is included in this timeout with no reason. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11542) Fix flacky test testGivenCacheWithPojoValueAndPds_WhenPut_ThenNoHangup.
Andrew Mashenkov created IGNITE-11542: - Summary: Fix flacky test testGivenCacheWithPojoValueAndPds_WhenPut_ThenNoHangup. Key: IGNITE-11542 URL: https://issues.apache.org/jira/browse/IGNITE-11542 Project: Ignite Issue Type: Test Reporter: Andrew Mashenkov IgnitePdsBinarySortObjectFieldsTest.testGivenCacheWithPojoValueAndPds_WhenPut_ThenNoHangup fails sporadically on TC due to 5 sec timeout may be not enough for grid startup. Test checks "put" operation will complete in 5 sec timeout, but grid initialization is included in this timeout with no reason. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
