[jira] [Updated] (IGNITE-7682) C++: LocalSize cache functions
[ https://issues.apache.org/jira/browse/IGNITE-7682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Bastanov updated IGNITE-7682: --- Summary: C++: LocalSize cache functions (was: LocalSize cache functions on C++) > C++: LocalSize cache functions > -- > > Key: IGNITE-7682 > URL: https://issues.apache.org/jira/browse/IGNITE-7682 > Project: Ignite > Issue Type: Bug > Components: platforms > Environment: Ignite builded by jdk1.8.0_152 with sources > tag:ignite-2.3 > cpp libs builded by Microsoft Visual Studio Enterprise 2015 Version > 14.0.25431.01 Update 3 > all x64 >Reporter: Roman Bastanov >Priority: Major > > LocalSize functions with all variations of CachePeekMode returns same results. > They always returns all cache size, the sum of all node caches. > {code} > auto cache = IgniteNode.GetCache<...>(cache_name); > cache.LocalSize(ignite::cache::CachePeekMode::BACKUP) > cache.LocalSize(ignite::cache::CachePeekMode::NEAR_CACHE) > cache.LocalSize(ignite::cache::CachePeekMode::OFFHEAP) > cache.LocalSize(ignite::cache::CachePeekMode::ONHEAP) > cache.LocalSize(ignite::cache::CachePeekMode::PRIMARY) > cache.LocalSize(ignite::cache::CachePeekMode::SWAP) > {code} > Despite this, manually calculations are correct, and returns local size(cache > on this node). > {code} > auto query = cache::query::ScanQuery(); > query.SetLocal(true); > auto cursor = cache.Query(query); > while (cursor.HasNext()) { > cache_size++; > }{code} -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-7682) LocalSize cache functions on C++
Roman Bastanov created IGNITE-7682: -- Summary: LocalSize cache functions on C++ Key: IGNITE-7682 URL: https://issues.apache.org/jira/browse/IGNITE-7682 Project: Ignite Issue Type: Bug Components: platforms Environment: Ignite builded by jdk1.8.0_152 with sources tag:ignite-2.3 cpp libs builded by Microsoft Visual Studio Enterprise 2015 Version 14.0.25431.01 Update 3 all x64 Reporter: Roman Bastanov LocalSize functions with all variations of CachePeekMode returns same results. They always returns all cache size, the sum of all node caches. {code} auto cache = IgniteNode.GetCache<...>(cache_name); cache.LocalSize(ignite::cache::CachePeekMode::BACKUP) cache.LocalSize(ignite::cache::CachePeekMode::NEAR_CACHE) cache.LocalSize(ignite::cache::CachePeekMode::OFFHEAP) cache.LocalSize(ignite::cache::CachePeekMode::ONHEAP) cache.LocalSize(ignite::cache::CachePeekMode::PRIMARY) cache.LocalSize(ignite::cache::CachePeekMode::SWAP) {code} Despite this, manually calculations are correct, and returns local size(cache on this node). {code} auto query = cache::query::ScanQuery(); query.SetLocal(true); auto cursor = cache.Query(query); while (cursor.HasNext()) { cache_size++; }{code} -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-7167) Optimize 'select count(*) from Table'
[ https://issues.apache.org/jira/browse/IGNITE-7167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16362003#comment-16362003 ] Vladimir Ozerov edited comment on IGNITE-7167 at 2/13/18 8:49 AM: -- [~vkulichenko], Regarding MVCC - when doing {{COUNT(*)}} you should count only elements visible to your MVCC counter. The only way to achieve this is counting elements one-by-one, filtering out the following entries: 1) Entries for not-yet committed transactions 2) Entries for aborted transactions 3) Entries for newer committed transactions which are not visible to current transaction Certain optimizations exist, such as aggregating visibility info on per-block level, but in general case we still resort to a kind of iteration over some elements (tuple or block), rather than reading a single number. NB: When MVCC is enabled {{IgniteCache.size()}} would also likely be O(N) operation rather than O(1). was (Author: vozerov): [~vkulichenko], Regarding MVCC - when doing COUNT(*) you should count only elements visible to your MVCC counter. The only way to achieve this is counting elements one-by-one, filtering out the following entries: 1) Entries for not-yet committed transactions 2) Entries for aborted transactions 3) Entries for newer committed transactions which are not visible to current transaction Certain optimizations exist, such as aggregating visibility info on per-block level, but in general case we still resort to a kind of iteration over some elements (tuple or block), rather than reading a single number. NB: When MVCC is enabled {{IgniteCache.size()}} would also likely be O(N) operation rather than O(1). > Optimize 'select count(*) from Table' > - > > Key: IGNITE-7167 > URL: https://issues.apache.org/jira/browse/IGNITE-7167 > Project: Ignite > Issue Type: Improvement > Components: sql >Affects Versions: 2.3 >Reporter: Valentin Kulichenko >Priority: Major > > Currently query like {{select count(*) from Table}} effectively scans the > cache and take a lot of time for large datasets. Probably makes sense to > optimize it to use {{IgniteCache#size}} directly when possible. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7167) Optimize 'select count(*) from Table'
[ https://issues.apache.org/jira/browse/IGNITE-7167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16362003#comment-16362003 ] Vladimir Ozerov commented on IGNITE-7167: - [~vkulichenko], Regarding MVCC - when doing COUNT(*) you should count only elements visible to your MVCC counter. The only way to achieve this is counting elements one-by-one, filtering out the following entries: 1) Entries for not-yet committed transactions 2) Entries for aborted transactions 3) Entries for newer committed transactions which are not visible to current transaction Certain optimizations exist, such as aggregating visibility info on per-block level, but in general case we still resort to a kind of iteration over some elements (tuple or block), rather than reading a single number. NB: When MVCC is enabled {{IgniteCache.size()}} would also likely be O(N) operation rather than O(1). > Optimize 'select count(*) from Table' > - > > Key: IGNITE-7167 > URL: https://issues.apache.org/jira/browse/IGNITE-7167 > Project: Ignite > Issue Type: Improvement > Components: sql >Affects Versions: 2.3 >Reporter: Valentin Kulichenko >Priority: Major > > Currently query like {{select count(*) from Table}} effectively scans the > cache and take a lot of time for large datasets. Probably makes sense to > optimize it to use {{IgniteCache#size}} directly when possible. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-7167) Optimize 'select count(*) from Table'
[ https://issues.apache.org/jira/browse/IGNITE-7167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16362003#comment-16362003 ] Vladimir Ozerov edited comment on IGNITE-7167 at 2/13/18 8:50 AM: -- [~vkulichenko], Regarding MVCC - when doing {{COUNT\(*\)}} you should count only elements visible to your MVCC version. The only way to achieve this is counting elements one-by-one, filtering out the following entries: 1) Entries for not-yet committed transactions 2) Entries for aborted transactions 3) Entries for newer committed transactions which are not visible to current transaction Certain optimizations exist, such as aggregating visibility info on per-block level, but in general case we still resort to a kind of iteration over some elements (tuples or blocks), rather than reading a single number. NB: When MVCC is enabled {{IgniteCache.size()}} would also likely be O(N) operation rather than O(1). was (Author: vozerov): [~vkulichenko], Regarding MVCC - when doing {{COUNT\(*\)}} you should count only elements visible to your MVCC version. The only way to achieve this is counting elements one-by-one, filtering out the following entries: 1) Entries for not-yet committed transactions 2) Entries for aborted transactions 3) Entries for newer committed transactions which are not visible to current transaction Certain optimizations exist, such as aggregating visibility info on per-block level, but in general case we still resort to a kind of iteration over some elements (tuple or block), rather than reading a single number. NB: When MVCC is enabled {{IgniteCache.size()}} would also likely be O(N) operation rather than O(1). > Optimize 'select count(*) from Table' > - > > Key: IGNITE-7167 > URL: https://issues.apache.org/jira/browse/IGNITE-7167 > Project: Ignite > Issue Type: Improvement > Components: sql >Affects Versions: 2.3 >Reporter: Valentin Kulichenko >Priority: Major > > Currently query like {{select count(*) from Table}} effectively scans the > cache and take a lot of time for large datasets. Probably makes sense to > optimize it to use {{IgniteCache#size}} directly when possible. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-7167) Optimize 'select count(*) from Table'
[ https://issues.apache.org/jira/browse/IGNITE-7167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16362003#comment-16362003 ] Vladimir Ozerov edited comment on IGNITE-7167 at 2/13/18 8:50 AM: -- [~vkulichenko], Regarding MVCC - when doing {{COUNT\(*\)}} you should count only elements visible to your MVCC counter. The only way to achieve this is counting elements one-by-one, filtering out the following entries: 1) Entries for not-yet committed transactions 2) Entries for aborted transactions 3) Entries for newer committed transactions which are not visible to current transaction Certain optimizations exist, such as aggregating visibility info on per-block level, but in general case we still resort to a kind of iteration over some elements (tuple or block), rather than reading a single number. NB: When MVCC is enabled {{IgniteCache.size()}} would also likely be O(N) operation rather than O(1). was (Author: vozerov): [~vkulichenko], Regarding MVCC - when doing {{COUNT(*)}} you should count only elements visible to your MVCC counter. The only way to achieve this is counting elements one-by-one, filtering out the following entries: 1) Entries for not-yet committed transactions 2) Entries for aborted transactions 3) Entries for newer committed transactions which are not visible to current transaction Certain optimizations exist, such as aggregating visibility info on per-block level, but in general case we still resort to a kind of iteration over some elements (tuple or block), rather than reading a single number. NB: When MVCC is enabled {{IgniteCache.size()}} would also likely be O(N) operation rather than O(1). > Optimize 'select count(*) from Table' > - > > Key: IGNITE-7167 > URL: https://issues.apache.org/jira/browse/IGNITE-7167 > Project: Ignite > Issue Type: Improvement > Components: sql >Affects Versions: 2.3 >Reporter: Valentin Kulichenko >Priority: Major > > Currently query like {{select count(*) from Table}} effectively scans the > cache and take a lot of time for large datasets. Probably makes sense to > optimize it to use {{IgniteCache#size}} directly when possible. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-7167) Optimize 'select count(*) from Table'
[ https://issues.apache.org/jira/browse/IGNITE-7167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16362003#comment-16362003 ] Vladimir Ozerov edited comment on IGNITE-7167 at 2/13/18 8:50 AM: -- [~vkulichenko], Regarding MVCC - when doing {{COUNT\(*\)}} you should count only elements visible to your MVCC version. The only way to achieve this is counting elements one-by-one, filtering out the following entries: 1) Entries for not-yet committed transactions 2) Entries for aborted transactions 3) Entries for newer committed transactions which are not visible to current transaction Certain optimizations exist, such as aggregating visibility info on per-block level, but in general case we still resort to a kind of iteration over some elements (tuple or block), rather than reading a single number. NB: When MVCC is enabled {{IgniteCache.size()}} would also likely be O(N) operation rather than O(1). was (Author: vozerov): [~vkulichenko], Regarding MVCC - when doing {{COUNT\(*\)}} you should count only elements visible to your MVCC counter. The only way to achieve this is counting elements one-by-one, filtering out the following entries: 1) Entries for not-yet committed transactions 2) Entries for aborted transactions 3) Entries for newer committed transactions which are not visible to current transaction Certain optimizations exist, such as aggregating visibility info on per-block level, but in general case we still resort to a kind of iteration over some elements (tuple or block), rather than reading a single number. NB: When MVCC is enabled {{IgniteCache.size()}} would also likely be O(N) operation rather than O(1). > Optimize 'select count(*) from Table' > - > > Key: IGNITE-7167 > URL: https://issues.apache.org/jira/browse/IGNITE-7167 > Project: Ignite > Issue Type: Improvement > Components: sql >Affects Versions: 2.3 >Reporter: Valentin Kulichenko >Priority: Major > > Currently query like {{select count(*) from Table}} effectively scans the > cache and take a lot of time for large datasets. Probably makes sense to > optimize it to use {{IgniteCache#size}} directly when possible. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-6132) Need to add criteria query to web console
[ https://issues.apache.org/jira/browse/IGNITE-6132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov reassigned IGNITE-6132: Assignee: (was: Vica Abramova) > Need to add criteria query to web console > - > > Key: IGNITE-6132 > URL: https://issues.apache.org/jira/browse/IGNITE-6132 > Project: Ignite > Issue Type: New Feature > Components: wizards >Reporter: Yakov Zhdanov >Priority: Major > Labels: web-console > > It would be handy to set several "name"-"value" pairs with operation and > provide way of combination of those pairs (AND, OR, ()) to scan cache and > provide paginated results back -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-6132) Need to add criteria query to web console
[ https://issues.apache.org/jira/browse/IGNITE-6132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov updated IGNITE-6132: - Description: It would be handy to set several "name"-"value" pairs with operation and provide way of combination of those pairs (AND, OR, ()) to scan cache and provide paginated results back We can look at how it implemented in HZ: http://docs.hazelcast.org/docs/latest-development/manual/html/Distributed_Query/How_Distributed_Query_Works/Querying_with_SQL.html was:It would be handy to set several "name"-"value" pairs with operation and provide way of combination of those pairs (AND, OR, ()) to scan cache and provide paginated results back > Need to add criteria query to web console > - > > Key: IGNITE-6132 > URL: https://issues.apache.org/jira/browse/IGNITE-6132 > Project: Ignite > Issue Type: New Feature > Components: wizards >Reporter: Yakov Zhdanov >Priority: Major > Labels: web-console > > It would be handy to set several "name"-"value" pairs with operation and > provide way of combination of those pairs (AND, OR, ()) to scan cache and > provide paginated results back > > We can look at how it implemented in HZ: > http://docs.hazelcast.org/docs/latest-development/manual/html/Distributed_Query/How_Distributed_Query_Works/Querying_with_SQL.html -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-3111) .NET: Configure SSL without Spring
[ https://issues.apache.org/jira/browse/IGNITE-3111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16362031#comment-16362031 ] Sergey Kalashnikov commented on IGNITE-3111: [~alexey.tank2], looks good to me. > .NET: Configure SSL without Spring > -- > > Key: IGNITE-3111 > URL: https://issues.apache.org/jira/browse/IGNITE-3111 > Project: Ignite > Issue Type: Improvement > Components: platforms >Affects Versions: 1.6 >Reporter: Pavel Tupitsyn >Assignee: Alexey Popov >Priority: Major > Labels: .net > Fix For: 2.5 > > > User should be able to configure SLL in .NET terms without Spring and Java > KeyStore. > See https://apacheignite.readme.io/docs/ssltls. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7652) ContinuousQueryWithTransformer example
[ https://issues.apache.org/jira/browse/IGNITE-7652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16362078#comment-16362078 ] Nikolay Izhikov commented on IGNITE-7652: - [~dmagda] Yes, this documentation should go in 2.5 Thank you for giving me permissions. > ContinuousQueryWithTransformer example > -- > > Key: IGNITE-7652 > URL: https://issues.apache.org/jira/browse/IGNITE-7652 > Project: Ignite > Issue Type: Improvement > Components: cache >Affects Versions: 2.5 >Reporter: Nikolay Izhikov >Assignee: Nikolay Izhikov >Priority: Major > Fix For: 2.5 > > > Need to create example for a ContinuousQueryWithTransformer. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-7683) ContinuousQueryWithTransformer needs to be documented
Nikolay Izhikov created IGNITE-7683: --- Summary: ContinuousQueryWithTransformer needs to be documented Key: IGNITE-7683 URL: https://issues.apache.org/jira/browse/IGNITE-7683 Project: Ignite Issue Type: Improvement Components: documentation Reporter: Nikolay Izhikov Assignee: Nikolay Izhikov Fix For: 2.5 New API - ContinuousQueryWithTransformer should be documented. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7652) ContinuousQueryWithTransformer example
[ https://issues.apache.org/jira/browse/IGNITE-7652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16362087#comment-16362087 ] Nikolay Izhikov commented on IGNITE-7652: - I keep this ticket for an CQWT example. IGNITE-7683 is for documentation. > ContinuousQueryWithTransformer example > -- > > Key: IGNITE-7652 > URL: https://issues.apache.org/jira/browse/IGNITE-7652 > Project: Ignite > Issue Type: Improvement > Components: cache >Affects Versions: 2.5 >Reporter: Nikolay Izhikov >Assignee: Nikolay Izhikov >Priority: Major > Fix For: 2.5 > > > Need to create example for a ContinuousQueryWithTransformer. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-3111) .NET: Configure SSL without Spring
[ https://issues.apache.org/jira/browse/IGNITE-3111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16362089#comment-16362089 ] Igor Sapego commented on IGNITE-3111: - Everything looks good to me. > .NET: Configure SSL without Spring > -- > > Key: IGNITE-3111 > URL: https://issues.apache.org/jira/browse/IGNITE-3111 > Project: Ignite > Issue Type: Improvement > Components: platforms >Affects Versions: 1.6 >Reporter: Pavel Tupitsyn >Assignee: Alexey Popov >Priority: Major > Labels: .net > Fix For: 2.5 > > > User should be able to configure SLL in .NET terms without Spring and Java > KeyStore. > See https://apacheignite.readme.io/docs/ssltls. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-3111) .NET: Configure SSL without Spring
[ https://issues.apache.org/jira/browse/IGNITE-3111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16362100#comment-16362100 ] ASF GitHub Bot commented on IGNITE-3111: Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/3498 > .NET: Configure SSL without Spring > -- > > Key: IGNITE-3111 > URL: https://issues.apache.org/jira/browse/IGNITE-3111 > Project: Ignite > Issue Type: Improvement > Components: platforms >Affects Versions: 1.6 >Reporter: Pavel Tupitsyn >Assignee: Alexey Popov >Priority: Major > Labels: .net > Fix For: 2.5 > > > User should be able to configure SLL in .NET terms without Spring and Java > KeyStore. > See https://apacheignite.readme.io/docs/ssltls. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-5265) Eviction Rate memory metric to be implemented
[ https://issues.apache.org/jira/browse/IGNITE-5265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16362110#comment-16362110 ] Ivan Rakov commented on IGNITE-5265: [~alex_pl], I've looked through your pull request. Changes look good, please merge. > Eviction Rate memory metric to be implemented > - > > Key: IGNITE-5265 > URL: https://issues.apache.org/jira/browse/IGNITE-5265 > Project: Ignite > Issue Type: Task > Components: general >Reporter: Sergey Chugunov >Assignee: Aleksey Plekhanov >Priority: Major > Fix For: 2.5 > > > Eviction rate metric is declared on *MemoryMetrics* interface but isn't > implemented in *MemoryMetricsImpl* (current implementation returns 0 right > away). > This metric must be implemented identically to *allocationRate* metric from > the same interface (algorithm for *allocationRate* can be reused with minor > refactoring). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-3111) .NET: Configure SSL without Spring
[ https://issues.apache.org/jira/browse/IGNITE-3111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16360365#comment-16360365 ] Alexey Popov edited comment on IGNITE-3111 at 2/13/18 10:54 AM: [~isapego] , fixed. Now we have only ISslContextFactory interface https://reviews.ignite.apache.org/ignite/review/IGNT-CR-489 was (Author: alexey.tank2): [~isapego] , fixed. Now we have only ISslContextFactory interface > .NET: Configure SSL without Spring > -- > > Key: IGNITE-3111 > URL: https://issues.apache.org/jira/browse/IGNITE-3111 > Project: Ignite > Issue Type: Improvement > Components: platforms >Affects Versions: 1.6 >Reporter: Pavel Tupitsyn >Assignee: Alexey Popov >Priority: Major > Labels: .net > Fix For: 2.5 > > > User should be able to configure SLL in .NET terms without Spring and Java > KeyStore. > See https://apacheignite.readme.io/docs/ssltls. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-7684) Ignore IGNITE_USE_ASYNC_FILE_IO_FACTORY in FileWriteAheadLogManager
Alexander Belyak created IGNITE-7684: Summary: Ignore IGNITE_USE_ASYNC_FILE_IO_FACTORY in FileWriteAheadLogManager Key: IGNITE-7684 URL: https://issues.apache.org/jira/browse/IGNITE-7684 Project: Ignite Issue Type: Improvement Components: general Affects Versions: 2.4 Reporter: Alexander Belyak If IGNITE_USE_ASYNC_FILE_IO_FACTORY specified and no IGNITE_WAL_MMAP we get: {noformat} java.lang.UnsupportedOperationException: AsynchronousFileChannel doesn't support mmap. at org.apache.ignite.internal.processors.cache.persistence.file.AsyncFileIO.map(AsyncFileIO.java:173) at org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.restoreWriteHandle(FileWriteAheadLogManager.java:1068) at org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.resumeLogging(FileWriteAheadLogManager.java:552) at org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.readCheckpointAndRestoreMemory(GridCacheDatabaseSharedManager.java:714) at org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onClusterStateChangeRequest(GridDhtPartitionsExchangeFuture.java:841) at org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:595) at org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2329) at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110) at java.lang.Thread.run(Thread.java:748) {noformat} -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-7685) Incorrect AllocationRate counting
[ https://issues.apache.org/jira/browse/IGNITE-7685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Vinogradov updated IGNITE-7685: - Affects Version/s: 2.4 > Incorrect AllocationRate counting > - > > Key: IGNITE-7685 > URL: https://issues.apache.org/jira/browse/IGNITE-7685 > Project: Ignite > Issue Type: Task >Affects Versions: 2.4 >Reporter: Anton Vinogradov >Assignee: Andrey Kuznetsov >Priority: Major > Fix For: 2.5 > > > Each call of > {{org.apache.ignite.internal.processors.cache.persistence.DataRegionMetricsImpl#updateTotalAllocatedPages}} > performs {{allocRate.onHit()}} call which is not correct since delta can be > negative or bigger that 1. > Need to fix allocationRate counting -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-7685) Incorrect AllocationRate counting
Anton Vinogradov created IGNITE-7685: Summary: Incorrect AllocationRate counting Key: IGNITE-7685 URL: https://issues.apache.org/jira/browse/IGNITE-7685 Project: Ignite Issue Type: Task Reporter: Anton Vinogradov Assignee: Andrey Kuznetsov Each call of {{org.apache.ignite.internal.processors.cache.persistence.DataRegionMetricsImpl#updateTotalAllocatedPages}} performs {{allocRate.onHit()}} call which is not correct since delta can be negative or bigger that 1. Need to fix allocationRate counting -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-7685) Incorrect AllocationRate counting
[ https://issues.apache.org/jira/browse/IGNITE-7685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Vinogradov updated IGNITE-7685: - Fix Version/s: 2.5 > Incorrect AllocationRate counting > - > > Key: IGNITE-7685 > URL: https://issues.apache.org/jira/browse/IGNITE-7685 > Project: Ignite > Issue Type: Task >Affects Versions: 2.4 >Reporter: Anton Vinogradov >Assignee: Andrey Kuznetsov >Priority: Major > Fix For: 2.5 > > > Each call of > {{org.apache.ignite.internal.processors.cache.persistence.DataRegionMetricsImpl#updateTotalAllocatedPages}} > performs {{allocRate.onHit()}} call which is not correct since delta can be > negative or bigger that 1. > Need to fix allocationRate counting -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-7513) Get rid of org.jsr166.ConcurrentHashMap8
[ https://issues.apache.org/jira/browse/IGNITE-7513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16362212#comment-16362212 ] Anton Vinogradov edited comment on IGNITE-7513 at 2/13/18 12:22 PM: [~andrey-kuznetsov], I'll check is there any performance drop using our bench lab and let you know about results. was (Author: avinogradov): [~andrey-kuznetsov], I'll check is there any performance prop using our bench lab and let you know about results. > Get rid of org.jsr166.ConcurrentHashMap8 > > > Key: IGNITE-7513 > URL: https://issues.apache.org/jira/browse/IGNITE-7513 > Project: Ignite > Issue Type: Sub-task >Reporter: Andrey Kuznetsov >Assignee: Andrey Kuznetsov >Priority: Major > Fix For: 2.5 > > > This class was made of ConcurrentHashMapV8, an intermediate implementation of > Java8's ConcurrentHashMap. Now we should switch to standard CHM. Possibly, > we'll have to check for performance implications. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7513) Get rid of org.jsr166.ConcurrentHashMap8
[ https://issues.apache.org/jira/browse/IGNITE-7513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16362212#comment-16362212 ] Anton Vinogradov commented on IGNITE-7513: -- [~andrey-kuznetsov], I'll check is there any performance prop using our bench lab and let you know about results. > Get rid of org.jsr166.ConcurrentHashMap8 > > > Key: IGNITE-7513 > URL: https://issues.apache.org/jira/browse/IGNITE-7513 > Project: Ignite > Issue Type: Sub-task >Reporter: Andrey Kuznetsov >Assignee: Andrey Kuznetsov >Priority: Major > Fix For: 2.5 > > > This class was made of ConcurrentHashMapV8, an intermediate implementation of > Java8's ConcurrentHashMap. Now we should switch to standard CHM. Possibly, > we'll have to check for performance implications. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-7686) PDS Direct IO failue: IgnitePdsEvictionTest.testPageEviction
Dmitriy Pavlov created IGNITE-7686: -- Summary: PDS Direct IO failue: IgnitePdsEvictionTest.testPageEviction Key: IGNITE-7686 URL: https://issues.apache.org/jira/browse/IGNITE-7686 Project: Ignite Issue Type: Bug Components: persistence Reporter: Dmitriy Pavlov Assignee: Dmitriy Pavlov Fix For: 2.5 java.util.concurrent.TimeoutException: Test has been timed out [test=testPageEviction, timeout=30] Reproduced only on TC agent -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-7652) ContinuousQueryWithTransformer example
[ https://issues.apache.org/jira/browse/IGNITE-7652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16362282#comment-16362282 ] Nikolay Izhikov edited comment on IGNITE-7652 at 2/13/18 1:07 PM: -- [~dmagda] Can you, please, review my changes created in this ticket? It a relatively small(100 loc) example of usage of new CQWT API. TC looks good - https://ci.ignite.apache.org/viewLog.html?buildId=1089937&tab=queuedBuildOverviewTab was (Author: nizhikov): [~dmagda] Can you, please, review my changes created in this ticket? It a relatively small(100 loc) example of usage of new CQWT API. > ContinuousQueryWithTransformer example > -- > > Key: IGNITE-7652 > URL: https://issues.apache.org/jira/browse/IGNITE-7652 > Project: Ignite > Issue Type: Improvement > Components: cache >Affects Versions: 2.5 >Reporter: Nikolay Izhikov >Assignee: Nikolay Izhikov >Priority: Major > Fix For: 2.5 > > > Need to create example for a ContinuousQueryWithTransformer. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7652) ContinuousQueryWithTransformer example
[ https://issues.apache.org/jira/browse/IGNITE-7652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16362282#comment-16362282 ] Nikolay Izhikov commented on IGNITE-7652: - [~dmagda] Can you, please, review my changes created in this ticket? It a relatively small(100 loc) example of usage of new CQWT API. > ContinuousQueryWithTransformer example > -- > > Key: IGNITE-7652 > URL: https://issues.apache.org/jira/browse/IGNITE-7652 > Project: Ignite > Issue Type: Improvement > Components: cache >Affects Versions: 2.5 >Reporter: Nikolay Izhikov >Assignee: Nikolay Izhikov >Priority: Major > Fix For: 2.5 > > > Need to create example for a ContinuousQueryWithTransformer. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-7686) PDS Direct IO failure: IgnitePdsEvictionTest.testPageEviction
[ https://issues.apache.org/jira/browse/IGNITE-7686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-7686: --- Summary: PDS Direct IO failure: IgnitePdsEvictionTest.testPageEviction (was: PDS Direct IO failue: IgnitePdsEvictionTest.testPageEviction ) > PDS Direct IO failure: IgnitePdsEvictionTest.testPageEviction > -- > > Key: IGNITE-7686 > URL: https://issues.apache.org/jira/browse/IGNITE-7686 > Project: Ignite > Issue Type: Bug > Components: persistence >Reporter: Dmitriy Pavlov >Assignee: Dmitriy Pavlov >Priority: Major > Labels: MakeTeamcityGreenAgain > Fix For: 2.5 > > > java.util.concurrent.TimeoutException: Test has been timed out > [test=testPageEviction, timeout=30] > Reproduced only on TC agent -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-7686) PDS Direct IO failure: IgnitePdsEvictionTest.testPageEviction
[ https://issues.apache.org/jira/browse/IGNITE-7686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-7686: --- Description: java.util.concurrent.TimeoutException: Test has been timed out [test=testPageEviction, timeout=30] Reproduced only on TC agent https://ci.ignite.apache.org/viewLog.html?buildId=1090347&tab=buildResultsDiv&buildTypeId=IgniteTests24Java8_IgnitePds1DirectIo#testNameId3144891032708936796 was: java.util.concurrent.TimeoutException: Test has been timed out [test=testPageEviction, timeout=30] Reproduced only on TC agent > PDS Direct IO failure: IgnitePdsEvictionTest.testPageEviction > -- > > Key: IGNITE-7686 > URL: https://issues.apache.org/jira/browse/IGNITE-7686 > Project: Ignite > Issue Type: Bug > Components: persistence >Reporter: Dmitriy Pavlov >Assignee: Dmitriy Pavlov >Priority: Major > Labels: MakeTeamcityGreenAgain > Fix For: 2.5 > > > java.util.concurrent.TimeoutException: Test has been timed out > [test=testPageEviction, timeout=30] > Reproduced only on TC agent > https://ci.ignite.apache.org/viewLog.html?buildId=1090347&tab=buildResultsDiv&buildTypeId=IgniteTests24Java8_IgnitePds1DirectIo#testNameId3144891032708936796 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7684) Ignore IGNITE_USE_ASYNC_FILE_IO_FACTORY in FileWriteAheadLogManager
[ https://issues.apache.org/jira/browse/IGNITE-7684?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16362321#comment-16362321 ] Dmitriy Pavlov commented on IGNITE-7684: It seems it was already fixed for master. WAL ignores factory now. > Ignore IGNITE_USE_ASYNC_FILE_IO_FACTORY in FileWriteAheadLogManager > --- > > Key: IGNITE-7684 > URL: https://issues.apache.org/jira/browse/IGNITE-7684 > Project: Ignite > Issue Type: Improvement > Components: general >Affects Versions: 2.4 >Reporter: Alexander Belyak >Priority: Major > > If IGNITE_USE_ASYNC_FILE_IO_FACTORY specified and no IGNITE_WAL_MMAP we get: > {noformat} > java.lang.UnsupportedOperationException: AsynchronousFileChannel doesn't > support mmap. > at > org.apache.ignite.internal.processors.cache.persistence.file.AsyncFileIO.map(AsyncFileIO.java:173) > > at > org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.restoreWriteHandle(FileWriteAheadLogManager.java:1068) > > at > org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.resumeLogging(FileWriteAheadLogManager.java:552) > at > org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.readCheckpointAndRestoreMemory(GridCacheDatabaseSharedManager.java:714) > at > org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onClusterStateChangeRequest(GridDhtPartitionsExchangeFuture.java:841) > at > org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:595) > at > org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2329) > at > org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110) > at java.lang.Thread.run(Thread.java:748) > {noformat} -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-5804) ScanQuery transformer applies to first results page only.
[ https://issues.apache.org/jira/browse/IGNITE-5804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16362333#comment-16362333 ] Dmitriy Pavlov commented on IGNITE-5804: Hi [~slava.koptilin], I've found everal suspicious tests, which never failed in master but failed in PR: Could you check if they are related to current PR changes {noformat} Ignite Cache 4 [ tests 3 ] org.apache.ignite.testsuites.IgniteCacheTestSuite4: org.apache.ignite.internal.processors.cache.CacheGetEntryPessimisticReadCommittedSeltTest.testReplicatedTransactional (fail rate 0%) org.apache.ignite.testsuites.IgniteCacheTestSuite4: org.apache.ignite.internal.processors.cache.CacheGetEntryPessimisticRepeatableReadSeltTest.testNearTransactional (fail rate 0%) org.apache.ignite.testsuites.IgniteCacheTestSuite4: org.apache.ignite.internal.processors.cache.CacheGetEntryPessimisticRepeatableReadSeltTest.testReplicatedTransactional (fail rate 0%) Ignite Cache 2 [ tests 2 ] org.apache.ignite.testsuites.IgniteCacheTestSuite2: org.apache.ignite.internal.processors.cache.distributed.near.GridCachePartitionedTxSingleThreadedSelfTest.testOptimisticReadCommittedCommit (fail rate 0%) org.apache.ignite.testsuites.IgniteCacheTestSuite2: org.apache.ignite.internal.processors.cache.distributed.near.GridCachePartitionedTxSingleThreadedSelfTest.testOptimisticRepeatableReadRollback (fail rate 0%) Ignite Cache Tx Recovery [ tests 1 ] org.apache.ignite.testsuites.IgniteCacheTxRecoverySelfTestSuite: org.apache.ignite.internal.processors.cache.distributed.dht.TxRecoveryStoreEnabledTest.testPessimistic (fail rate 0%) {noformat} > ScanQuery transformer applies to first results page only. > - > > Key: IGNITE-5804 > URL: https://issues.apache.org/jira/browse/IGNITE-5804 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 1.9 >Reporter: Andrew Mashenkov >Assignee: Vyacheslav Koptilin >Priority: Major > Fix For: 2.5 > > > Issue is successfully reproduces on GridCacheQueryTransformerSelfTest if > set ScanQuery.pageSize much lower then cache size. > We should rework GridCacheQueryTransformerSelfTest to run test on larger > dataset > to make pagination used as well. > http://apache-ignite-users.70518.x6.nabble.com/Transformer-not-called-on-every-ScanQuery-td15171.html -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7653) Merge test suites into SQL tests or delete
[ https://issues.apache.org/jira/browse/IGNITE-7653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16362341#comment-16362341 ] Dmitriy Pavlov commented on IGNITE-7653: Probably we need also remove IgniteTests24Java8_IgniteIgfsExamples. Suite is failed with no examples, {noformat} AssertionFailedError: No tests found in org.apache.ignite.examples.IgfsExamplesSelfTest {noformat} but this suite seems to be included into Examples suite. Probably need additional approve from [~vozerov] > Merge test suites into SQL tests or delete > -- > > Key: IGNITE-7653 > URL: https://issues.apache.org/jira/browse/IGNITE-7653 > Project: Ignite > Issue Type: Bug >Reporter: Eduard Shangareev >Assignee: Peter Ivanov >Priority: Major > Labels: MakeTeamcityGreenAgain > > JSR-310 Java 8 Date and Time API Queries & Ignite Spring3 > does not execute any tests -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7682) C++: LocalSize cache functions
[ https://issues.apache.org/jira/browse/IGNITE-7682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16362343#comment-16362343 ] Igor Sapego commented on IGNITE-7682: - [~Roman_BRR], what about Java API? Does it behave the same? > C++: LocalSize cache functions > -- > > Key: IGNITE-7682 > URL: https://issues.apache.org/jira/browse/IGNITE-7682 > Project: Ignite > Issue Type: Bug > Components: platforms > Environment: Ignite builded by jdk1.8.0_152 with sources > tag:ignite-2.3 > cpp libs builded by Microsoft Visual Studio Enterprise 2015 Version > 14.0.25431.01 Update 3 > all x64 >Reporter: Roman Bastanov >Priority: Major > > LocalSize functions with all variations of CachePeekMode returns same results. > They always returns all cache size, the sum of all node caches. > {code} > auto cache = IgniteNode.GetCache<...>(cache_name); > cache.LocalSize(ignite::cache::CachePeekMode::BACKUP) > cache.LocalSize(ignite::cache::CachePeekMode::NEAR_CACHE) > cache.LocalSize(ignite::cache::CachePeekMode::OFFHEAP) > cache.LocalSize(ignite::cache::CachePeekMode::ONHEAP) > cache.LocalSize(ignite::cache::CachePeekMode::PRIMARY) > cache.LocalSize(ignite::cache::CachePeekMode::SWAP) > {code} > Despite this, manually calculations are correct, and returns local size(cache > on this node). > {code} > auto query = cache::query::ScanQuery(); > query.SetLocal(true); > auto cursor = cache.Query(query); > while (cursor.HasNext()) { > cache_size++; > }{code} -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-7687) SQL SELECT doesn't update TTL for Touched/AccessedExpiryPolicy
Stanislav Lukyanov created IGNITE-7687: -- Summary: SQL SELECT doesn't update TTL for Touched/AccessedExpiryPolicy Key: IGNITE-7687 URL: https://issues.apache.org/jira/browse/IGNITE-7687 Project: Ignite Issue Type: Bug Components: sql Affects Versions: 2.5 Reporter: Stanislav Lukyanov SQL SELECT queries don't update TTLs when TouchedExpiryPolicy or AccessedExpiryPolicy is used (unlike IgniteCache::get which does update the TTLs). Example (modified SqlDmlExample): CacheConfiguration orgCacheCfg = new CacheConfiguration(ORG_CACHE) .setIndexedTypes(Long.class, Organization.class) .setExpiryPolicyFactory(TouchedExpiryPolicy.factoryOf(new Duration(TimeUnit.SECONDS, 10))); IgniteCache orgCache = ignite.getOrCreateCache(orgCacheCfg); SqlFieldsQuery qry = new SqlFieldsQuery("insert into Organization (_key, id, name) values (?, ?, ?)"); orgCache.query(qry.setArgs(1L, 1L, "ASF")); orgCache.query(qry.setArgs(2L, 2L, "Eclipse")); SqlFieldsQuery qry1 = new SqlFieldsQuery("select id, name from Organization as o"); for (int i = 0; ;i++) { List> res = orgCache.query(qry1).getAll(); print("i = " + i); for (Object next : res) System.out.println(">>> " + next); U.sleep(5000); } Output: >>> i = 0 >>> [1, ASF] >>> [2, Eclipse] >>> i = 1 >>> [1, ASF] >>> [2, Eclipse] >>> i = 2 >>> i = 3 ... -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-1948) ClusterTopologyCheckedException can return null for retryReadyFuture()
[ https://issues.apache.org/jira/browse/IGNITE-1948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Menshikov reassigned IGNITE-1948: --- Assignee: (was: Alexander Menshikov) > ClusterTopologyCheckedException can return null for retryReadyFuture() > -- > > Key: IGNITE-1948 > URL: https://issues.apache.org/jira/browse/IGNITE-1948 > Project: Ignite > Issue Type: Bug > Components: general >Reporter: Denis Magda >Priority: Major > > It was noted that {{ClusterTopologyCheckedException}} ready future can be > null. > Go though all the places where this kind of exception is being initialized > and check why the ready future is not set in some cases. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-1948) ClusterTopologyCheckedException can return null for retryReadyFuture()
[ https://issues.apache.org/jira/browse/IGNITE-1948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16362354#comment-16362354 ] Alexander Menshikov commented on IGNITE-1948: - I guess some one else can try to fix it in future. > ClusterTopologyCheckedException can return null for retryReadyFuture() > -- > > Key: IGNITE-1948 > URL: https://issues.apache.org/jira/browse/IGNITE-1948 > Project: Ignite > Issue Type: Bug > Components: general >Reporter: Denis Magda >Priority: Major > > It was noted that {{ClusterTopologyCheckedException}} ready future can be > null. > Go though all the places where this kind of exception is being initialized > and check why the ready future is not set in some cases. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-4365) Data grid in deadlock on stop
[ https://issues.apache.org/jira/browse/IGNITE-4365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Menshikov reassigned IGNITE-4365: --- Assignee: (was: Alexander Menshikov) > Data grid in deadlock on stop > - > > Key: IGNITE-4365 > URL: https://issues.apache.org/jira/browse/IGNITE-4365 > Project: Ignite > Issue Type: Bug > Components: cache >Reporter: Yakov Zhdanov >Priority: Major > Labels: busylock, gateway, performance > Attachments: thread-dump.txt > > > Attached is the threaddump describing the problem. > # several public threads wait for new cache topology version > # onExchangeFinish() tries to stop the gateway, but cannot do it due to > public threads waiting inside the GW. > # grid stopping thread waits for job requests to complete -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-4501) Improvement of connection in a cluster of new node
[ https://issues.apache.org/jira/browse/IGNITE-4501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Menshikov reassigned IGNITE-4501: --- Assignee: (was: Alexander Menshikov) > Improvement of connection in a cluster of new node > -- > > Key: IGNITE-4501 > URL: https://issues.apache.org/jira/browse/IGNITE-4501 > Project: Ignite > Issue Type: Improvement > Components: messaging >Affects Versions: 1.8 >Reporter: Vyacheslav Daradur >Priority: Major > Labels: important > > h3. Main description: > Cluster nodes connect a ring. > For example: we have 6 nodes: A, B, C, D, E, F. > They can connect a ring in any possible way: A-B-C-D-E-F-A, or A-F-B-E-C-D-A, > etc. > If some node leaves topology, adjacent nodes must reconnect. > If nodes A, B, C are in same physical place, nodes D, E, F are in other > place, and places lost connect each other, we will have many ways of > reconnections. > At best case, if we had a ring: A-B-CxD-E-FxA ('x' means disconnect) -- then > we have only one reconnect (C > will be connected to A or F will be connected to D -- depends on what part of > the cluster was alive. > Also, if we had a not ring: AxFxBxExCxDxA -- then we have a lot of > reconnections (A to B, B to C, C to A -- in general n/2 reconnections, where > n -- number of nodes). > h3. Approach: > It is necessary to develop approach of node insertion to the correct place > for creation of the correct ring-topology. > h3. Solutions: > Main idea is a sorting according to latency. > * group nodes in arcs on an ARC_ID. (manualy?) > * implement NodeComparator (nodes on the same host : nodes on the same subnet > : other nodes). We will use it when we connect a new node. > * [dev list > thread|http://mail-archives.apache.org/mod_mbox/ignite-dev/201612.mbox/%3CCAN+WSNyWYXSXEBpGErVt72zTgi2pTQzUWLv8JY=ke83-5-r...@mail.gmail.com%3E] > Update Dec, 29 Yakov Zhdanov: > # introduce CLUSTER_REGION_ID node attribute. This can be done by adding > public static final constant to TcpDiscoverySpi. > # Alter > org.apache.ignite.spi.discovery.tcp.internal.TcpDiscoveryNodesRing#nextNode(java.util.Collection) > to order basing on per node attribute value > # Node comparison should be stable and consistent. E.g. if CLUSTER_REGION_IDs > are equal then we should compare nodes' IDs. This way we have consistent > order on all nodes in topology. > # Also nextNode() has to group nodes on same host and in same subnet. This > can be postponed and implemented after we have other points done. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-603) [Test] GridP2PMissedResourceCacheSizeSelfTest has commented tests
[ https://issues.apache.org/jira/browse/IGNITE-603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Menshikov reassigned IGNITE-603: -- Assignee: (was: Alexander Menshikov) > [Test] GridP2PMissedResourceCacheSizeSelfTest has commented tests > - > > Key: IGNITE-603 > URL: https://issues.apache.org/jira/browse/IGNITE-603 > Project: Ignite > Issue Type: Bug >Reporter: Artem Shutak >Priority: Major > Labels: Muted_test > Attachments: testSize2ContinuousMode.txt, testSize2IsolatedMode.txt, > testSize2PrivateMode.txt, testSize2SharedMode.txt > > > Test have to be uncommented and fixed or the commented code have to be > removed. > See comments at GG-3804. > Update at 2/3/17. > API has changed. So if we add initialization of "ignite" field to > GridP2PEventFilterExternalPath1 and GridP2PEventFilterExternalPath2 and > uncomments tests you can get result like in attached file. > testSize2IsolatedMode and testSize2PrivateMode tests don't fail. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-7688) DDL does not working properly on sql queries.
Muratcan TUKSAL created IGNITE-7688: --- Summary: DDL does not working properly on sql queries. Key: IGNITE-7688 URL: https://issues.apache.org/jira/browse/IGNITE-7688 Project: Ignite Issue Type: Bug Components: 2.3 Affects Versions: 2.3 Environment: we have 5 node running on Ubuntu 16.04(VM). we donwloaded binary dist. from download page. Reporter: Muratcan TUKSAL Attachments: buggy-config.xml * start ignite cluster persistent enabled mode (tried on 5 node) * activate cluster via ignitevisor * Create a table through jdbc * kill all nodes * start all nodes again * activate cluster via ignitevisor * drop that specific table * deactivate cluster(doesnt matter via top -deactivate or kill all nodes) * activate cluster * dropped table still there with no data -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-7689) IgnitePdsBinaryMetadataOnClusterRestartTest flaky fails on TC
Alexey Goncharuk created IGNITE-7689: Summary: IgnitePdsBinaryMetadataOnClusterRestartTest flaky fails on TC Key: IGNITE-7689 URL: https://issues.apache.org/jira/browse/IGNITE-7689 Project: Ignite Issue Type: Test Reporter: Alexey Goncharuk -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-7689) IgnitePdsBinaryMetadataOnClusterRestartTest flaky fails on TC
[ https://issues.apache.org/jira/browse/IGNITE-7689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk reassigned IGNITE-7689: Assignee: Alexey Goncharuk > IgnitePdsBinaryMetadataOnClusterRestartTest flaky fails on TC > - > > Key: IGNITE-7689 > URL: https://issues.apache.org/jira/browse/IGNITE-7689 > Project: Ignite > Issue Type: Test >Reporter: Alexey Goncharuk >Assignee: Alexey Goncharuk >Priority: Major > Labels: MakeTeamcityGreenAgain > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7660) Refactor LSQR algorithm
[ https://issues.apache.org/jira/browse/IGNITE-7660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16362405#comment-16362405 ] Boran Sahindal commented on IGNITE-7660: We, 5 students, as a part of our software engineering course, are planning to work on this issue. I would like to know if any work has been done since the issues creation that is not mentioned here. > Refactor LSQR algorithm > --- > > Key: IGNITE-7660 > URL: https://issues.apache.org/jira/browse/IGNITE-7660 > Project: Ignite > Issue Type: Improvement > Components: ml >Reporter: Anton Dmitriev >Priority: Minor > > We need to refactor LSQR algorithm > (`org.apache.ignite.ml.math.isolve.lsqr.AbstractLSQR`) to be more "Java". > Currently it's adopted Python/Fortran code. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7632) NPE in IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.updateIgfsMetrics()
[ https://issues.apache.org/jira/browse/IGNITE-7632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16362451#comment-16362451 ] Dmitriy Pavlov commented on IGNITE-7632: Hi [~pvinokurov], why did you use basic tests subset? It is required to run-all tests, basic do not cover this code. > NPE in IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.updateIgfsMetrics() > --- > > Key: IGNITE-7632 > URL: https://issues.apache.org/jira/browse/IGNITE-7632 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.3 >Reporter: Alexandr Kuramshin >Assignee: Pavel Vinokurov >Priority: Major > > Occurs on destroying cache while rebuilding indices in progress > {noformat} > Partition eviction failed, this can cause grid hang. > java.lang.NullPointerException: null > at > org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.updateIgfsMetrics(IgniteCacheOffheapManagerImpl.java:1576) > at > org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.finishRemove(IgniteCacheOffheapManagerImpl.java:1403) > at > org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.remove(IgniteCacheOffheapManagerImpl.java:1368) > at > org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.remove(GridCacheOffheapManager.java:1312) > at > org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.remove(IgniteCacheOffheapManagerImpl.java:368) > at > org.apache.ignite.internal.processors.cache.GridCacheMapEntry.removeValue(GridCacheMapEntry.java:3224) > at > org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheEntry.clearInternal(GridDhtCacheEntry.java:588) > at > org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLocalPartition.clearAll(GridDhtLocalPartition.java:895) > at > org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLocalPartition.tryEvict(GridDhtLocalPartition.java:753) > at > org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPreloader$3.call(GridDhtPreloader.java:593) > at > org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPreloader$3.call(GridDhtPreloader.java:580) > at > org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:6639) > at > org.apache.ignite.internal.processors.closure.GridClosureProcessor$2.body(GridClosureProcessor.java:967) > ... > {noformat} -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-7640) Refactor DiscoveryDataClusterState to be immutable
[ https://issues.apache.org/jira/browse/IGNITE-7640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Menshikov reassigned IGNITE-7640: --- Assignee: Alexander Menshikov > Refactor DiscoveryDataClusterState to be immutable > -- > > Key: IGNITE-7640 > URL: https://issues.apache.org/jira/browse/IGNITE-7640 > Project: Ignite > Issue Type: Improvement > Components: cache >Affects Versions: 2.4 >Reporter: Alexey Goncharuk >Assignee: Alexander Menshikov >Priority: Major > Fix For: 2.5 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7481) Suspended transaction rollbacs incorrectly
[ https://issues.apache.org/jira/browse/IGNITE-7481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16362471#comment-16362471 ] ASF GitHub Bot commented on IGNITE-7481: GitHub user voipp opened a pull request: https://github.com/apache/ignite/pull/3514 IGNITE-7481 suspended tx timeout rollback fix You can merge this pull request into a Git repository by running: $ git pull https://github.com/voipp/ignite IGNITE-7481 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/3514.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #3514 commit ef84639e627b3a7060da960dd61c21a6ffebdbf1 Author: voipp Date: 2018-02-13T15:15:00Z IGNITE-7481 suspended tx timeout rollback fix > Suspended transaction rollbacs incorrectly > > > Key: IGNITE-7481 > URL: https://issues.apache.org/jira/browse/IGNITE-7481 > Project: Ignite > Issue Type: Bug >Reporter: Alexey Kuznetsov >Assignee: Alexey Kuznetsov >Priority: Major > > When we suspend transaction, and then timeout occures , transaction would be > rollbacked incorrectly. > One of incorrect behaviors : rollback\end tx metrics are not incremented. > Thre reason is that transactionMap is cleared when we suspend transaction. > We need not clear transactionMap. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-7690) Move shared memory suite (IpcSharedMemoryCrashDetectionSelfTest) to Ignite Basic 2
Dmitriy Pavlov created IGNITE-7690: -- Summary: Move shared memory suite (IpcSharedMemoryCrashDetectionSelfTest) to Ignite Basic 2 Key: IGNITE-7690 URL: https://issues.apache.org/jira/browse/IGNITE-7690 Project: Ignite Issue Type: Task Reporter: Dmitriy Pavlov Assignee: Ivan Rakov Test is flaky but included into basic (stable) suite Ignite Basic [ tests 1 ] i org.apache.ignite.testsuites.IgniteBasicTestSuite: org.apache.ignite.internal.util.ipc.shmem.IpcSharedMemoryCrashDetectionSelfTest.testIgfsServerClientInteractionsUponClientKilling (fail rate 2%) https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=-2464527718752484555&branch=%3Cdefault%3E&tab=testDetails It is better to move this test to basic 2 suite - place for flaky and long running tests. It is also desired to introduce IgniteBasic2 suite in code with correct comments on purpose -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-7691) Provide info about DECIMAL column scale and precision
Nikolay Izhikov created IGNITE-7691: --- Summary: Provide info about DECIMAL column scale and precision Key: IGNITE-7691 URL: https://issues.apache.org/jira/browse/IGNITE-7691 Project: Ignite Issue Type: Improvement Components: sql Affects Versions: 2.4 Reporter: Nikolay Izhikov Assignee: Nikolay Izhikov Fix For: 2.5 Currently, it impossible to obtain scale and precision of DECIMAL column from sql table metadata. Ignite should provide those type of meta information. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-7692) affinityCall and affinityRun may execute code on backup partitions
[ https://issues.apache.org/jira/browse/IGNITE-7692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-7692: - Labels: usability (was: ) > affinityCall and affinityRun may execute code on backup partitions > -- > > Key: IGNITE-7692 > URL: https://issues.apache.org/jira/browse/IGNITE-7692 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.1 >Reporter: Alexey Goncharuk >Priority: Major > Labels: usability > Fix For: 2.5 > > > Apparently, the affinityCall and affinityRun methods reserve partitions and > check their state to be OWNING, however, if topology changes and partition > role is changed to backup from primary, the code is still executed. > This can be an issue if a user executes a local SQL query inside the > affinityCall runnable. In this case, the query result may return null. > This can be observed in the > IgniteCacheLockPartitionOnAffinityRunTest#getPersonsCountSingleCache - note > an additional check I've added to make the test pass. > I think it is ok to have an old semantics for the API, because in some cases > (scan query, local gets) a backup OWNER is enough. However, it looks like we > need to add another API method to enforce that affinity run be executed on > primary nodes and forbid primary role change. > Another option is to detect a topology version of the affinity run and use > that version for local SQL queries. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-7692) affinityCall and affinityRun may execute code on backup partitions
Alexey Goncharuk created IGNITE-7692: Summary: affinityCall and affinityRun may execute code on backup partitions Key: IGNITE-7692 URL: https://issues.apache.org/jira/browse/IGNITE-7692 Project: Ignite Issue Type: Bug Affects Versions: 2.1 Reporter: Alexey Goncharuk Fix For: 2.5 Apparently, the affinityCall and affinityRun methods reserve partitions and check their state to be OWNING, however, if topology changes and partition role is changed to backup from primary, the code is still executed. This can be an issue if a user executes a local SQL query inside the affinityCall runnable. In this case, the query result may return null. This can be observed in the IgniteCacheLockPartitionOnAffinityRunTest#getPersonsCountSingleCache - note an additional check I've added to make the test pass. I think it is ok to have an old semantics for the API, because in some cases (scan query, local gets) a backup OWNER is enough. However, it looks like we need to add another API method to enforce that affinity run be executed on primary nodes and forbid primary role change. Another option is to detect a topology version of the affinity run and use that version for local SQL queries. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-7692) affinityCall and affinityRun may execute code on backup partitions
[ https://issues.apache.org/jira/browse/IGNITE-7692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-7692: - Component/s: sql > affinityCall and affinityRun may execute code on backup partitions > -- > > Key: IGNITE-7692 > URL: https://issues.apache.org/jira/browse/IGNITE-7692 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.1 >Reporter: Alexey Goncharuk >Priority: Major > Labels: usability > Fix For: 2.5 > > > Apparently, the affinityCall and affinityRun methods reserve partitions and > check their state to be OWNING, however, if topology changes and partition > role is changed to backup from primary, the code is still executed. > This can be an issue if a user executes a local SQL query inside the > affinityCall runnable. In this case, the query result may return null. > This can be observed in the > IgniteCacheLockPartitionOnAffinityRunTest#getPersonsCountSingleCache - note > an additional check I've added to make the test pass. > I think it is ok to have an old semantics for the API, because in some cases > (scan query, local gets) a backup OWNER is enough. However, it looks like we > need to add another API method to enforce that affinity run be executed on > primary nodes and forbid primary role change. > Another option is to detect a topology version of the affinity run and use > that version for local SQL queries. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7090) Semaphore Stuck when no acquirers to assign permit
[ https://issues.apache.org/jira/browse/IGNITE-7090?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16362555#comment-16362555 ] Tim Onyschak commented on IGNITE-7090: -- [~vladisav] code has been updated, sorry for so many iteration. Let me know if i finally have it right. Thanks > Semaphore Stuck when no acquirers to assign permit > -- > > Key: IGNITE-7090 > URL: https://issues.apache.org/jira/browse/IGNITE-7090 > Project: Ignite > Issue Type: Bug > Components: cache, data structures >Affects Versions: 2.1, 2.4 >Reporter: Tim Onyschak >Assignee: Tim Onyschak >Priority: Major > Fix For: 2.5 > > Attachments: SemaphoreFailoverNoWaitingAcquirerTest.java > > > If no acquirers are available to take permit of semaphore, the permit never > gets release and any further acquirerers will wait forever. > On node shut down DataStructuresProcessor.dsMap gets cleared out prior to > event listener being able to execute onNodeRemoved, hence owner is never > cleared out if it was unable to pass to a different acquirer. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-7693) New node joining via ZookeeperDiscoverySpi should print out its ZooKeeper sessionId
[ https://issues.apache.org/jira/browse/IGNITE-7693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Chugunov updated IGNITE-7693: Fix Version/s: 2.5 > New node joining via ZookeeperDiscoverySpi should print out its ZooKeeper > sessionId > --- > > Key: IGNITE-7693 > URL: https://issues.apache.org/jira/browse/IGNITE-7693 > Project: Ignite > Issue Type: Improvement >Reporter: Sergey Chugunov >Priority: Major > Fix For: 2.5 > > > For now there is no way to match Ignite nodes joining to Ignite cluster with > log entries in ZooKeeper nodes' logs. > In ZooKeeper logs there are entries like this: > {noformat} > myid:1] - INFO [CommitProcessor:1:ZooKeeperServer@687] - Established session > 0x161575d88530007 with negotiated timeout 1 for client > /:{noformat} > but it is hard to match them with Ignite nodes when there are several started > on the same host. > If Ignite node prints out its session on join it makes correlating them with > particular ZooKeeper instance much easier. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-7693) New node joining via ZookeeperDiscoverySpi should print out its ZooKeeper sessionId
Sergey Chugunov created IGNITE-7693: --- Summary: New node joining via ZookeeperDiscoverySpi should print out its ZooKeeper sessionId Key: IGNITE-7693 URL: https://issues.apache.org/jira/browse/IGNITE-7693 Project: Ignite Issue Type: Improvement Reporter: Sergey Chugunov For now there is no way to match Ignite nodes joining to Ignite cluster with log entries in ZooKeeper nodes' logs. In ZooKeeper logs there are entries like this: {noformat} myid:1] - INFO [CommitProcessor:1:ZooKeeperServer@687] - Established session 0x161575d88530007 with negotiated timeout 1 for client /:{noformat} but it is hard to match them with Ignite nodes when there are several started on the same host. If Ignite node prints out its session on join it makes correlating them with particular ZooKeeper instance much easier. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-6890) General way for handling Ignite failures
[ https://issues.apache.org/jira/browse/IGNITE-6890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16362581#comment-16362581 ] Anton Vinogradov commented on IGNITE-6890: -- [~cyberdemon], We should not map case NOOP: return NOOP; Instead of doing this onSegmentation should call IgniteFailureProcessor -> restartJvm or stopNode directly with correct reason (IgniteFailureType) > General way for handling Ignite failures > > > Key: IGNITE-6890 > URL: https://issues.apache.org/jira/browse/IGNITE-6890 > Project: Ignite > Issue Type: Improvement >Reporter: Anton Vinogradov >Assignee: Dmitriy Sorokin >Priority: Major > Labels: iep-7 > Fix For: 2.5 > > > Ignite failures which should be handled are: > # Topology segmentation; > # Exchange worker stop; > # Persistence errors. > Proper behavior should be selected according to result of calling > IgniteFailureHandler instance, custom implementation of which can be provided > in IgniteConfiguration. It can be node stop, restart or nothing. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7686) PDS Direct IO failure: IgnitePdsEvictionTest.testPageEviction
[ https://issues.apache.org/jira/browse/IGNITE-7686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16362586#comment-16362586 ] Dmitriy Pavlov commented on IGNITE-7686: https://github.com/apache/ignite/pull/3511 > PDS Direct IO failure: IgnitePdsEvictionTest.testPageEviction > -- > > Key: IGNITE-7686 > URL: https://issues.apache.org/jira/browse/IGNITE-7686 > Project: Ignite > Issue Type: Bug > Components: persistence >Reporter: Dmitriy Pavlov >Assignee: Dmitriy Pavlov >Priority: Major > Labels: MakeTeamcityGreenAgain > Fix For: 2.5 > > > java.util.concurrent.TimeoutException: Test has been timed out > [test=testPageEviction, timeout=30] > Reproduced only on TC agent > https://ci.ignite.apache.org/viewLog.html?buildId=1090347&tab=buildResultsDiv&buildTypeId=IgniteTests24Java8_IgnitePds1DirectIo#testNameId3144891032708936796 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7660) Refactor LSQR algorithm
[ https://issues.apache.org/jira/browse/IGNITE-7660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16362592#comment-16362592 ] Anton Dmitriev commented on IGNITE-7660: Hello. As far as I know nothing has been done regarding this issue and it will be great if you start working on it. > Refactor LSQR algorithm > --- > > Key: IGNITE-7660 > URL: https://issues.apache.org/jira/browse/IGNITE-7660 > Project: Ignite > Issue Type: Improvement > Components: ml >Reporter: Anton Dmitriev >Priority: Minor > > We need to refactor LSQR algorithm > (`org.apache.ignite.ml.math.isolve.lsqr.AbstractLSQR`) to be more "Java". > Currently it's adopted Python/Fortran code. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-7694) testActiveClientReconnectToInactiveCluster hangs because of an assertion
Alexey Goncharuk created IGNITE-7694: Summary: testActiveClientReconnectToInactiveCluster hangs because of an assertion Key: IGNITE-7694 URL: https://issues.apache.org/jira/browse/IGNITE-7694 Project: Ignite Issue Type: Bug Reporter: Alexey Goncharuk -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-7694) testActiveClientReconnectToInactiveCluster hangs because of an assertion
[ https://issues.apache.org/jira/browse/IGNITE-7694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-7694: - Component/s: persistence > testActiveClientReconnectToInactiveCluster hangs because of an assertion > > > Key: IGNITE-7694 > URL: https://issues.apache.org/jira/browse/IGNITE-7694 > Project: Ignite > Issue Type: Bug > Components: persistence >Affects Versions: 2.5 >Reporter: Alexey Goncharuk >Priority: Major > Fix For: 2.5 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-7694) testActiveClientReconnectToInactiveCluster hangs because of an assertion
[ https://issues.apache.org/jira/browse/IGNITE-7694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-7694: - Affects Version/s: 2.5 > testActiveClientReconnectToInactiveCluster hangs because of an assertion > > > Key: IGNITE-7694 > URL: https://issues.apache.org/jira/browse/IGNITE-7694 > Project: Ignite > Issue Type: Bug > Components: persistence >Affects Versions: 2.5 >Reporter: Alexey Goncharuk >Priority: Major > Fix For: 2.5 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-7694) testActiveClientReconnectToInactiveCluster hangs because of an assertion
[ https://issues.apache.org/jira/browse/IGNITE-7694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-7694: - Fix Version/s: 2.5 > testActiveClientReconnectToInactiveCluster hangs because of an assertion > > > Key: IGNITE-7694 > URL: https://issues.apache.org/jira/browse/IGNITE-7694 > Project: Ignite > Issue Type: Bug > Components: persistence >Affects Versions: 2.5 >Reporter: Alexey Goncharuk >Priority: Major > Fix For: 2.5 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-7694) testActiveClientReconnectToInactiveCluster hangs because of an assertion
[ https://issues.apache.org/jira/browse/IGNITE-7694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk reassigned IGNITE-7694: Assignee: Alexey Goncharuk > testActiveClientReconnectToInactiveCluster hangs because of an assertion > > > Key: IGNITE-7694 > URL: https://issues.apache.org/jira/browse/IGNITE-7694 > Project: Ignite > Issue Type: Bug > Components: persistence >Affects Versions: 2.5 >Reporter: Alexey Goncharuk >Assignee: Alexey Goncharuk >Priority: Major > Fix For: 2.5 > > > This is a regression from > The test hangs because there is an assertion happened after the client > reconnects to the cluster: > {code} > [2018-02-13 > 19:36:33,559][ERROR][tcp-client-disco-msg-worker-#18%nodeClient%][TcpDiscoverySpi] > Failed to unmarshal discovery custom message. > java.lang.AssertionError: lastAffVer=AffinityTopologyVersion [topVer=4, > minorTopVer=0], topVer=AffinityTopologyVersion [topVer=3, minorTopVer=1] > at > org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.onDiscoveryEvent(CacheAffinitySharedManager.java:185) > at > org.apache.ignite.internal.processors.cache.GridCacheProcessor.onDiscoveryEvent(GridCacheProcessor.java:3231) > at > org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery0(GridDiscoveryManager.java:681) > at > org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery(GridDiscoveryManager.java:576) > at > org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.notifyDiscovery(ClientImpl.java:2414) > at > org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.processCustomMessage(ClientImpl.java:2320) > at > org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.processDiscoveryMessage(ClientImpl.java:1897) > at > org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.body(ClientImpl.java:1781) > at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62) > {code} > The reason for the assertion is that the client does not clear {{lastAffVer}} > field when disconnected, and cluster is restarted when the client is in the > disconnected state. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7694) testActiveClientReconnectToInactiveCluster hangs because of an assertion
[ https://issues.apache.org/jira/browse/IGNITE-7694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16362611#comment-16362611 ] Alexey Goncharuk commented on IGNITE-7694: -- At the first glance, setting lastAffVer to null in the onDisconnected callback fixes the issue. > testActiveClientReconnectToInactiveCluster hangs because of an assertion > > > Key: IGNITE-7694 > URL: https://issues.apache.org/jira/browse/IGNITE-7694 > Project: Ignite > Issue Type: Bug > Components: persistence >Affects Versions: 2.5 >Reporter: Alexey Goncharuk >Assignee: Alexey Goncharuk >Priority: Major > Fix For: 2.5 > > > This is a regression from > The test hangs because there is an assertion happened after the client > reconnects to the cluster: > {code} > [2018-02-13 > 19:36:33,559][ERROR][tcp-client-disco-msg-worker-#18%nodeClient%][TcpDiscoverySpi] > Failed to unmarshal discovery custom message. > java.lang.AssertionError: lastAffVer=AffinityTopologyVersion [topVer=4, > minorTopVer=0], topVer=AffinityTopologyVersion [topVer=3, minorTopVer=1] > at > org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.onDiscoveryEvent(CacheAffinitySharedManager.java:185) > at > org.apache.ignite.internal.processors.cache.GridCacheProcessor.onDiscoveryEvent(GridCacheProcessor.java:3231) > at > org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery0(GridDiscoveryManager.java:681) > at > org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery(GridDiscoveryManager.java:576) > at > org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.notifyDiscovery(ClientImpl.java:2414) > at > org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.processCustomMessage(ClientImpl.java:2320) > at > org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.processDiscoveryMessage(ClientImpl.java:1897) > at > org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.body(ClientImpl.java:1781) > at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62) > {code} > The reason for the assertion is that the client does not clear {{lastAffVer}} > field when disconnected, and cluster is restarted when the client is in the > disconnected state. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-7694) testActiveClientReconnectToInactiveCluster hangs because of an assertion
[ https://issues.apache.org/jira/browse/IGNITE-7694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-7694: - Description: This is a regression from The test hangs because there is an assertion happened after the client reconnects to the cluster: {code} [2018-02-13 19:36:33,559][ERROR][tcp-client-disco-msg-worker-#18%nodeClient%][TcpDiscoverySpi] Failed to unmarshal discovery custom message. java.lang.AssertionError: lastAffVer=AffinityTopologyVersion [topVer=4, minorTopVer=0], topVer=AffinityTopologyVersion [topVer=3, minorTopVer=1] at org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.onDiscoveryEvent(CacheAffinitySharedManager.java:185) at org.apache.ignite.internal.processors.cache.GridCacheProcessor.onDiscoveryEvent(GridCacheProcessor.java:3231) at org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery0(GridDiscoveryManager.java:681) at org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery(GridDiscoveryManager.java:576) at org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.notifyDiscovery(ClientImpl.java:2414) at org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.processCustomMessage(ClientImpl.java:2320) at org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.processDiscoveryMessage(ClientImpl.java:1897) at org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.body(ClientImpl.java:1781) at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62) {code} The reason for the assertion is that the client does not clear {{lastAffVer}} field when disconnected, and cluster is restarted when the client is in the disconnected state. > testActiveClientReconnectToInactiveCluster hangs because of an assertion > > > Key: IGNITE-7694 > URL: https://issues.apache.org/jira/browse/IGNITE-7694 > Project: Ignite > Issue Type: Bug > Components: persistence >Affects Versions: 2.5 >Reporter: Alexey Goncharuk >Priority: Major > Fix For: 2.5 > > > This is a regression from > The test hangs because there is an assertion happened after the client > reconnects to the cluster: > {code} > [2018-02-13 > 19:36:33,559][ERROR][tcp-client-disco-msg-worker-#18%nodeClient%][TcpDiscoverySpi] > Failed to unmarshal discovery custom message. > java.lang.AssertionError: lastAffVer=AffinityTopologyVersion [topVer=4, > minorTopVer=0], topVer=AffinityTopologyVersion [topVer=3, minorTopVer=1] > at > org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.onDiscoveryEvent(CacheAffinitySharedManager.java:185) > at > org.apache.ignite.internal.processors.cache.GridCacheProcessor.onDiscoveryEvent(GridCacheProcessor.java:3231) > at > org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery0(GridDiscoveryManager.java:681) > at > org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery(GridDiscoveryManager.java:576) > at > org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.notifyDiscovery(ClientImpl.java:2414) > at > org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.processCustomMessage(ClientImpl.java:2320) > at > org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.processDiscoveryMessage(ClientImpl.java:1897) > at > org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.body(ClientImpl.java:1781) > at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62) > {code} > The reason for the assertion is that the client does not clear {{lastAffVer}} > field when disconnected, and cluster is restarted when the client is in the > disconnected state. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-7694) testActiveClientReconnectToInactiveCluster hangs because of an assertion
[ https://issues.apache.org/jira/browse/IGNITE-7694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-7694: --- Labels: MakeTeamcityGreenAgain (was: ) > testActiveClientReconnectToInactiveCluster hangs because of an assertion > > > Key: IGNITE-7694 > URL: https://issues.apache.org/jira/browse/IGNITE-7694 > Project: Ignite > Issue Type: Bug > Components: persistence >Affects Versions: 2.5 >Reporter: Alexey Goncharuk >Assignee: Alexey Goncharuk >Priority: Major > Labels: MakeTeamcityGreenAgain > Fix For: 2.5 > > > This is a regression from > The test hangs because there is an assertion happened after the client > reconnects to the cluster: > {code} > [2018-02-13 > 19:36:33,559][ERROR][tcp-client-disco-msg-worker-#18%nodeClient%][TcpDiscoverySpi] > Failed to unmarshal discovery custom message. > java.lang.AssertionError: lastAffVer=AffinityTopologyVersion [topVer=4, > minorTopVer=0], topVer=AffinityTopologyVersion [topVer=3, minorTopVer=1] > at > org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.onDiscoveryEvent(CacheAffinitySharedManager.java:185) > at > org.apache.ignite.internal.processors.cache.GridCacheProcessor.onDiscoveryEvent(GridCacheProcessor.java:3231) > at > org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery0(GridDiscoveryManager.java:681) > at > org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery(GridDiscoveryManager.java:576) > at > org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.notifyDiscovery(ClientImpl.java:2414) > at > org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.processCustomMessage(ClientImpl.java:2320) > at > org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.processDiscoveryMessage(ClientImpl.java:1897) > at > org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.body(ClientImpl.java:1781) > at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62) > {code} > The reason for the assertion is that the client does not clear {{lastAffVer}} > field when disconnected, and cluster is restarted when the client is in the > disconnected state. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7640) Refactor DiscoveryDataClusterState to be immutable
[ https://issues.apache.org/jira/browse/IGNITE-7640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16362633#comment-16362633 ] ASF GitHub Bot commented on IGNITE-7640: GitHub user SharplEr opened a pull request: https://github.com/apache/ignite/pull/3515 IGNITE-7640: make DiscoveryDataClusterState immutable for CI testing You can merge this pull request into a Git repository by running: $ git pull https://github.com/SharplEr/ignite ignite-7640 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/3515.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #3515 commit 9a52c8a851006bea1c647f694df8ea398da50595 Author: Alexander Menshikov Date: 2018-02-13T16:15:36Z make DiscoveryDataClusterState immutable > Refactor DiscoveryDataClusterState to be immutable > -- > > Key: IGNITE-7640 > URL: https://issues.apache.org/jira/browse/IGNITE-7640 > Project: Ignite > Issue Type: Improvement > Components: cache >Affects Versions: 2.4 >Reporter: Alexey Goncharuk >Assignee: Alexander Menshikov >Priority: Major > Fix For: 2.5 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-7695) Enable Ignite Update Notifier tests
Dmitriy Pavlov created IGNITE-7695: -- Summary: Enable Ignite Update Notifier tests Key: IGNITE-7695 URL: https://issues.apache.org/jira/browse/IGNITE-7695 Project: Ignite Issue Type: Task Reporter: Dmitriy Pavlov Assignee: Dmitriy Pavlov org.apache.ignite.internal.GridVersionSelfTest#testVersions org.apache.ignite.internal.IgniteUpdateNotifierPerClusterSettingSelfTest#testNotifierEnabledForCluster and unmute on TC -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7695) Enable Ignite Update Notifier tests
[ https://issues.apache.org/jira/browse/IGNITE-7695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16362685#comment-16362685 ] ASF GitHub Bot commented on IGNITE-7695: GitHub user dspavlov opened a pull request: https://github.com/apache/ignite/pull/3516 IGNITE-7695: Enable Ignite Update Notifier tests You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-7695 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/3516.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #3516 commit e2850e2d6116ccdea809bb925aa90cf530e817ee Author: dpavlov Date: 2018-02-13T17:16:51Z IGNITE-7695: Enable Ignite Update Notifier tests > Enable Ignite Update Notifier tests > --- > > Key: IGNITE-7695 > URL: https://issues.apache.org/jira/browse/IGNITE-7695 > Project: Ignite > Issue Type: Task >Reporter: Dmitriy Pavlov >Assignee: Dmitriy Pavlov >Priority: Major > > org.apache.ignite.internal.GridVersionSelfTest#testVersions > org.apache.ignite.internal.IgniteUpdateNotifierPerClusterSettingSelfTest#testNotifierEnabledForCluster > and unmute on TC -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-7695) Enable Ignite Update Notifier tests
[ https://issues.apache.org/jira/browse/IGNITE-7695?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-7695: --- Fix Version/s: 2.5 > Enable Ignite Update Notifier tests > --- > > Key: IGNITE-7695 > URL: https://issues.apache.org/jira/browse/IGNITE-7695 > Project: Ignite > Issue Type: Task >Reporter: Dmitriy Pavlov >Assignee: Dmitriy Pavlov >Priority: Major > Labels: MakeTeamcityGreenAgain > Fix For: 2.5 > > > org.apache.ignite.internal.GridVersionSelfTest#testVersions > org.apache.ignite.internal.IgniteUpdateNotifierPerClusterSettingSelfTest#testNotifierEnabledForCluster > and unmute on TC -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-7695) Enable Ignite Update Notifier tests
[ https://issues.apache.org/jira/browse/IGNITE-7695?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-7695: --- Labels: MakeTeamcityGreenAgain (was: ) > Enable Ignite Update Notifier tests > --- > > Key: IGNITE-7695 > URL: https://issues.apache.org/jira/browse/IGNITE-7695 > Project: Ignite > Issue Type: Task >Reporter: Dmitriy Pavlov >Assignee: Dmitriy Pavlov >Priority: Major > Labels: MakeTeamcityGreenAgain > Fix For: 2.5 > > > org.apache.ignite.internal.GridVersionSelfTest#testVersions > org.apache.ignite.internal.IgniteUpdateNotifierPerClusterSettingSelfTest#testNotifierEnabledForCluster > and unmute on TC -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7695) Enable Ignite Update Notifier tests
[ https://issues.apache.org/jira/browse/IGNITE-7695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16362705#comment-16362705 ] ASF GitHub Bot commented on IGNITE-7695: Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/3516 > Enable Ignite Update Notifier tests > --- > > Key: IGNITE-7695 > URL: https://issues.apache.org/jira/browse/IGNITE-7695 > Project: Ignite > Issue Type: Task >Reporter: Dmitriy Pavlov >Assignee: Dmitriy Pavlov >Priority: Major > Labels: MakeTeamcityGreenAgain > Fix For: 2.5 > > > org.apache.ignite.internal.GridVersionSelfTest#testVersions > org.apache.ignite.internal.IgniteUpdateNotifierPerClusterSettingSelfTest#testNotifierEnabledForCluster > and unmute on TC -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-7574) Ignite Getting Started confuses developers
[ https://issues.apache.org/jira/browse/IGNITE-7574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda reassigned IGNITE-7574: --- Assignee: Prachi Garg (was: Denis Magda) > Ignite Getting Started confuses developers > -- > > Key: IGNITE-7574 > URL: https://issues.apache.org/jira/browse/IGNITE-7574 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Denis Magda >Assignee: Prachi Garg >Priority: Blocker > Fix For: 2.4 > > > By some reason, we suggest to build Ignite from sources at the very beginning > of the getting started guide: > [https://apacheignite.readme.io/docs/getting-started] > I got a feedback that this confuses a lot especially because it's 100% > optional! The reporter wasted much of his time trying to build Ignite with > JDK 9 and could succeed only after a private conversation with me. > > Revisit and rework the guide. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7574) Ignite Getting Started confuses developers
[ https://issues.apache.org/jira/browse/IGNITE-7574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16362718#comment-16362718 ] Denis Magda commented on IGNITE-7574: - [~pgarg] , please review the whole page and close the ticket: https://apacheignite.readme.io/v2.3/docs/getting-started-24 > Ignite Getting Started confuses developers > -- > > Key: IGNITE-7574 > URL: https://issues.apache.org/jira/browse/IGNITE-7574 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Denis Magda >Assignee: Denis Magda >Priority: Blocker > Fix For: 2.4 > > > By some reason, we suggest to build Ignite from sources at the very beginning > of the getting started guide: > [https://apacheignite.readme.io/docs/getting-started] > I got a feedback that this confuses a lot especially because it's 100% > optional! The reporter wasted much of his time trying to build Ignite with > JDK 9 and could succeed only after a private conversation with me. > > Revisit and rework the guide. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7660) Refactor LSQR algorithm
[ https://issues.apache.org/jira/browse/IGNITE-7660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16362818#comment-16362818 ] Boran Sahindal commented on IGNITE-7660: We are starting right away. We would also appriciate a little more detailed description of the issue. We generally understand the concept and the task but we would like to hear your opinions about what parts in the code should be more "Java" - whenever you have time > Refactor LSQR algorithm > --- > > Key: IGNITE-7660 > URL: https://issues.apache.org/jira/browse/IGNITE-7660 > Project: Ignite > Issue Type: Improvement > Components: ml >Reporter: Anton Dmitriev >Priority: Minor > > We need to refactor LSQR algorithm > (`org.apache.ignite.ml.math.isolve.lsqr.AbstractLSQR`) to be more "Java". > Currently it's adopted Python/Fortran code. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-7660) Refactor LSQR algorithm
[ https://issues.apache.org/jira/browse/IGNITE-7660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Dmitriev updated IGNITE-7660: --- Description: This issues is the nest step of the IGNITE-7438 task. In the IGNITE-7438 the AbstractLSQR implementation has been copied from the SciPy implementation which has been copies from another old implementation. As result the code in the [AbstractLSQR|https://github.com/apache/ignite/blob/master/modules/ml/src/main/java/org/apache/ignite/ml/math/isolve/lsqr/AbstractLSQR.java] looks a bit weird. All variables have meaningless names and the whole algorithm written as the one method. The goal of this task is to refactor the LSQR code and: * Make variable names more meaningful. * Add comments to the variables and result (see [LSQRResult|https://github.com/apache/ignite/blob/master/modules/ml/src/main/java/org/apache/ignite/ml/math/isolve/lsqr/LSQRResult.java]). * Move parts of the algorithm into separate methods where it's appropriate. was:We need to refactor LSQR algorithm (`org.apache.ignite.ml.math.isolve.lsqr.AbstractLSQR`) to be more "Java". Currently it's adopted Python/Fortran code. > Refactor LSQR algorithm > --- > > Key: IGNITE-7660 > URL: https://issues.apache.org/jira/browse/IGNITE-7660 > Project: Ignite > Issue Type: Improvement > Components: ml >Reporter: Anton Dmitriev >Priority: Minor > > This issues is the nest step of the IGNITE-7438 task. > In the IGNITE-7438 the AbstractLSQR implementation has been copied from the > SciPy implementation which has been copies from another old implementation. > As result the code in the > [AbstractLSQR|https://github.com/apache/ignite/blob/master/modules/ml/src/main/java/org/apache/ignite/ml/math/isolve/lsqr/AbstractLSQR.java] > looks a bit weird. All variables have meaningless names and the whole > algorithm written as the one method. > The goal of this task is to refactor the LSQR code and: > * Make variable names more meaningful. > * Add comments to the variables and result (see > [LSQRResult|https://github.com/apache/ignite/blob/master/modules/ml/src/main/java/org/apache/ignite/ml/math/isolve/lsqr/LSQRResult.java]). > * Move parts of the algorithm into separate methods where it's appropriate. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7660) Refactor LSQR algorithm
[ https://issues.apache.org/jira/browse/IGNITE-7660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16362851#comment-16362851 ] Anton Dmitriev commented on IGNITE-7660: I've updated description, please take a look. > Refactor LSQR algorithm > --- > > Key: IGNITE-7660 > URL: https://issues.apache.org/jira/browse/IGNITE-7660 > Project: Ignite > Issue Type: Improvement > Components: ml >Reporter: Anton Dmitriev >Priority: Minor > > This issues is the nest step of the IGNITE-7438 task. > In the IGNITE-7438 the AbstractLSQR implementation has been copied from the > SciPy implementation which has been copies from another old implementation. > As result the code in the > [AbstractLSQR|https://github.com/apache/ignite/blob/master/modules/ml/src/main/java/org/apache/ignite/ml/math/isolve/lsqr/AbstractLSQR.java] > looks a bit weird. All variables have meaningless names and the whole > algorithm written as the one method. > The goal of this task is to refactor the LSQR code and: > * Make variable names more meaningful. > * Add comments to the variables and result (see > [LSQRResult|https://github.com/apache/ignite/blob/master/modules/ml/src/main/java/org/apache/ignite/ml/math/isolve/lsqr/LSQRResult.java]). > * Move parts of the algorithm into separate methods where it's appropriate. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (IGNITE-7167) Optimize 'select count(*) from Table'
[ https://issues.apache.org/jira/browse/IGNITE-7167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Valentin Kulichenko closed IGNITE-7167. --- > Optimize 'select count(*) from Table' > - > > Key: IGNITE-7167 > URL: https://issues.apache.org/jira/browse/IGNITE-7167 > Project: Ignite > Issue Type: Improvement > Components: sql >Affects Versions: 2.3 >Reporter: Valentin Kulichenko >Priority: Major > > Currently query like {{select count(*) from Table}} effectively scans the > cache and take a lot of time for large datasets. Probably makes sense to > optimize it to use {{IgniteCache#size}} directly when possible. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-7167) Optimize 'select count(*) from Table'
[ https://issues.apache.org/jira/browse/IGNITE-7167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Valentin Kulichenko resolved IGNITE-7167. - Resolution: Won't Fix (was: Duplicate) > Optimize 'select count(*) from Table' > - > > Key: IGNITE-7167 > URL: https://issues.apache.org/jira/browse/IGNITE-7167 > Project: Ignite > Issue Type: Improvement > Components: sql >Affects Versions: 2.3 >Reporter: Valentin Kulichenko >Priority: Major > > Currently query like {{select count(*) from Table}} effectively scans the > cache and take a lot of time for large datasets. Probably makes sense to > optimize it to use {{IgniteCache#size}} directly when possible. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-7660) Refactor LSQR algorithm
[ https://issues.apache.org/jira/browse/IGNITE-7660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16362851#comment-16362851 ] Anton Dmitriev edited comment on IGNITE-7660 at 2/13/18 6:39 PM: - I've updated the description, please take a look. was (Author: dmitrievanthony): I've updated description, please take a look. > Refactor LSQR algorithm > --- > > Key: IGNITE-7660 > URL: https://issues.apache.org/jira/browse/IGNITE-7660 > Project: Ignite > Issue Type: Improvement > Components: ml >Reporter: Anton Dmitriev >Priority: Minor > > This issues is the nest step of the IGNITE-7438 task. > In the IGNITE-7438 the AbstractLSQR implementation has been copied from the > SciPy implementation which has been copies from another old implementation. > As result the code in the > [AbstractLSQR|https://github.com/apache/ignite/blob/master/modules/ml/src/main/java/org/apache/ignite/ml/math/isolve/lsqr/AbstractLSQR.java] > looks a bit weird. All variables have meaningless names and the whole > algorithm written as the one method. > The goal of this task is to refactor the LSQR code and: > * Make variable names more meaningful. > * Add comments to the variables and result (see > [LSQRResult|https://github.com/apache/ignite/blob/master/modules/ml/src/main/java/org/apache/ignite/ml/math/isolve/lsqr/LSQRResult.java]). > * Move parts of the algorithm into separate methods where it's appropriate. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7588) Deprecate CacheLocalStore annotation
[ https://issues.apache.org/jira/browse/IGNITE-7588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16362865#comment-16362865 ] ASF GitHub Bot commented on IGNITE-7588: GitHub user daradurvs opened a pull request: https://github.com/apache/ignite/pull/3517 IGNITE-7588 Deprecate CacheLocalStore annotation You can merge this pull request into a Git repository by running: $ git pull https://github.com/daradurvs/ignite ignite-7588 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/3517.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #3517 commit ff3caa20e6ed7106002e59573067b18965bab3cf Author: Vyacheslav Daradur Date: 2018-02-13T18:44:32Z ignite-7588: @CacheLocaleStore was annotated as deprecated > Deprecate CacheLocalStore annotation > > > Key: IGNITE-7588 > URL: https://issues.apache.org/jira/browse/IGNITE-7588 > Project: Ignite > Issue Type: Task > Components: general >Affects Versions: 2.3, 2.4 >Reporter: Vyacheslav Daradur >Assignee: Vyacheslav Daradur >Priority: Major > Labels: deprecation > Fix For: 2.5 > > > We should annotate @CacheLocalStore as @Depricated, because of using > CacheLocalStore annotation has the hidden issues like rebalancing and > possible data consistency issues. > See [dev-list > discussion|http://apache-ignite-developers.2346864.n4.nabble.com/Should-we-annotate-CacheLocalStore-as-Depricated-tt26490.html] > for details. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7690) Move shared memory suite (IpcSharedMemoryCrashDetectionSelfTest) to Ignite Basic 2
[ https://issues.apache.org/jira/browse/IGNITE-7690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16362964#comment-16362964 ] ASF GitHub Bot commented on IGNITE-7690: GitHub user glukos opened a pull request: https://github.com/apache/ignite/pull/3518 IGNITE-7690 Move shared memory suite to Ignite Basic 2 You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-7690 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/3518.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #3518 commit b60356a440e929800da6fd654a179a1dfb69 Author: Ivan Rakov Date: 2018-02-13T20:02:04Z IGNITE-7690 Move shared memory suite (IpcSharedMemoryCrashDetectionSelfTest) to Ignite Basic 2 > Move shared memory suite (IpcSharedMemoryCrashDetectionSelfTest) to Ignite > Basic 2 > -- > > Key: IGNITE-7690 > URL: https://issues.apache.org/jira/browse/IGNITE-7690 > Project: Ignite > Issue Type: Task >Reporter: Dmitriy Pavlov >Assignee: Ivan Rakov >Priority: Major > Labels: MakeTeamcityGreenAgain > > Test is flaky but included into basic (stable) suite >Ignite Basic [ tests 1 ] i > org.apache.ignite.testsuites.IgniteBasicTestSuite: > org.apache.ignite.internal.util.ipc.shmem.IpcSharedMemoryCrashDetectionSelfTest.testIgfsServerClientInteractionsUponClientKilling > (fail rate 2%) > https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=-2464527718752484555&branch=%3Cdefault%3E&tab=testDetails > It is better to move this test to basic 2 suite - place for flaky and long > running tests. > It is also desired to introduce IgniteBasic2 suite in code with correct > comments on purpose -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7690) Move shared memory suite (IpcSharedMemoryCrashDetectionSelfTest) to Ignite Basic 2
[ https://issues.apache.org/jira/browse/IGNITE-7690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16362968#comment-16362968 ] Ivan Rakov commented on IGNITE-7690: Please take a look. I've also updated Basic 2 suite on public TC. Regarding separate class for Basic 2 suite - we can't do it as most of Basic 2 subsuites reside in different modules. > Move shared memory suite (IpcSharedMemoryCrashDetectionSelfTest) to Ignite > Basic 2 > -- > > Key: IGNITE-7690 > URL: https://issues.apache.org/jira/browse/IGNITE-7690 > Project: Ignite > Issue Type: Task >Reporter: Dmitriy Pavlov >Assignee: Ivan Rakov >Priority: Major > Labels: MakeTeamcityGreenAgain > > Test is flaky but included into basic (stable) suite >Ignite Basic [ tests 1 ] i > org.apache.ignite.testsuites.IgniteBasicTestSuite: > org.apache.ignite.internal.util.ipc.shmem.IpcSharedMemoryCrashDetectionSelfTest.testIgfsServerClientInteractionsUponClientKilling > (fail rate 2%) > https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=-2464527718752484555&branch=%3Cdefault%3E&tab=testDetails > It is better to move this test to basic 2 suite - place for flaky and long > running tests. > It is also desired to introduce IgniteBasic2 suite in code with correct > comments on purpose -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (IGNITE-7588) Deprecate CacheLocalStore annotation
[ https://issues.apache.org/jira/browse/IGNITE-7588?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Valentin Kulichenko closed IGNITE-7588. --- > Deprecate CacheLocalStore annotation > > > Key: IGNITE-7588 > URL: https://issues.apache.org/jira/browse/IGNITE-7588 > Project: Ignite > Issue Type: Task > Components: general >Affects Versions: 2.3, 2.4 >Reporter: Vyacheslav Daradur >Assignee: Vyacheslav Daradur >Priority: Major > Labels: deprecation > Fix For: 2.5 > > > We should annotate @CacheLocalStore as @Depricated, because of using > CacheLocalStore annotation has the hidden issues like rebalancing and > possible data consistency issues. > See [dev-list > discussion|http://apache-ignite-developers.2346864.n4.nabble.com/Should-we-annotate-CacheLocalStore-as-Depricated-tt26490.html] > for details. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7588) Deprecate CacheLocalStore annotation
[ https://issues.apache.org/jira/browse/IGNITE-7588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16363095#comment-16363095 ] ASF GitHub Bot commented on IGNITE-7588: Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/3517 > Deprecate CacheLocalStore annotation > > > Key: IGNITE-7588 > URL: https://issues.apache.org/jira/browse/IGNITE-7588 > Project: Ignite > Issue Type: Task > Components: general >Affects Versions: 2.3, 2.4 >Reporter: Vyacheslav Daradur >Assignee: Vyacheslav Daradur >Priority: Major > Labels: deprecation > Fix For: 2.5 > > > We should annotate @CacheLocalStore as @Depricated, because of using > CacheLocalStore annotation has the hidden issues like rebalancing and > possible data consistency issues. > See [dev-list > discussion|http://apache-ignite-developers.2346864.n4.nabble.com/Should-we-annotate-CacheLocalStore-as-Depricated-tt26490.html] > for details. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (IGNITE-7574) Ignite Getting Started confuses developers
[ https://issues.apache.org/jira/browse/IGNITE-7574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prachi Garg closed IGNITE-7574. --- > Ignite Getting Started confuses developers > -- > > Key: IGNITE-7574 > URL: https://issues.apache.org/jira/browse/IGNITE-7574 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Denis Magda >Assignee: Prachi Garg >Priority: Blocker > Fix For: 2.4 > > > By some reason, we suggest to build Ignite from sources at the very beginning > of the getting started guide: > [https://apacheignite.readme.io/docs/getting-started] > I got a feedback that this confuses a lot especially because it's 100% > optional! The reporter wasted much of his time trying to build Ignite with > JDK 9 and could succeed only after a private conversation with me. > > Revisit and rework the guide. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-7574) Ignite Getting Started confuses developers
[ https://issues.apache.org/jira/browse/IGNITE-7574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prachi Garg resolved IGNITE-7574. - Resolution: Fixed Reviewed and made minor edits. > Ignite Getting Started confuses developers > -- > > Key: IGNITE-7574 > URL: https://issues.apache.org/jira/browse/IGNITE-7574 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Denis Magda >Assignee: Prachi Garg >Priority: Blocker > Fix For: 2.4 > > > By some reason, we suggest to build Ignite from sources at the very beginning > of the getting started guide: > [https://apacheignite.readme.io/docs/getting-started] > I got a feedback that this confuses a lot especially because it's 100% > optional! The reporter wasted much of his time trying to build Ignite with > JDK 9 and could succeed only after a private conversation with me. > > Revisit and rework the guide. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-6994) Need to document PartitionLossPolicy
[ https://issues.apache.org/jira/browse/IGNITE-6994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16363184#comment-16363184 ] Denis Magda commented on IGNITE-6994: - [~pgarg] , I've improved this section of the documentation. Please help with the review and complete the TODOs there: https://apacheignite.readme.io/v2.3/docs/cache-modes-24#section-partition-loss-policies > Need to document PartitionLossPolicy > > > Key: IGNITE-6994 > URL: https://issues.apache.org/jira/browse/IGNITE-6994 > Project: Ignite > Issue Type: Task > Components: documentation >Affects Versions: 2.3 >Reporter: Valentin Kulichenko >Assignee: Denis Magda >Priority: Critical > Labels: documentation > Fix For: 2.4 > > > Since 2.0 we have a feature that makes cache(s) unavailable in case of data > loss; exact behavior is controlled by {{PartitionLossPolicy}}: > [https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/cache/PartitionLossPolicy.html] > However, there is no mentioning in the documentation about this. Need to > provide an explanation of how and when it should be used and provide > configuration examples. > The documentation has to address questions and misunderstandings asked in > these discussions: > * > [http://apache-ignite-developers.2346864.n4.nabble.com/Partition-loss-policy-how-to-use-td25341.html] > * > [http://apache-ignite-developers.2346864.n4.nabble.com/Partition-loss-policy-to-disable-cache-completely-td26212.html] > Improve the JavaDoc too whenever is possible. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-6994) Need to document PartitionLossPolicy
[ https://issues.apache.org/jira/browse/IGNITE-6994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda reassigned IGNITE-6994: --- Assignee: Prachi Garg (was: Denis Magda) > Need to document PartitionLossPolicy > > > Key: IGNITE-6994 > URL: https://issues.apache.org/jira/browse/IGNITE-6994 > Project: Ignite > Issue Type: Task > Components: documentation >Affects Versions: 2.3 >Reporter: Valentin Kulichenko >Assignee: Prachi Garg >Priority: Critical > Labels: documentation > Fix For: 2.4 > > > Since 2.0 we have a feature that makes cache(s) unavailable in case of data > loss; exact behavior is controlled by {{PartitionLossPolicy}}: > [https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/cache/PartitionLossPolicy.html] > However, there is no mentioning in the documentation about this. Need to > provide an explanation of how and when it should be used and provide > configuration examples. > The documentation has to address questions and misunderstandings asked in > these discussions: > * > [http://apache-ignite-developers.2346864.n4.nabble.com/Partition-loss-policy-how-to-use-td25341.html] > * > [http://apache-ignite-developers.2346864.n4.nabble.com/Partition-loss-policy-to-disable-cache-completely-td26212.html] > Improve the JavaDoc too whenever is possible. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-2483) Cache metrics functionality for client nodes should be developed.
[ https://issues.apache.org/jira/browse/IGNITE-2483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda updated IGNITE-2483: Labels: community iep-6 (was: community) > Cache metrics functionality for client nodes should be developed. > - > > Key: IGNITE-2483 > URL: https://issues.apache.org/jira/browse/IGNITE-2483 > Project: Ignite > Issue Type: Bug > Components: cache >Reporter: Valentin Kulichenko >Priority: Major > Labels: community, iep-6 > > User list discussion: > http://apache-ignite-users.70518.x6.nabble.com/Is-there-a-way-to-get-cache-metrics-for-all-the-nodes-in-cluster-combined-td2674.html > Currently there are at least three issues with cache metrics: > # When metrics are acquired on client, average put times are always zero. > This happens because timings are calculated on the client, but puts are > counted on servers. > # Size and keySize are always zero even if cache is not empty. > # Default metrics() method that doesn't take a cluster group provides metrics > for local node only. So if it's called on client, they are always empty. It > should calculate metrics for the whole cluster instead. > Also looks like this code is very undertested. Coverage should be > significantly improved. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-5539) MemoryMetrics.getTotalAllocatedPages return 0 when persistence is enabled
[ https://issues.apache.org/jira/browse/IGNITE-5539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda updated IGNITE-5539: Fix Version/s: 2.5 > MemoryMetrics.getTotalAllocatedPages return 0 when persistence is enabled > - > > Key: IGNITE-5539 > URL: https://issues.apache.org/jira/browse/IGNITE-5539 > Project: Ignite > Issue Type: Bug > Components: persistence >Affects Versions: 2.1 >Reporter: Alexey Kuznetsov >Assignee: Sergey Chugunov >Priority: Major > Labels: iep-6 > Fix For: 2.5 > > > In memory only mode metrics show some not zero values. > With persistence it shows zero. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-3495) CacheMetrics.getAverage###Time is not calculated properly
[ https://issues.apache.org/jira/browse/IGNITE-3495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda updated IGNITE-3495: Labels: iep-6 (was: ) > CacheMetrics.getAverage###Time is not calculated properly > - > > Key: IGNITE-3495 > URL: https://issues.apache.org/jira/browse/IGNITE-3495 > Project: Ignite > Issue Type: Bug >Affects Versions: 1.6 >Reporter: Denis Magda >Priority: Major > Labels: iep-6 > Attachments: ExampleNodeStartupClient.java, IGNITE_3495.patch, > example-default.xml > > > {{CacheMetrics.getAverageGetTime}}, {{CacheMetrics.getAveragePutTime}} and > {{CacheMetrics.getAverageRemoveTime}} are not calculated properly in the > following scenario: > - start a server node; > - start a client node that will perform gets and puts; > - {{CacheMetrics.getAverage###Time}} will always be 0 for the server node's > cluster group. > The issue happens because {{CacheMetricsImpl.add###TimeNanos}} method is not > called on the server side when a metric related event happens. > In the attache you can find source that showcases the bug. > - start basic {{ExampleNodeStartup}} using attached configuration > {{example-default.xml}} conjuration; > - start {{ExampleNodeStartupClient}}. You will see that average metrics are > not incremented. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-4867) CacheMetricsSnapshot ignores 'size' and 'keySize' fields
[ https://issues.apache.org/jira/browse/IGNITE-4867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda updated IGNITE-4867: Labels: iep-6 newbie (was: newbie) > CacheMetricsSnapshot ignores 'size' and 'keySize' fields > > > Key: IGNITE-4867 > URL: https://issues.apache.org/jira/browse/IGNITE-4867 > Project: Ignite > Issue Type: Bug >Reporter: Dmitry Karachentsev >Assignee: Ritesh Modi >Priority: Major > Labels: iep-6, newbie > > 'size' and 'keySize' fields in CacheMetricsSnapshot must be serialized and > properly processed to show correct values in CacheClusterMetricsMXBeanImpl. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-5539) MemoryMetrics.getTotalAllocatedPages return 0 when persistence is enabled
[ https://issues.apache.org/jira/browse/IGNITE-5539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda updated IGNITE-5539: Labels: iep-6 (was: ) > MemoryMetrics.getTotalAllocatedPages return 0 when persistence is enabled > - > > Key: IGNITE-5539 > URL: https://issues.apache.org/jira/browse/IGNITE-5539 > Project: Ignite > Issue Type: Bug > Components: persistence >Affects Versions: 2.1 >Reporter: Alexey Kuznetsov >Assignee: Sergey Chugunov >Priority: Major > Labels: iep-6 > Fix For: 2.5 > > > In memory only mode metrics show some not zero values. > With persistence it shows zero. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-5490) Implement replacement for obsolete CacheMetrics#getOffHeapAllocatedSize
[ https://issues.apache.org/jira/browse/IGNITE-5490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda updated IGNITE-5490: Labels: iep-6 (was: ) > Implement replacement for obsolete CacheMetrics#getOffHeapAllocatedSize > --- > > Key: IGNITE-5490 > URL: https://issues.apache.org/jira/browse/IGNITE-5490 > Project: Ignite > Issue Type: Improvement > Components: cache >Affects Versions: 2.0 >Reporter: Ivan Rakov >Priority: Major > Labels: iep-6 > > With new 2.0 architecture, many caches can share one memory policy. Memory > metrics allows to measure memory usage (loaded pages) for the whole policy. > However, there's also a need to measure how much memory (or pages) is used by > each cache. > Before 2.0 such information was accessible with > CacheMetrics#getOffHeapAllocatedSize, but current implemetation returns 0. > We should either implement it or provide alternative metrics (e. g. > approximate number of loaded pages per cache). Please note that if > persistence is *disabled*, precise number of loaded pages per cache is not > defined - one page can contain entries of different caches. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-6564) Incorrect calculation size and keySize for cluster cache metrics
[ https://issues.apache.org/jira/browse/IGNITE-6564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda updated IGNITE-6564: Labels: iep-6 (was: ) > Incorrect calculation size and keySize for cluster cache metrics > > > Key: IGNITE-6564 > URL: https://issues.apache.org/jira/browse/IGNITE-6564 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.2 >Reporter: Ilya Kasnacheev >Priority: Minor > Labels: iep-6 > > They are currently not passed by ring and therefore only taken from current > node, which returns incorrect (local) value. > See CacheMetricsSnapshot class. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7652) ContinuousQueryWithTransformer example
[ https://issues.apache.org/jira/browse/IGNITE-7652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16363351#comment-16363351 ] Denis Magda commented on IGNITE-7652: - [~NIzhikov] , please find my comments in the pull-request. In general, it would be better to use 'Organization' model instead of 'Employees' that have a complex key. That complex key (EmployeeKey) is not needed in this example. > ContinuousQueryWithTransformer example > -- > > Key: IGNITE-7652 > URL: https://issues.apache.org/jira/browse/IGNITE-7652 > Project: Ignite > Issue Type: Improvement > Components: cache >Affects Versions: 2.5 >Reporter: Nikolay Izhikov >Assignee: Nikolay Izhikov >Priority: Major > Fix For: 2.5 > > > Need to create example for a ContinuousQueryWithTransformer. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7693) New node joining via ZookeeperDiscoverySpi should print out its ZooKeeper sessionId
[ https://issues.apache.org/jira/browse/IGNITE-7693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16363409#comment-16363409 ] ASF GitHub Bot commented on IGNITE-7693: GitHub user shroman opened a pull request: https://github.com/apache/ignite/pull/3519 IGNITE-7693: Printing out session ids on joining via ZookeeperDiscove… …rySpi. You can merge this pull request into a Git repository by running: $ git pull https://github.com/shroman/ignite IGNITE-7693 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/3519.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #3519 commit fce93839db7ddc303ca5ced3cb71e6603d4b1adc Author: shroman Date: 2018-02-14T02:50:29Z IGNITE-7693: Printing out session ids on joining via ZookeeperDiscoverySpi. > New node joining via ZookeeperDiscoverySpi should print out its ZooKeeper > sessionId > --- > > Key: IGNITE-7693 > URL: https://issues.apache.org/jira/browse/IGNITE-7693 > Project: Ignite > Issue Type: Improvement >Reporter: Sergey Chugunov >Priority: Major > Fix For: 2.5 > > > For now there is no way to match Ignite nodes joining to Ignite cluster with > log entries in ZooKeeper nodes' logs. > In ZooKeeper logs there are entries like this: > {noformat} > myid:1] - INFO [CommitProcessor:1:ZooKeeperServer@687] - Established session > 0x161575d88530007 with negotiated timeout 1 for client > /:{noformat} > but it is hard to match them with Ignite nodes when there are several started > on the same host. > If Ignite node prints out its session on join it makes correlating them with > particular ZooKeeper instance much easier. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7693) New node joining via ZookeeperDiscoverySpi should print out its ZooKeeper sessionId
[ https://issues.apache.org/jira/browse/IGNITE-7693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16363415#comment-16363415 ] Roman Shtykh commented on IGNITE-7693: -- [~sergey-chugunov] Please have a look. Probably still not the best way to see session id in the logs, but at least now you can have these lines in your node logs. {noformat} [TcpDiscoveryZookeeperIpFinder] Connected with session id: 0x2619230f8d0 ... [TcpDiscoveryZookeeperIpFinder] Registering addresses with ZooKeeper IP Finder: [/127.0.0.1:47500]{noformat} > New node joining via ZookeeperDiscoverySpi should print out its ZooKeeper > sessionId > --- > > Key: IGNITE-7693 > URL: https://issues.apache.org/jira/browse/IGNITE-7693 > Project: Ignite > Issue Type: Improvement >Reporter: Sergey Chugunov >Priority: Major > Fix For: 2.5 > > > For now there is no way to match Ignite nodes joining to Ignite cluster with > log entries in ZooKeeper nodes' logs. > In ZooKeeper logs there are entries like this: > {noformat} > myid:1] - INFO [CommitProcessor:1:ZooKeeperServer@687] - Established session > 0x161575d88530007 with negotiated timeout 1 for client > /:{noformat} > but it is hard to match them with Ignite nodes when there are several started > on the same host. > If Ignite node prints out its session on join it makes correlating them with > particular ZooKeeper instance much easier. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-7684) Ignore IGNITE_USE_ASYNC_FILE_IO_FACTORY in FileWriteAheadLogManager
[ https://issues.apache.org/jira/browse/IGNITE-7684?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Belyak resolved IGNITE-7684. -- Resolution: Duplicate > Ignore IGNITE_USE_ASYNC_FILE_IO_FACTORY in FileWriteAheadLogManager > --- > > Key: IGNITE-7684 > URL: https://issues.apache.org/jira/browse/IGNITE-7684 > Project: Ignite > Issue Type: Improvement > Components: general >Affects Versions: 2.4 >Reporter: Alexander Belyak >Priority: Major > > If IGNITE_USE_ASYNC_FILE_IO_FACTORY specified and no IGNITE_WAL_MMAP we get: > {noformat} > java.lang.UnsupportedOperationException: AsynchronousFileChannel doesn't > support mmap. > at > org.apache.ignite.internal.processors.cache.persistence.file.AsyncFileIO.map(AsyncFileIO.java:173) > > at > org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.restoreWriteHandle(FileWriteAheadLogManager.java:1068) > > at > org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.resumeLogging(FileWriteAheadLogManager.java:552) > at > org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.readCheckpointAndRestoreMemory(GridCacheDatabaseSharedManager.java:714) > at > org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onClusterStateChangeRequest(GridDhtPartitionsExchangeFuture.java:841) > at > org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:595) > at > org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2329) > at > org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110) > at java.lang.Thread.run(Thread.java:748) > {noformat} -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-7696) Deadlock at GridDhtAtomicCache.lockEntries called through GridDhtAtomicCache.updateAllAsyncInternal
Sadayuki Furuhashi created IGNITE-7696: -- Summary: Deadlock at GridDhtAtomicCache.lockEntries called through GridDhtAtomicCache.updateAllAsyncInternal Key: IGNITE-7696 URL: https://issues.apache.org/jira/browse/IGNITE-7696 Project: Ignite Issue Type: Bug Components: cache Affects Versions: 2.3 Environment: * Ignite 2.3 * OpenJDK version "1.8.0_151" * Linux 4.4.0 Reporter: Sadayuki Furuhashi We observed that all nodes in a cluster completely stalls and put/get/remove operations to a cache blocks for ever. When it happens, we can see following log in thread dump: {code:java} 2018-02-14_04:21:33.84410 Found one Java-level deadlock: 2018-02-14_04:21:33.84410 = 2018-02-14_04:21:33.84411 "sys-#41%IgniteManager%": 2018-02-14_04:21:33.84411 waiting to lock monitor 0x7f6d5e41a558 (object 0x000781083ef0, a org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheEntry), 2018-02-14_04:21:33.84411 which is held by "sys-stripe-5-#6%IgniteManager%" 2018-02-14_04:21:33.84412 "sys-stripe-5-#6%IgniteManager%": 2018-02-14_04:21:33.84412 waiting to lock monitor 0x7f6d5e41de68 (object 0x000781083e70, a org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheEntry) 2018-02-14_04:21:33.84412 in JNI, which is held by "sys-stripe-2-#3%IgniteManager%" 2018-02-14_04:21:33.84412 "sys-stripe-2-#3%IgniteManager%": 2018-02-14_04:21:33.84413 waiting to lock monitor 0x7f6d5e41a558 (object 0x000781083ef0, a org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheEntry) 2018-02-14_04:21:33.84413 in JNI, which is held by "sys-stripe-5-#6%IgniteManager%" 2018-02-14_04:21:33.84413 2018-02-14_04:21:33.84414 Java stack information for the threads listed above: 2018-02-14_04:21:33.84414 === 2018-02-14_04:21:33.84416 "sys-#41%IgniteManager%": 2018-02-14_04:21:33.84416 at org.apache.ignite.internal.processors.cache.GridCacheMapEntry.markObsoleteVersion(GridCacheMapEntry.java:2153) 2018-02-14_04:21:33.84417 - waiting to lock <0x000781083ef0> (a org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheEntry) 2018-02-14_04:21:33.84417 at org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLocalPartition.removeVersionedEntry(GridDhtLocalPartition.java:368) 2018-02-14_04:21:33.84418 at org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLocalPartition.cleanupRemoveQueue(GridDhtLocalPartition.java:392) 2018-02-14_04:21:33.84418 at org.apache.ignite.internal.processors.cache.GridCacheProcessor$RemovedItemsCleanupTask$1.run(GridCacheProcessor.java:4051) 2018-02-14_04:21:33.84418 at org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:6687) 2018-02-14_04:21:33.84419 at org.apache.ignite.internal.processors.closure.GridClosureProcessor$1.body(GridClosureProcessor.java:827) 2018-02-14_04:21:33.84419 at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110) 2018-02-14_04:21:33.84419 at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) 2018-02-14_04:21:33.84420 at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 2018-02-14_04:21:33.84421 at java.lang.Thread.run(Thread.java:748) 2018-02-14_04:21:33.84421 "sys-stripe-5-#6%IgniteManager%": 2018-02-14_04:21:33.84421 at sun.misc.Unsafe.monitorEnter(Native Method) 2018-02-14_04:21:33.84421 at org.apache.ignite.internal.util.GridUnsafe.monitorEnter(GridUnsafe.java:1207) 2018-02-14_04:21:33.84422 at org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.lockEntries(GridDhtAtomicCache.java:2848) 2018-02-14_04:21:33.84422 at org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1707) 2018-02-14_04:21:33.84423 at org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1629) 2018-02-14_04:21:33.84423 at org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.processNearAtomicUpdateRequest(GridDhtAtomicCache.java:3056) 2018-02-14_04:21:33.84424 at org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.access$400(GridDhtAtomicCache.java:131) 2018-02-14_04:21:33.84424 at org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$5.apply(GridDhtAtomicCache.java:267) 2018-02-14_04:21:33.84425 at org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$5.apply(GridDhtAtomicCache.java:262) 2018-02-14_04:21:33.84425 at org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1060) 2018-02-14_04:21:33.84425 at or
[jira] [Updated] (IGNITE-7696) Deadlock at GridDhtAtomicCache.lockEntries called through GridDhtAtomicCache.updateAllAsyncInternal
[ https://issues.apache.org/jira/browse/IGNITE-7696?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sadayuki Furuhashi updated IGNITE-7696: --- Description: We observed that all nodes in a cluster completely stalls and put/get/remove operations to a cache block for ever. When it happens, we can see following log in thread dump: {code} 2018-02-14_04:21:33.84410 Found one Java-level deadlock: 2018-02-14_04:21:33.84410 = 2018-02-14_04:21:33.84411 "sys-#41%IgniteManager%": 2018-02-14_04:21:33.84411 waiting to lock monitor 0x7f6d5e41a558 (object 0x000781083ef0, a org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheEntry), 2018-02-14_04:21:33.84411 which is held by "sys-stripe-5-#6%IgniteManager%" 2018-02-14_04:21:33.84412 "sys-stripe-5-#6%IgniteManager%": 2018-02-14_04:21:33.84412 waiting to lock monitor 0x7f6d5e41de68 (object 0x000781083e70, a org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheEntry) 2018-02-14_04:21:33.84412 in JNI, which is held by "sys-stripe-2-#3%IgniteManager%" 2018-02-14_04:21:33.84412 "sys-stripe-2-#3%IgniteManager%": 2018-02-14_04:21:33.84413 waiting to lock monitor 0x7f6d5e41a558 (object 0x000781083ef0, a org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheEntry) 2018-02-14_04:21:33.84413 in JNI, which is held by "sys-stripe-5-#6%IgniteManager%" 2018-02-14_04:21:33.84413 2018-02-14_04:21:33.84414 Java stack information for the threads listed above: 2018-02-14_04:21:33.84414 === 2018-02-14_04:21:33.84416 "sys-#41%IgniteManager%": 2018-02-14_04:21:33.84416 at org.apache.ignite.internal.processors.cache.GridCacheMapEntry.markObsoleteVersion(GridCacheMapEntry.java:2153) 2018-02-14_04:21:33.84417 - waiting to lock <0x000781083ef0> (a org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheEntry) 2018-02-14_04:21:33.84417 at org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLocalPartition.removeVersionedEntry(GridDhtLocalPartition.java:368) 2018-02-14_04:21:33.84418 at org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLocalPartition.cleanupRemoveQueue(GridDhtLocalPartition.java:392) 2018-02-14_04:21:33.84418 at org.apache.ignite.internal.processors.cache.GridCacheProcessor$RemovedItemsCleanupTask$1.run(GridCacheProcessor.java:4051) 2018-02-14_04:21:33.84418 at org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:6687) 2018-02-14_04:21:33.84419 at org.apache.ignite.internal.processors.closure.GridClosureProcessor$1.body(GridClosureProcessor.java:827) 2018-02-14_04:21:33.84419 at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110) 2018-02-14_04:21:33.84419 at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) 2018-02-14_04:21:33.84420 at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 2018-02-14_04:21:33.84421 at java.lang.Thread.run(Thread.java:748) 2018-02-14_04:21:33.84421 "sys-stripe-5-#6%IgniteManager%": 2018-02-14_04:21:33.84421 at sun.misc.Unsafe.monitorEnter(Native Method) 2018-02-14_04:21:33.84421 at org.apache.ignite.internal.util.GridUnsafe.monitorEnter(GridUnsafe.java:1207) 2018-02-14_04:21:33.84422 at org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.lockEntries(GridDhtAtomicCache.java:2848) 2018-02-14_04:21:33.84422 at org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1707) 2018-02-14_04:21:33.84423 at org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1629) 2018-02-14_04:21:33.84423 at org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.processNearAtomicUpdateRequest(GridDhtAtomicCache.java:3056) 2018-02-14_04:21:33.84424 at org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.access$400(GridDhtAtomicCache.java:131) 2018-02-14_04:21:33.84424 at org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$5.apply(GridDhtAtomicCache.java:267) 2018-02-14_04:21:33.84425 at org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$5.apply(GridDhtAtomicCache.java:262) 2018-02-14_04:21:33.84425 at org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1060) 2018-02-14_04:21:33.84425 at org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:579) 2018-02-14_04:21:33.84426 at org.apache.ignite.internal.processors.cache