[jira] [Updated] (IGNITE-9680) Web console: add component for status output
[ https://issues.apache.org/jira/browse/IGNITE-9680?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Borisov updated IGNITE-9680: - Description: Create a component that output status: 1. It should accept a list of possible statuses as an argument, each item should specify label to display, model value, color (red, green or regular) and whether to show an inline spinner or not. 2. It should also accept status value as an argument. 3. Given that same the status might be displayed in various places, provide a way to omit repeating lengthy statuses list argument. Maybe a component factory that binds statuses to a new component? 4. The new component should be based on either _ignite-status_ component or supersede it. Use the new component in: 1. Connected clusters dialog. was: Create a component that output status: 1. It should accept a list of possible statuses as an argument, each item should specify label to display, model value, color (red, green or regular) and whether to show an inline spinner or not. 2. It should also accept status value as an argument. 3. Given that same the status might be displayed in various places, provide a way to omit repeating lengthy statuses list argument. Maybe a component factory that binds statuses to a new component? Use the new component in: 1. Connected clusters dialog. Remove the _ignite-status_ component. > Web console: add component for status output > > > Key: IGNITE-9680 > URL: https://issues.apache.org/jira/browse/IGNITE-9680 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Ilya Borisov >Assignee: Ilya Borisov >Priority: Minor > > Create a component that output status: > 1. It should accept a list of possible statuses as an argument, each item > should specify label to display, model value, color (red, green or regular) > and whether to show an inline spinner or not. > 2. It should also accept status value as an argument. > 3. Given that same the status might be displayed in various places, provide a > way to omit repeating lengthy statuses list argument. Maybe a component > factory that binds statuses to a new component? > 4. The new component should be based on either _ignite-status_ component or > supersede it. > Use the new component in: > 1. Connected clusters dialog. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9680) Web console: add component for status output
Ilya Borisov created IGNITE-9680: Summary: Web console: add component for status output Key: IGNITE-9680 URL: https://issues.apache.org/jira/browse/IGNITE-9680 Project: Ignite Issue Type: Improvement Components: wizards Reporter: Ilya Borisov Assignee: Ilya Borisov Create a component that output status: 1. It should accept a list of possible statuses as an argument, each item should specify label to display, model value, color (red, green or regular) and whether to show an inline spinner or not. 2. It should also accept status value as an argument. 3. Given that same the status might be displayed in various places, provide a way to omit repeating lengthy statuses list argument. Maybe a component factory that binds statuses to a new component? Use the new component in: 1. Connected clusters dialog. Remove the _ignite-status_ component. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8880) Add setIgnite() in SpringCacheManager and SpringTransactionManager
[ https://issues.apache.org/jira/browse/IGNITE-8880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amir Akhmedov updated IGNITE-8880: -- Fix Version/s: (was: 2.7) 2.8 > Add setIgnite() in SpringCacheManager and SpringTransactionManager > -- > > Key: IGNITE-8880 > URL: https://issues.apache.org/jira/browse/IGNITE-8880 > Project: Ignite > Issue Type: Improvement > Components: spring >Reporter: Amir Akhmedov >Assignee: Amir Akhmedov >Priority: Major > Labels: newbie > Fix For: 2.8 > > > Neet to add setIgnite() in SpringCacheManager and SpringTransactionManager to > make explicit injection of Ignite instance. > For more details refer: > https://issues.apache.org/jira/browse/IGNITE-8740?focusedCommentId=16520894=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16520894 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-640) Implement IgniteMultimap data structures
[
https://issues.apache.org/jira/browse/IGNITE-640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amir Akhmedov updated IGNITE-640:
-
Fix Version/s: (was: 2.7)
2.8
> Implement IgniteMultimap data structures
>
>
> Key: IGNITE-640
> URL: https://issues.apache.org/jira/browse/IGNITE-640
> Project: Ignite
> Issue Type: Sub-task
> Components: data structures
>Reporter: Dmitriy Setrakyan
>Assignee: Amir Akhmedov
>Priority: Major
> Fix For: 2.8
>
>
> We need to add {{IgniteMultimap}} data structure in addition to other data
> structures provided by Ignite. {{IgniteMultiMap}} should have similar API to
> {{java.util.Map}} class in JDK, but support the semantics of multiple values
> per key, similar to [Guava
> Multimap|http://docs.guava-libraries.googlecode.com/git/javadoc/com/google/common/collect/Multimap.html].
>
> However, unlike in Guava, our multi-map should work with Lists, not
> Collections. Lists should make it possible to support the following methods:
> {code}
> // Gets value at a certain index for a key.
> V get(K, index);
> // Gets all values for a collection of keys at a certain index.
> Map getAll(Collection, index);
> // Gets values for specified indexes for a key.
> List get(K, Iterable indexes);
> // Gets all values for a collection of keys at specified indexes.
> Map> getAll(Collection, Iterable indexes);
> // Gets values for specified range of indexes, between min and max.
> List get(K, int min, int max);
> // Gets all values for a collection of keys for a specified index range,
> between min and max.
> Map> getAll(Collection, int min, int max);
> // Gets all values for a specific key.
> List get(K);
> // Gets all values for a collection of keys.
> Map> getAll(Collection);
> // Iterate through all elements with a certain index.
> Iterator> iterate(int idx);
> // Do we need this?
> Collection> get(K, IgniteBiPredicate)
> {code}
> Multimap should also support colocated and non-colocated modes, similar to
> [IgniteQueue|https://github.com/apache/incubator-ignite/blob/master/modules/core/src/main/java/org/apache/ignite/IgniteQueue.java]
> and its implementation,
> [GridAtomicCacheQueueImpl|https://github.com/apache/incubator-ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/datastructures/GridAtomicCacheQueueImpl.java].
> h2. Design Details
> The most natural way to implement such map, would be to store every value
> under a separate key in an Ignite cache. For example, let's say that we have
> a key {{K}} with multiple values: {{V0, V1, V2, ...}}. Then the cache should
> end up with the following values {{K0, V0}}, {{K1, V1}}, {{K2, V2}}, etc.
> This means that we need to wrap user key into our own, internal key, which
> will also have {{index}} field.
> Also note that we need to collocate all the values for the same key on the
> same node, which means that we need to define user key K as the affinity key,
> like so:
> {code}
> class MultiKey {
> @CacheAffinityMapped
> private K key;
> int index;
> }
> {code}
> Look ups of values at specific indexes becomes very simple. Just attach a
> specific index to a key and do a cache lookup. Look ups for all values for a
> key should work as following:
> {code}
> MultiKey key;
> V v = null;
> int index = 0;
> List res = new LinkedList<>();
> do {
> v = cache.get(MultiKey(K, index));
> if (v != null)
> res.add(v);
> index++;
> }
> while (v != null);
> return res;
> {code}
> We could also use batching for performance reason. In this case the batch
> size should be configurable.
> {code}
> int index = 0;
> List res = new LinkedList<>();
> while (true) {
> List batch = new ArrayList<>(batchSize);
> // Populate batch.
> for (; index < batchSize; index++)
> batch.add(new MultiKey(K, index % batchSize);
> Map batchRes = cache.getAll(batch);
> // Potentially need to properly sort values, based on the key order,
> // if the returning map does not do it automatically.
> res.addAll(batchRes.values());
> if (res.size() < batch.size())
> break;
> }
> return res;
> {code}
> h2. Evictions
> Evictions in the {{IgniteMultiMap}} should have 2 levels: maximum number of
> keys, and maximum number of values for a key. The maximum number of keys
> should be controlled by Ignite standard eviction policy. The maximum number
> of values for a key should be controlled by the implementation of the
> multi-map. Either eviction parameter should be configurable.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-640) Implement IgniteMultimap data structures
[
https://issues.apache.org/jira/browse/IGNITE-640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16626697#comment-16626697
]
Amir Akhmedov commented on IGNITE-640:
--
[~NIzhikov], I don't think it's feasible to include it into 2.7.
> Implement IgniteMultimap data structures
>
>
> Key: IGNITE-640
> URL: https://issues.apache.org/jira/browse/IGNITE-640
> Project: Ignite
> Issue Type: Sub-task
> Components: data structures
>Reporter: Dmitriy Setrakyan
>Assignee: Amir Akhmedov
>Priority: Major
> Fix For: 2.8
>
>
> We need to add {{IgniteMultimap}} data structure in addition to other data
> structures provided by Ignite. {{IgniteMultiMap}} should have similar API to
> {{java.util.Map}} class in JDK, but support the semantics of multiple values
> per key, similar to [Guava
> Multimap|http://docs.guava-libraries.googlecode.com/git/javadoc/com/google/common/collect/Multimap.html].
>
> However, unlike in Guava, our multi-map should work with Lists, not
> Collections. Lists should make it possible to support the following methods:
> {code}
> // Gets value at a certain index for a key.
> V get(K, index);
> // Gets all values for a collection of keys at a certain index.
> Map getAll(Collection, index);
> // Gets values for specified indexes for a key.
> List get(K, Iterable indexes);
> // Gets all values for a collection of keys at specified indexes.
> Map> getAll(Collection, Iterable indexes);
> // Gets values for specified range of indexes, between min and max.
> List get(K, int min, int max);
> // Gets all values for a collection of keys for a specified index range,
> between min and max.
> Map> getAll(Collection, int min, int max);
> // Gets all values for a specific key.
> List get(K);
> // Gets all values for a collection of keys.
> Map> getAll(Collection);
> // Iterate through all elements with a certain index.
> Iterator> iterate(int idx);
> // Do we need this?
> Collection> get(K, IgniteBiPredicate)
> {code}
> Multimap should also support colocated and non-colocated modes, similar to
> [IgniteQueue|https://github.com/apache/incubator-ignite/blob/master/modules/core/src/main/java/org/apache/ignite/IgniteQueue.java]
> and its implementation,
> [GridAtomicCacheQueueImpl|https://github.com/apache/incubator-ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/datastructures/GridAtomicCacheQueueImpl.java].
> h2. Design Details
> The most natural way to implement such map, would be to store every value
> under a separate key in an Ignite cache. For example, let's say that we have
> a key {{K}} with multiple values: {{V0, V1, V2, ...}}. Then the cache should
> end up with the following values {{K0, V0}}, {{K1, V1}}, {{K2, V2}}, etc.
> This means that we need to wrap user key into our own, internal key, which
> will also have {{index}} field.
> Also note that we need to collocate all the values for the same key on the
> same node, which means that we need to define user key K as the affinity key,
> like so:
> {code}
> class MultiKey {
> @CacheAffinityMapped
> private K key;
> int index;
> }
> {code}
> Look ups of values at specific indexes becomes very simple. Just attach a
> specific index to a key and do a cache lookup. Look ups for all values for a
> key should work as following:
> {code}
> MultiKey key;
> V v = null;
> int index = 0;
> List res = new LinkedList<>();
> do {
> v = cache.get(MultiKey(K, index));
> if (v != null)
> res.add(v);
> index++;
> }
> while (v != null);
> return res;
> {code}
> We could also use batching for performance reason. In this case the batch
> size should be configurable.
> {code}
> int index = 0;
> List res = new LinkedList<>();
> while (true) {
> List batch = new ArrayList<>(batchSize);
> // Populate batch.
> for (; index < batchSize; index++)
> batch.add(new MultiKey(K, index % batchSize);
> Map batchRes = cache.getAll(batch);
> // Potentially need to properly sort values, based on the key order,
> // if the returning map does not do it automatically.
> res.addAll(batchRes.values());
> if (res.size() < batch.size())
> break;
> }
> return res;
> {code}
> h2. Evictions
> Evictions in the {{IgniteMultiMap}} should have 2 levels: maximum number of
> keys, and maximum number of values for a key. The maximum number of keys
> should be controlled by Ignite standard eviction policy. The maximum number
> of values for a key should be controlled by the implementation of the
> multi-map. Either eviction parameter should be configurable.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-7196) Exchange can stuck and wait while new node restoring state from disk and starting caches
[ https://issues.apache.org/jira/browse/IGNITE-7196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16626461#comment-16626461 ] Maxim Muzafarov commented on IGNITE-7196: - Summary, [Without minor changes - Run :: All #4342 (10 Sep 18 20:45)|https://ci.ignite.apache.org/viewLog.html?buildId=1835822=buildResultsDiv=IgniteTests24Java8_RunAll] [Run :: All #4832 (24 Sep 18 12:11)|https://ci.ignite.apache.org/viewLog.html?buildId=1929194=buildResultsDiv=IgniteTests24Java8_RunAll] [ZooKeeper (Discovery) 2 #3538 (24 Sep 18 20:11)|https://ci.ignite.apache.org/viewLog.html?buildId=1933147=buildResultsDiv=IgniteTests24Java8_ZooKeeperDiscovery2] > Exchange can stuck and wait while new node restoring state from disk and > starting caches > > > Key: IGNITE-7196 > URL: https://issues.apache.org/jira/browse/IGNITE-7196 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.3 >Reporter: Mikhail Cherkasov >Assignee: Maxim Muzafarov >Priority: Critical > Fix For: 2.7 > > > Exchange can stuck and wait while new node restoring state from disk and > starting caches, there's a log snippet from a just joined new node that shows > the issue: > [21:36:13,023][INFO][exchange-worker-#62%statement_grid%][time] Started > exchange init [topVer=AffinityTopologyVersion [topVer=57, minorTopVer=0], > crd=false, evt=NODE_JOINED, evtNode=3ac1160e-0de4-41bc-a366-59292c9f03c1, > customEvt=null, allowMerge=true] > [21:36:13,023][INFO][exchange-worker-#62%statement_grid%][FilePageStoreManager] > Resolved page store work directory: > /mnt/store/node00-d1eb270c-d2cc-4550-87aa-64f6df2a9463 > [21:36:13,024][INFO][exchange-worker-#62%statement_grid%][FileWriteAheadLogManager] > Resolved write ahead log work directory: > /mnt/wal/WAL/node00-d1eb270c-d2cc-4550-87aa-64f6df2a9463 > [21:36:13,024][INFO][exchange-worker-#62%statement_grid%][FileWriteAheadLogManager] > Resolved write ahead log archive directory: > /mnt/wal/WAL_archive/node00-d1eb270c-d2cc-4550-87aa-64f6df2a9463 > [21:36:13,046][INFO][exchange-worker-#62%statement_grid%][FileWriteAheadLogManager] > Started write-ahead log manager [mode=DEFAULT] > [21:36:13,065][INFO][exchange-worker-#62%statement_grid%][PageMemoryImpl] > Started page memory [memoryAllocated=100.0 MiB, pages=6352, tableSize=373.4 > KiB, checkpointBuffer=100.0 MiB] > [21:36:13,105][INFO][exchange-worker-#62%statement_grid%][PageMemoryImpl] > Started page memory [memoryAllocated=32.0 GiB, pages=2083376, tableSize=119.6 > MiB, checkpointBuffer=896.0 MiB] > [21:36:13,428][INFO][exchange-worker-#62%statement_grid%][GridCacheDatabaseSharedManager] > Read checkpoint status > [startMarker=/mnt/store/node00-d1eb270c-d2cc-4550-87aa-64f6df2a9463/cp/1512930965253-306c0895-1f5f-4237-bebf-8bf2b49682af-START.bin, > > endMarker=/mnt/store/node00-d1eb270c-d2cc-4550-87aa-64f6df2a9463/cp/1512930869357-1c24b6dc-d64c-4b83-8166-11edf1bfdad3-END.bin] > [21:36:13,429][INFO][exchange-worker-#62%statement_grid%][GridCacheDatabaseSharedManager] > Checking memory state [lastValidPos=FileWALPointer [idx=3582, > fileOffset=59186076, len=9229, forceFlush=false], lastMarked=FileWALPointer > [idx=3629, fileOffset=50829700, len=9229, forceFlush=false], > lastCheckpointId=306c0895-1f5f-4237-bebf-8bf2b49682af] > [21:36:13,429][WARNING][exchange-worker-#62%statement_grid%][GridCacheDatabaseSharedManager] > Ignite node stopped in the middle of checkpoint. Will restore memory state > and finish checkpoint on node start. > [21:36:18,312][INFO][grid-nio-worker-tcp-comm-0-#41%statement_grid%][TcpCommunicationSpi] > Accepted incoming communication connection [locAddr=/172.31.20.209:48100, > rmtAddr=/172.31.17.115:57148] > [21:36:21,619][INFO][exchange-worker-#62%statement_grid%][GridCacheDatabaseSharedManager] > Found last checkpoint marker [cpId=306c0895-1f5f-4237-bebf-8bf2b49682af, > pos=FileWALPointer [idx=3629, fileOffset=50829700, len=9229, > forceFlush=false]] > [21:36:21,620][INFO][exchange-worker-#62%statement_grid%][GridCacheDatabaseSharedManager] > Finished applying memory changes [changesApplied=165103, time=8189ms] > [21:36:22,403][INFO][grid-nio-worker-tcp-comm-1-#42%statement_grid%][TcpCommunicationSpi] > Accepted incoming communication connection [locAddr=/172.31.20.209:48100, > rmtAddr=/172.31.28.10:47964] > [21:36:23,414][INFO][grid-nio-worker-tcp-comm-2-#43%statement_grid%][TcpCommunicationSpi] > Accepted incoming communication connection [locAddr=/172.31.20.209:48100, > rmtAddr=/172.31.27.101:46000] > [21:36:33,019][WARNING][main][GridCachePartitionExchangeManager] Failed to > wait for initial partition map exchange. Possible reasons are: > ^-- Transactions in deadlock. > ^-- Long running transactions (ignore if
[jira] [Commented] (IGNITE-9679) Document critical workers liveness checking implementation
[
https://issues.apache.org/jira/browse/IGNITE-9679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16626422#comment-16626422
]
Denis Magda commented on IGNITE-9679:
-
[~Artem Budnikov], please help to document this issue.
> Document critical workers liveness checking implementation
> --
>
> Key: IGNITE-9679
> URL: https://issues.apache.org/jira/browse/IGNITE-9679
> Project: Ignite
> Issue Type: Task
> Components: documentation
>Reporter: Andrey Kuznetsov
>Assignee: Artem Budnikov
>Priority: Major
> Fix For: 2.7
>
>
> Newly implemented critical worker thread liveness checks should be mentioned
> in Ignite Documentation. Brief description of the functionality follows.
> Ignite node has a number of critical worker threads that should be alive and
> responsive, otherwise node's health is not guaranteed. These threads monitor
> each other periodically and track two aspects for a thread being checked:
> - whether it's alive;
> - whether it updates its internal heartbeat timestamp.
> Both checks use {{IgniteConfiguration.failureDetectionTimeout}} property as a
> threshold value.
> Whenever at least one of the above conditions is violated, checker thread
> logs the error and calls currently configured {{FailureHandler}}.
> Liveness checks are enabled by default, but can be disabled through
> {{WorkersControlMXBean.healthMonitoringEnabled}} property.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-9679) Document critical workers liveness checking implementation
[
https://issues.apache.org/jira/browse/IGNITE-9679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Magda reassigned IGNITE-9679:
---
Assignee: Artem Budnikov (was: Denis Magda)
> Document critical workers liveness checking implementation
> --
>
> Key: IGNITE-9679
> URL: https://issues.apache.org/jira/browse/IGNITE-9679
> Project: Ignite
> Issue Type: Task
> Components: documentation
>Reporter: Andrey Kuznetsov
>Assignee: Artem Budnikov
>Priority: Major
> Fix For: 2.7
>
>
> Newly implemented critical worker thread liveness checks should be mentioned
> in Ignite Documentation. Brief description of the functionality follows.
> Ignite node has a number of critical worker threads that should be alive and
> responsive, otherwise node's health is not guaranteed. These threads monitor
> each other periodically and track two aspects for a thread being checked:
> - whether it's alive;
> - whether it updates its internal heartbeat timestamp.
> Both checks use {{IgniteConfiguration.failureDetectionTimeout}} property as a
> threshold value.
> Whenever at least one of the above conditions is violated, checker thread
> logs the error and calls currently configured {{FailureHandler}}.
> Liveness checks are enabled by default, but can be disabled through
> {{WorkersControlMXBean.healthMonitoringEnabled}} property.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9655) SQL: Create benchmark suite for DML operations.
[ https://issues.apache.org/jira/browse/IGNITE-9655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16626323#comment-16626323 ] ASF GitHub Bot commented on IGNITE-9655: GitHub user pavel-kuznetsov opened a pull request: https://github.com/apache/ignite/pull/4821 IGNITE-9655 DML benchmark suite (except selects) Created benchmark suite for updates and insert+deletes. Removed outdated benchmarks. You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-9655 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4821.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 #4821 commit 858426ca5b65262fde5e73d524caf9fa187637c8 Author: Pavel Kuznetsov Date: 2018-09-21T14:32:51Z ignite-9655: created configuration with my benchmarks. commit dce4e0ef3e5b6d0b95d27f246da1a13c6d0ce969 Author: Pavel Kuznetsov Date: 2018-09-23T23:20:56Z ignite-9655: updated benchmarks. Left questions in the end in comments. Use only native sql. commit 43f7495b248478b92a725a803021b3ca85c864bd Author: Pavel Kuznetsov Date: 2018-09-24T11:47:30Z ignite-9655: fixed extra ',' commit 0cda529d54cec967daee05328cde85103ee57416 Author: Pavel Kuznetsov Date: 2018-09-24T14:52:29Z ignite-9655: added other drivers. commit c93abcfb700f82d71e2920e16a5ce6aee86dba97 Author: Pavel Kuznetsov Date: 2018-09-24T15:44:07Z ignite-9655: removed duplicated -cl flag. commit a05f486a30be05c0c9080407a85df2ce763164ba Author: Pavel Kuznetsov Date: 2018-09-24T19:28:05Z ignite-9655: removed incorrect benchmarks (dml). Removed benchmarks from package org.apache.ignite.yardstick.cache.dml that don't have steady state. commit 7304a2ecc86d2fd02cca885de1252576edb1e659 Author: Pavel Kuznetsov Date: 2018-09-24T18:40:49Z ignite-9655: removed incorrect benchmarks (jdbc.store). Removed benchmarks from package org.apache.ignite.yardstick.cache.store.jdbc since they are not needed. > SQL: Create benchmark suite for DML operations. > --- > > Key: IGNITE-9655 > URL: https://issues.apache.org/jira/browse/IGNITE-9655 > Project: Ignite > Issue Type: Task >Reporter: Pavel Kuznetsov >Assignee: Pavel Kuznetsov >Priority: Major > > Create benchmark configuration that contains benchmark runs for DML > operations. > 1) insert + delete > 2) update (single, range -with-/without contention). > Currently we have benchmark code for 1 and 2 without contention. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9679) Document critical workers liveness checking implementation
Andrey Kuznetsov created IGNITE-9679:
Summary: Document critical workers liveness checking implementation
Key: IGNITE-9679
URL: https://issues.apache.org/jira/browse/IGNITE-9679
Project: Ignite
Issue Type: Task
Components: documentation
Reporter: Andrey Kuznetsov
Assignee: Denis Magda
Fix For: 2.7
Newly implemented critical worker thread liveness checks should be mentioned in
Ignite Documentation. Brief description of the functionality follows.
Ignite node has a number of critical worker threads that should be alive and
responsive, otherwise node's health is not guaranteed. These threads monitor
each other periodically and track two aspects for a thread being checked:
- whether it's alive;
- whether it updates its internal heartbeat timestamp.
Both checks use {{IgniteConfiguration.failureDetectionTimeout}} property as a
threshold value.
Whenever at least one of the above conditions is violated, checker thread logs
the error and calls currently configured {{FailureHandler}}.
Liveness checks are enabled by default, but can be disabled through
{{WorkersControlMXBean.healthMonitoringEnabled}} property.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-9678) [TC Bot] Trigger Run All for github comment
Nikolay Izhikov created IGNITE-9678: --- Summary: [TC Bot] Trigger Run All for github comment Key: IGNITE-9678 URL: https://issues.apache.org/jira/browse/IGNITE-9678 Project: Ignite Issue Type: Bug Reporter: Nikolay Izhikov Team City bot should work in the following way: It should be able to: 1. Execute "Run all" suite for specific PR when the author of PR makes a comment "@mtcga.bot Run Tests!" in GitHub comments. 2. Send a comment with "Run All" results both: to a Jira ticket and GitHub comment. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8283) CPP: Implement 'varint' solution to be configurable via BinaryConfiguration
[
https://issues.apache.org/jira/browse/IGNITE-8283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov updated IGNITE-8283:
Fix Version/s: (was: 2.7)
2.8
> CPP: Implement 'varint' solution to be configurable via BinaryConfiguration
> ---
>
> Key: IGNITE-8283
> URL: https://issues.apache.org/jira/browse/IGNITE-8283
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Vyacheslav Daradur
>Priority: Major
> Fix For: 2.8
>
>
> Need to finish the solution that has been prepared into IGNITE-5153 to be
> configurable via {{BinaryConfiguration}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9347) Attempt to start a dynamic cache with invalid configuration leads to exchange worker death
[
https://issues.apache.org/jira/browse/IGNITE-9347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov updated IGNITE-9347:
Fix Version/s: (was: 2.7)
2.8
> Attempt to start a dynamic cache with invalid configuration leads to exchange
> worker death
> --
>
> Key: IGNITE-9347
> URL: https://issues.apache.org/jira/browse/IGNITE-9347
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.5, 2.6
>Reporter: Vladimir Ozerov
>Priority: Blocker
> Fix For: 2.8
>
>
> Reproducer - {{SqlIllegalSchemaSelfTest}}. Technically, this test pass. But
> note the following:
> 1) See logs of {{*Dynamic}} tests - instead of normal stop, node gets killed
> by failure detector:
> {code:java}
> [2018-08-22
> 14:20:39,777][ERROR][exchange-worker-#77%query.SqlIllegalSchemaSelfTest%][IgniteTestResources]
> Critical system error detected. Will be handled accordingly to configured
> handler [hnd=class o.a.i.failure.NoOpFailureHandler,
> failureCtx=FailureContext [type=SYSTEM_WORKER_TERMINATION,
> err=java.lang.AssertionError: stopping=true, groupName=null, caches=[]]]
> java.lang.AssertionError: stopping=true, groupName=null, caches=[]
> at
> org.apache.ignite.internal.processors.cache.CacheGroupContext.singleCacheContext(CacheGroupContext.java:371){code}
> 2) Similar behavior is observed if one tries to start caches with invalid
> configuration twice. Pick any {{*Dynamic}} test and just copy/paste
> {{GridTestUtils.assertThrows}} logic one after another. Expected - two
> expected exceptions, actual - node is killed.
>
> Possibly duplicate of IGNITE-8640 (need to double-check)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-7641) Add CacheEntry#ttl method
[
https://issues.apache.org/jira/browse/IGNITE-7641?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov updated IGNITE-7641:
Fix Version/s: (was: 2.7)
2.8
> Add CacheEntry#ttl method
> -
>
> Key: IGNITE-7641
> URL: https://issues.apache.org/jira/browse/IGNITE-7641
> Project: Ignite
> Issue Type: Improvement
> Components: cache
>Affects Versions: 2.3
>Reporter: Valentin Kulichenko
>Priority: Major
> Fix For: 2.8
>
>
> Ignite provides a way to specify an expiry policy on per entry level, but
> there is no way to know the current TTL for a particular key.
> We can add {{CacheEntry#ttl()}} and/or {{IgniteCache#ttl(K key)}} method that
> will provide this information. Looks like it's already available via
> {{GridCacheMapEntry#ttl()}}, so we just need to properly expose it to public
> API.
> Here is the user forum discussion about this:
> http://apache-ignite-users.70518.x6.nabble.com/Get-TTL-of-the-specific-K-V-entry-td19817.html
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-7472) Exchange initiated by custom disco events could hang in case of coordinator leave
[
https://issues.apache.org/jira/browse/IGNITE-7472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov updated IGNITE-7472:
Fix Version/s: (was: 2.7)
2.8
> Exchange initiated by custom disco events could hang in case of coordinator
> leave
> -
>
> Key: IGNITE-7472
> URL: https://issues.apache.org/jira/browse/IGNITE-7472
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.4
>Reporter: Vladimir Ozerov
>Priority: Critical
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.8
>
>
> Reproducer: {{WalModeChangeAdvancedSelfTest.testServerRestartCoordinator}}
> WAL mode change operation initiates an exchange through custom discovery
> event. The test does the following:
> 1) Initiate constant flow of such events from one node
> 2) Constantly stops current coordinator node and start another one sever node
> Debug shows the following:
> 1) Remaining client nodes is on exchange X, waiting for new coordinator to
> send affinity message
> 2) New coordinator is on exchange [X+1], waiting for client to send partition
> message
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-7798) Give user an ability to check driver metrics in Cassandra store
[
https://issues.apache.org/jira/browse/IGNITE-7798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov updated IGNITE-7798:
Fix Version/s: (was: 2.7)
2.8
> Give user an ability to check driver metrics in Cassandra store
> ---
>
> Key: IGNITE-7798
> URL: https://issues.apache.org/jira/browse/IGNITE-7798
> Project: Ignite
> Issue Type: Improvement
> Components: cassandra
>Affects Versions: 2.3
>Reporter: Valentin Kulichenko
>Priority: Major
> Fix For: 2.8
>
>
> Cassandra store uses generic client driver to connect to the cluster. The
> driver provides {{Metrics}} object which can be useful for monitoring,
> however there is no way for user to acquire it. Need to find a way to expose
> this information to public API.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9621) MVCC: sqlline warning that transactions are not supported
[
https://issues.apache.org/jira/browse/IGNITE-9621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov updated IGNITE-9621:
Fix Version/s: (was: 2.7)
2.8
> MVCC: sqlline warning that transactions are not supported
> -
>
> Key: IGNITE-9621
> URL: https://issues.apache.org/jira/browse/IGNITE-9621
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Reporter: Stepan Pilschikov
>Priority: Major
> Fix For: 2.8
>
>
> MVCC enabled
> --autoCommit=false
> In sqlline first initial lines throwing warning message:
> {code}
> [1;34missuing: !connect jdbc:ignite:thin://127.0.0.1:10800 '' ''
> org.apache.ignite.IgniteJdbcThinDriver[m
> [1;34mConnecting to jdbc:ignite:thin://127.0.0.1:10800[m
> [1;34mConnected to: Apache Ignite (version 2.7.1#19700101-sha1:)[m
> [1;34mDriver: Apache Ignite Thin JDBC Driver (version
> 2.7.1#19700101-sha1:)[m
> [1;34mAutocommit status: false[m
> Sep 17, 2018 5:44:32 PM
> org.apache.ignite.internal.jdbc.thin.JdbcThinConnection
> setTransactionIsolation
> WARNING: Transactions are not supported.
> Sep 17, 2018 5:44:32 PM
> org.apache.ignite.internal.jdbc.thin.JdbcThinConnection
> getTransactionIsolation
> WARNING: Transactions are not supported.
> [1;34mTransaction isolation: TRANSACTION_REPEATABLE_READ[m
> sqlline version 1.3.0
> 0: jdbc:ignite:thin://127.0.0.1:10800>
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-6910) Introduce a force join parameter to clear PDS after branching pointing
[ https://issues.apache.org/jira/browse/IGNITE-6910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov updated IGNITE-6910: Fix Version/s: (was: 2.7) 2.8 > Introduce a force join parameter to clear PDS after branching pointing > -- > > Key: IGNITE-6910 > URL: https://issues.apache.org/jira/browse/IGNITE-6910 > Project: Ignite > Issue Type: New Feature > Components: persistence >Reporter: Sergey Puchnin >Priority: Major > Labels: IEP-4, Phase-2 > Fix For: 2.8 > > > Need to give an opportunity to clean a PDS on a node that is trying to join > after branching pointing. It may be a "force-join" or a "force-clean" > parameter -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9620) MVCC: select throwing `Transaction is already completed` exception after mvcc missmatch
[
https://issues.apache.org/jira/browse/IGNITE-9620?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov updated IGNITE-9620:
Fix Version/s: (was: 2.7)
2.8
> MVCC: select throwing `Transaction is already completed` exception after
> mvcc missmatch
>
>
> Key: IGNITE-9620
> URL: https://issues.apache.org/jira/browse/IGNITE-9620
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Reporter: Stepan Pilschikov
>Priority: Major
> Fix For: 2.8
>
>
> Using sqlline with autoCommit=false
> {code}
> switch to first user
> - select * from test:
> result: [[1, 1, test_1]]
> switch to second user
> - insert into test(id, field_int, field_var) values (2, 2, 'test_2'):
> - commit:
> - select * from test:
> result: [[1, 1, test_1], [2, 2, test_2]]
> switch to first user
> - insert into test(id, field_int, field_var) values (2, 2, 'test_2'):
> error: Mvcc version mismatch.
> - select * from test
> {code}
> During last select throwing exception
> {code}
> 0: jdbc:ignite:thin://127.0.0.1:10800> select * from test;
> select * from test;
> [1;31mError: Transaction is already completed. (state=25000,code=0)[m
> java.sql.SQLException: Transaction is already completed.
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinConnection.sendRequest(JdbcThinConnection.java:764)
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute0(JdbcThinStatement.java:212)
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute(JdbcThinStatement.java:475)
> at sqlline.Commands.execute(Commands.java:823)
> at sqlline.Commands.sql(Commands.java:733)
> at sqlline.SqlLine.dispatch(SqlLine.java:795)
> at sqlline.SqlLine.begin(SqlLine.java:668)
> at sqlline.SqlLine.start(SqlLine.java:373)
> at sqlline.SqlLine.main(SqlLine.java:265)
> {code}
> Exception in node logs:
> {code}
> [17:44:36,234][SEVERE][jdbc-request-handler-worker-#61][JdbcRequestHandler]
> Failed to execute SQL query [reqId=0, req=JdbcQueryExecuteRequest
> [schemaName=PUBLIC, pageSize=1024, maxRows=0, sqlQry=select * from test,
> args=Object[] [], stmtType=ANY_STATEMENT_TYPE, autoCommit=false]]
> class org.apache.ignite.internal.processors.query.IgniteSQLException:
> Transaction is already completed.
> at
> org.apache.ignite.internal.processors.cache.mvcc.MvccUtils.checkActive(MvccUtils.java:623)
> at
> org.apache.ignite.internal.processors.cache.mvcc.MvccUtils.requestSnapshot(MvccUtils.java:780)
> at
> org.apache.ignite.internal.processors.cache.mvcc.MvccUtils.mvccTracker(MvccUtils.java:761)
> at
> org.apache.ignite.internal.processors.cache.mvcc.MvccUtils.mvccTracker(MvccUtils.java:744)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.runQueryTwoStep(IgniteH2Indexing.java:1731)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.doRunDistributedQuery(IgniteH2Indexing.java:2521)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.querySqlFields(IgniteH2Indexing.java:2074)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:2139)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:2134)
> at
> org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2711)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2148)
> at
> org.apache.ignite.internal.processors.odbc.jdbc.JdbcRequestHandler.executeQuery(JdbcRequestHandler.java:511)
> at
> org.apache.ignite.internal.processors.odbc.jdbc.JdbcRequestHandler.doHandle(JdbcRequestHandler.java:245)
> at
> org.apache.ignite.internal.processors.odbc.jdbc.JdbcRequestHandlerWorker.body(JdbcRequestHandlerWorker.java:90)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> Works for any query which is throwing mvcc missmatch exception
> After commit select query works again
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9291) IgniteJdbcThinDriver with SSL doesn't work for sqlline on Windows
[
https://issues.apache.org/jira/browse/IGNITE-9291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov updated IGNITE-9291:
Fix Version/s: (was: 2.7)
2.8
> IgniteJdbcThinDriver with SSL doesn't work for sqlline on Windows
> -
>
> Key: IGNITE-9291
> URL: https://issues.apache.org/jira/browse/IGNITE-9291
> Project: Ignite
> Issue Type: Bug
> Components: jdbc
>Affects Versions: 2.6
>Reporter: Sergey Kozlov
>Priority: Major
> Fix For: 2.8
>
>
> I tried to run AI 2.6 with same configuration under Linux (Ubuntu) and
> Windows 10 and then connect {sqlline} with activated SSL.
> It works fine for Linux and doesn't work for Windows.
> There's no errors on server nodes but sqlline prints out following:
> {noformat}
> C:/BuildAgent/work/dd4d79acf76cc870/i2test/var/suite-client/gg-pro-fab-nolgpl/bin/sqlline.bat,
> WARN: IGNITE_HOME environment variable may be pointing to wrong folder:
> C:/BuildAgent/work/dd4d79acf76cc870/i2test/var/suite-client/gg-pro-fab-nolgpl
> Setting property: [force, true]
> Setting property: [showWarnings, true]
> Setting property: [showNestedErrs, true]
> issuing: !connect jdbc:ignite:thin://127.0.0.1/?sslMode=require '' ''
> org.apache.ignite.IgniteJdbcThinDriver
> Connecting to jdbc:ignite:thin://127.0.0.1/?sslMode=require
> Error: Failed to SSL connect to server
> [url=jdbc:ignite:thin://127.0.0.1:10800] (state=08001,code=0)
> java.sql.SQLException: Failed to SSL connect to server
> [url=jdbc:ignite:thin://127.0.0.1:10800]
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinSSLUtil.createSSLSocket(JdbcThinSSLUtil.java:93)
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinTcpIo.connect(JdbcThinTcpIo.java:217)
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinTcpIo.start(JdbcThinTcpIo.java:159)
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinTcpIo.start(JdbcThinTcpIo.java:134)
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinConnection.ensureConnected(JdbcThinConnection.java:151)
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinConnection.(JdbcThinConnection.java:140)
> at
> org.apache.ignite.IgniteJdbcThinDriver.connect(IgniteJdbcThinDriver.java:157)
> at sqlline.DatabaseConnection.connect(DatabaseConnection.java:156)
> at sqlline.DatabaseConnection.getConnection(DatabaseConnection.java:204)
> at sqlline.Commands.connect(Commands.java:1095)
> at sqlline.Commands.connect(Commands.java:1001)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> sqlline.ReflectiveCommandHandler.execute(ReflectiveCommandHandler.java:38)
> at sqlline.SqlLine.dispatch(SqlLine.java:791)
> at sqlline.SqlLine.initArgs(SqlLine.java:566)
> at sqlline.SqlLine.begin(SqlLine.java:643)
> at sqlline.SqlLine.start(SqlLine.java:373)
> at sqlline.SqlLine.main(SqlLine.java:265)
> Caused by: javax.net.ssl.SSLHandshakeException:
> sun.security.validator.ValidatorException: PKIX path building failed:
> sun.security.provider.certpath.SunCertPathBuilderException: unable to find
> valid certification path to requested target
> at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
> at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1949)
> at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:302)
> at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:296)
> at
> sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1509)
> at
> sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:216)
> at sun.security.ssl.Handshaker.processLoop(Handshaker.java:979)
> at sun.security.ssl.Handshaker.process_record(Handshaker.java:914)
> at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1062)
> at
> sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1375)
> at
> sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1403)
> at
> sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1387)
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinSSLUtil.createSSLSocket(JdbcThinSSLUtil.java:88)
> ... 20 more
> Caused by: sun.security.validator.ValidatorException: PKIX path building
> failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to
> find valid certification path to requested target
> at
[jira] [Updated] (IGNITE-8356) Possible race at the discovery on the start node
[ https://issues.apache.org/jira/browse/IGNITE-8356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov updated IGNITE-8356: Fix Version/s: (was: 2.7) 2.8 > Possible race at the discovery on the start node > > > Key: IGNITE-8356 > URL: https://issues.apache.org/jira/browse/IGNITE-8356 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.4 >Reporter: Taras Ledkov >Priority: Major > Fix For: 2.8 > > > The problem was discovered on the IGNITE-8355. > But *root cause* is the race on the start of the node discovery. > The race happens because a joining node may start processing NodeAddMessage > before processing local node's NodeAddFinishedMessage. Because of this, the > local node will not have any constructed DiscoCache yet and NPE happens. > We need to take a look at the workaround suggested in IGNITE-8355 and > 1) Check if any public API changes are needed on DiscoverySpi interface > 2) Verify it works for ZookeeperDiscoverySpi. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-6664) Memcached example refactoring
[
https://issues.apache.org/jira/browse/IGNITE-6664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov updated IGNITE-6664:
Fix Version/s: (was: 2.7)
2.8
> Memcached example refactoring
> -
>
> Key: IGNITE-6664
> URL: https://issues.apache.org/jira/browse/IGNITE-6664
> Project: Ignite
> Issue Type: Task
> Components: examples
>Affects Versions: 2.2
>Reporter: Sergey Kozlov
>Priority: Major
> Fix For: 2.8
>
>
> The memcached example {{examples/memcached/memcached-example.php}} looks like
> outpdated and doesn't work for php 7.0/7.1.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-1535) Evicted entries still are presented
[
https://issues.apache.org/jira/browse/IGNITE-1535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov updated IGNITE-1535:
Fix Version/s: (was: 2.7)
2.8
> Evicted entries still are presented
>
>
> Key: IGNITE-1535
> URL: https://issues.apache.org/jira/browse/IGNITE-1535
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: ignite-1.4
>Reporter: Sergey Kozlov
>Priority: Critical
> Fix For: 2.8
>
> Attachments: CacheFifoEvictExample.java, grid_evict.xml
>
>
> Test creates 4 caches: 2 PARTITIONED for testing and 2 REPLICATED for
> comparison. Each cache has FIFO eviction policy with maxSize=750.
> Test puts 1000 entries (order: 1 ... 1000) and check that 1..250 entries are
> removed and 251..1000 presented in cache.
> 1. Copy grid_evict.xml in examples/config directory
> 2. Copy CacheFifoEvictExample in
> examples/src/main/java/org/apache/ignite/examples/datagrid
> 3. Build examples
> 4. Run 3 nodes bin/ignite.sh examples/config/grid_evict.xml
> 5. Run CacheFifoEvictExample
> Expected output:
> {noformat}
> >>>cache_1
> put keys 1..1000
> get keys 1..1000
> >>>cache_2
> put keys 1..1000
> get keys 1..1000
> {noformat}
> Bur for PARTITIONED caches I got
> {noformat}
> >>>cache_1
> put keys 1..1000
> get keys 1..1000
> >>> not null value found for 18
> >>> not null value found for 19
> >>> not null value found for 20
> >>> not null value found for 21
> >>> not null value found for 22
> >>> not null value found for 23
> >>> not null value found for 24
> >>> not null value found for 25
> >>> not null value found for 28
> ...
> >>>cache_2
> put keys 1..1000
> get keys 1..1000
> >>> not null value found for 1
> >>> not null value found for 3
> >>> not null value found for 6
> >>> not null value found for 10
> >>> not null value found for 18
> >>> not null value found for 19
> >>> not null value found for 20
> >>> not null value found for 21
> >>> not null value found for 22
> >>> not null value found for 23
> >>> not null value found for 24
> >>> not null value found for 25
> ...
> {noformat}
> Delay between puts and gets doesn't fix the issue but add null values for
> keys > 250
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-8550) CacheAbstractJdbcStore expects merge to always return 1 but MySQL may also return 2 or 0
[
https://issues.apache.org/jira/browse/IGNITE-8550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov updated IGNITE-8550:
Fix Version/s: (was: 2.7)
2.8
> CacheAbstractJdbcStore expects merge to always return 1 but MySQL may also
> return 2 or 0
>
>
> Key: IGNITE-8550
> URL: https://issues.apache.org/jira/browse/IGNITE-8550
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Reporter: Stanislav Lukyanov
>Priority: Minor
> Labels: newbie
> Fix For: 2.8
>
>
> CacheAbstractJdbcStore.write attempts to execute a merge update if it is
> available, and expects the merge to always return 1 (as the number of updated
> entries is always 1).
> However, MySQL's `INSERT ... ON DUPLICATE KEY UPDATE`
> (https://dev.mysql.com/doc/refman/8.0/en/insert-on-duplicate.html) may return
> 0 or 2, depending on what was updated:
> {quote}With ON DUPLICATE KEY UPDATE, the affected-rows value per row is 1 if
> the row is inserted as a new row, 2 if an existing row is updated, and 0 if
> an existing row is set to its current values.{quote}
> Because of that, CacheAbstractJdbcStore may report a false warning.
> Need to consider either removing the warning or special-case the MySQL
> dialect to allow to return values other than 1.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-7369) .NET: Thin client: Transactions
[ https://issues.apache.org/jira/browse/IGNITE-7369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov updated IGNITE-7369: Fix Version/s: (was: 2.7) 2.8 > .NET: Thin client: Transactions > --- > > Key: IGNITE-7369 > URL: https://issues.apache.org/jira/browse/IGNITE-7369 > Project: Ignite > Issue Type: Improvement > Components: platforms, thin client >Affects Versions: 2.4 >Reporter: Pavel Tupitsyn >Priority: Major > Labels: .NET > Fix For: 2.8 > > > Implement transactions in thin client protocol and .NET thin client. > Main issue: Ignite transactions are tied to a specific thread. > See how JDBC works around this by starting a dedicated thread. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-7552) .NET: AtomicConfiguration.DefaultBackups should be 1
[
https://issues.apache.org/jira/browse/IGNITE-7552?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov updated IGNITE-7552:
Fix Version/s: (was: 2.7)
2.8
> .NET: AtomicConfiguration.DefaultBackups should be 1
>
>
> Key: IGNITE-7552
> URL: https://issues.apache.org/jira/browse/IGNITE-7552
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 2.4
>Reporter: Pavel Tupitsyn
>Priority: Major
> Labels: .NET
> Fix For: 2.8
>
>
> Defaults have changed in Java (see {{AtomicConfiguration.DFLT_BACKUPS}}),
> update .NET part, add test (we usually check that .NET and Java defaults
> match in {{IgniteConfigurationTest.TestSpringXml}}).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-7072) IgniteCache.replace(k, v, nv) does not work in binary mode without classes
[
https://issues.apache.org/jira/browse/IGNITE-7072?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov updated IGNITE-7072:
Fix Version/s: 2.8
> IgniteCache.replace(k, v, nv) does not work in binary mode without classes
> --
>
> Key: IGNITE-7072
> URL: https://issues.apache.org/jira/browse/IGNITE-7072
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Reporter: Pavel Tupitsyn
>Priority: Major
> Fix For: 2.8
>
>
> {{IgniteCache.replace(K key, V oldVal, V newVal)}} method deserializes cache
> values in order to compare them, which causes exception when classes are not
> present on server:
> {code}
> class org.apache.ignite.IgniteCheckedException: Unknown pair [platformId=0,
> typeId=-1690383137]
> at
> org.apache.ignite.internal.util.IgniteUtils.cast(IgniteUtils.java:7260)
> at
> org.apache.ignite.internal.processors.cache.GridCacheContext.isAll(GridCacheContext.java:1242)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.onEntriesLocked(GridDhtTxPrepareFuture.java:464)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.prepare0(GridDhtTxPrepareFuture.java:1223)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.mapIfLocked(GridDhtTxPrepareFuture.java:666)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.prepare(GridDhtTxPrepareFuture.java:1040)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.prepareAsyncLocal(GridNearTxLocal.java:3452)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.prepareColocatedTx(IgniteTxHandler.java:257)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearOptimisticTxPrepareFuture.proceedPrepare(GridNearOptimisticTxPrepareFuture.java:574)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearOptimisticTxPrepareFuture.prepareSingle(GridNearOptimisticTxPrepareFuture.java:401)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearOptimisticTxPrepareFuture.prepare0(GridNearOptimisticTxPrepareFuture.java:344)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearOptimisticTxPrepareFutureAdapter.prepareOnTopology(GridNearOptimisticTxPrepareFutureAdapter.java:137)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearOptimisticTxPrepareFutureAdapter.prepare(GridNearOptimisticTxPrepareFutureAdapter.java:74)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.prepareNearTxLocal(GridNearTxLocal.java:3161)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.commitNearTxLocalAsync(GridNearTxLocal.java:3221)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.optimisticPutFuture(GridNearTxLocal.java:2391)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.putAsync0(GridNearTxLocal.java:622)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.putAsync(GridNearTxLocal.java:385)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter$34.op(GridCacheAdapter.java:2707)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter$AsyncOp.op(GridCacheAdapter.java:5120)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.asyncOp(GridCacheAdapter.java:4260)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter$AsyncOpRetryFuture.execute(GridCacheAdapter.java:4841)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.asyncOp(GridCacheAdapter.java:4173)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.putAsync0(GridCacheAdapter.java:2705)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.putAsync(GridCacheAdapter.java:2689)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.replaceAsync(GridCacheAdapter.java:2776)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.replaceAsync(IgniteCacheProxyImpl.java:1182)
> at
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.replaceAsync(GatewayProtectedCacheProxy.java:1082)
> at
> org.apache.ignite.internal.processors.platform.cache.PlatformCache.processInStreamOutLong(PlatformCache.java:677)
> at
> org.apache.ignite.internal.processors.platform.PlatformTargetProxyImpl.inStreamOutLong(PlatformTargetProxyImpl.java:67)
> Caused by:
[jira] [Updated] (IGNITE-7445) Thin client: SQL batching
[
https://issues.apache.org/jira/browse/IGNITE-7445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov updated IGNITE-7445:
Fix Version/s: (was: 2.7)
2.8
> Thin client: SQL batching
> -
>
> Key: IGNITE-7445
> URL: https://issues.apache.org/jira/browse/IGNITE-7445
> Project: Ignite
> Issue Type: Improvement
> Components: thin client
>Affects Versions: 2.4
>Reporter: Pavel Tupitsyn
>Priority: Major
> Fix For: 2.8
>
>
> SQL batching allows executing multiple SQL queries in one client request,
> improving performance.
> See how JDBC does it in {{JdbcBatchExecuteRequest}}, add a similar thing in
> Thin Client protocol.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9133) SQL TX: Proper empty DHT transactions handling.
[
https://issues.apache.org/jira/browse/IGNITE-9133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov updated IGNITE-9133:
Fix Version/s: (was: 2.7)
2.8
> SQL TX: Proper empty DHT transactions handling.
> ---
>
> Key: IGNITE-9133
> URL: https://issues.apache.org/jira/browse/IGNITE-9133
> Project: Ignite
> Issue Type: Bug
> Components: mvcc, sql
>Reporter: Roman Kondakov
>Priority: Major
> Fix For: 2.8
>
>
> In the cases when DHT transaction is empty (i.e. no keys were enlisted) after
> the enlist step, we need to rollback local DHT transaction to exclude it from
> the further transaction flow in order to performance increasing.
> An ordinary Dht tx rollback {{GridDhtTxLocal#rollbackDhtLocalAsync}} is not
> suitable in this situation because it adds tx to
> {{IgniteTxManager#completedVersHashMap}} which is unacceptable because this
> action prevents possible Dht transaction creation if the next tx statements
> enlist some keys at this node in the future. As well as direct tx map
> cleaning by means of {{IgniteTxManager#rollbackTx(tx, true, true)}} is not an
> aid because leads to grid hanging due to undiscovered reasons. In order to
> reproduce hanging you need to reapply commit d231a81 and run
> {{CacheMvccPartitionedSqlCoordinatorFailoverTest}}. Example of hanged thread
> stack is listed below.
> Our goal is the proper Dht transaction rollback without adding it to
> {{IgniteTxManager#completedVersHashMap.}}
> {code:java}
> Thread [name="writer-2", id=2281, state=WAITING, blockCnt=40, waitCnt=10260]
> at sun.misc.Unsafe.park(Native Method)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
> at
> o.a.i.i.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:177)
> at
> o.a.i.i.util.future.GridFutureAdapter.get(GridFutureAdapter.java:140)
> at
> o.a.i.i.processors.query.h2.DmlStatementsProcessor.executeUpdateStatement(DmlStatementsProcessor.java:560)
> at
> o.a.i.i.processors.query.h2.DmlStatementsProcessor.updateSqlFields(DmlStatementsProcessor.java:185)
> at
> o.a.i.i.processors.query.h2.DmlStatementsProcessor.updateSqlFieldsDistributed(DmlStatementsProcessor.java:358)
> at
> o.a.i.i.processors.query.h2.IgniteH2Indexing.doRunPrepared(IgniteH2Indexing.java:2132)
> at
> o.a.i.i.processors.query.h2.IgniteH2Indexing.querySqlFields(IgniteH2Indexing.java:2083)
> at
> o.a.i.i.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:2139)
> at
> o.a.i.i.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:2134)
> at
> o.a.i.i.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
> at
> o.a.i.i.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2682)
> at
> o.a.i.i.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2148)
> at
> o.a.i.i.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:668)
> at
> o.a.i.i.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:619)
> at
> o.a.i.i.processors.cache.GatewayProtectedCacheProxy.query(GatewayProtectedCacheProxy.java:388)
> at
> o.a.i.i.processors.cache.mvcc.CacheMvccAbstractTest.removeSql(CacheMvccAbstractTest.java:832)
> at
> o.a.i.i.processors.cache.mvcc.CacheMvccAbstractTest.access$400(CacheMvccAbstractTest.java:104)
> at
> o.a.i.i.processors.cache.mvcc.CacheMvccAbstractTest$2.apply(CacheMvccAbstractTest.java:494)
> at
> o.a.i.i.processors.cache.mvcc.CacheMvccAbstractTest$2.apply(CacheMvccAbstractTest.java:401)
> at
> o.a.i.i.processors.cache.mvcc.CacheMvccAbstractTest$9.call(CacheMvccAbstractTest.java:1294)
> at
> o.a.i.i.processors.cache.mvcc.CacheMvccAbstractTest$9.call(CacheMvccAbstractTest.java:1289)
> at o.a.i.testframework.GridTestThread.run(GridTestThread.java:86)
> {code}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-7551) .NET: AtomicConfiguration parity test
[
https://issues.apache.org/jira/browse/IGNITE-7551?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov updated IGNITE-7551:
Fix Version/s: (was: 2.7)
2.8
> .NET: AtomicConfiguration parity test
> -
>
> Key: IGNITE-7551
> URL: https://issues.apache.org/jira/browse/IGNITE-7551
> Project: Ignite
> Issue Type: Improvement
> Components: platforms
>Affects Versions: 2.4
>Reporter: Pavel Tupitsyn
>Priority: Minor
> Labels: .NET
> Fix For: 2.8
>
>
> See {{CacheConfigurationParityTest}} as an example, add same thing for
> {{AtomicConfiguration}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-7665) .NET: Target .NET Standard 2.0
[
https://issues.apache.org/jira/browse/IGNITE-7665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov updated IGNITE-7665:
Fix Version/s: (was: 2.7)
2.8
> .NET: Target .NET Standard 2.0
> --
>
> Key: IGNITE-7665
> URL: https://issues.apache.org/jira/browse/IGNITE-7665
> Project: Ignite
> Issue Type: Improvement
> Components: platforms
>Reporter: Pavel Tupitsyn
>Priority: Major
> Labels: .NET, xplat
> Fix For: 2.8
>
>
> As explained in IGNITE-2662 and
> https://apacheignite-net.readme.io/v2.4/docs/cross-platform-support, our
> projects/assemblies still target .NET 4.0.
> This simplifies build/release procedures, but has issues:
> * Ignite.NET *can't be used from .NET Standard 2.0 libraries* (big one)
> * Warning is displayed
> * Incompatible API usages may sneak in despite tests
> We should target {{netstandard2.0}} as well as .NET 4. Release package should
> contain two set of assemblies.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-7072) IgniteCache.replace(k, v, nv) does not work in binary mode without classes
[
https://issues.apache.org/jira/browse/IGNITE-7072?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov updated IGNITE-7072:
Fix Version/s: (was: 2.7)
> IgniteCache.replace(k, v, nv) does not work in binary mode without classes
> --
>
> Key: IGNITE-7072
> URL: https://issues.apache.org/jira/browse/IGNITE-7072
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Reporter: Pavel Tupitsyn
>Priority: Major
> Fix For: 2.8
>
>
> {{IgniteCache.replace(K key, V oldVal, V newVal)}} method deserializes cache
> values in order to compare them, which causes exception when classes are not
> present on server:
> {code}
> class org.apache.ignite.IgniteCheckedException: Unknown pair [platformId=0,
> typeId=-1690383137]
> at
> org.apache.ignite.internal.util.IgniteUtils.cast(IgniteUtils.java:7260)
> at
> org.apache.ignite.internal.processors.cache.GridCacheContext.isAll(GridCacheContext.java:1242)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.onEntriesLocked(GridDhtTxPrepareFuture.java:464)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.prepare0(GridDhtTxPrepareFuture.java:1223)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.mapIfLocked(GridDhtTxPrepareFuture.java:666)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.prepare(GridDhtTxPrepareFuture.java:1040)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.prepareAsyncLocal(GridNearTxLocal.java:3452)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.prepareColocatedTx(IgniteTxHandler.java:257)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearOptimisticTxPrepareFuture.proceedPrepare(GridNearOptimisticTxPrepareFuture.java:574)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearOptimisticTxPrepareFuture.prepareSingle(GridNearOptimisticTxPrepareFuture.java:401)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearOptimisticTxPrepareFuture.prepare0(GridNearOptimisticTxPrepareFuture.java:344)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearOptimisticTxPrepareFutureAdapter.prepareOnTopology(GridNearOptimisticTxPrepareFutureAdapter.java:137)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearOptimisticTxPrepareFutureAdapter.prepare(GridNearOptimisticTxPrepareFutureAdapter.java:74)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.prepareNearTxLocal(GridNearTxLocal.java:3161)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.commitNearTxLocalAsync(GridNearTxLocal.java:3221)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.optimisticPutFuture(GridNearTxLocal.java:2391)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.putAsync0(GridNearTxLocal.java:622)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.putAsync(GridNearTxLocal.java:385)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter$34.op(GridCacheAdapter.java:2707)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter$AsyncOp.op(GridCacheAdapter.java:5120)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.asyncOp(GridCacheAdapter.java:4260)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter$AsyncOpRetryFuture.execute(GridCacheAdapter.java:4841)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.asyncOp(GridCacheAdapter.java:4173)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.putAsync0(GridCacheAdapter.java:2705)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.putAsync(GridCacheAdapter.java:2689)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.replaceAsync(GridCacheAdapter.java:2776)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.replaceAsync(IgniteCacheProxyImpl.java:1182)
> at
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.replaceAsync(GatewayProtectedCacheProxy.java:1082)
> at
> org.apache.ignite.internal.processors.platform.cache.PlatformCache.processInStreamOutLong(PlatformCache.java:677)
> at
> org.apache.ignite.internal.processors.platform.PlatformTargetProxyImpl.inStreamOutLong(PlatformTargetProxyImpl.java:67)
> Caused by:
[jira] [Updated] (IGNITE-5300) .NET: LINQ RemoveAll and UpdateAll examples
[
https://issues.apache.org/jira/browse/IGNITE-5300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov updated IGNITE-5300:
Fix Version/s: (was: 2.7)
2.8
> .NET: LINQ RemoveAll and UpdateAll examples
> ---
>
> Key: IGNITE-5300
> URL: https://issues.apache.org/jira/browse/IGNITE-5300
> Project: Ignite
> Issue Type: Improvement
> Components: platforms
>Affects Versions: 2.1
>Reporter: Pavel Tupitsyn
>Priority: Major
> Labels: .NET, LINQ
> Fix For: 2.8
>
>
> Update examples (normal and LinqPad) to demonstrate {{RemoveAll}} and
> {{UpdateAll}} LINQ bulk operations (IGNITE-4904, IGNITE-5298).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9644) SQL: local DML query should pin affected partitions
[ https://issues.apache.org/jira/browse/IGNITE-9644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov updated IGNITE-9644: Fix Version/s: (was: 2.7) 2.8 > SQL: local DML query should pin affected partitions > --- > > Key: IGNITE-9644 > URL: https://issues.apache.org/jira/browse/IGNITE-9644 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Sergey Grimstad >Priority: Major > Fix For: 2.8 > > > Related to IGNITE-7039. Need to expand for DML. Commented out test market as > TODO: IGNITE-9644 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9229) Integration with Spark Data Frame. Add support for a ARRAY data type
[ https://issues.apache.org/jira/browse/IGNITE-9229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov updated IGNITE-9229: Fix Version/s: (was: 2.7) 2.8 > Integration with Spark Data Frame. Add support for a ARRAY data type > > > Key: IGNITE-9229 > URL: https://issues.apache.org/jira/browse/IGNITE-9229 > Project: Ignite > Issue Type: Bug > Components: spark >Affects Versions: 2.6 >Reporter: Nikolay Izhikov >Priority: Critical > Fix For: 2.8 > > > Currently, integration with Spark Data Frames doesn't support ARRAY data type. > We need to add support for it -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-3878) Add isPrimary() and isBackup() methods on CacheQUeryEntryEvent
[ https://issues.apache.org/jira/browse/IGNITE-3878?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov updated IGNITE-3878: Fix Version/s: (was: 2.7) 2.8 > Add isPrimary() and isBackup() methods on CacheQUeryEntryEvent > -- > > Key: IGNITE-3878 > URL: https://issues.apache.org/jira/browse/IGNITE-3878 > Project: Ignite > Issue Type: Improvement > Components: cache >Affects Versions: 1.7 >Reporter: Nikolai Tikhonov >Priority: Minor > Fix For: 2.8 > > > In some cases useful know where (on primary or backup nodes) was invoked a > continuous query filter. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-5848) Ignite should support Hibernate 5.2.X
[
https://issues.apache.org/jira/browse/IGNITE-5848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov updated IGNITE-5848:
Fix Version/s: (was: 2.7)
2.8
> Ignite should support Hibernate 5.2.X
> -
>
> Key: IGNITE-5848
> URL: https://issues.apache.org/jira/browse/IGNITE-5848
> Project: Ignite
> Issue Type: Sub-task
> Components: cache, hibernate
>Affects Versions: 2.0, 2.1
>Reporter: Nikolai Tikhonov
>Priority: Major
> Labels: community, java8
> Fix For: 2.8
>
>
> Currently Ignite supports Hibernate 5.1.X
> With Hibernate version of 5.2.X got the following exception:
> {code:java}
> Handler dispatch failed; nested exception is java.lang.AbstractMethodError:
> org.apache.ignite.cache.hibernate.HibernateEntityRegion$AccessStrategy.putFromLoad(Lorg/hibernate/engine/spi/SharedSessionContractImplementor;Ljava/lang/Object;Ljava/lang/Object;JLjava/lang/Object;Z)Z
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-6854) Enabling Persistent Memory for Ignite
[ https://issues.apache.org/jira/browse/IGNITE-6854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov updated IGNITE-6854: Fix Version/s: (was: 2.7) 2.8 > Enabling Persistent Memory for Ignite > - > > Key: IGNITE-6854 > URL: https://issues.apache.org/jira/browse/IGNITE-6854 > Project: Ignite > Issue Type: New Feature >Affects Versions: 2.3 >Reporter: Mulugeta Mammo >Priority: Major > Fix For: 2.8 > > > Ignite, when persistence mode is enabled, stores data and indexes on disk. To > minimize the latency of disks, several tuning options can be applied. Setting > the page size of a memory region to match the page size of the underlying > storage, using a separate disk for the WAL, and using production-level SSDs > are just a few of them [ > https://apacheignite.readme.io/docs/durable-memory-tuning#section-native-persistence-related-tuning > ]. > > A persistent memory store with low latency and high capacity offers a viable > alternative to disks. In light of this, we are proposing to make use of our > Low Level Persistent Library (LLPL), > https://github.com/pmem/pcj/tree/master/LLPL, to offer a persistent memory > storage for Ignite. > > At this point, we envision two distinct implementation options: > # Data and indexes will continue to be stored in the off-heap memory but the > disk will be replaced by a persistent memory. Since persistence memory in > this option is not a file system, the logic currently offered by WAL file and > the partition files would have to be implemented from scratch. > # In this option, we eliminate the current check-point process and the WAL > file. We will use a memory region defined by LLPL to store data and indexes. > There will be no off-heap memory. DRAM will be exclusively used to store hot > cache entries just like the on-heap cache is in the current implementation. > > > In both cases, there are more details and subtleties that have to handled – > e.g. the atomic and transactional guarantees offered. More clarifications > will be given as we go along. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8845) GridUnsafe.allocateMemory throws OutOfMemoryError which isn't handled
[ https://issues.apache.org/jira/browse/IGNITE-8845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov updated IGNITE-8845: Fix Version/s: (was: 2.7) 2.8 > GridUnsafe.allocateMemory throws OutOfMemoryError which isn't handled > - > > Key: IGNITE-8845 > URL: https://issues.apache.org/jira/browse/IGNITE-8845 > Project: Ignite > Issue Type: Bug > Components: general >Affects Versions: 2.5 >Reporter: Mikhail Cherkasov >Priority: Major > Fix For: 2.8 > > Attachments: Main.java > > > If there's no more native memory then Unsafe.allocateMemor throws > java.lang.OutOfMemoryError. Errors - is type of exception after which you > can't restore application and you need to close it and restart. I think in > this case we can handle it and throw IgniteOOM instead. > > Reproducer is attached, it throws the following exception: > > Exception in thread "main" java.lang.OutOfMemoryError > at sun.misc.Unsafe.allocateMemory(Native Method) > at > org.apache.ignite.internal.util.GridUnsafe.allocateMemory(GridUnsafe.java:1068) > at > org.apache.ignite.internal.mem.unsafe.UnsafeMemoryProvider.nextRegion(UnsafeMemoryProvider.java:80) > at > org.apache.ignite.internal.pagemem.impl.PageMemoryNoStoreImpl.addSegment(PageMemoryNoStoreImpl.java:612) > at > org.apache.ignite.internal.pagemem.impl.PageMemoryNoStoreImpl.allocatePage(PageMemoryNoStoreImpl.java:287) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-7115) .NET: Thin client: performance: use buffer pool
[
https://issues.apache.org/jira/browse/IGNITE-7115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov updated IGNITE-7115:
Fix Version/s: (was: 2.7)
2.8
> .NET: Thin client: performance: use buffer pool
> ---
>
> Key: IGNITE-7115
> URL: https://issues.apache.org/jira/browse/IGNITE-7115
> Project: Ignite
> Issue Type: Improvement
> Components: platforms, thin client
>Affects Versions: 2.4
>Reporter: Pavel Tupitsyn
>Priority: Major
> Labels: .NET, performance
> Fix For: 2.8
>
>
> Currently we allocate a lot of {{byte[]}} arrays for socket operations, which
> is suboptimal, especially for large arrays which go to Large Object Heap.
> Use a shared buffer pool instead, see {{PlatformMemoryPool}} for reference.
> Make sure to maintain correct detachment semantics:
> {{BinaryReader.ReadAsBinary}} in some cases may pass streamed array to user
> code.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-6665) Client node re-joins only to the list from disco configuration and ignores the rest nodes
[ https://issues.apache.org/jira/browse/IGNITE-6665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov updated IGNITE-6665: Fix Version/s: (was: 2.7) 2.8 > Client node re-joins only to the list from disco configuration and ignores > the rest nodes > - > > Key: IGNITE-6665 > URL: https://issues.apache.org/jira/browse/IGNITE-6665 > Project: Ignite > Issue Type: Bug > Components: general >Affects Versions: 2.2 >Reporter: Mikhail Cherkasov >Priority: Major > Fix For: 2.8 > > Attachments: ClientReJoinTest.java > > > Client node re-joins only to the list from disco configuration and ignores > the rest nodes. > if we have a cluster with 3 server nodes and in client discovery > configuration only 1 is mentioned and this server node left cluster, client > node will try to re-join only to this one and will ignore the rest 2 server > nodes. > Reproducer is attached. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-7136) .NET: IndexesAllocatedPages metrics
[ https://issues.apache.org/jira/browse/IGNITE-7136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov updated IGNITE-7136: Fix Version/s: (was: 2.7) 2.8 > .NET: IndexesAllocatedPages metrics > --- > > Key: IGNITE-7136 > URL: https://issues.apache.org/jira/browse/IGNITE-7136 > Project: Ignite > Issue Type: Sub-task > Components: platforms >Reporter: Nikolay Izhikov >Priority: Major > Labels: .NET, iep-6 > Fix For: 2.8 > > > New JMX metric implemented in IGNITE-6903. > We need to add support for this metric to .Net -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8118) sqlline.bat throws NPE under PowerShell in corner case
[
https://issues.apache.org/jira/browse/IGNITE-8118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov updated IGNITE-8118:
Fix Version/s: (was: 2.7)
2.8
> sqlline.bat throws NPE under PowerShell in corner case
> --
>
> Key: IGNITE-8118
> URL: https://issues.apache.org/jira/browse/IGNITE-8118
> Project: Ignite
> Issue Type: Bug
>Reporter: Pavel Konstantinov
>Priority: Major
> Fix For: 2.8
>
>
> {code}
> .\sqlline.bat -u
> "'jdbc:ignite:thin://18.17.12.22:9652?user=ignite=111'"
> No known driver to handle "'jdbc:ignite:thin://18.17.12.22:9652?user=ignite".
> Searching for known drivers...
> java.lang.NullPointerException
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-8157) Remove boilerplate and unused code due to grids stopping by default
[
https://issues.apache.org/jira/browse/IGNITE-8157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov updated IGNITE-8157:
Fix Version/s: (was: 2.7)
2.8
> Remove boilerplate and unused code due to grids stopping by default
> ---
>
> Key: IGNITE-8157
> URL: https://issues.apache.org/jira/browse/IGNITE-8157
> Project: Ignite
> Issue Type: Task
>Affects Versions: 2.4
>Reporter: Maxim Muzafarov
>Priority: Minor
> Labels: test
> Fix For: 2.8
>
>
> Changes IGNITE-6842 guarantee us stopping all Ignite instances after test
> completion by default.
> # We should remove a lot of bolerplate code in our test-classes.
> e.g.
> {code:java|title=BaseDecisionTreeTest.java|borderStyle=solid}
> /** {@inheritDoc} */
> @Override protected void afterTestsStopped() throws Exception {
> stopAllGrids();
> }
> {code}
> # We shuold carefully review whole usages of stopAllGrids method in our
> test-classes and remove if it not necessary anymore or change for using in
> proper way\position.
> e.g.
> {code:java|title=TcpClientDiscoverySpiSelfTest.java|borderStyle=solid}
> /** {@inheritDoc} */
> @Override protected void afterTest() throws Exception {
> stopAllClients(true);
> stopAllServers(true);
>
> ...
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-6753) Allow plugable page memory for testing purpose
[ https://issues.apache.org/jira/browse/IGNITE-6753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov updated IGNITE-6753: Fix Version/s: (was: 2.7) 2.8 > Allow plugable page memory for testing purpose > -- > > Key: IGNITE-6753 > URL: https://issues.apache.org/jira/browse/IGNITE-6753 > Project: Ignite > Issue Type: Improvement > Components: general > Environment: Allow plugable page memory for testing proposes. We need > this ability to force fast IgniteOOM in tests. >Reporter: Mikhail Cherkasov >Priority: Minor > Fix For: 2.8 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-1903) Cache configuration is serialized to nodes whether they require it or not
[
https://issues.apache.org/jira/browse/IGNITE-1903?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov updated IGNITE-1903:
Fix Version/s: (was: 2.7)
2.8
> Cache configuration is serialized to nodes whether they require it or not
> -
>
> Key: IGNITE-1903
> URL: https://issues.apache.org/jira/browse/IGNITE-1903
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 1.5.0.final
>Reporter: Michael Griggs
>Priority: Major
> Labels: community, usability
> Fix For: 2.8
>
>
> See User discussion thread:
> http://apache-ignite-users.70518.x6.nabble.com/CacheStore-being-serialized-to-client-td1931.html
> Brief summary: When a grid client joins the grid (clientMode=true) it
> receives a message from the server node(s) on the grid that contains the
> serialized CacheStore implementation object. If the client does not have
> this class on its CLASSPATH (and there is no reason it should, as it is a
> client) then the de-serialization of this message will fail, causing this
> exception:
> {code}SEVERE: Failed to unmarshal discovery data for component: 1
> class org.apache.ignite.IgniteCheckedException: Failed to find class with
> given class loader for unmarshalling (make sure same versions of all classes
> are available on all nodes or enable peer-class-loading):
> sun.misc.Launcher$AppClassLoader@14dad5dc
> at
> org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal(JdkMarshaller.java:104)
>
> at
> org.apache.ignite.marshaller.AbstractMarshaller.unmarshal(AbstractMarshaller.java:67)
>
> at
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.onExchange(TcpDiscoverySpi.java:1529)
>
> at
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.processNodeAddFinishedMessage(ClientImpl.java:1317)
>
> at
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.processDiscoveryMessage(ClientImpl.java:1229)
>
> at
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.body(ClientImpl.java:1199)
>
> at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
> Caused by: java.lang.ClassNotFoundException:
> c.g.r.cachewrapper.ignite.CacheMissHandlerIgnite
> {code}
> where {{c.g.r.cachewrapper.ignite.CacheMissHandlerIgnite}} is the CacheStore
> implementation.
> The ostensible reason for the CacheStore serialization is so that clients of
> a TRANSACTIONAL cache can begin the transaction on the underlying store.
> The only current solution to this is to add the grid node's CacheStore
> implementation class definition to the CLASSPATH of the client. This creates
> an *undesirable coupling* between server and client.
> ---
> *UPDATE (copy-paste from comment below)*
> This is actually more generic issue. When a new node joins (client or
> server), all existing cache configurations (which include cache stores) are
> sent to this node. It then deserializes it during startup which can cause
> exceptions on clients or servers where cache is not supposed to be deployed
> as defined by node filter.
> As a solution we can do the following:
> * During discovery, send node filter and cache store factory in binary format
> along with the cache configuration, not as its parts.
> * On server, check node filter first and deserialize cache configuration and
> cache store only if it returns true. In case of error, STOP join process (now
> we just print exception in log and go on, which is very error-prone).
> * On client, do not deserialize cache configuration and cache store until
> user's code tries to actually use the cache (calls Ignite.cache. If cache is
> ATOMIC, never deserialize the cache store.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-8558) Provide an opportunity to stop grids and cancel tasks after execution all tests
[ https://issues.apache.org/jira/browse/IGNITE-8558?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov updated IGNITE-8558: Fix Version/s: (was: 2.7) 2.8 > Provide an opportunity to stop grids and cancel tasks after execution all > tests > --- > > Key: IGNITE-8558 > URL: https://issues.apache.org/jira/browse/IGNITE-8558 > Project: Ignite > Issue Type: Sub-task >Reporter: Maxim Muzafarov >Priority: Minor > Labels: newbie > Fix For: 2.8 > > > IGNITE-6842 guarantee us stopping all Ignite instances after test completion > by default and stopping it without cancelling tasks. > User should have ability to override this behavior and use stopAllGirds(true) > after all tests execution. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-7028) Memcached does not set type flags for response
[ https://issues.apache.org/jira/browse/IGNITE-7028?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov updated IGNITE-7028: Fix Version/s: (was: 2.7) 2.8 > Memcached does not set type flags for response > -- > > Key: IGNITE-7028 > URL: https://issues.apache.org/jira/browse/IGNITE-7028 > Project: Ignite > Issue Type: Bug > Components: rest >Affects Versions: 2.3 >Reporter: Mikhail Cherkasov >Priority: Major > Fix For: 2.8 > > > Memcached does not set type flags for response: > http://apache-ignite-users.70518.x6.nabble.com/Memcached-doesn-t-store-flags-td18403.html -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-7458) NPE occurs after node restart with native persistence enabled.
[ https://issues.apache.org/jira/browse/IGNITE-7458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov updated IGNITE-7458: Fix Version/s: (was: 2.7) 2.8 > NPE occurs after node restart with native persistence enabled. > -- > > Key: IGNITE-7458 > URL: https://issues.apache.org/jira/browse/IGNITE-7458 > Project: Ignite > Issue Type: Bug > Components: persistence >Affects Versions: 2.3 >Reporter: Mikhail Cherkasov >Priority: Major > Fix For: 2.8 > > > We have a report from a user: > [http://apache-ignite-users.70518.x6.nabble.com/NPE-from-the-native-persistence-enable-node-td19555.html] > > it says that NPE occurred after node restart with native persistence enabled. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8622) Zookeeper and TCP discovery SPI' getSpiState method inconsistent
[ https://issues.apache.org/jira/browse/IGNITE-8622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov updated IGNITE-8622: Fix Version/s: (was: 2.7) 2.8 > Zookeeper and TCP discovery SPI' getSpiState method inconsistent > > > Key: IGNITE-8622 > URL: https://issues.apache.org/jira/browse/IGNITE-8622 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.5 >Reporter: Max Shonichev >Priority: Minor > Labels: jmx > Fix For: 2.8 > > > getSpiState of TcpDiscoverySpi Mbean returns uppercased human-readable state, > e.g. 'CONNECTED' > getSpiState of ZookeeperDiscoverySpi Mbean returns camelcased one, e.g. > 'Connected' -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8621) TcpDiscoverySpi's UpTime/StartTimestamp methods do not work
[ https://issues.apache.org/jira/browse/IGNITE-8621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov updated IGNITE-8621: Fix Version/s: (was: 2.7) 2.8 > TcpDiscoverySpi's UpTime/StartTimestamp methods do not work > --- > > Key: IGNITE-8621 > URL: https://issues.apache.org/jira/browse/IGNITE-8621 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.5 >Reporter: Max Shonichev >Priority: Major > Labels: jmx > Fix For: 2.8 > > Attachments: Screenshot from 2018-05-28 12-57-13.png > > > getUpTime and getStartTimestamp methods of TcpDiscoverySpiMBeanImpl returns > 0, which does not look like normal value > also, getUpTimeFormatted returns 00:00:00.000 and getStartTimestampFormatted > returns Jan 1, 1970 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9292) MVCC SQL: Unexpected state exception when updating backup
[
https://issues.apache.org/jira/browse/IGNITE-9292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov updated IGNITE-9292:
Fix Version/s: (was: 2.7)
2.8
> MVCC SQL: Unexpected state exception when updating backup
> -
>
> Key: IGNITE-9292
> URL: https://issues.apache.org/jira/browse/IGNITE-9292
> Project: Ignite
> Issue Type: Bug
> Components: mvcc, sql
>Reporter: Ivan Pavlukhin
>Priority: Major
> Fix For: 2.8
>
> Attachments: MvccInsertUpdateConcurrent.java
>
>
> Unexpected state exception is observed during concurrent execution insert and
> fast update for same key.
> One of observed with concurrent update and insert for the same key from the
> same node serializes as follows:
> 1. insert on primary
> 2. insert on backup
> 3. update on primary waits on lock
> 4. insert is prepared on backup
> 5. insert is prepared on primary
> 6. insert is committed on primary (before committing on backup)
> 7. update waiting on lock wakes up
> 8. update is executed on primary
> 9. update fails on backup because sees inserted row in prepared state
> It is one possible erroneous scenario. There might be others. TX log update
> procedure should be thoroughly reviewed.
> {noformat}
> [2018-08-16
> 16:32:25,452][ERROR][ForkJoinPool.commonPool-worker-2][DmlStatementsProcessor]
> Error during update [localNodeId=6709af72-2fe9-4eab-9ee5-be83eab0]
> class org.apache.ignite.IgniteCheckedException: Failed to update backup node:
> [localNodeId=6709af72-2fe9-4eab-9ee5-be83eab0,
> remoteNodeId=4ca5b185-c5d1-4756-8977-e57aec31]
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxAbstractEnlistFuture.onResult(GridDhtTxAbstractEnlistFuture.java:931)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter.processDhtTxQueryEnlistResponse(GridDhtTransactionalCacheAdapter.java:2245)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter.access$1000(GridDhtTransactionalCacheAdapter.java:106)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter$16.apply(GridDhtTransactionalCacheAdapter.java:237)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter$16.apply(GridDhtTransactionalCacheAdapter.java:235)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1056)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:581)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:380)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:306)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:101)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:295)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1569)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1197)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:127)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1093)
> at
> org.apache.ignite.internal.util.StripedExecutor$Stripe.body(StripedExecutor.java:496)
> at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: class org.apache.ignite.IgniteCheckedException: Runtime failure on
> bounds: [lower=MvccMaxSearchRow [], upper=MvccMinSearchRow []]
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.visit(BPlusTree.java:1047)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.mvccUpdate(IgniteCacheOffheapManagerImpl.java:1887)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.mvccUpdate(IgniteCacheOffheapManagerImpl.java:523)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.mvccSet(GridCacheMapEntry.java:1080)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxRemote.mvccEnlistBatch(GridDhtTxRemote.java:451)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter.processDhtTxQueryEnlistRequest(GridDhtTransactionalCacheAdapter.java:2209)
> at
>
[jira] [Updated] (IGNITE-7371) MVCC: Repeatable read TX should cache entries locally.
[ https://issues.apache.org/jira/browse/IGNITE-7371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov updated IGNITE-7371: Fix Version/s: (was: 2.7) 2.8 > MVCC: Repeatable read TX should cache entries locally. > -- > > Key: IGNITE-7371 > URL: https://issues.apache.org/jira/browse/IGNITE-7371 > Project: Ignite > Issue Type: New Feature > Components: cache, mvcc >Reporter: Igor Seliverstov >Priority: Major > Fix For: 2.8 > > > Repeatable read isolation implies that each GET operation whithin tx gets a > last commited version of entry *at the time the tx was started*. > A value that just has been got, should be cached locally in TX to avoid > remote call on repeatable get(). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8352) IgniteStandByClusterSuite: IgniteClusterActivateDeactivateTest.testClientReconnectClusterDeactivateInProgress flaky fail rate 12%
[ https://issues.apache.org/jira/browse/IGNITE-8352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov updated IGNITE-8352: Fix Version/s: (was: 2.7) 2.8 > IgniteStandByClusterSuite: > IgniteClusterActivateDeactivateTest.testClientReconnectClusterDeactivateInProgress > flaky fail rate 12% > - > > Key: IGNITE-8352 > URL: https://issues.apache.org/jira/browse/IGNITE-8352 > Project: Ignite > Issue Type: Test >Reporter: Maxim Muzafarov >Priority: Major > Labels: MakeTeamcityGreenAgain > Fix For: 2.8 > > > IgniteStandByClusterSuite: > IgniteClusterActivateDeactivateTest.testClientReconnectClusterDeactivateInProgress > (master fail rate 12,8%) > [https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=5210129488604303757=%3Cdefault%3E=testDetails] > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-7176) SqlQuery does not always find matching entries
[ https://issues.apache.org/jira/browse/IGNITE-7176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov updated IGNITE-7176: Fix Version/s: (was: 2.7) 2.8 > SqlQuery does not always find matching entries > -- > > Key: IGNITE-7176 > URL: https://issues.apache.org/jira/browse/IGNITE-7176 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.3, 2.4 >Reporter: Markus Kinzler >Priority: Critical > Fix For: 2.8 > > Attachments: sqlbug.zip > > > When the @QuerySqlField annotation is put on a custom class, the sql query > sometimes does not find the entry. > With an cache of 100'000 entries, the problem occurs in about 50% of the test > runs for 1 - 2 entries. > When the entry is not found, no log statement is written and no exception is > thrown, but the result is missing, despite beeing accessible via > cache.get(key). > Note that i could not reproduce the Issue when i rename the class > LegaldocAcceptPk to TestEntityPk. > A reproducible unit test is attached. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9622) MVCC Cache API: prohibit non PESSIMISTIC REPEATABLE_READ transactions
[ https://issues.apache.org/jira/browse/IGNITE-9622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov updated IGNITE-9622: Fix Version/s: (was: 2.7) 2.8 > MVCC Cache API: prohibit non PESSIMISTIC REPEATABLE_READ transactions > - > > Key: IGNITE-9622 > URL: https://issues.apache.org/jira/browse/IGNITE-9622 > Project: Ignite > Issue Type: Bug > Components: mvcc >Reporter: Ivan Pavlukhin >Priority: Major > Fix For: 2.8 > > > For cache with enabled mvcc we should allow running only PESSIMISTIC > REPEATABLE_READ transactions. For other modes exception should be thrown > (like is done for SQL API). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-7731) ClassCastException at restarted node if killed during checkpoint
[
https://issues.apache.org/jira/browse/IGNITE-7731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov updated IGNITE-7731:
Fix Version/s: (was: 2.7)
2.8
> ClassCastException at restarted node if killed during checkpoint
>
>
> Key: IGNITE-7731
> URL: https://issues.apache.org/jira/browse/IGNITE-7731
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.3
>Reporter: Ksenia Rybakova
>Priority: Major
> Fix For: 2.8
>
> Attachments:
> 120728_id11_172.25.1.49_cache-random-benchmark-2-backup.log,
> 121729_id11-1_172.25.1.49cache-random-benchmark-2-backup.log,
> ignite-base-load-config.xml, run-load.properties, run-load.xml
>
>
> During failover test restarted node fails to start with the following
> exception:
> {noformat}
> [2018-02-15 12:17:46,388][INFO
> ][exchange-worker-#62][GridCacheDatabaseSharedManager] Read checkpoint status
> [startMarker=/storage/ssd/krybakova/20181502-120637-2.3.0-SNAPSHOT-failover-756ae8d4-c12-s24-p20-r40-b2-d7200/yardstick/work/db/node00-730721d0-e532-4f3a-b9e9-29277c0b7a9a/cp/1518685946892-39fa4858-66cb-4c88-9a1c-13a8625e1158-START.bin,
> endMarker=null]
> [2018-02-15 12:17:46,389][INFO
> ][exchange-worker-#62][GridCacheDatabaseSharedManager] Checking memory state
> [lastValidPos=FileWALPointer [idx=0, fileOffset=0, len=0, forceFlush=false],
> lastMarked=FileWALPointer [idx=1, fileOffset=47809760, len=177151,
> forceFlush=false], lastCheckpointId=39fa4858-66cb-4c88-9a1c-13a8625e1158]
> [2018-02-15 12:17:46,389][WARN
> ][exchange-worker-#62][GridCacheDatabaseSharedManager] Ignite node stopped in
> the middle of checkpoint. Will restore memory state and finish checkpoint on
> node start.
> [2018-02-15
> 12:17:46,448][ERROR][exchange-worker-#62][GridDhtPartitionsExchangeFuture]
> Failed to reinitialize local partitions (preloading will be stopped):
> GridDhtPartitionExchangeId [topVer=AffinityTopologyVersion [topVer=38,
> minorTopVer=0], discoEvt=DiscoveryEvent [evtNode=TcpDiscoveryNode
> [id=b8684b5c-29f5-41db-bedc-f4b4ee4cab6b, addrs=[127.0.0.1, 172.25.1.49],
> sockAddrs=[lab49.gridgain.local/172.25.1.49:47500, /127.0.0.1:47500],
> discPort=47500, order=38, intOrder=37, lastExchangeTime=1518686253183,
> loc=true, ver=2.3.0#20180213-sha1:756ae8d4, isClient=false], topVer=38,
> nodeId8=b8684b5c, msg=null, type=NODE_JOINED, tstamp=1518686266006],
> nodeId=b8684b5c, evt=NODE_JOINED]
> java.lang.ClassCastException:
> org.apache.ignite.internal.pagemem.impl.PageMemoryNoStoreImpl cannot be cast
> to
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryEx
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.getPageMemoryForCacheGroup(GridCacheDatabaseSharedManager.java:1595)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.restoreMemory(GridCacheDatabaseSharedManager.java:1533)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.readCheckpointAndRestoreMemory(GridCacheDatabaseSharedManager.java:568)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.initCachesOnLocalJoin(GridDhtPartitionsExchangeFuture.java:724)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:611)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2279)
> at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> This happens if node was killed during checkpoint (it seems only during the
> first one).
> Load conifg:
> * Yardstick with CacheRandomOperationBenchmark
> * 12 client nodes, 24 server nodes, 12 hosts (2 per host). The issue is also
> reproduced when restarted node is 1 per host.
> * Several caches with different configs: pds/in memory, tx/atomic,
> with/without eviction etc. No dynamic caches. Complete configs are attached.
> * 1 node is restarted periodically.
> Logs of restarted node are attached.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-7384) MVCC TX: Support historical rebalance
[
https://issues.apache.org/jira/browse/IGNITE-7384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov updated IGNITE-7384:
Fix Version/s: (was: 2.7)
2.8
> MVCC TX: Support historical rebalance
> -
>
> Key: IGNITE-7384
> URL: https://issues.apache.org/jira/browse/IGNITE-7384
> Project: Ignite
> Issue Type: Task
> Components: mvcc
>Reporter: Igor Seliverstov
>Priority: Major
> Fix For: 2.8
>
>
> In case a node returns to topology it requests a delta instead of full
> partition, WAL-based iterator is used there
> ({{o.a.i.i.processors.cache.persistence.GridCacheOffheapManager#rebalanceIterator}})
> WAL-based iterator doesn't contain MVCC versions which causes issues.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9489) CorruptedTreeException on index create.
[
https://issues.apache.org/jira/browse/IGNITE-9489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov updated IGNITE-9489:
Fix Version/s: (was: 2.7)
2.8
> CorruptedTreeException on index create.
> ---
>
> Key: IGNITE-9489
> URL: https://issues.apache.org/jira/browse/IGNITE-9489
> Project: Ignite
> Issue Type: Bug
> Components: cache, sql
>Affects Versions: 2.4, 2.5, 2.6
>Reporter: Igor Seliverstov
>Priority: Major
> Fix For: 2.8
>
> Attachments: Test.java
>
>
> Currently on dynamic index drop with enabled persistence H2TreeIndex
> instances aren't destroyed. That means that their root pages aren't removed
> from meta tree (see
> {{org.apache.ignite.internal.processors.cache.persistence.IndexStorageImpl#getOrAllocateForTree}})
> and reused on subsequent dynamic index create that leads
> CorruptedTreeException on initial index rebuild because there are some items
> with broken links on the root page.
> Reproducer attached.
> Error log:
> {noformat}
> Error during parallel index create/rebuild.
> org.h2.message.DbException: Внутренняя ошибка: "class
> org.apache.ignite.internal.processors.cache.persistence.tree.CorruptedTreeException:
> Runtime failure on row: Row@7745722d[ key:
> org.apache.ignite.internal.processors.cache.index.AbstractSchemaSelfTest$KeyClass
> [idHash=2038596277, hash=-1388553726, id=1], val:
> org.apache.ignite.internal.processors.cache.index.AbstractSchemaSelfTest$ValueClass
> [idHash=2109544797, hash=-898815788, field1=val1], ver: GridCacheVersion
> [topVer=147733489, order=1536253488473, nodeOrder=2] ][ 1, val1, null ]"
> General error: "class
> org.apache.ignite.internal.processors.cache.persistence.tree.CorruptedTreeException:
> Runtime failure on row: Row@7745722d[ key:
> org.apache.ignite.internal.processors.cache.index.AbstractSchemaSelfTest$KeyClass
> [idHash=2038596277, hash=-1388553726, id=1], val:
> org.apache.ignite.internal.processors.cache.index.AbstractSchemaSelfTest$ValueClass
> [idHash=2109544797, hash=-898815788, field1=val1], ver: GridCacheVersion
> [topVer=147733489, order=1536253488473, nodeOrder=2] ][ 1, val1, null ]"
> [5-195]
> at org.h2.message.DbException.get(DbException.java:168)
> at org.h2.message.DbException.convert(DbException.java:295)
> at
> org.apache.ignite.internal.processors.query.h2.database.H2TreeIndex.putx(H2TreeIndex.java:251)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing$3.apply(IgniteH2Indexing.java:890)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.updateIndex(GridCacheMapEntry.java:4320)
> at
> org.apache.ignite.internal.processors.query.schema.SchemaIndexCacheVisitorImpl.processKey(SchemaIndexCacheVisitorImpl.java:244)
> at
> org.apache.ignite.internal.processors.query.schema.SchemaIndexCacheVisitorImpl.processPartition(SchemaIndexCacheVisitorImpl.java:207)
> at
> org.apache.ignite.internal.processors.query.schema.SchemaIndexCacheVisitorImpl.processPartitions(SchemaIndexCacheVisitorImpl.java:166)
> at
> org.apache.ignite.internal.processors.query.schema.SchemaIndexCacheVisitorImpl.access$100(SchemaIndexCacheVisitorImpl.java:50)
> at
> org.apache.ignite.internal.processors.query.schema.SchemaIndexCacheVisitorImpl$AsyncWorker.body(SchemaIndexCacheVisitorImpl.java:317)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: org.h2.jdbc.JdbcSQLException: Внутренняя ошибка: "class
> org.apache.ignite.internal.processors.cache.persistence.tree.CorruptedTreeException:
> Runtime failure on row: Row@7745722d[ key:
> org.apache.ignite.internal.processors.cache.index.AbstractSchemaSelfTest$KeyClass
> [idHash=2038596277, hash=-1388553726, id=1], val:
> org.apache.ignite.internal.processors.cache.index.AbstractSchemaSelfTest$ValueClass
> [idHash=2109544797, hash=-898815788, field1=val1], ver: GridCacheVersion
> [topVer=147733489, order=1536253488473, nodeOrder=2] ][ 1, val1, null ]"
> General error: "class
> org.apache.ignite.internal.processors.cache.persistence.tree.CorruptedTreeException:
> Runtime failure on row: Row@7745722d[ key:
> org.apache.ignite.internal.processors.cache.index.AbstractSchemaSelfTest$KeyClass
> [idHash=2038596277, hash=-1388553726, id=1], val:
> org.apache.ignite.internal.processors.cache.index.AbstractSchemaSelfTest$ValueClass
> [idHash=2109544797, hash=-898815788, field1=val1], ver: GridCacheVersion
> [topVer=147733489, order=1536253488473, nodeOrder=2] ][ 1, val1, null ]"
> [5-195]
> at org.h2.message.DbException.getJdbcSQLException(DbException.java:345)
> ... 12 more
> Caused by: class
>
[jira] [Updated] (IGNITE-9293) CPP: Add API to set baseline topology for C++
[ https://issues.apache.org/jira/browse/IGNITE-9293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov updated IGNITE-9293: Fix Version/s: (was: 2.7) > CPP: Add API to set baseline topology for C++ > -- > > Key: IGNITE-9293 > URL: https://issues.apache.org/jira/browse/IGNITE-9293 > Project: Ignite > Issue Type: New Feature > Components: platforms >Affects Versions: 2.6 >Reporter: Igor Sapego >Priority: Major > Labels: cpp > Fix For: 2.8 > > > We need to add API for C++ to set baseline topology. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8310) CPP: Remove strong dependency on Boost 1.58.0
[ https://issues.apache.org/jira/browse/IGNITE-8310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov updated IGNITE-8310: Fix Version/s: (was: 2.7) 2.8 > CPP: Remove strong dependency on Boost 1.58.0 > - > > Key: IGNITE-8310 > URL: https://issues.apache.org/jira/browse/IGNITE-8310 > Project: Ignite > Issue Type: Improvement > Components: odbc, platforms >Affects Versions: 2.4 >Reporter: Igor Sapego >Priority: Major > Labels: boost, cpp, odbc > Fix For: 2.8 > > > Currently, tests for C++ client and ODBC depend on the Boost 1.58.0. There is > a strong dependency on the exact version, which causes troubles for the > developers and which should not be there from the very beginning as we do not > really need some features from this particular version. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9559) Node.js thin: nodejs directory should be included binary release
[
https://issues.apache.org/jira/browse/IGNITE-9559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov updated IGNITE-9559:
Fix Version/s: (was: 2.7)
2.8
> Node.js thin: nodejs directory should be included binary release
>
>
> Key: IGNITE-9559
> URL: https://issues.apache.org/jira/browse/IGNITE-9559
> Project: Ignite
> Issue Type: Improvement
> Components: build, thin client
>Reporter: Igor Sapego
>Priority: Major
> Labels: nodejs
> Fix For: 2.8
>
>
> Currently, nodejs directory is not generated by the {{maven install}}
> command. Need to add appropriate copy steps to
> {{assembly/release-fabric-base.xml}} file.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-8626) ODBC: Can not compile ODBC with OpenSSL 1.1
[ https://issues.apache.org/jira/browse/IGNITE-8626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov updated IGNITE-8626: Fix Version/s: (was: 2.7) 2.8 > ODBC: Can not compile ODBC with OpenSSL 1.1 > --- > > Key: IGNITE-8626 > URL: https://issues.apache.org/jira/browse/IGNITE-8626 > Project: Ignite > Issue Type: Bug > Components: odbc >Affects Versions: 2.4 >Reporter: Igor Sapego >Priority: Major > Labels: newbie > Fix For: 2.8 > > Attachments: 01(1).patch > > > Can not compile ODBC with OpenSSL 1.1. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9293) CPP: Add API to set baseline topology for C++
[ https://issues.apache.org/jira/browse/IGNITE-9293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov updated IGNITE-9293: Fix Version/s: 2.8 > CPP: Add API to set baseline topology for C++ > -- > > Key: IGNITE-9293 > URL: https://issues.apache.org/jira/browse/IGNITE-9293 > Project: Ignite > Issue Type: New Feature > Components: platforms >Affects Versions: 2.6 >Reporter: Igor Sapego >Priority: Major > Labels: cpp > Fix For: 2.8 > > > We need to add API for C++ to set baseline topology. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9583) PHP thin: php directory should be included in binary release
[
https://issues.apache.org/jira/browse/IGNITE-9583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov updated IGNITE-9583:
Fix Version/s: (was: 2.7)
2.8
> PHP thin: php directory should be included in binary release
>
>
> Key: IGNITE-9583
> URL: https://issues.apache.org/jira/browse/IGNITE-9583
> Project: Ignite
> Issue Type: Improvement
> Components: build, thin client
>Reporter: Igor Sapego
>Priority: Major
> Labels: php
> Fix For: 2.8
>
>
> Currently, php directory is not generated by the {{maven install}} command.
> Need to add appropriate copy steps to {{assembly/release-fabric-base.xml}}
> file.
> The following components should be copied:
> {noformat}
> ignite/modules/platforms/php/composer.json
> ignite/modules/platforms/php/src
> ignite/modules/platforms/php/examples
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9257) LOCAL cache doesn't evict entries from heap
[ https://issues.apache.org/jira/browse/IGNITE-9257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov updated IGNITE-9257: Fix Version/s: (was: 2.7) 2.8 > LOCAL cache doesn't evict entries from heap > --- > > Key: IGNITE-9257 > URL: https://issues.apache.org/jira/browse/IGNITE-9257 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.6 >Reporter: Dmitry Karachentsev >Priority: Critical > Fix For: 2.8 > > > Reproducer > http://apache-ignite-users.70518.x6.nabble.com/When-using-CacheMode-LOCAL-OOM-td23285.html > This happens because all entries are kept in GridCacheAdapter#map. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-7651) Assertion error on cache start while reading meta pages
[
https://issues.apache.org/jira/browse/IGNITE-7651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov updated IGNITE-7651:
Fix Version/s: (was: 2.7)
2.8
> Assertion error on cache start while reading meta pages
> ---
>
> Key: IGNITE-7651
> URL: https://issues.apache.org/jira/browse/IGNITE-7651
> Project: Ignite
> Issue Type: Bug
>Reporter: Eduard Shangareev
>Priority: Critical
> Fix For: 2.8
>
>
> We recently have added assertion. Now it has found issue with start cache
> after restart.
> {code:java}
> java.lang.AssertionError: calculatedOffset=16384, allocated=8192,
> headerSize=4096
> at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStore.read(FilePageStore.java:341)
> at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.read(FilePageStoreManager.java:322)
> at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.read(FilePageStoreManager.java:306)
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.acquirePage(PageMemoryImpl.java:658)
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.acquirePage(PageMemoryImpl.java:578)
> at
> org.apache.ignite.internal.processors.cache.persistence.DataStructure.acquirePage(DataStructure.java:130)
> at
> org.apache.ignite.internal.processors.cache.persistence.freelist.PagesList.init(PagesList.java:167)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.reuse.ReuseListImpl.(ReuseListImpl.java:56)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager.initDataStructures(GridCacheOffheapManager.java:103)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.start(IgniteCacheOffheapManagerImpl.java:131)
> at
> org.apache.ignite.internal.processors.cache.CacheGroupContext.start(CacheGroupContext.java:893)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.startCacheGroup(GridCacheProcessor.java:1979)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheStart(GridCacheProcessor.java:1869)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.startCachesOnLocalJoin(GridCacheProcessor.java:1759)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.initCachesOnLocalJoin(GridDhtPartitionsExchangeFuture.java:769)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:651)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2337)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:748)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-7899) Write Zookeeper Discovery documentation in java docs
[ https://issues.apache.org/jira/browse/IGNITE-7899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov updated IGNITE-7899: Fix Version/s: (was: 2.7) 2.8 > Write Zookeeper Discovery documentation in java docs > > > Key: IGNITE-7899 > URL: https://issues.apache.org/jira/browse/IGNITE-7899 > Project: Ignite > Issue Type: Task > Components: zookeeper >Affects Versions: 2.5 >Reporter: Dmitry Sherstobitov >Priority: Major > Fix For: 2.8 > > > Describe Zookeeper Discovery in java docs -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-7351) Create a page for continuous queries
[ https://issues.apache.org/jira/browse/IGNITE-7351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov updated IGNITE-7351: Fix Version/s: (was: 2.7) 2.8 > Create a page for continuous queries > > > Key: IGNITE-7351 > URL: https://issues.apache.org/jira/browse/IGNITE-7351 > Project: Ignite > Issue Type: Task > Components: site >Reporter: Denis Magda >Priority: Major > Fix For: 2.8 > > > Create a page for continuous queries putting it under Features menu on the > site. This capability is a strong distinguisher from relational databases > that do not support continuous notifications and processing built around them. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8500) [Cassandra] Allow dynamic cache creation with Cassandra Store
[
https://issues.apache.org/jira/browse/IGNITE-8500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov updated IGNITE-8500:
Fix Version/s: (was: 2.7)
2.8
> [Cassandra] Allow dynamic cache creation with Cassandra Store
> -
>
> Key: IGNITE-8500
> URL: https://issues.apache.org/jira/browse/IGNITE-8500
> Project: Ignite
> Issue Type: Improvement
> Components: cassandra
>Affects Versions: 2.5
>Reporter: Dmitry Karachentsev
>Priority: Major
> Fix For: 2.8
>
>
> It's not possible for now dynamically create caches with Cassandra cache
> store:
> {noformat}
> class org.apache.ignite.IgniteCheckedException: null
> at
> org.apache.ignite.internal.util.IgniteUtils.cast(IgniteUtils.java:7307)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.resolve(GridFutureAdapter.java:259)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:207)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:159)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:151)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body0(GridCachePartitionExchangeManager.java:2433)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2299)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.NullPointerException
> at
> org.apache.ignite.cache.store.cassandra.persistence.PojoField.calculatedField(PojoField.java:155)
> at
> org.apache.ignite.cache.store.cassandra.persistence.PersistenceController.prepareLoadStatements(PersistenceController.java:313)
> at
> org.apache.ignite.cache.store.cassandra.persistence.PersistenceController.(PersistenceController.java:85)
> at
> org.apache.ignite.cache.store.cassandra.CassandraCacheStore.(CassandraCacheStore.java:106)
> at
> org.apache.ignite.cache.store.cassandra.CassandraCacheStoreFactory.create(CassandraCacheStoreFactory.java:59)
> at
> org.apache.ignite.cache.store.cassandra.CassandraCacheStoreFactory.create(CassandraCacheStoreFactory.java:34)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.createCache(GridCacheProcessor.java:1437)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheStart(GridCacheProcessor.java:1945)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.startReceivedCaches(GridCacheProcessor.java:1864)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:674)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body0(GridCachePartitionExchangeManager.java:2419)
> ... 3 more
> {noformat}
> PR with test https://github.com/apache/ignite/pull/4003
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-8986) Need to add configuration validation template on startup
[ https://issues.apache.org/jira/browse/IGNITE-8986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov updated IGNITE-8986: Fix Version/s: (was: 2.7) 2.8 > Need to add configuration validation template on startup > > > Key: IGNITE-8986 > URL: https://issues.apache.org/jira/browse/IGNITE-8986 > Project: Ignite > Issue Type: Improvement > Components: general >Reporter: Dmitriy Setrakyan >Priority: Major > Fix For: 2.8 > > > We should have a validation template file (e.g. ignite-validate.xml), and > make sure on startup that all config properties specified in that file match. > This way a user could put this file somewhere on a shared network drive and > have an extra degree of confidence that the configuration is valid. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-6454) Data structure suite timeout: test is not able to fail after interruption
[
https://issues.apache.org/jira/browse/IGNITE-6454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov updated IGNITE-6454:
Fix Version/s: (was: 2.7)
2.8
> Data structure suite timeout: test is not able to fail after interruption
> -
>
> Key: IGNITE-6454
> URL: https://issues.apache.org/jira/browse/IGNITE-6454
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Dmitriy Pavlov
>Priority: Critical
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.8
>
> Attachments:
> lastStartedTest_GridCacheReplicatedDataStructuresFailoverSelfTest.testFairReentrantLockConstantMultipleTopologyChangeNonFailoverSafe.log.zip,
>
> lastStartedTest_GridCacheReplicatedDataStructuresFailoverSelfTest.testReentrantLockConstantMultipleTopologyChangeNonFailoverSafe.log.zip
>
>
> https://ci.ignite.apache.org/viewType.html?buildTypeId=Ignite20Tests_IgniteDataStrucutures=%3Cdefault%3E=buildTypeStatusDiv
> Most often timeout is caused by following tests:
> GridCacheReplicatedDataStructuresFailoverSelfTest
> - testReentrantLockConstantMultipleTopologyChangeNonFailoverSafe()
> - testFairReentrantLockConstantMultipleTopologyChangeNonFailoverSafe()
> And most of thread dumps contains the following
> {noformat}
> ] :[Step 4/5] Thread
> [name="test-runner-#35143%replicated.GridCacheReplicatedDataStructuresFailoverSelfTest%",
> id=38586, state=RUNNABLE, blockCnt=0, waitCnt=60]
> [20:34:26] : [Step 4/5] at
> java.lang.Throwable.fillInStackTrace(Native Method)
> [20:34:26] : [Step 4/5] at
> java.lang.Throwable.fillInStackTrace(Throwable.java:783)
> [20:34:26] : [Step 4/5] - locked o.a.i.IgniteException@754033e
> [20:34:26] : [Step 4/5] at
> java.lang.Throwable.(Throwable.java:265)
> [20:34:26] : [Step 4/5] at
> java.lang.Exception.(Exception.java:66)
> [20:34:26] : [Step 4/5] at
> java.lang.RuntimeException.(RuntimeException.java:62)
> [20:34:26] : [Step 4/5] at
> o.a.i.IgniteException.(IgniteException.java:44)
> [20:34:26] : [Step 4/5] at
> o.a.i.i.processors.datastructures.GridCacheLockImpl$Sync.validate(GridCacheLockImpl.java:275)
> [20:34:26] : [Step 4/5] at
> o.a.i.i.processors.datastructures.GridCacheLockImpl$Sync.access$1000(GridCacheLockImpl.java:122)
> [20:34:26] : [Step 4/5] at
> o.a.i.i.processors.datastructures.GridCacheLockImpl.lock(GridCacheLockImpl.java:1200)
> [20:34:26] : [Step 4/5] at
> o.a.i.i.processors.cache.datastructures.GridCacheAbstractDataStructuresFailoverSelfTest.doTestReentrantLock(GridCacheAbstractDataStructuresFailoverSelfTest.java:785)
> [20:34:26] : [Step 4/5] at
> o.a.i.i.processors.cache.datastructures.GridCacheAbstractDataStructuresFailoverSelfTest.testFairReentrantLockConstantMultipleTopologyChangeNonFailoverSafe(GridCacheAbstractDataStructuresFailoverSelfTest.java:739)
> [20:34:26] : [Step 4/5] at
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [20:34:26] : [Step 4/5] at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> [20:34:26] : [Step 4/5] at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [20:34:26] : [Step 4/5] at
> java.lang.reflect.Method.invoke(Method.java:606)
> [20:34:26] : [Step 4/5] at
> junit.framework.TestCase.runTest(TestCase.java:176)
> [20:34:26] : [Step 4/5] at
> o.a.i.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2000)
> [20:34:26] : [Step 4/5] at
> o.a.i.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:132)
> [20:34:26] : [Step 4/5] at
> o.a.i.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1915)
> [20:34:26] : [Step 4/5] at java.lang.Thread.run(Thread.java:745)
> [20:34:26] : [Step 4/5]
> {noformat}
> That can be indicator that threads are interrupted and flag
> org.apache.ignite.internal.processors.datastructures.GridCacheLockImpl#interruptAll
> is set,
> than org.apache.ignite.IgniteException is thrown, but it is ignored by test
> and test continues to execute
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-8896) Wrong javadoc for TcpCommunicationSpi.setSlowClientQueueLimit()
[
https://issues.apache.org/jira/browse/IGNITE-8896?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov updated IGNITE-8896:
Fix Version/s: (was: 2.7)
2.8
> Wrong javadoc for TcpCommunicationSpi.setSlowClientQueueLimit()
> ---
>
> Key: IGNITE-8896
> URL: https://issues.apache.org/jira/browse/IGNITE-8896
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Dmitry Karachentsev
>Priority: Minor
> Labels: newbie
> Fix For: 2.8
>
>
> Javadoc for TcpCommunicationSpi.setSlowClientQueueLimit() says that is should
> be set to value equal to TcpCommunicationSpi.getMessageQueueLimit().
> But this is wrong, because first checks back pressure limit and sender thread
> will be blocked before slow client check. Also, warning checks the value
> correctly, but message should be "...greater or equal...":
> {code:java}
> if (slowClientQueueLimit > 0 && msgQueueLimit > 0 && slowClientQueueLimit >=
> msgQueueLimit) {
> U.quietAndWarn(log, "Slow client queue limit is set to a value
> greater than message queue limit " +
> "(slow client queue limit will have no effect)
> [msgQueueLimit=" + msgQueueLimit +
> ", slowClientQueueLimit=" + slowClientQueueLimit + ']');
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-5979) [Test Failed] GridCacheAtomicInvalidPartitionHandlingSelfTest.testPrimaryFullAsync
[
https://issues.apache.org/jira/browse/IGNITE-5979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov updated IGNITE-5979:
Fix Version/s: (was: 2.7)
2.8
> [Test Failed]
> GridCacheAtomicInvalidPartitionHandlingSelfTest.testPrimaryFullAsync
>
>
> Key: IGNITE-5979
> URL: https://issues.apache.org/jira/browse/IGNITE-5979
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Eduard Shangareev
>Priority: Major
> Labels: MakeTeamcityGreenAgain, Muted_test
> Fix For: 2.8
>
>
> Example of failing -
> http://ci.ignite.apache.org/viewLog.html?buildId=760709=buildResultsDiv=Ignite20Tests_IgniteDataGridFailover#testNameId6248548165747570497
> {noformat}
> junit.framework.AssertionFailedError: Failed to check value for key
> [key=72625, node=0671e5c8-8bd5-4f2a-b1b8-9e945742, primary=false,
> recNodeId=101770ef-a622-4f7c-b714-70ecf1f1] expected:<0> but
> was:<-1994497644>
> at junit.framework.Assert.fail(Assert.java:57)
> at junit.framework.Assert.failNotEquals(Assert.java:329)
> at junit.framework.Assert.assertEquals(Assert.java:78)
> at junit.framework.TestCase.assertEquals(TestCase.java:244)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridCacheAtomicInvalidPartitionHandlingSelfTest.checkRestarts(GridCacheAtomicInvalidPartitionHandlingSelfTest.java:334)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridCacheAtomicInvalidPartitionHandlingSelfTest.testPrimaryFullAsync(GridCacheAtomicInvalidPartitionHandlingSelfTest.java:154)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9430) Add ability to override all caches's "rebalanceThrottle" option via JVM node option
[ https://issues.apache.org/jira/browse/IGNITE-9430?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov updated IGNITE-9430: Fix Version/s: (was: 2.7) 2.8 > Add ability to override all caches's "rebalanceThrottle" option via JVM node > option > > > Key: IGNITE-9430 > URL: https://issues.apache.org/jira/browse/IGNITE-9430 > Project: Ignite > Issue Type: Improvement > Components: general >Affects Versions: 2.5 >Reporter: ARomantsov >Priority: Major > Fix For: 2.8 > > > I found ability to set rebalanceThrottle option for any cache , but can we > have JVM key for override that parameter for all caches at once -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9325) Add to all command-line utility ability to make sound after complite execution
[ https://issues.apache.org/jira/browse/IGNITE-9325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov updated IGNITE-9325: Fix Version/s: (was: 2.7) 2.8 > Add to all command-line utility ability to make sound after complite execution > -- > > Key: IGNITE-9325 > URL: https://issues.apache.org/jira/browse/IGNITE-9325 > Project: Ignite > Issue Type: Improvement > Components: examples >Affects Versions: 2.5 >Reporter: ARomantsov >Priority: Major > Labels: command-line > Fix For: 2.8 > > > Often I work simultaneously on several clusters over ssh and there are > situations when I forget to check that the first cluster has completed the > command (for example, activation), while working on the second. > Because of this, I would like to have same functionality in the product -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9356) Ignite rest command http://localhost:8080/ignite?cmd=log=n=m return more line in linux than windows
[ https://issues.apache.org/jira/browse/IGNITE-9356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov updated IGNITE-9356: Fix Version/s: (was: 2.7) 2.8 > Ignite rest command http://localhost:8080/ignite?cmd=log=n=m return > more line in linux than windows > - > > Key: IGNITE-9356 > URL: https://issues.apache.org/jira/browse/IGNITE-9356 > Project: Ignite > Issue Type: Improvement > Components: rest >Affects Versions: 2.5 > Environment: Centos/ Windows10 >Reporter: ARomantsov >Priority: Major > Fix For: 2.8 > > > I run cluster in diffrent configuration (centos and windows 10) and notice > that log command return diffrent count of rows in same from and to > Windows rest return 1 less rows -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8837) windows ignite.bat ignores command-line parameters with the count of arguments-J greater than 4
[ https://issues.apache.org/jira/browse/IGNITE-8837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov updated IGNITE-8837: Fix Version/s: (was: 2.7) 2.8 > windows ignite.bat ignores command-line parameters with the count of > arguments-J greater than 4 > --- > > Key: IGNITE-8837 > URL: https://issues.apache.org/jira/browse/IGNITE-8837 > Project: Ignite > Issue Type: Bug > Components: general >Affects Versions: 2.5 > Environment: Windows 10 > java version "1.8.0_171" > Java(TM) SE Runtime Environment (build 1.8.0_171-b11) > Java HotSpot(TM) 64-Bit Server VM (build 25.171-b11, mixed mode) >Reporter: ARomantsov >Priority: Major > Fix For: 2.8 > > Attachments: run_with_4arg-J.txt, run_with_5arg-J.txt > > > Try to run > C:\Users\artur\Downloads\apache-ignite-fabric-2.5.0-bin\apache-ignite-fabric-2.5.0-bin>bin\ignite.bat > > C:\Users\artur\Downloads\apache-ignite-fabric-2.5.0-bin\apache-ignite-fabric-2.5.0-bin\examples\config\example-data-regions.xml > -v -J-Da1=1 -J-Da2=2 -J-Da3=3 -J-DA4=4 > run_with_4arg-J.txt 2>&1 > *Run ok, take normal config* > C:\Users\artur\Downloads\apache-ignite-fabric-2.5.0-bin\apache-ignite-fabric-2.5.0-bin>bin\ignite.bat > > C:\Users\artur\Downloads\apache-ignite-fabric-2.5.0-bin\apache-ignite-fabric-2.5.0-bin\examples\config\example-data-regions.xml > -v -J-Da1=1 -J-Da2=2 -J-Da3=3 -J-DA4=4 -J-DA5=5 > run_with_5arg-J.txt > *Run not ok, ignoring all options and take default config* > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-6862) SparseDistributedMatrixStorage cache config possibly allows read of old state of matrix
[ https://issues.apache.org/jira/browse/IGNITE-6862?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov updated IGNITE-6862: Fix Version/s: (was: 2.7) 2.8 > SparseDistributedMatrixStorage cache config possibly allows read of old > state of matrix > > > Key: IGNITE-6862 > URL: https://issues.apache.org/jira/browse/IGNITE-6862 > Project: Ignite > Issue Type: Bug >Reporter: Artem Malykh >Priority: Major > Fix For: 2.8 > > > Because synchronization mode is PRIMARY_SYNC, but by default we have > readFromBackup=true, we can read old state of matrix from backups. It seem to > be an issue. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9432) Investigate ability to make ScanQuery faster
[ https://issues.apache.org/jira/browse/IGNITE-9432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov updated IGNITE-9432: Fix Version/s: (was: 2.7) 2.8 > Investigate ability to make ScanQuery faster > > > Key: IGNITE-9432 > URL: https://issues.apache.org/jira/browse/IGNITE-9432 > Project: Ignite > Issue Type: Improvement > Components: ml >Affects Versions: 2.7 >Reporter: Anton Dmitriev >Priority: Major > Fix For: 2.8 > > > When we make ScanQuery via Binary Client Protocol it works very slowly in > case we need to retrieve a big amount of objects (all objects in our case). > The most slower part is a waiting for response from Apache Ignite. This also > mentioned on devlist > [http://apache-ignite-developers.2346864.n4.nabble.com/How-to-reduce-Scan-Query-execution-time-td34212.html]. > To reproduce the problem we've prepared a small example: > [slow-scan-query-reproducer|https://github.com/dmitrievanthony/slow-scan-query-reproducer]. > In this example we creates a cache with 500 objects 1Mb each (on localhost), > we make ScanQuery with different page sizes and calculate time between the > moment when the request has been sent and the moment when the response is > ready to be receive. The measurements are here: > Page size 5 Mb, waiting time 119.85 ± 6.72 ms > Page size 10 Mb, waiting time 157.70 ± 15.35 ms > Page size 20 Mb, waiting time 204.50 ± 19.18 ms > Page size 50 Mb, waiting time 264.70 ± 22.30 ms > Page size 100 Mb, waiting time 463.35 ± 17.12 ms > Page size 150 Mb, waiting time 672.50 ± 21.98 ms > As result we spend ~4ms per every megabyte on _something_. It means that we > will be able to achieve 250Mb/s throughput in best case. It's too slow, isn't > it? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9416) [ML] Update distribution approach for TensorFlow module
[ https://issues.apache.org/jira/browse/IGNITE-9416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov updated IGNITE-9416: Fix Version/s: (was: 2.7) 2.8 > [ML] Update distribution approach for TensorFlow module > --- > > Key: IGNITE-9416 > URL: https://issues.apache.org/jira/browse/IGNITE-9416 > Project: Ignite > Issue Type: Improvement > Components: ml >Affects Versions: 2.7 >Reporter: Anton Dmitriev >Priority: Major > Fix For: 2.8 > > > So far we package "ignite-tf.sh" into zip file in "ignite-tensorflow" module. > We need to define right approach to do it so that users are able to use it > easily the same way as other Ignite command line tools. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-7005) Ability to disable WAL (Recoverable case)
[ https://issues.apache.org/jira/browse/IGNITE-7005?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov updated IGNITE-7005: Fix Version/s: (was: 2.7) 2.8 > Ability to disable WAL (Recoverable case) > - > > Key: IGNITE-7005 > URL: https://issues.apache.org/jira/browse/IGNITE-7005 > Project: Ignite > Issue Type: Task > Components: persistence >Reporter: Anton Vinogradov >Priority: Major > Fix For: 2.8 > > > In addition to non recoverable case(IGNITE-7003): > On WAL disabling we should (on each node) > - trigger exchange to guarantie consistent state > - schedule new checkpoint. This checkpoint should be recorded to special > place (temporary checkpoint location), to prevent damage of latest one. > All new checkpoints should update temporary checkpoint. > On WAL enabling we should (on each node) after all nodes reported that > checkpoints finished > - merge temp checkpoint with stable (scheduled before WAL disabling) > - clean WAL > before enabling proxies > On any failure during loading (while WAL disabled or enabling) we should be > able to reactivate cluster with > - data from original checkpoints & WAL for affected caches > - latest state for non affected caches > Failover: > Any topology change should be covered(while WAL disabled or enabling) > - Node(s) Left (inc. coordinator) > - Node(s) Join -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9090) When client node make cache.QueryCursorImpl.getAll they have OOM and continue working
[
https://issues.apache.org/jira/browse/IGNITE-9090?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov updated IGNITE-9090:
Fix Version/s: (was: 2.7)
2.8
> When client node make cache.QueryCursorImpl.getAll they have OOM and continue
> working
> -
>
> Key: IGNITE-9090
> URL: https://issues.apache.org/jira/browse/IGNITE-9090
> Project: Ignite
> Issue Type: Bug
> Components: clients
>Affects Versions: 2.4
> Environment: 2 server node, 1 client, 1 cache with 15 kk size
>Reporter: ARomantsov
>Priority: Critical
> Fix For: 2.8
>
>
> {code:java}
> [12:21:22,390][SEVERE][query-#69][GridCacheIoManager] Failed to process
> message [senderId=30cab4ec-1da7-4e9f-a262-bdfa4d466865, messageType=class
> o.a.i.i.processors.cache.query.GridCacheQueryResponse]
> java.lang.OutOfMemoryError: GC overhead limit exceeded
> at java.lang.Long.valueOf(Long.java:840)
> at
> org.apache.ignite.internal.marshaller.optimized.OptimizedObjectInputStream.readObject0(OptimizedObjectInputStream.java:250)
> at
> org.apache.ignite.internal.marshaller.optimized.OptimizedObjectInputStream.readObjectOverride(OptimizedObjectInputStream.java:198)
> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:421)
> at
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryResponseEntry.readExternal(GridCacheQueryResponseEntry.java:90)
> at
> org.apache.ignite.internal.marshaller.optimized.OptimizedObjectInputStream.readExternalizable(OptimizedObjectInputStream.java:555)
> at
> org.apache.ignite.internal.marshaller.optimized.OptimizedClassDescriptor.read(OptimizedClassDescriptor.java:917)
> at
> org.apache.ignite.internal.marshaller.optimized.OptimizedObjectInputStream.readObject0(OptimizedObjectInputStream.java:346)
> at
> org.apache.ignite.internal.marshaller.optimized.OptimizedObjectInputStream.readObjectOverride(OptimizedObjectInputStream.java:198)
> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:421)
> at
> org.apache.ignite.internal.marshaller.optimized.OptimizedMarshaller.unmarshal0(OptimizedMarshaller.java:227)
> at
> org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.unmarshal(AbstractNodeNameAwareMarshaller.java:94)
> at
> org.apache.ignite.internal.binary.BinaryUtils.doReadOptimized(BinaryUtils.java:1777)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1964)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1716)
> at
> org.apache.ignite.internal.binary.GridBinaryMarshaller.deserialize(GridBinaryMarshaller.java:310)
> at
> org.apache.ignite.internal.binary.BinaryMarshaller.unmarshal0(BinaryMarshaller.java:99)
> at
> org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.unmarshal(AbstractNodeNameAwareMarshaller.java:82)
> at
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryResponse.unmarshalCollection0(GridCacheQueryResponse.java:189)
> at
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryResponse.finishUnmarshal(GridCacheQueryResponse.java:162)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.unmarshall(GridCacheIoManager.java:1530)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:576)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$700(GridCacheIoManager.java:101)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$OrderedMessageListener.onMessage(GridCacheIoManager.java:1613)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1556)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4100(GridIoManager.java:125)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$GridCommunicationMessageSet.unwind(GridIoManager.java:2752)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.unwindMessageSet(GridIoManager.java:1516)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4400(GridIoManager.java:125)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$10.run(GridIoManager.java:1485)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>
[jira] [Updated] (IGNITE-9255) -DIGNITE_QUIET=false not work in windows, -v work ok
[ https://issues.apache.org/jira/browse/IGNITE-9255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov updated IGNITE-9255: Fix Version/s: (was: 2.7) 2.8 > -DIGNITE_QUIET=false not work in windows, -v work ok > > > Key: IGNITE-9255 > URL: https://issues.apache.org/jira/browse/IGNITE-9255 > Project: Ignite > Issue Type: Bug > Components: general >Affects Versions: 2.5 >Reporter: ARomantsov >Priority: Major > Fix For: 2.8 > > > I try to run > 1) Ignite.bat - Work anticipated > 2) Ignite.bat -v - Work anticipated > 3) Ignite.bat -J-DIGNITE_QUIET=false - Work like first , but expected like > second variant -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-7004) Ability to disable WAL (Cross-cache tx should be rescricted while WAL disabled)
[ https://issues.apache.org/jira/browse/IGNITE-7004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov updated IGNITE-7004: Fix Version/s: (was: 2.7) 2.8 > Ability to disable WAL (Cross-cache tx should be rescricted while WAL > disabled) > --- > > Key: IGNITE-7004 > URL: https://issues.apache.org/jira/browse/IGNITE-7004 > Project: Ignite > Issue Type: Task > Components: persistence >Reporter: Anton Vinogradov >Priority: Major > Fix For: 2.8 > > > Cross-cache transactions affecting caches with different modes (e.g. one > enabled, another disabled) are not allowed -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8223) GridNearTxLocal.clearPrepareFuture does effectively nothing
[
https://issues.apache.org/jira/browse/IGNITE-8223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov updated IGNITE-8223:
Fix Version/s: (was: 2.7)
2.8
> GridNearTxLocal.clearPrepareFuture does effectively nothing
> ---
>
> Key: IGNITE-8223
> URL: https://issues.apache.org/jira/browse/IGNITE-8223
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.4
>Reporter: Andrey Kuznetsov
>Priority: Trivial
> Labels: newbie
> Fix For: 2.8
>
>
> It's unclear whether {{GridNearTxLocal.clearPrepareFuture}} is called at all,
> but the method does nothing, since its argument type is never used as target
> field value. Proposed change is to make the method no-op explicitly.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-8061) GridCachePartitionedDataStructuresFailoverSelfTest.testCountDownLatchConstantMultipleTopologyChange may hang on TeamCity
[ https://issues.apache.org/jira/browse/IGNITE-8061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov updated IGNITE-8061: Fix Version/s: (was: 2.7) 2.8 > GridCachePartitionedDataStructuresFailoverSelfTest.testCountDownLatchConstantMultipleTopologyChange > may hang on TeamCity > > > Key: IGNITE-8061 > URL: https://issues.apache.org/jira/browse/IGNITE-8061 > Project: Ignite > Issue Type: Bug > Components: data structures >Affects Versions: 2.4 >Reporter: Andrey Kuznetsov >Priority: Major > Fix For: 2.8 > > Attachments: log.txt > > > The log attached contains 'Test has been timed out and will be interrupted' > message, but does not contain subsequent 'Test has been timed out [test=...'. > Known facts: > * There is pending GridDhtColocatedLockFuture in the log. > * On timeout, InterruptedException comes to doTestCountDownLatch, but > finally-block contains the code leading to distributed locking. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8098) Getting affinity for topology version earlier than affinity is calculated because of data race
[
https://issues.apache.org/jira/browse/IGNITE-8098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov updated IGNITE-8098:
Fix Version/s: (was: 2.7)
2.8
> Getting affinity for topology version earlier than affinity is calculated
> because of data race
> --
>
> Key: IGNITE-8098
> URL: https://issues.apache.org/jira/browse/IGNITE-8098
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.3
>Reporter: Andrey Aleksandrov
>Priority: Minor
> Fix For: 2.8
>
>
> From time to time the Ignite cluster with services throws next exception
> during restarting of some nodes:
> java.lang.IllegalStateException: Getting affinity for topology version
> earlier than affinity is calculated [locNode=TcpDiscoveryNode
> [id=c770dbcf-2908-442d-8aa0-bf26a2aecfef, addrs=[10.44.162.169, 127.0.0.1],
> sockAddrs=[clrv041279.ic.ing.net/10.44.162.169:56500, /127.0.0.1:56500],
> discPort=56500, order=11, intOrder=8, lastExchangeTime=1520931375337,
> loc=true, ver=2.3.3#20180213-sha1:f446df34, isClient=false],
> grp=ignite-sys-cache, topVer=AffinityTopologyVersion [topVer=13,
> minorTopVer=0], head=AffinityTopologyVersion [topVer=15, minorTopVer=0],
> history=[AffinityTopologyVersion [topVer=11, minorTopVer=0],
> AffinityTopologyVersion [topVer=11, minorTopVer=1], AffinityTopologyVersion
> [topVer=12, minorTopVer=0], AffinityTopologyVersion [topVer=15,
> minorTopVer=0]]]
> Looks like the reason of this issue is the data race in GridServiceProcessor
> class.
> How to reproduce:
> 1)To simulate data race you should update next place in source code:
> Class: GridServiceProcessor
> Method: @Override public void onEvent(final DiscoveryEvent evt, final
> DiscoCache discoCache) {
> Place:
>
> try {
> svcName.set(dep.configuration().getName());
> ctx.cache().internalCache(UTILITY_CACHE_NAME).context().affinity().
> affinityReadyFuture(topVer).get();
> //HERE (between GET and REASSIGN) you should add Thread.sleep(100) for
> example.
> //try {
> //Thread.sleep(100);
> //}
> //catch (InterruptedException e1) {
> //e1.printStackTrace();
> //}
>
> reassign(dep, topVer);
> }
> catch (IgniteCheckedException ex) {
> if (!(e instanceof ClusterTopologyCheckedException))
> LT.error(log, ex, "Failed to do service reassignment (will retry): " +
> dep.configuration().getName());
> retries.add(dep);
> }
> ...
> 2)After that you should imitate start/shutdown iterations. For reproducing I
> used GridServiceProcessorBatchDeploySelfTest (but timeout on future.get
> should be increased to avoid timeout error)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-8885) GridCacheDhtPreloadMultiThreadedSelfTest.testConcurrentNodesStartStop fails flakily
[
https://issues.apache.org/jira/browse/IGNITE-8885?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov updated IGNITE-8885:
Fix Version/s: (was: 2.7)
2.8
> GridCacheDhtPreloadMultiThreadedSelfTest.testConcurrentNodesStartStop fails
> flakily
> ---
>
> Key: IGNITE-8885
> URL: https://issues.apache.org/jira/browse/IGNITE-8885
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.5
>Reporter: Andrey Kuznetsov
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.8
>
>
> Sometimes the following assertion failure can be observed (master branch).
> {noformat}
> [11:05:34] (err) Failed to notify listener:
> o.a.i.i.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture$8$1$1...@e18f6e4java.lang.AssertionError
> at
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager$13.applyx(CacheAffinitySharedManager.java:1335)
> at
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager$13.applyx(CacheAffinitySharedManager.java:1326)
> at
> org.apache.ignite.internal.util.lang.IgniteInClosureX.apply(IgniteInClosureX.java:38)
> at
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.forAllCacheGroups(CacheAffinitySharedManager.java:1119)
> at
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.onLocalJoin(CacheAffinitySharedManager.java:1326)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.processFullMessage(GridDhtPartitionsExchangeFuture.java:3281)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onBecomeCoordinator(GridDhtPartitionsExchangeFuture.java:3730)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.access$3300(GridDhtPartitionsExchangeFuture.java:130)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture$8$1$1.apply(GridDhtPartitionsExchangeFuture.java:3626)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture$8$1$1.apply(GridDhtPartitionsExchangeFuture.java:3615)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:383)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.unblock(GridFutureAdapter.java:347)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.unblockAll(GridFutureAdapter.java:335)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:495)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:474)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:451)
> at
> org.apache.ignite.internal.util.future.GridCompoundFuture.checkComplete(GridCompoundFuture.java:285)
> at
> org.apache.ignite.internal.util.future.GridCompoundFuture.apply(GridCompoundFuture.java:144)
> at
> org.apache.ignite.internal.util.future.GridCompoundFuture.apply(GridCompoundFuture.java:45)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:383)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.unblock(GridFutureAdapter.java:347)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.unblockAll(GridFutureAdapter.java:335)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:495)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:474)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:440)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.InitNewCoordinatorFuture.onMessage(InitNewCoordinatorFuture.java:254)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onReceiveSingleMessage(GridDhtPartitionsExchangeFuture.java:2115)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.processSinglePartitionUpdate(GridCachePartitionExchangeManager.java:1580)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.access$1000(GridCachePartitionExchangeManager.java:138)
> at
>
[jira] [Updated] (IGNITE-8630) Node filter IgnitePredicate executes twice during deploying on one single node cluster
[
https://issues.apache.org/jira/browse/IGNITE-8630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov updated IGNITE-8630:
Fix Version/s: (was: 2.7)
2.8
> Node filter IgnitePredicate executes twice during deploying on one single
> node cluster
> --
>
> Key: IGNITE-8630
> URL: https://issues.apache.org/jira/browse/IGNITE-8630
> Project: Ignite
> Issue Type: Bug
> Components: managed services
>Affects Versions: 2.4
>Reporter: Andrey Aleksandrov
>Priority: Major
> Fix For: 2.8
>
>
> Next code:
> {code:java}
> Ignite ignite =
> IgnitionEx.start("examples/config/example-ignite.xml", "ignite-1");
> // Deploy services only on server nodes.
> ignite.services().deploy(new ServiceConfiguration()
> .setMaxPerNodeCount(1)
> .setNodeFilter(new IgnitePredicate() {
> Ignite filterIgnite;
> @Override public boolean apply(ClusterNode node) {
> System.out.println("Is local node: " + node.isLocal());
> System.out.println("ignite: " + (isNull(filterIgnite) ?
> null : filterIgnite.name()));
> return true;
> }
> @IgniteInstanceResource
> void setFilterIgnite(Ignite filterIgnite) {
> this.filterIgnite = filterIgnite;
> }
> })
> .setName("my-service")
> .setService(new SimpleMapServiceImpl<>())
> );
> {code}
> Produces next output:
> {code:java}
> Is local node: true
> ignite: ignite-1
> Service was initialized: my-service
> Executing distributed service: my-service
> Is local node: true
> ignite: ignite-1{code}
> In case if we will increase the cluster size to 2 then we will have:
> {code:java}
> Ignite ignite = IgnitionEx.start("examples/config/example-ignite.xml",
> "ignite-1");
> Ignite ignite2 = IgnitionEx.start("examples/config/example-ignite.xml",
> "ignite-2");
> // Deploy services only on server nodes.
> ignite.services().deploy(new ServiceConfiguration()
> .setMaxPerNodeCount(1)
> .setNodeFilter(new IgnitePredicate() {
> Ignite filterIgnite;
> @Override public boolean apply(ClusterNode node) {
> System.out.println("Is local node: " + node.isLocal());
> System.out.println("ignite: " + (isNull(filterIgnite) ? null :
> filterIgnite.name()));
> return true;
> }
> @IgniteInstanceResource
> void setFilterIgnite(Ignite filterIgnite) {
> this.filterIgnite = filterIgnite;
> }
> })
> .setName("my-service")
> .setService(new SimpleMapServiceImpl<>())
> );
> {code}
> We will get:
> {code:java}
> Is local node: true
> ignite: ignite-1
> Is local node: false
> ignite: ignite-1
> Service was initialized: my-service
> Executing distributed service: my-service
> Service was initialized: my-service
> Is local node: true
> ignite: ignite-1
> Is local node: false
> ignite: ignite-1
> Executing distributed service: my-service
> Is local node: true
> ignite: ignite-1
> Is local node: false
> ignite: ignite-1
> {code}
> So we have additional execution:
> {code:java}
> Is local node: true
> ignite: ignite-1
> Is local node: false
> ignite: ignite-1{code}
> So Ignite executes apply method several times (2 times for 1 server, 6 times
> for 2 servers). This behavior should be documented or fixed because at the
> moment it's could be unexpected for the user.
> You can see the same behaviour during deploying of the caches with nodeFilter
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-8887) IgfsLocalSecondaryFileSystemDualAsyncSelfTest.testAccessAndModificationTimeUpwardsPropagation fails flakily on master
[
https://issues.apache.org/jira/browse/IGNITE-8887?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov updated IGNITE-8887:
Fix Version/s: (was: 2.7)
2.8
> IgfsLocalSecondaryFileSystemDualAsyncSelfTest.testAccessAndModificationTimeUpwardsPropagation
> fails flakily on master
> -
>
> Key: IGNITE-8887
> URL: https://issues.apache.org/jira/browse/IGNITE-8887
> Project: Ignite
> Issue Type: Bug
> Components: igfs
>Affects Versions: 2.5
>Reporter: Andrey Kuznetsov
>Priority: Major
> Fix For: 2.8
>
>
> {noformat}
> junit.framework.AssertionFailedError: expected: [val1=153008911, val2=153008911]> but was: [val1=1530089111000, val2=153008911]>
> at junit.framework.Assert.fail(Assert.java:57)
> at junit.framework.Assert.failNotEquals(Assert.java:329)
> at junit.framework.Assert.assertEquals(Assert.java:78)
> at junit.framework.Assert.assertEquals(Assert.java:86)
> at junit.framework.TestCase.assertEquals(TestCase.java:253)
> at
> org.apache.ignite.internal.processors.igfs.IgfsDualAbstractSelfTest.testAccessAndModificationTimeUpwardsPropagation(IgfsDualAbstractSelfTest.java:1544)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-8522) Transaction incorrect state after cache closed
[
https://issues.apache.org/jira/browse/IGNITE-8522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov updated IGNITE-8522:
Fix Version/s: (was: 2.7)
2.8
> Transaction incorrect state after cache closed
> --
>
> Key: IGNITE-8522
> URL: https://issues.apache.org/jira/browse/IGNITE-8522
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexey Kuznetsov
>Priority: Major
> Fix For: 2.8
>
>
> When we started transaction on client node and closed cache , transaction is
> rolled back.
> But tx state is still ACTIVE which causes unexpected exception when we try to
> commit it.
> The expected exception is TransactionRollbackException.
> Look at the following code:
> {code:java}
> public void testTxRollbackWhenCacheClosed() throws Exception {
> startGrid(0);// server node started
> client = true;
> IgniteEx clientNode = startGrid(1);
> IgniteCache cache = clientNode.createCache();// transactional cache
> is started
> IgniteTransactions transactions = clientNode.transactions();
> Transaction tx = transactions.txStart();
> cache.put(1, 1);
> multithreaded(cache::close, 1);
> tx.commit();// TransactionRollbackException expected, but NPE is
> thrown.
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9663) MVCC: Data node failure can cause TX hanging.
[ https://issues.apache.org/jira/browse/IGNITE-9663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov updated IGNITE-9663: Fix Version/s: (was: 2.7) 2.8 > MVCC: Data node failure can cause TX hanging. > - > > Key: IGNITE-9663 > URL: https://issues.apache.org/jira/browse/IGNITE-9663 > Project: Ignite > Issue Type: Bug > Components: cache, mvcc >Reporter: Andrew Mashenkov >Priority: Major > Labels: MakeTeamcityGreenAgain > Fix For: 2.8 > > > Next test hangs due to a bug: > CacheMvccTransactionsTest.testPutAllGetAll_ClientServer_Backups1_Restart_Scan > Possibly, it is caused with a race in MvccTracker and can be partially fixed > in [#1] or > we have a bug in TX mapping in enlist phase on unstable topology. > > I've tried to avoid races in Tracker and see TX hanged awaiting PME that > version has just been completed. This need to be investigated. > > [1] https://issues.apache.org/jira/browse/IGNITE-9428 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-7065) Cannot use multiple Ignite Kafka Sink Connectors
[ https://issues.apache.org/jira/browse/IGNITE-7065?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov updated IGNITE-7065: Fix Version/s: (was: 2.7) 2.8 > Cannot use multiple Ignite Kafka Sink Connectors > - > > Key: IGNITE-7065 > URL: https://issues.apache.org/jira/browse/IGNITE-7065 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.3 >Reporter: Alexey Kukushkin >Priority: Major > Fix For: 2.8 > > > Stopping an Ignite Kafka sink connector makes other connectors deployed in > the same worker unusable. As a result we cannot stream different topics in > different caches since connector support streaming to single cache only. > See > http://apache-ignite-users.70518.x6.nabble.com/Issues-with-multiple-kafka-connectors-questions-regarding-ignite-caches-tc18297.html > for more details. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9446) MVCC: Races in Vacuum worker on cache stop.
[ https://issues.apache.org/jira/browse/IGNITE-9446?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov updated IGNITE-9446: Fix Version/s: (was: 2.7) 2.8 > MVCC: Races in Vacuum worker on cache stop. > --- > > Key: IGNITE-9446 > URL: https://issues.apache.org/jira/browse/IGNITE-9446 > Project: Ignite > Issue Type: Bug > Components: mvcc >Reporter: Andrew Mashenkov >Priority: Minor > Fix For: 2.8 > > > For now, partition store BTree can be destroyed while vacuum in progress > regardless partition reservations which causes VacuumTask failure without > negative side effect (such as worker failure or any hanging). > VacuumTask successfully catch and log the exception, but further check in > afterTest() method reports vacuum failure. > For now vacuum is disabled for this test. > We should fix vacuum failure properly in that case and fix > CacheMvccPartitionedSqlQueriesTest.testDistributedJoinSimple() test. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-7486) Сache operation failed after transaction rolled back due to deadlock
[ https://issues.apache.org/jira/browse/IGNITE-7486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov updated IGNITE-7486: Fix Version/s: (was: 2.7) 2.8 > Сache operation failed after transaction rolled back due to deadlock > > > Key: IGNITE-7486 > URL: https://issues.apache.org/jira/browse/IGNITE-7486 > Project: Ignite > Issue Type: Bug >Reporter: Alexey Kuznetsov >Priority: Major > Fix For: 2.8 > > Attachments: CacheOperationAfterTxDeadlockDetectedTest.java > > > When you have your transaction rolled back due to detected deadlock, you are > unabled to perform cache operations (in thread where tx was started and > rolled back), because it leads to TransactionTimeoutException. > The reason of such behavior is that tx thread map (txManager#threadMap) was > not cleared from tx when roll back occured. > In GridNearTxLocal#onTimeout you can find comment on that : > // Note: if rollback asynchronously on timeout should not clear thread map > // since thread started tx still should be able to see > this tx. > Cache operation picks up tx from that map and throws exception. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-7891) awaitPartitionMapExchange works incorrectly if partitioned cache has backup
[ https://issues.apache.org/jira/browse/IGNITE-7891?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov updated IGNITE-7891: Fix Version/s: (was: 2.7) 2.8 > awaitPartitionMapExchange works incorrectly if partitioned cache has backup > --- > > Key: IGNITE-7891 > URL: https://issues.apache.org/jira/browse/IGNITE-7891 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.5 >Reporter: Alexey Kuznetsov >Priority: Critical > Labels: rebalance > Fix For: 2.8 > > > When cluster is started with partitioned cache with backups, > awaitPartitionMapExchange(true, true, null) may work incorrectly : it > doesn't wait for full rebalance to be finished. > See > [reproducer|https://github.com/voipp/ignite/commit/78d96c4950b7f82abea1d3cec8b508a96089f2a5] > Note that reproducer is flaky, it fails 80% of times -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9444) TcpDiscoveryCloudIpFinderSelfTest.testRackspace fails in master
[
https://issues.apache.org/jira/browse/IGNITE-9444?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov updated IGNITE-9444:
Fix Version/s: (was: 2.7)
2.8
> TcpDiscoveryCloudIpFinderSelfTest.testRackspace fails in master
> ---
>
> Key: IGNITE-9444
> URL: https://issues.apache.org/jira/browse/IGNITE-9444
> Project: Ignite
> Issue Type: Test
>Reporter: Alexey Goncharuk
>Priority: Major
> Fix For: 2.8
>
>
> Looks like something changed in the rackspace infrastructure, the test
> started to fail with {{java.util.NoSuchElementException: apiType compute not
> found in catalog []}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9303) PageSnapshot can contain wrong pageId tag when not dirty page is recycling
[
https://issues.apache.org/jira/browse/IGNITE-9303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov updated IGNITE-9303:
Fix Version/s: (was: 2.7)
2.8
> PageSnapshot can contain wrong pageId tag when not dirty page is recycling
> --
>
> Key: IGNITE-9303
> URL: https://issues.apache.org/jira/browse/IGNITE-9303
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.6
>Reporter: Aleksey Plekhanov
>Priority: Major
> Fix For: 2.8
>
>
> When page is recycling (for example in {{BPlusTree.Remove#freePage()}} ->
> {{DataStructure#recyclePage()}}) tag of {{pageId}} is modified, but original
> {{pageId}} is passed to {{writeUnlock()}} method and this passed {{pageId}}
> is stored to PageSnapshot WAL record.
> This bug may lead to errors in WAL applying during crash recovery.
> Reproducer (ignite-indexing module must be in classpath):
> {code:java}
> public class WalFailReproducer extends AbstractWalDeltaConsistencyTest {
> @Override protected boolean checkPagesOnCheckpoint() {
> return true;
> }
> public final void testPutRemoveCacheDestroy() throws Exception {
> CacheConfiguration ccfg = new
> CacheConfiguration<>("cache0");
> ccfg.setIndexedTypes(Integer.class, Integer.class);
> IgniteEx ignite = startGrid(0);
> ignite.cluster().active(true);
> IgniteCache cache0 = ignite.getOrCreateCache(ccfg);
> for (int i = 0; i < 5_000; i++)
> cache0.put(i, i);
> forceCheckpoint();
> for (int i = 1_000; i < 4_000; i++)
> cache0.remove(i);
> forceCheckpoint();
> stopAllGrids();
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-8296) Move Spark Scala DataFrames code examples to correct directory and prefix with "Scalar" to follow convention used with other Scala examples
[ https://issues.apache.org/jira/browse/IGNITE-8296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov updated IGNITE-8296: Fix Version/s: (was: 2.7) 2.8 > Move Spark Scala DataFrames code examples to correct directory and prefix > with "Scalar" to follow convention used with other Scala examples > > > Key: IGNITE-8296 > URL: https://issues.apache.org/jira/browse/IGNITE-8296 > Project: Ignite > Issue Type: Improvement > Components: spark >Affects Versions: 2.4 >Reporter: Akmal Chaudhri >Priority: Minor > Fix For: 2.8 > > > # The Spark Scala DataFrames code examples are in the wrong directory. They > should be moved to the correct directory structure. > # The Spark Scala DataFrames code examples should follow the naming > convention used for other Scala code examples and be prefixed with "Scalar". -- This message was sent by Atlassian JIRA (v7.6.3#76005)
