[jira] [Comment Edited] (IGNITE-8776) Eviction policy MBeans are never registered if evictionPolicyFactory is used
[ https://issues.apache.org/jira/browse/IGNITE-8776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16534452#comment-16534452 ] kcheng.mvp edited comment on IGNITE-8776 at 7/6/18 5:48 AM: [~slukyanov] I have triggered the tests many times on TeamCity. every time I get the same result. Platform .NET (Core Linux) pull/4300/head #1109Exit code 1 (new) https://ci.ignite.apache.org/viewLog.html?buildId=1460429=buildResultsDiv=IgniteTests24Java8_RunBasicTests. I checked the history of 'Platform .NET (Core Linux) ' and found there are many other build also runs into the same result. was (Author: kcheng.mvp): I have triggered the tests many times on TeamCity. every time I get the same result. Platform .NET (Core Linux) pull/4300/head #1109Exit code 1 (new) https://ci.ignite.apache.org/viewLog.html?buildId=1460429=buildResultsDiv=IgniteTests24Java8_RunBasicTests. I checked the history of 'Platform .NET (Core Linux) ' and found there are many other build also runs into the same result. > Eviction policy MBeans are never registered if evictionPolicyFactory is used > > > Key: IGNITE-8776 > URL: https://issues.apache.org/jira/browse/IGNITE-8776 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.5 >Reporter: Stanislav Lukyanov >Assignee: kcheng.mvp >Priority: Minor > Labels: newbie > > Eviction policy MBeans, such as LruEvictionPolicyMBean, are never registered > if evictionPolicyFactory is set instead of evictionPolicy (the latter is > deprecated). > This happens because GridCacheProcessor::registerMbean attempts to find > either an *MBean interface or IgniteMBeanAware interface on the passed > object. It works for LruEvictionPolicy but not for LruEvictionPolicyFactory > (which doesn't implement these interfaces). > The code needs to be adjusted to handle factories correctly. > New tests are needed to make sure that all standard beans are registered > (IgniteKernalMbeansTest does that for kernal mbeans - need the same for cache > beans). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8776) Eviction policy MBeans are never registered if evictionPolicyFactory is used
[ https://issues.apache.org/jira/browse/IGNITE-8776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16534452#comment-16534452 ] kcheng.mvp commented on IGNITE-8776: I have triggered the tests many times on TeamCity. every time I get the same result. Platform .NET (Core Linux) pull/4300/head #1109Exit code 1 (new) https://ci.ignite.apache.org/viewLog.html?buildId=1460429=buildResultsDiv=IgniteTests24Java8_RunBasicTests. I checked the history of 'Platform .NET (Core Linux) ' and found there are many other build also runs into the same result. > Eviction policy MBeans are never registered if evictionPolicyFactory is used > > > Key: IGNITE-8776 > URL: https://issues.apache.org/jira/browse/IGNITE-8776 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.5 >Reporter: Stanislav Lukyanov >Assignee: kcheng.mvp >Priority: Minor > Labels: newbie > > Eviction policy MBeans, such as LruEvictionPolicyMBean, are never registered > if evictionPolicyFactory is set instead of evictionPolicy (the latter is > deprecated). > This happens because GridCacheProcessor::registerMbean attempts to find > either an *MBean interface or IgniteMBeanAware interface on the passed > object. It works for LruEvictionPolicy but not for LruEvictionPolicyFactory > (which doesn't implement these interfaces). > The code needs to be adjusted to handle factories correctly. > New tests are needed to make sure that all standard beans are registered > (IgniteKernalMbeansTest does that for kernal mbeans - need the same for cache > beans). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-640) Implement IgniteMultimap data structures
[
https://issues.apache.org/jira/browse/IGNITE-640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16534428#comment-16534428
]
Amir Akhmedov edited comment on IGNITE-640 at 7/6/18 5:11 AM:
--
Hi [~avinogradov],
I made a changes discussed above, please check them.
I think it worth to add generic type for key into MapItemKey, without it code
in MultimapImpl looks a little odd.
PR: [https://github.com/apache/ignite/pull/4207]
was (Author: aakhmedov):
Hi [~avinogradov],
I made a changes discussed above, please check them.
I think it worth to add generic type for key into MapItemKey, without it code
in MultimapImpl looks a little odd.
> 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.7
>
>
> 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
[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=16534428#comment-16534428
]
Amir Akhmedov commented on IGNITE-640:
--
Hi [~avinogradov],
I made a changes discussed above, please check them.
I think it worth to add generic type for key into MapItemKey, without it code
in MultimapImpl looks a little odd.
> 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.7
>
>
> 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-8945) Stored cache data files corruption when node stops abruptly.
[ https://issues.apache.org/jira/browse/IGNITE-8945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16534275#comment-16534275 ] ASF GitHub Bot commented on IGNITE-8945: GitHub user ivandasch opened a pull request: https://github.com/apache/ignite/pull/4319 IGNITE-8945: Add additional checks with informative error message and implement more robust storedcachedata save. You can merge this pull request into a Git repository by running: $ git pull https://github.com/ivandasch/ignite ignite-8945 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4319.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 #4319 commit c8e80325c8862d76289516a5053a4b5b66738044 Author: Ivan Daschinskiy Date: 2018-07-05T22:38:21Z IGNITE-8945: Add additional checks with informative error message and implement more robust storedcachedata save. > Stored cache data files corruption when node stops abruptly. > > > Key: IGNITE-8945 > URL: https://issues.apache.org/jira/browse/IGNITE-8945 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.5 >Reporter: Ivan Daschinskiy >Assignee: Ivan Daschinskiy >Priority: Major > Fix For: 2.7 > > > When node is halted during saving stored cache data, content of this file can > be corrupted. > 1. Additional check should be implemented in > FilePageStoreManager.readCacheData > (print the name of corrupted file) > 2. In storeCacheData we need to serialize StoredCacheData to temp file then > swap. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8946) AssertionError can occur during release of WAL history that was reserved for historical rebalance
[
https://issues.apache.org/jira/browse/IGNITE-8946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Rakov updated IGNITE-8946:
---
Fix Version/s: 2.7
> AssertionError can occur during release of WAL history that was reserved for
> historical rebalance
> -
>
> Key: IGNITE-8946
> URL: https://issues.apache.org/jira/browse/IGNITE-8946
> Project: Ignite
> Issue Type: Bug
>Reporter: Ivan Rakov
>Priority: Critical
> Fix For: 2.7
>
>
> Attempt to release WAL history after exchange may fail with AssertionError.
> Seems like we have a bug and may try to release more WAL segments than we
> have reserved:
> {noformat}
> java.lang.AssertionError: null
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.SegmentReservationStorage.release(SegmentReservationStorage.java:54)
> - locked <0x1c12> (a
> org.apache.ignite.internal.processors.cache.persistence.wal.SegmentReservationStorage)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.release(FileWriteAheadLogManager.java:862)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.releaseHistoryForExchange(GridCacheDatabaseSharedManager.java:1691)
> - locked <0x1c17> (a
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onDone(GridDhtPartitionsExchangeFuture.java:1751)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.finishExchangeOnCoordinator(GridDhtPartitionsExchangeFuture.java:2858)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onAllReceived(GridDhtPartitionsExchangeFuture.java:2591)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.processSingleMessage(GridDhtPartitionsExchangeFuture.java:2283)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.access$100(GridDhtPartitionsExchangeFuture.java:129)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture$2.apply(GridDhtPartitionsExchangeFuture.java:2140)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture$2.apply(GridDhtPartitionsExchangeFuture.java:2128)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:383)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.listen(GridFutureAdapter.java:353)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onReceiveSingleMessage(GridDhtPartitionsExchangeFuture.java:2128)
> 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
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$2.onMessage(GridCachePartitionExchangeManager.java:345)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$2.onMessage(GridCachePartitionExchangeManager.java:325)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$MessageHandler.apply(GridCachePartitionExchangeManager.java:2848)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$MessageHandler.apply(GridCachePartitionExchangeManager.java:2827)
> 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
>
[jira] [Updated] (IGNITE-8946) AssertionError can occur during release of WAL history that was reserved for historical rebalance
[
https://issues.apache.org/jira/browse/IGNITE-8946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Rakov updated IGNITE-8946:
---
Description:
Attempt to release WAL history after exchange may fail with AssertionError.
Seems like we have a bug and may try to release more WAL segments than we have
reserved:
{noformat}
java.lang.AssertionError: null
at
org.apache.ignite.internal.processors.cache.persistence.wal.SegmentReservationStorage.release(SegmentReservationStorage.java:54)
- locked <0x1c12> (a
org.apache.ignite.internal.processors.cache.persistence.wal.SegmentReservationStorage)
at
org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.release(FileWriteAheadLogManager.java:862)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.releaseHistoryForExchange(GridCacheDatabaseSharedManager.java:1691)
- locked <0x1c17> (a
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onDone(GridDhtPartitionsExchangeFuture.java:1751)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.finishExchangeOnCoordinator(GridDhtPartitionsExchangeFuture.java:2858)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onAllReceived(GridDhtPartitionsExchangeFuture.java:2591)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.processSingleMessage(GridDhtPartitionsExchangeFuture.java:2283)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.access$100(GridDhtPartitionsExchangeFuture.java:129)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture$2.apply(GridDhtPartitionsExchangeFuture.java:2140)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture$2.apply(GridDhtPartitionsExchangeFuture.java:2128)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:383)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.listen(GridFutureAdapter.java:353)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onReceiveSingleMessage(GridDhtPartitionsExchangeFuture.java:2128)
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
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$2.onMessage(GridCachePartitionExchangeManager.java:345)
at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$2.onMessage(GridCachePartitionExchangeManager.java:325)
at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$MessageHandler.apply(GridCachePartitionExchangeManager.java:2848)
at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$MessageHandler.apply(GridCachePartitionExchangeManager.java:2827)
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:1556)
at
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1184)
at
org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:125)
at
org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1091)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
[jira] [Updated] (IGNITE-8946) AssertionError can occur during release of WAL history that was reserved for historical rebalance
[
https://issues.apache.org/jira/browse/IGNITE-8946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Rakov updated IGNITE-8946:
---
Summary: AssertionError can occur during release of WAL history that was
reserved for historical rebalance (was: AssertionError can occur during
reservation of WAL history for historical rebalance)
> AssertionError can occur during release of WAL history that was reserved for
> historical rebalance
> -
>
> Key: IGNITE-8946
> URL: https://issues.apache.org/jira/browse/IGNITE-8946
> Project: Ignite
> Issue Type: Bug
>Reporter: Ivan Rakov
>Priority: Critical
>
> Attempt to release WAL after exchange may fail with AssertionError. Seems
> like we have a bug and may try to release more WAL segments than we have
> reserved:
> {noformat}
> java.lang.AssertionError: null
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.SegmentReservationStorage.release(SegmentReservationStorage.java:54)
> - locked <0x1c12> (a
> org.apache.ignite.internal.processors.cache.persistence.wal.SegmentReservationStorage)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.release(FileWriteAheadLogManager.java:862)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.releaseHistoryForExchange(GridCacheDatabaseSharedManager.java:1691)
> - locked <0x1c17> (a
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onDone(GridDhtPartitionsExchangeFuture.java:1751)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.finishExchangeOnCoordinator(GridDhtPartitionsExchangeFuture.java:2858)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onAllReceived(GridDhtPartitionsExchangeFuture.java:2591)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.processSingleMessage(GridDhtPartitionsExchangeFuture.java:2283)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.access$100(GridDhtPartitionsExchangeFuture.java:129)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture$2.apply(GridDhtPartitionsExchangeFuture.java:2140)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture$2.apply(GridDhtPartitionsExchangeFuture.java:2128)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:383)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.listen(GridFutureAdapter.java:353)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onReceiveSingleMessage(GridDhtPartitionsExchangeFuture.java:2128)
> 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
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$2.onMessage(GridCachePartitionExchangeManager.java:345)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$2.onMessage(GridCachePartitionExchangeManager.java:325)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$MessageHandler.apply(GridCachePartitionExchangeManager.java:2848)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$MessageHandler.apply(GridCachePartitionExchangeManager.java:2827)
> 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
>
[jira] [Updated] (IGNITE-8946) AssertionError can occur during release of WAL history that was reserved for historical rebalance
[
https://issues.apache.org/jira/browse/IGNITE-8946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Rakov updated IGNITE-8946:
---
Description:
Attempt to release WAL history after exchange may fail with AssertionError.
Seems like we have a bug and may try to release more WAL segments than we have
reserved:
{noformat}
java.lang.AssertionError: null
at
org.apache.ignite.internal.processors.cache.persistence.wal.SegmentReservationStorage.release(SegmentReservationStorage.java:54)
- locked <0x1c12> (a
org.apache.ignite.internal.processors.cache.persistence.wal.SegmentReservationStorage)
at
org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.release(FileWriteAheadLogManager.java:862)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.releaseHistoryForExchange(GridCacheDatabaseSharedManager.java:1691)
- locked <0x1c17> (a
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onDone(GridDhtPartitionsExchangeFuture.java:1751)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.finishExchangeOnCoordinator(GridDhtPartitionsExchangeFuture.java:2858)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onAllReceived(GridDhtPartitionsExchangeFuture.java:2591)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.processSingleMessage(GridDhtPartitionsExchangeFuture.java:2283)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.access$100(GridDhtPartitionsExchangeFuture.java:129)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture$2.apply(GridDhtPartitionsExchangeFuture.java:2140)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture$2.apply(GridDhtPartitionsExchangeFuture.java:2128)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:383)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.listen(GridFutureAdapter.java:353)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onReceiveSingleMessage(GridDhtPartitionsExchangeFuture.java:2128)
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
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$2.onMessage(GridCachePartitionExchangeManager.java:345)
at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$2.onMessage(GridCachePartitionExchangeManager.java:325)
at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$MessageHandler.apply(GridCachePartitionExchangeManager.java:2848)
at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$MessageHandler.apply(GridCachePartitionExchangeManager.java:2827)
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:1556)
at
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1184)
at
org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:125)
at
org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1091)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
[jira] [Created] (IGNITE-8946) AssertionError can occur during reservation of WAL history for historical rebalance
Ivan Rakov created IGNITE-8946:
--
Summary: AssertionError can occur during reservation of WAL
history for historical rebalance
Key: IGNITE-8946
URL: https://issues.apache.org/jira/browse/IGNITE-8946
Project: Ignite
Issue Type: Bug
Reporter: Ivan Rakov
Attempt to release WAL after exchange may fail with AssertionError. Seems like
we have a bug and may try to release more WAL segments than we have reserved:
{noformat}
java.lang.AssertionError: null
at
org.apache.ignite.internal.processors.cache.persistence.wal.SegmentReservationStorage.release(SegmentReservationStorage.java:54)
- locked <0x1c12> (a
org.apache.ignite.internal.processors.cache.persistence.wal.SegmentReservationStorage)
at
org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.release(FileWriteAheadLogManager.java:862)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.releaseHistoryForExchange(GridCacheDatabaseSharedManager.java:1691)
- locked <0x1c17> (a
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onDone(GridDhtPartitionsExchangeFuture.java:1751)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.finishExchangeOnCoordinator(GridDhtPartitionsExchangeFuture.java:2858)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onAllReceived(GridDhtPartitionsExchangeFuture.java:2591)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.processSingleMessage(GridDhtPartitionsExchangeFuture.java:2283)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.access$100(GridDhtPartitionsExchangeFuture.java:129)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture$2.apply(GridDhtPartitionsExchangeFuture.java:2140)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture$2.apply(GridDhtPartitionsExchangeFuture.java:2128)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:383)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.listen(GridFutureAdapter.java:353)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onReceiveSingleMessage(GridDhtPartitionsExchangeFuture.java:2128)
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
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$2.onMessage(GridCachePartitionExchangeManager.java:345)
at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$2.onMessage(GridCachePartitionExchangeManager.java:325)
at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$MessageHandler.apply(GridCachePartitionExchangeManager.java:2848)
at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$MessageHandler.apply(GridCachePartitionExchangeManager.java:2827)
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:1556)
at
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1184)
at
org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:125)
at
org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1091)
at
[jira] [Created] (IGNITE-8945) Stored cache data files corruption when node stops abruptly.
Ivan Daschinskiy created IGNITE-8945: Summary: Stored cache data files corruption when node stops abruptly. Key: IGNITE-8945 URL: https://issues.apache.org/jira/browse/IGNITE-8945 Project: Ignite Issue Type: Bug Affects Versions: 2.5 Reporter: Ivan Daschinskiy Assignee: Ivan Daschinskiy Fix For: 2.7 When node is halted during saving stored cache data, content of this file can be corrupted. 1. Additional check should be implemented in FilePageStoreManager.readCacheData (print the name of corrupted file) 2. In storeCacheData we need to serialize StoredCacheData to temp file then swap. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-8906) SQL TX: Immediate rollback for Near transactions during topology changing.
[ https://issues.apache.org/jira/browse/IGNITE-8906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Kondakov reassigned IGNITE-8906: -- Assignee: Roman Kondakov > SQL TX: Immediate rollback for Near transactions during topology changing. > -- > > Key: IGNITE-8906 > URL: https://issues.apache.org/jira/browse/IGNITE-8906 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Roman Kondakov >Assignee: Roman Kondakov >Priority: Major > Labels: mvcc > > At the moment all near transaction that was active during PME, but hadn't > locked topology (i.e. read transactions), are marked as rollback only in > GridDhtPartitionsExchangeFuture#onDone. But it is better to stop transaction > execution immediately to prevent useless updates. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8789) Add a call to the FailureHandler for an error with meta-data.
[
https://issues.apache.org/jira/browse/IGNITE-8789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16533993#comment-16533993
]
ASF GitHub Bot commented on IGNITE-8789:
Github user agura closed the pull request at:
https://github.com/apache/ignite/pull/4204
> Add a call to the FailureHandler for an error with meta-data.
> -
>
> Key: IGNITE-8789
> URL: https://issues.apache.org/jira/browse/IGNITE-8789
> Project: Ignite
> Issue Type: Improvement
>Reporter: Dmitriy Gladkikh
>Assignee: Andrey Gura
>Priority: Critical
> Fix For: 2.7
>
>
> This is a critical situation, corresponding exception should be propagated to
> handler to make necessary actions.
> Need to add a call to the FailureHandler if the specified error occurs.
> When processing a message in the GridCacheIoManager#onMessage0 method, an
> exception was thrown: Failed to process message
> [senderId=f815a46c-8973-4cda-ac77-51325e731cda, messageType=class
> o.a.i.i.processors.cache.distributed.near.GridNearTxFinishRequest]
> An error occurred during the error logging associated with the meta-data:
> Cannot find schema for object with compact footer [typeId=1599442645,
> schemaId=-1705721149]
> The original exception was lost.
> {code:java}
> 2018-06-13
> 09:04:01.593[ERROR][sys-stripe-22-#23%DPL_GRID%DplGridNodeName%][o.a.i.i.p.cache.GridCacheIoManager]
> Failed to process message [senderId=f815a46c-8973-4cda-ac77-51325e731cda,
> messageType=class
> o.a.i.i.processors.cache.distributed.near.GridNearTxFinishRequest]
> org.apache.ignite.IgniteException: Failed to create string representation of
> binary object.
> at
> org.apache.ignite.internal.util.tostring.GridToStringBuilder.toStringImpl(GridToStringBuilder.java:1028)
> at
> org.apache.ignite.internal.util.tostring.GridToStringBuilder.toString(GridToStringBuilder.java:826)
> at
> org.apache.ignite.internal.util.tostring.GridToStringBuilder.toString(GridToStringBuilder.java:783)
> at
> org.apache.ignite.internal.processors.cache.distributed.GridDistributedTxFinishRequest.toString(GridDistributedTxFinishRequest.java:561)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxFinishRequest.toString(GridNearTxFinishRequest.java:221)
> at java.lang.String.valueOf(String.java:2994)
> at java.lang.StringBuilder.append(StringBuilder.java:131)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1060)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:579)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:378)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:304)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:99)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:293)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1556)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1184)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:125)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1091)
> at
> org.apache.ignite.internal.util.StripedExecutor$Stripe.run(StripedExecutor.java:511)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: org.apache.ignite.IgniteException: Failed to create string
> representation of binary object.
> at
> org.apache.ignite.internal.util.tostring.GridToStringBuilder.toStringImpl(GridToStringBuilder.java:1028)
> at
> org.apache.ignite.internal.util.tostring.GridToStringBuilder.toString(GridToStringBuilder.java:826)
> at
> org.apache.ignite.internal.util.tostring.GridToStringBuilder.toString(GridToStringBuilder.java:783)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxStateImpl.toString(IgniteTxStateImpl.java:466)
> at java.lang.String.valueOf(String.java:2994)
> at
> org.apache.ignite.internal.util.GridStringBuilder.a(GridStringBuilder.java:101)
> at
> org.apache.ignite.internal.util.tostring.SBLimitedLength.a(SBLimitedLength.java:88)
> at
> org.apache.ignite.internal.util.tostring.GridToStringBuilder.toString(GridToStringBuilder.java:939)
> at
> org.apache.ignite.internal.util.tostring.GridToStringBuilder.toStringImpl(GridToStringBuilder.java:1005)
> ... 18 common frames omitted
> Caused by: org.apache.ignite.IgniteException: Failed to create string
> representation of binary object.
> at
[jira] [Updated] (IGNITE-8944) TcpDiscoverySpi: set connection check frequency to fixed value
[
https://issues.apache.org/jira/browse/IGNITE-8944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry Karachentsev updated IGNITE-8944:
Labels: discovery (was: )
> TcpDiscoverySpi: set connection check frequency to fixed value
> --
>
> Key: IGNITE-8944
> URL: https://issues.apache.org/jira/browse/IGNITE-8944
> Project: Ignite
> Issue Type: Improvement
> Components: general
>Affects Versions: 2.5
>Reporter: Dmitry Karachentsev
>Priority: Major
> Labels: discovery
> Fix For: 2.7
>
>
> Now connCheckFreq value calculated by some not obvious code:
> {code:java}
> private void initConnectionCheckFrequency() {
> if (spi.failureDetectionTimeoutEnabled())
> connCheckThreshold = spi.failureDetectionTimeout();
> else
> connCheckThreshold = Math.min(spi.getSocketTimeout(),
> spi.metricsUpdateFreq);
> for (int i = 3; i > 0; i--) {
> connCheckFreq = connCheckThreshold / i;
> if (connCheckFreq > 10)
> break;
> }
> assert connCheckFreq > 0;
> if (log.isInfoEnabled())
> log.info("Connection check frequency is calculated: " +
> connCheckFreq);
> }
> {code}
> It should be replaced with constant.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-8944) TcpDiscoverySpi: set connection check frequency to fixed value
[
https://issues.apache.org/jira/browse/IGNITE-8944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry Karachentsev updated IGNITE-8944:
Affects Version/s: 2.5
> TcpDiscoverySpi: set connection check frequency to fixed value
> --
>
> Key: IGNITE-8944
> URL: https://issues.apache.org/jira/browse/IGNITE-8944
> Project: Ignite
> Issue Type: Improvement
> Components: general
>Affects Versions: 2.5
>Reporter: Dmitry Karachentsev
>Priority: Major
> Labels: discovery
> Fix For: 2.7
>
>
> Now connCheckFreq value calculated by some not obvious code:
> {code:java}
> private void initConnectionCheckFrequency() {
> if (spi.failureDetectionTimeoutEnabled())
> connCheckThreshold = spi.failureDetectionTimeout();
> else
> connCheckThreshold = Math.min(spi.getSocketTimeout(),
> spi.metricsUpdateFreq);
> for (int i = 3; i > 0; i--) {
> connCheckFreq = connCheckThreshold / i;
> if (connCheckFreq > 10)
> break;
> }
> assert connCheckFreq > 0;
> if (log.isInfoEnabled())
> log.info("Connection check frequency is calculated: " +
> connCheckFreq);
> }
> {code}
> It should be replaced with constant.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-8944) TcpDiscoverySpi: set connection check frequency to fixed value
[
https://issues.apache.org/jira/browse/IGNITE-8944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry Karachentsev updated IGNITE-8944:
Component/s: general
> TcpDiscoverySpi: set connection check frequency to fixed value
> --
>
> Key: IGNITE-8944
> URL: https://issues.apache.org/jira/browse/IGNITE-8944
> Project: Ignite
> Issue Type: Improvement
> Components: general
>Affects Versions: 2.5
>Reporter: Dmitry Karachentsev
>Priority: Major
> Labels: discovery
> Fix For: 2.7
>
>
> Now connCheckFreq value calculated by some not obvious code:
> {code:java}
> private void initConnectionCheckFrequency() {
> if (spi.failureDetectionTimeoutEnabled())
> connCheckThreshold = spi.failureDetectionTimeout();
> else
> connCheckThreshold = Math.min(spi.getSocketTimeout(),
> spi.metricsUpdateFreq);
> for (int i = 3; i > 0; i--) {
> connCheckFreq = connCheckThreshold / i;
> if (connCheckFreq > 10)
> break;
> }
> assert connCheckFreq > 0;
> if (log.isInfoEnabled())
> log.info("Connection check frequency is calculated: " +
> connCheckFreq);
> }
> {code}
> It should be replaced with constant.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-8944) TcpDiscoverySpi: set connection check frequency to fixed value
[
https://issues.apache.org/jira/browse/IGNITE-8944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry Karachentsev updated IGNITE-8944:
Fix Version/s: 2.7
> TcpDiscoverySpi: set connection check frequency to fixed value
> --
>
> Key: IGNITE-8944
> URL: https://issues.apache.org/jira/browse/IGNITE-8944
> Project: Ignite
> Issue Type: Improvement
> Components: general
>Affects Versions: 2.5
>Reporter: Dmitry Karachentsev
>Priority: Major
> Labels: discovery
> Fix For: 2.7
>
>
> Now connCheckFreq value calculated by some not obvious code:
> {code:java}
> private void initConnectionCheckFrequency() {
> if (spi.failureDetectionTimeoutEnabled())
> connCheckThreshold = spi.failureDetectionTimeout();
> else
> connCheckThreshold = Math.min(spi.getSocketTimeout(),
> spi.metricsUpdateFreq);
> for (int i = 3; i > 0; i--) {
> connCheckFreq = connCheckThreshold / i;
> if (connCheckFreq > 10)
> break;
> }
> assert connCheckFreq > 0;
> if (log.isInfoEnabled())
> log.info("Connection check frequency is calculated: " +
> connCheckFreq);
> }
> {code}
> It should be replaced with constant.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-8944) TcpDiscoverySpi: set connection check frequency to fixed value
Dmitry Karachentsev created IGNITE-8944:
---
Summary: TcpDiscoverySpi: set connection check frequency to fixed
value
Key: IGNITE-8944
URL: https://issues.apache.org/jira/browse/IGNITE-8944
Project: Ignite
Issue Type: Improvement
Reporter: Dmitry Karachentsev
Now connCheckFreq value calculated by some not obvious code:
{code:java}
private void initConnectionCheckFrequency() {
if (spi.failureDetectionTimeoutEnabled())
connCheckThreshold = spi.failureDetectionTimeout();
else
connCheckThreshold = Math.min(spi.getSocketTimeout(),
spi.metricsUpdateFreq);
for (int i = 3; i > 0; i--) {
connCheckFreq = connCheckThreshold / i;
if (connCheckFreq > 10)
break;
}
assert connCheckFreq > 0;
if (log.isInfoEnabled())
log.info("Connection check frequency is calculated: " +
connCheckFreq);
}
{code}
It should be replaced with constant.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8935) IgniteConfiguration dependents should have toString
[ https://issues.apache.org/jira/browse/IGNITE-8935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16533968#comment-16533968 ] ASF GitHub Bot commented on IGNITE-8935: GitHub user alamar opened a pull request: https://github.com/apache/ignite/pull/4318 IGNITE-8935 toString() or exclusion for most classes accessible from IgniteConfiguration You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-8935 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4318.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 #4318 commit 2c664b7be5cce57f5e5e1ecb97705f372632c36a Author: Ilya Kasnacheev Date: 2018-07-05T17:52:51Z IGNITE-8935 toString() or exclusion for most classes accessible from IgniteConfiguration. > IgniteConfiguration dependents should have toString > --- > > Key: IGNITE-8935 > URL: https://issues.apache.org/jira/browse/IGNITE-8935 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.5 >Reporter: Ilya Kasnacheev >Assignee: Ilya Kasnacheev >Priority: Minor > Labels: usability > > Ignite configuration is printed on startup, but some classes which are > usually referred do not have toString() implemented, leading to gems such as > connectorCfg=org.apache.ignite.configuration.ConnectorConfiguration@7d8704ef > Those classes should have toString implemented which will conform to > https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines#CodingGuidelines-StringOutput -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8766) TcpDiscoverySpi: discovery threads naming
[
https://issues.apache.org/jira/browse/IGNITE-8766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16533963#comment-16533963
]
Dmitry Karachentsev commented on IGNITE-8766:
-
Added coordinator flag. If local node is coordinator "crd" will be adder to
ring message worker thread name:
{noformat}
"tcp-disco-msg-worker-[ebd1a087 127.0.0.1:47501 crd]-#2"
{noformat}
> TcpDiscoverySpi: discovery threads naming
> -
>
> Key: IGNITE-8766
> URL: https://issues.apache.org/jira/browse/IGNITE-8766
> Project: Ignite
> Issue Type: Improvement
> Components: general
>Reporter: Sergey Chugunov
>Assignee: Dmitry Karachentsev
>Priority: Major
> Labels: discovery
> Fix For: 2.7
>
>
> Including information about next/prev nodes into names of discovery-related
> threads could be very helpful when investigating situations of network
> glitches.
> tcp-disco-sock-reader and tcp-disco-msg-worker threads must include such
> information in their names.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-8766) TcpDiscoverySpi: discovery threads naming
[
https://issues.apache.org/jira/browse/IGNITE-8766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16533963#comment-16533963
]
Dmitry Karachentsev edited comment on IGNITE-8766 at 7/5/18 5:52 PM:
-
Added coordinator flag. If local node is coordinator, "crd" will be added to
ring message worker thread name:
{noformat}
"tcp-disco-msg-worker-[ebd1a087 127.0.0.1:47501 crd]-#2"
{noformat}
was (Author: dkarachentsev):
Added coordinator flag. If local node is coordinator, "crd" will be adder to
ring message worker thread name:
{noformat}
"tcp-disco-msg-worker-[ebd1a087 127.0.0.1:47501 crd]-#2"
{noformat}
> TcpDiscoverySpi: discovery threads naming
> -
>
> Key: IGNITE-8766
> URL: https://issues.apache.org/jira/browse/IGNITE-8766
> Project: Ignite
> Issue Type: Improvement
> Components: general
>Reporter: Sergey Chugunov
>Assignee: Dmitry Karachentsev
>Priority: Major
> Labels: discovery
> Fix For: 2.7
>
>
> Including information about next/prev nodes into names of discovery-related
> threads could be very helpful when investigating situations of network
> glitches.
> tcp-disco-sock-reader and tcp-disco-msg-worker threads must include such
> information in their names.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-8766) TcpDiscoverySpi: discovery threads naming
[
https://issues.apache.org/jira/browse/IGNITE-8766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16533963#comment-16533963
]
Dmitry Karachentsev edited comment on IGNITE-8766 at 7/5/18 5:52 PM:
-
Added coordinator flag. If local node is coordinator, "crd" will be adder to
ring message worker thread name:
{noformat}
"tcp-disco-msg-worker-[ebd1a087 127.0.0.1:47501 crd]-#2"
{noformat}
was (Author: dkarachentsev):
Added coordinator flag. If local node is coordinator "crd" will be adder to
ring message worker thread name:
{noformat}
"tcp-disco-msg-worker-[ebd1a087 127.0.0.1:47501 crd]-#2"
{noformat}
> TcpDiscoverySpi: discovery threads naming
> -
>
> Key: IGNITE-8766
> URL: https://issues.apache.org/jira/browse/IGNITE-8766
> Project: Ignite
> Issue Type: Improvement
> Components: general
>Reporter: Sergey Chugunov
>Assignee: Dmitry Karachentsev
>Priority: Major
> Labels: discovery
> Fix For: 2.7
>
>
> Including information about next/prev nodes into names of discovery-related
> threads could be very helpful when investigating situations of network
> glitches.
> tcp-disco-sock-reader and tcp-disco-msg-worker threads must include such
> information in their names.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-8943) Deactivation in large cluster during rebalance can not finish
[ https://issues.apache.org/jira/browse/IGNITE-8943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Medvedev updated IGNITE-8943: Summary: Deactivation in large cluster during rebalance can not finish (was: Deactivation in large cluster hangs during rebalance) > Deactivation in large cluster during rebalance can not finish > - > > Key: IGNITE-8943 > URL: https://issues.apache.org/jira/browse/IGNITE-8943 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.5 >Reporter: Andrew Medvedev >Priority: Major > > In large cluster (> 100 nodes) deactivation during rebalance does not finish > (we have waited for at least an hour). > All nodes log "Start deactivation process" message, but on all nodes > exchange-worker threads in cluster are WAITING with this stack: > "exchange-worker-#152%DPL_GRID%DplGridNodeName%" #520 daemon prio=5 os_prio=0 > tid=0x7f5cfb2b6000 nid=0x2dc7bc waiting on condition [0x7f59a05b2000] > java.lang.Thread.State: WAITING (parking) > at sun.misc.Unsafe.park(Native Method) > at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304) > at > org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:177) > at > org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:140) > at > org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryManager.cancelInternalQuery(CacheContinuousQueryManager.java:575) > at > org.apache.ignite.internal.processors.datastructures.DataStructuresProcessor.onKernalStop(DataStructuresProcessor.java:253) > at > org.apache.ignite.internal.processors.datastructures.DataStructuresProcessor.onDeActivate(DataStructuresProcessor.java:299) > at > org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onClusterStateChangeRequest(GridDhtPartitionsExchangeFuture.java:954) > at > org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:650) > at > org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body0(GridCachePartitionExchangeManager.java:2452) > at > org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2332) > at > org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110) > at java.lang.Thread.run(Thread.java:745) > This is reproducible -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8943) Deactivation in large cluster hangs during rebalance
Andrew Medvedev created IGNITE-8943: --- Summary: Deactivation in large cluster hangs during rebalance Key: IGNITE-8943 URL: https://issues.apache.org/jira/browse/IGNITE-8943 Project: Ignite Issue Type: Bug Affects Versions: 2.5 Reporter: Andrew Medvedev In large cluster (> 100 nodes) deactivation during rebalance does not finish (we have waited for at least an hour). All nodes log "Start deactivation process" message, but on all nodes exchange-worker threads in cluster are WAITING with this stack: "exchange-worker-#152%DPL_GRID%DplGridNodeName%" #520 daemon prio=5 os_prio=0 tid=0x7f5cfb2b6000 nid=0x2dc7bc waiting on condition [0x7f59a05b2000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304) at org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:177) at org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:140) at org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryManager.cancelInternalQuery(CacheContinuousQueryManager.java:575) at org.apache.ignite.internal.processors.datastructures.DataStructuresProcessor.onKernalStop(DataStructuresProcessor.java:253) at org.apache.ignite.internal.processors.datastructures.DataStructuresProcessor.onDeActivate(DataStructuresProcessor.java:299) at org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onClusterStateChangeRequest(GridDhtPartitionsExchangeFuture.java:954) at org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:650) at org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body0(GridCachePartitionExchangeManager.java:2452) at org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2332) at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110) at java.lang.Thread.run(Thread.java:745) This is reproducible -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8766) TcpDiscoverySpi: discovery threads naming
[ https://issues.apache.org/jira/browse/IGNITE-8766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16533928#comment-16533928 ] ASF GitHub Bot commented on IGNITE-8766: GitHub user dkarachentsev opened a pull request: https://github.com/apache/ignite/pull/4317 IGNITE-8766 - TcpDiscoverySpi: discovery threads naming You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-8766 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4317.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 #4317 commit 8971f29cefe49b1b30bd885919dedef71811fe99 Author: dkarachentsev Date: 2018-07-05T17:25:18Z IGNITE-8766 - TcpDiscoverySpi: discovery threads naming > TcpDiscoverySpi: discovery threads naming > - > > Key: IGNITE-8766 > URL: https://issues.apache.org/jira/browse/IGNITE-8766 > Project: Ignite > Issue Type: Improvement > Components: general >Reporter: Sergey Chugunov >Assignee: Dmitry Karachentsev >Priority: Major > Labels: discovery > > Including information about next/prev nodes into names of discovery-related > threads could be very helpful when investigating situations of network > glitches. > tcp-disco-sock-reader and tcp-disco-msg-worker threads must include such > information in their names. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8754) Node outside of baseline does not start when service configured
[
https://issues.apache.org/jira/browse/IGNITE-8754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16533887#comment-16533887
]
Anton Kalashnikov commented on IGNITE-8754:
---
Looks good for me. But some tests were failed. I restarted thier but
nevertheless could you check this suit -
https://ci.ignite.apache.org/viewLog.html?buildId=1457403. It contains your
tests which you just written.
After tests was success it can be merged.
> Node outside of baseline does not start when service configured
> ---
>
> Key: IGNITE-8754
> URL: https://issues.apache.org/jira/browse/IGNITE-8754
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Assignee: Vladislav Pyatkov
>Priority: Major
> Attachments: ServiceOnNodeOutOfBaselineTest.java
>
>
> Enough to configure service in {{ServiceConfiguration}} and the node does not
> started if the node outside of baseline.
> {noformat}
> "async-runnable-runner-1" #287 prio=5 os_prio=0 tid=0x24e0c800
> nid=0x4e6c waiting on condition [0xe87fe000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:177)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:140)
> at
> org.apache.ignite.internal.processors.service.GridServiceProcessor.onKernalStart0(GridServiceProcessor.java:287)
> at
> org.apache.ignite.internal.processors.service.GridServiceProcessor.onKernalStart(GridServiceProcessor.java:228)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1105)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2014)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1723)
> - locked <0x00076c142400> (a
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1151)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:649)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:882)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:845)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:833)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:799)
> at
> org.gridgain.internal.ServiceOnNodeOutOfBaselineTest.lambda$test$0(ServiceOnNodeOutOfBaselineTest.java:107)
> at
> org.gridgain.internal.ServiceOnNodeOutOfBaselineTest$$Lambda$22/781127963.run(Unknown
> Source)
> at
> org.apache.ignite.testframework.GridTestUtils.lambda$runAsync$1(GridTestUtils.java:898)
> at
> org.apache.ignite.testframework.GridTestUtils$$Lambda$23/1655470614.call(Unknown
> Source)
> at
> org.apache.ignite.testframework.GridTestUtils.lambda$runAsync$2(GridTestUtils.java:956)
> at
> org.apache.ignite.testframework.GridTestUtils$$Lambda$24/1782331932.run(Unknown
> Source)
> at
> org.apache.ignite.testframework.GridTestUtils$6.call(GridTestUtils.java:1254)
> at
> org.apache.ignite.testframework.GridTestThread.run(GridTestThread.java:86)
> {noformat}
> Test [^ServiceOnNodeOutOfBaselineTest.java] hangs with assertion because
> node can not started or stopped.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8938) file-decompressor thread termination should be handled with Failure handler
[
https://issues.apache.org/jira/browse/IGNITE-8938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16533883#comment-16533883
]
ASF GitHub Bot commented on IGNITE-8938:
GitHub user agura opened a pull request:
https://github.com/apache/ignite/pull/4316
IGNITE-8938 Failure handling for file-decompressor thread added
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/agura/incubator-ignite ignite-8938
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/4316.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 #4316
commit cd2b1562fe01cc4a1172aabdab74c3c1308b3237
Author: Andrey Gura
Date: 2018-07-05T16:40:26Z
IGNITE-8938 Failure handling for file-decompressor thread added
> file-decompressor thread termination should be handled with Failure handler
> ---
>
> Key: IGNITE-8938
> URL: https://issues.apache.org/jira/browse/IGNITE-8938
> Project: Ignite
> Issue Type: Bug
>Reporter: Andrey Gura
>Assignee: Andrey Gura
>Priority: Major
> Fix For: 2.7
>
>
> file-decompressor thread termination should be handled with Failure Handler
> (IEP-14).
> It doesn't work right now. Also exception handling in {{body()}} method
> should be revised.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-8942) In some cases grid cannot be deactivated because of hanging CQ internal cleanup.
Alexei Scherbakov created IGNITE-8942: - Summary: In some cases grid cannot be deactivated because of hanging CQ internal cleanup. Key: IGNITE-8942 URL: https://issues.apache.org/jira/browse/IGNITE-8942 Project: Ignite Issue Type: Bug Reporter: Alexei Scherbakov Assignee: Alexei Scherbakov Attachments: thread_dump_eip-server_2018-07-05-18-02.log See the attachment for thread dump. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8942) In some cases grid cannot be deactivated because of hanging CQ internal cleanup.
[ https://issues.apache.org/jira/browse/IGNITE-8942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexei Scherbakov updated IGNITE-8942: -- Fix Version/s: 2.6 > In some cases grid cannot be deactivated because of hanging CQ internal > cleanup. > > > Key: IGNITE-8942 > URL: https://issues.apache.org/jira/browse/IGNITE-8942 > Project: Ignite > Issue Type: Bug >Reporter: Alexei Scherbakov >Assignee: Alexei Scherbakov >Priority: Major > Fix For: 2.6 > > Attachments: thread_dump_eip-server_2018-07-05-18-02.log > > > See the attachment for thread dump. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8564) DataStreamer fails if client reconnected to the cluster and allowOverride = true
[ https://issues.apache.org/jira/browse/IGNITE-8564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16533854#comment-16533854 ] Ilya Kasnacheev commented on IGNITE-8564: - [~slava.koptilin] please review the proposed fix. > DataStreamer fails if client reconnected to the cluster and allowOverride = > true > > > Key: IGNITE-8564 > URL: https://issues.apache.org/jira/browse/IGNITE-8564 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.6 >Reporter: Ilya Kasnacheev >Assignee: Ilya Kasnacheev >Priority: Major > Labels: test > Fix For: 2.7 > > Attachments: DataStreamerClientReconnectAfterClusterRestartTest.java > > > But wait, there's more. > This only happens when client has reconnected to a new cluster and topology > version after that is exactly the same like when it left. > Please see the attached test. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8898) rename command argument '--force' to '--yes' for control.sh
[ https://issues.apache.org/jira/browse/IGNITE-8898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16533825#comment-16533825 ] Eduard Shangareev commented on IGNITE-8898: --- Please, replace if with a switch in the new test. And where is TC Run? > rename command argument '--force' to '--yes' for control.sh > --- > > Key: IGNITE-8898 > URL: https://issues.apache.org/jira/browse/IGNITE-8898 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.5 >Reporter: Max Shonichev >Assignee: Vladislav Pyatkov >Priority: Major > > control.sh requires admin to provide `--force` to auto-confirm actions > requiring manual confirmation as deactivation of the grid or setting new > baseline. Semantically, this is not 'forcing', but 'auto-confirmation', so > please, rename `--force` argument of control.sh to `--yes`. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-6854) Enabling Persistent Memory for Ignite
[ https://issues.apache.org/jira/browse/IGNITE-6854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16533790#comment-16533790 ] Mulugeta Mammo commented on IGNITE-6854: Hi, I have pulled down the patch and will post an enhancement proposal and pull request for a new version. Thanks > 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.7 > > > 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-6854) Enabling Persistent Memory for Ignite
[ https://issues.apache.org/jira/browse/IGNITE-6854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mulugeta Mammo updated IGNITE-6854: --- Attachment: (was: ignite_3DXPoint.patch) > 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.7 > > > 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] [Comment Edited] (IGNITE-2313) Need to add a mode to fail atomic operations within a transaction
[
https://issues.apache.org/jira/browse/IGNITE-2313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16533578#comment-16533578
]
Ryabov Dmitrii edited comment on IGNITE-2313 at 7/5/18 1:56 PM:
[~agoncharuk], I made improvement suggested by Anton and described this
behaviour in {{withAllowAtomicOpsInTx()}} javadoc, can you look it?
[Upsource|https://reviews.ignite.apache.org/ignite/review/IGNT-CR-675], [CI
tests|https://ci.ignite.apache.org/viewLog.html?buildId=1456467=buildResultsDiv=IgniteTests24Java8_RunAll]
are ok.
was (Author: somefire):
[~agoncharuk], I made improvement suggested by Anton and described this
behaviour in {{withAllowAtomicOpsInTx()}} javadoc, can you look it?
[Upsource|https://reviews.ignite.apache.org/ignite/review/IGNT-CR-675]
> Need to add a mode to fail atomic operations within a transaction
> -
>
> Key: IGNITE-2313
> URL: https://issues.apache.org/jira/browse/IGNITE-2313
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Reporter: Dmitriy Setrakyan
>Assignee: Ryabov Dmitrii
>Priority: Major
> Fix For: 2.7
>
>
> Currently atomic operations within a transaction succeed without alarming a
> user that no transaction really occurs. We should add a mode to fail such
> operations (such mode should be turned off by default).
> New transaction configuration flag (default is {{false}}):
> {code}TransactionConfiguration.isAllowAtomicUpdatesInTransaction(){code}
> If the flag is violated, we should throw an exception with the following
> error message: {{Transaction spans operations on atomic cache (consider
> setting TransactionConfiguration.isAllowAttomicUpdatesInTransaction() flag to
> true)}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8869) PartitionsExchangeOnDiscoveryHistoryOverflowTest hangs on TeamCity
[ https://issues.apache.org/jira/browse/IGNITE-8869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16533689#comment-16533689 ] Vladislav Pyatkov commented on IGNITE-8869: --- Locks good for me. That solution is obviously better then it was. > PartitionsExchangeOnDiscoveryHistoryOverflowTest hangs on TeamCity > -- > > Key: IGNITE-8869 > URL: https://issues.apache.org/jira/browse/IGNITE-8869 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.5 >Reporter: Ivan Daschinskiy >Assignee: Ivan Daschinskiy >Priority: Critical > Labels: MakeTeamcityGreenAgain > Fix For: 2.7 > > > After introduction of ExhangeLatches, > PartitionsExchangeOnDiscoveryHistoryOverflowTest will hangs permanently. In > current implementation, ExchangeLatchManager retrieves alive nodes from > discoveryCache with specific affinity topology version and fails because of a > too short discovery history. This causes fail of exchange-worker and > therefore NoOpFailureHandler leaves node in hanging state. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8941) BinaryInvalidTypeException is thrown on invoke
Mikhail Cherkasov created IGNITE-8941: - Summary: BinaryInvalidTypeException is thrown on invoke Key: IGNITE-8941 URL: https://issues.apache.org/jira/browse/IGNITE-8941 Project: Ignite Issue Type: Bug Components: general Reporter: Mikhail Cherkasov Attachments: MyPocTest.java Reproducer is attached. The following exception is thrown: [2018-07-05 16:31:44,554][ERROR][Thread-6][GridDhtAtomicCache] Unexpected exception during cache update class org.apache.ignite.binary.BinaryInvalidTypeException: invoke0 at org.apache.ignite.internal.binary.BinaryContext.descriptorForTypeId(BinaryContext.java:707) at org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1757) at org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1716) at org.apache.ignite.internal.binary.BinaryObjectImpl.deserializeValue(BinaryObjectImpl.java:798) at org.apache.ignite.internal.binary.BinaryObjectImpl.value(BinaryObjectImpl.java:143) at org.apache.ignite.internal.processors.cache.GridCacheUtils.value(GridCacheUtils.java:1312) at org.apache.ignite.internal.processors.cache.GridCacheReturn.addEntryProcessResult(GridCacheReturn.java:253) at org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateSingle(GridDhtAtomicCache.java:2553) at org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.update(GridDhtAtomicCache.java:1898) at org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1740) at org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1630) at org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.sendSingleRequest(GridNearAtomicAbstractUpdateFuture.java:299) at org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.map(GridNearAtomicSingleUpdateFuture.java:483) at org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.mapOnTopology(GridNearAtomicSingleUpdateFuture.java:443) at org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.map(GridNearAtomicAbstractUpdateFuture.java:248) at org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.update0(GridDhtAtomicCache.java:1119) at org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.invoke0(GridDhtAtomicCache.java:827) at org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.invoke(GridDhtAtomicCache.java:787) at org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.invoke(IgniteCacheProxyImpl.java:1417) at org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.invoke(IgniteCacheProxyImpl.java:1461) at org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.invoke(GatewayProtectedCacheProxy.java:1220) at my_poc_test.MyPocTest$InvokeTask.run(MyPocTest.java:172) at java.lang.Thread.run(Thread.java:748) Caused by: java.lang.ClassNotFoundException: invoke0 at java.net.URLClassLoader.findClass(URLClassLoader.java:381) at java.lang.ClassLoader.loadClass(ClassLoader.java:424) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:338) at java.lang.ClassLoader.loadClass(ClassLoader.java:357) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:348) at org.apache.ignite.internal.util.IgniteUtils.forName(IgniteUtils.java:8640) at org.apache.ignite.internal.MarshallerContextImpl.getClass(MarshallerContextImpl.java:349) at org.apache.ignite.internal.binary.BinaryContext.descriptorForTypeId(BinaryContext.java:698) ... 22 more -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8619) Remote node could not start in ssh connection
[ https://issues.apache.org/jira/browse/IGNITE-8619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Fedotov updated IGNITE-8619: - Summary: Remote node could not start in ssh connection (was: Remote node could not start' in ssh connection) > Remote node could not start in ssh connection > - > > Key: IGNITE-8619 > URL: https://issues.apache.org/jira/browse/IGNITE-8619 > Project: Ignite > Issue Type: Bug >Reporter: Ivan Fedotov >Assignee: Ivan Fedotov >Priority: Major > > Now there is a problem with launch remote node via ssh. Initially was an > assumption that it's due to remote process has not enough time to write > information into log: > [IGNITE-8085|https://issues.apache.org/jira/browse/IGNITE-8085]. But this > correction didn't fix [TeamCity > |https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=6814497542781613621=testDetails]. > > So it's necessary to make launch remote node via ssh always succesful. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8619) Remote node could not start in ssh connection
[ https://issues.apache.org/jira/browse/IGNITE-8619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16533636#comment-16533636 ] ASF GitHub Bot commented on IGNITE-8619: GitHub user 1vanan opened a pull request: https://github.com/apache/ignite/pull/4314 IGNITE-8619 Remote node could not start in ssh connection You can merge this pull request into a Git repository by running: $ git pull https://github.com/1vanan/ignite IGNITE-8619 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4314.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 #4314 commit e9e9e4ae5c1b31d9218865981cc3a936c6e922b8 Author: Fedotov Date: 2018-07-05T09:36:31Z change shell command commit b90c9cbde31eb8cfd522c7159d1d8c855e4f8904 Author: Fedotov Date: 2018-07-05T11:58:13Z fix shell command > Remote node could not start in ssh connection > - > > Key: IGNITE-8619 > URL: https://issues.apache.org/jira/browse/IGNITE-8619 > Project: Ignite > Issue Type: Bug >Reporter: Ivan Fedotov >Assignee: Ivan Fedotov >Priority: Major > > Now there is a problem with launch remote node via ssh. Initially was an > assumption that it's due to remote process has not enough time to write > information into log: > [IGNITE-8085|https://issues.apache.org/jira/browse/IGNITE-8085]. But this > correction didn't fix [TeamCity > |https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=6814497542781613621=testDetails]. > > So it's necessary to make launch remote node via ssh always succesful. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8619) Remote node could not start' in ssh connection
[ https://issues.apache.org/jira/browse/IGNITE-8619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Fedotov updated IGNITE-8619: - Summary: Remote node could not start' in ssh connection (was: 'Remote node could not start' in ssh connection) > Remote node could not start' in ssh connection > -- > > Key: IGNITE-8619 > URL: https://issues.apache.org/jira/browse/IGNITE-8619 > Project: Ignite > Issue Type: Bug >Reporter: Ivan Fedotov >Assignee: Ivan Fedotov >Priority: Major > > Now there is a problem with launch remote node via ssh. Initially was an > assumption that it's due to remote process has not enough time to write > information into log: > [IGNITE-8085|https://issues.apache.org/jira/browse/IGNITE-8085]. But this > correction didn't fix [TeamCity > |https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=6814497542781613621=testDetails]. > > So it's necessary to make launch remote node via ssh always succesful. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8714) CacheEntryEvent.getOldValue should be available
[ https://issues.apache.org/jira/browse/IGNITE-8714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16533624#comment-16533624 ] ASF GitHub Bot commented on IGNITE-8714: GitHub user NSAmelchev opened a pull request: https://github.com/apache/ignite/pull/4313 IGNITE-8714 For IGNITE-8714. You can merge this pull request into a Git repository by running: $ git pull https://github.com/NSAmelchev/ignite ignite-8714 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4313.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 #4313 commit 9ab86440476be4b499c618d00a8729db39528dd6 Author: Alexander Menshikov Date: 2018-06-04T09:11:31Z ignite-8687 Add JCache TCK 1.1.0 to TC Signed-off-by: NSAmelchev commit 187a644b99ae8c0a29f44b2ab46a084cd30af370 Author: Alexander Menshikov Date: 2018-06-07T09:37:51Z ignite-8714 CacheEntryEvent.getOldValue should be available Signed-off-by: NSAmelchev commit f626675f622d50b86fb3d5d9643f365ed67b4713 Author: Alexander Menshikov Date: 2018-06-14T10:05:40Z Revert "ignite-8687 Add JCache TCK 1.1.0 to TC" Signed-off-by: NSAmelchev commit 525da4854829855efa29b7a737b1a561180afa52 Author: Alexander Menshikov Date: 2018-06-19T10:35:59Z ignite-8714 fix problems with ignite's tests Signed-off-by: NSAmelchev commit 6f701a090003dd69b28d46559d22665e1ebe042b Author: Alexander Menshikov Date: 2018-06-21T08:55:33Z temp commit Signed-off-by: NSAmelchev commit 75ff37961ea72e782deaf6b73b71a57bc5009de8 Author: Alexander Menshikov Date: 2018-06-21T09:55:46Z fix problems with tests Signed-off-by: NSAmelchev commit f59f9ee66b5afd4848d83d020dd0b69746ea10f6 Author: Alexander Menshikov Date: 2018-06-21T12:25:32Z fix our tests Signed-off-by: NSAmelchev commit 4d9ae8b680e1d27e8455b92854f3b2b1fbd89099 Author: Alexander Menshikov Date: 2018-06-21T16:09:07Z fix prblms with tests Signed-off-by: NSAmelchev commit 6d2960c00d07170618fb15edd6dde8d42b38aff9 Author: Alexander Menshikov Date: 2018-06-22T11:31:12Z fx pr t Signed-off-by: NSAmelchev commit c791f9a4ee010519c8deb6ede793a02f4b34aa31 Author: Alexander Menshikov Date: 2018-06-22T12:50:05Z tempcmt1 Signed-off-by: NSAmelchev commit da17a41b10f66a82fd680873a7c5240db861fa5a Author: Alexander Menshikov Date: 2018-06-22T15:35:50Z tmp cmt Signed-off-by: NSAmelchev commit 79a0d4e59ecc7d35427f5724b1afb225c4004a9d Author: Alexander Menshikov Date: 2018-06-27T11:24:00Z fix hang Signed-off-by: NSAmelchev commit cc37a46c8032694448556135e0e3e8033c615235 Author: Alexander Menshikov Date: 2018-06-27T16:49:53Z remove temp files Signed-off-by: NSAmelchev commit b123a276801060cab722faba1ba5d0db08e204d8 Author: NSAmelchev Date: 2018-07-05T13:05:16Z revert optimization > CacheEntryEvent.getOldValue should be available > --- > > Key: IGNITE-8714 > URL: https://issues.apache.org/jira/browse/IGNITE-8714 > Project: Ignite > Issue Type: Sub-task >Reporter: Alexander Menshikov >Assignee: Amelchev Nikita >Priority: Major > Labels: iep-21 > Fix For: 2.7 > > > A table is copied from speck changing discussion: > When CacheEntryListenerConfiguration#isOldValueRequired is *true*: > ||CacheEntryEvent Method||CreatedListener||UpdatedListener||Removed/Expired > Listener|| > |getValue()|_value_|_value_|_oldValue_| > |getOldValue()|null|_oldValue_|_oldValue_| > The last column is new behavior for #getValue(). > Сurrent master fails with this reason on following tests: > * CacheListenerTest.testFilteredListener > * CacheListenerTest.testCacheEntryListener > I have to say tests testFilteredListener and testCacheEntryListener also fail > in `afterTests` section because of IGNITE-8715, so PR will not change the > number of failed tests if ignite-8715 unfixed. But it will change the reason > – please see the log. > Please see also link on JCache TCK and speck 1.1.0 changes. > > *UPD:* > There are a lot of our tests wich going to break by this change. Also, we use > events in Services deployment, which will be affected too. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8754) Node outside of baseline does not start when service configured
[
https://issues.apache.org/jira/browse/IGNITE-8754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16533616#comment-16533616
]
Vladislav Pyatkov commented on IGNITE-8754:
---
Look at the TC run:
https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_RunAll=buildTypeChains_IgniteTests24Java8=pull%2F4311%2Fhead#_expand=block_bt984-1457499=0=0
> Node outside of baseline does not start when service configured
> ---
>
> Key: IGNITE-8754
> URL: https://issues.apache.org/jira/browse/IGNITE-8754
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Assignee: Vladislav Pyatkov
>Priority: Major
> Attachments: ServiceOnNodeOutOfBaselineTest.java
>
>
> Enough to configure service in {{ServiceConfiguration}} and the node does not
> started if the node outside of baseline.
> {noformat}
> "async-runnable-runner-1" #287 prio=5 os_prio=0 tid=0x24e0c800
> nid=0x4e6c waiting on condition [0xe87fe000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:177)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:140)
> at
> org.apache.ignite.internal.processors.service.GridServiceProcessor.onKernalStart0(GridServiceProcessor.java:287)
> at
> org.apache.ignite.internal.processors.service.GridServiceProcessor.onKernalStart(GridServiceProcessor.java:228)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1105)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2014)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1723)
> - locked <0x00076c142400> (a
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1151)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:649)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:882)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:845)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:833)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:799)
> at
> org.gridgain.internal.ServiceOnNodeOutOfBaselineTest.lambda$test$0(ServiceOnNodeOutOfBaselineTest.java:107)
> at
> org.gridgain.internal.ServiceOnNodeOutOfBaselineTest$$Lambda$22/781127963.run(Unknown
> Source)
> at
> org.apache.ignite.testframework.GridTestUtils.lambda$runAsync$1(GridTestUtils.java:898)
> at
> org.apache.ignite.testframework.GridTestUtils$$Lambda$23/1655470614.call(Unknown
> Source)
> at
> org.apache.ignite.testframework.GridTestUtils.lambda$runAsync$2(GridTestUtils.java:956)
> at
> org.apache.ignite.testframework.GridTestUtils$$Lambda$24/1782331932.run(Unknown
> Source)
> at
> org.apache.ignite.testframework.GridTestUtils$6.call(GridTestUtils.java:1254)
> at
> org.apache.ignite.testframework.GridTestThread.run(GridTestThread.java:86)
> {noformat}
> Test [^ServiceOnNodeOutOfBaselineTest.java] hangs with assertion because
> node can not started or stopped.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8754) Node outside of baseline does not start when service configured
[
https://issues.apache.org/jira/browse/IGNITE-8754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16533613#comment-16533613
]
ASF GitHub Bot commented on IGNITE-8754:
GitHub user vldpyatkov opened a pull request:
https://github.com/apache/ignite/pull/4311
IGNITE-8754
Node outside of baseline does not start when service configured
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-4022
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/4311.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 #4311
commit 33c2e656d6fa64283b4e41ae6a15411039f4e9d9
Author: vd-pyatkov
Date: 2018-07-05T12:51:10Z
IGNITE-8754
Node outside of baseline does not start when service configured
> Node outside of baseline does not start when service configured
> ---
>
> Key: IGNITE-8754
> URL: https://issues.apache.org/jira/browse/IGNITE-8754
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Assignee: Vladislav Pyatkov
>Priority: Major
> Attachments: ServiceOnNodeOutOfBaselineTest.java
>
>
> Enough to configure service in {{ServiceConfiguration}} and the node does not
> started if the node outside of baseline.
> {noformat}
> "async-runnable-runner-1" #287 prio=5 os_prio=0 tid=0x24e0c800
> nid=0x4e6c waiting on condition [0xe87fe000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:177)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:140)
> at
> org.apache.ignite.internal.processors.service.GridServiceProcessor.onKernalStart0(GridServiceProcessor.java:287)
> at
> org.apache.ignite.internal.processors.service.GridServiceProcessor.onKernalStart(GridServiceProcessor.java:228)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1105)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2014)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1723)
> - locked <0x00076c142400> (a
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1151)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:649)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:882)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:845)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:833)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:799)
> at
> org.gridgain.internal.ServiceOnNodeOutOfBaselineTest.lambda$test$0(ServiceOnNodeOutOfBaselineTest.java:107)
> at
> org.gridgain.internal.ServiceOnNodeOutOfBaselineTest$$Lambda$22/781127963.run(Unknown
> Source)
> at
> org.apache.ignite.testframework.GridTestUtils.lambda$runAsync$1(GridTestUtils.java:898)
> at
> org.apache.ignite.testframework.GridTestUtils$$Lambda$23/1655470614.call(Unknown
> Source)
> at
> org.apache.ignite.testframework.GridTestUtils.lambda$runAsync$2(GridTestUtils.java:956)
> at
> org.apache.ignite.testframework.GridTestUtils$$Lambda$24/1782331932.run(Unknown
> Source)
> at
> org.apache.ignite.testframework.GridTestUtils$6.call(GridTestUtils.java:1254)
> at
> org.apache.ignite.testframework.GridTestThread.run(GridTestThread.java:86)
> {noformat}
> Test [^ServiceOnNodeOutOfBaselineTest.java] hangs with assertion because
> node can not started or stopped.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8753) Improve error message when requested topology version was preempted from Discovery Cache
[
https://issues.apache.org/jira/browse/IGNITE-8753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16533611#comment-16533611
]
Yakov Zhdanov commented on IGNITE-8753:
---
Agree, let's add it - see updated message below
{noformat}
Failed to resolve nodes topology (consider increasing value for
DISCOVERY_HISTORY system property) [cacheGrp=, topVer=, history=, snap=,
locNode=, curDiscoHistSize=]
{noformat}
> Improve error message when requested topology version was preempted from
> Discovery Cache
>
>
> Key: IGNITE-8753
> URL: https://issues.apache.org/jira/browse/IGNITE-8753
> Project: Ignite
> Issue Type: Improvement
>Reporter: Sergey Chugunov
>Priority: Major
>
> When a lot of nodes try to join cluster at the same time (which is common
> when ZookeeperDiscoverySpi is used), size of Discovery Cache may be exhausted
> so next node won't find topology version it needs to proceed with joining.
> For now exception is thrown in this situation, we need to improve its message
> with suggestion to check DISCOVERY_HISTORY setting.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8570) Create lighter version of GridStringLogger
[
https://issues.apache.org/jira/browse/IGNITE-8570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16533604#comment-16533604
]
ASF GitHub Bot commented on IGNITE-8570:
GitHub user voipp opened a pull request:
https://github.com/apache/ignite/pull/4310
IGNITE-8570 Create lighter version of GridStringLogger
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/voipp/ignite IGNITE-8570
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/4310.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 #4310
commit c5f1277edb5ffa2eed337304a0d5ed8e66d76f9b
Author: voipp
Date: 2018-06-28T20:14:54Z
logger implemented
> Create lighter version of GridStringLogger
> --
>
> Key: IGNITE-8570
> URL: https://issues.apache.org/jira/browse/IGNITE-8570
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.4
>Reporter: Andrey Kuznetsov
>Assignee: Alexey Kuznetsov
>Priority: Major
> Fix For: 2.7
>
>
> _+Problem with current GridStringLogger implementation+_:
> Most usages of {{GridStringLogger}} in test assumes the following scenario.
> First, it is set as a logger for some Ignite node.
> Then, after some activity on that node, log content is searched for some
> predefined strings.
> {{GridStringLogger}} uses {{StringBuilder}} of bounded size internally to
> store log contents, older contents gets dropped on exaustion.
> Thus, changes that add more logging may damage some independent tests that
> use {{GridStringLogger}}.
>
> +_The suggestion for new implementation:_+
> The suggestion is to implement and use another test logger conforming to
> these requirements:
> * It does not accumulate any logs(actually, it will print no logs to
> anywhere)
> * It allows to set the listener that fires when log message matches certain
> regular expression, {{Matcher}} can be passed to the listener
>
> _+Proposed design+_, pseudocode:
> ```
> Class GridRegexpLogger implements IgniteLogger{
> …
> debug(String str){
> if (/* str matches pattern. */)
> \{ /* notify listeners. */ }
> }
> …
> listen("regexp", loggerListener)
> { /* registers listener. */ }
> listenDebug("regexp", loggerListener)
> { /* registers listener for debug output only. */ }
> …
> waitFor("regexp", timeout)
> { /* like GridTestUtils.waitForCondition(), waits for regexp to occure in
> logs. */ }
> …
> }
> ```
> +_Sample regexp logger usage_+:
> ```
> GridRegexpLogger logger;
> logger.listen(“regexp”, new GridRegexpListener());
> logger.waitFor("regexp", 100);
> ```
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-8939) Transaction string reprsentation unhandled exception
[
https://issues.apache.org/jira/browse/IGNITE-8939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Evgenii Zagumennov updated IGNITE-8939:
---
Description:
IgniteTxHandler.finishDhtLocal() (IgniteTxHandler.java:957)
{code:java}
U.error(log, "Failed completing transaction [commit=" + req.commit() + ", tx="
+ *tx* + ']', e);{code}
tx.toString() can lead to excepion (in GridToStringBuilder.toStringImpl()), and
original exception in transaction will be lost. We need to log original
exception and catch probable tx.toString() exception.
was:
IgniteTxHandler.finishDhtLocal() (IgniteTxHandler.java:957)
U.error(log, "Failed completing transaction [commit=" + req.commit() + ", tx="
+ *tx* + ']', e);
tx.toString() can lead to excepion (because of errors in metadata), and
original exception in transaction will be lost. We need to log original
exception and catch probable tx.toString() exception.
> Transaction string reprsentation unhandled exception
>
>
> Key: IGNITE-8939
> URL: https://issues.apache.org/jira/browse/IGNITE-8939
> Project: Ignite
> Issue Type: Bug
> Components: binary
>Reporter: Evgenii Zagumennov
>Priority: Major
>
> IgniteTxHandler.finishDhtLocal() (IgniteTxHandler.java:957)
> {code:java}
> U.error(log, "Failed completing transaction [commit=" + req.commit() + ",
> tx=" + *tx* + ']', e);{code}
> tx.toString() can lead to excepion (in GridToStringBuilder.toStringImpl()),
> and original exception in transaction will be lost. We need to log original
> exception and catch probable tx.toString() exception.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8940) Activation job hangs(IgniteChangeGlobalStateTest#testFailGetLock)
[ https://issues.apache.org/jira/browse/IGNITE-8940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16533596#comment-16533596 ] ASF GitHub Bot commented on IGNITE-8940: GitHub user akalash opened a pull request: https://github.com/apache/ignite/pull/4309 IGNITE-8940 force fail of testFailGetLock You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-8940 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4309.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 #4309 commit a6ec608d41c1f51fd26c91572309ac42434c80a7 Author: Anton Kalashnikov Date: 2018-07-05T12:30:00Z IGNITE-8940 force fail of testFailGetLock > Activation job hangs(IgniteChangeGlobalStateTest#testFailGetLock) > - > > Key: IGNITE-8940 > URL: https://issues.apache.org/jira/browse/IGNITE-8940 > Project: Ignite > Issue Type: Test >Reporter: Anton Kalashnikov >Priority: Major > > given: > # Cluster consisted from 3 nodes which should fail activation cause "can't > get lock" > # 3 clients for cluster > when: > # Try to activate cluster from one of client > # Activation job start execution on one of 3 server nodes > # Activation triggered exchange > # Exchange is finished with error cause lock can not be acquired > then: > If job is executed on coordinator, its future successfuly finished otherwise > job is hang > > expected: > Job is finished on any nodes. > > why it is happen: > During handling of GridDhtPartitionsFullMessage on non-coordinator node, > execution finished before job's future finished cause if > clause(GridDhtPartitionsExchangeFuture#3230) > > Reason of this maybe task of > https://issues.apache.org/jira/browse/IGNITE-8657 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8939) Transaction string reprsentation unhandled exception
[ https://issues.apache.org/jira/browse/IGNITE-8939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgenii Zagumennov updated IGNITE-8939: --- Description: IgniteTxHandler.finishDhtLocal() (IgniteTxHandler.java:957) U.error(log, "Failed completing transaction [commit=" + req.commit() + ", tx=" + *tx* + ']', e); tx.toString() can lead to excepion (because of errors in metadata), and original exception in transaction will be lost. We need to log original exception and catch probable tx.toString() exception. > Transaction string reprsentation unhandled exception > > > Key: IGNITE-8939 > URL: https://issues.apache.org/jira/browse/IGNITE-8939 > Project: Ignite > Issue Type: Bug > Components: binary >Reporter: Evgenii Zagumennov >Priority: Major > > IgniteTxHandler.finishDhtLocal() (IgniteTxHandler.java:957) > U.error(log, "Failed completing transaction [commit=" + req.commit() + ", > tx=" + *tx* + ']', e); > tx.toString() can lead to excepion (because of errors in metadata), and > original exception in transaction will be lost. We need to log original > exception and catch probable tx.toString() exception. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8940) Activation job hangs(IgniteChangeGlobalStateTest#testFailGetLock)
Anton Kalashnikov created IGNITE-8940: - Summary: Activation job hangs(IgniteChangeGlobalStateTest#testFailGetLock) Key: IGNITE-8940 URL: https://issues.apache.org/jira/browse/IGNITE-8940 Project: Ignite Issue Type: Test Reporter: Anton Kalashnikov given: # Cluster consisted from 3 nodes which should fail activation cause "can't get lock" # 3 clients for cluster when: # Try to activate cluster from one of client # Activation job start execution on one of 3 server nodes # Activation triggered exchange # Exchange is finished with error cause lock can not be acquired then: If job is executed on coordinator, its future successfuly finished otherwise job is hang expected: Job is finished on any nodes. why it is happen: During handling of GridDhtPartitionsFullMessage on non-coordinator node, execution finished before job's future finished cause if clause(GridDhtPartitionsExchangeFuture#3230) Reason of this maybe task of https://issues.apache.org/jira/browse/IGNITE-8657 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8926) Deadlock in meta data registration
[ https://issues.apache.org/jira/browse/IGNITE-8926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgenii Zhuravlev updated IGNITE-8926: -- Attachment: DeadlockTest.java > Deadlock in meta data registration > -- > > Key: IGNITE-8926 > URL: https://issues.apache.org/jira/browse/IGNITE-8926 > Project: Ignite > Issue Type: Bug > Components: general >Reporter: Mikhail Cherkasov >Assignee: Ilya Lantukh >Priority: Major > Attachments: DeadlockTest.java, file.jstack > > > > Please file the attached jstack file with a deadlock. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8926) Deadlock in meta data registration
[ https://issues.apache.org/jira/browse/IGNITE-8926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16533584#comment-16533584 ] Evgenii Zhuravlev commented on IGNITE-8926: --- Attached reproducer for this deadlock > Deadlock in meta data registration > -- > > Key: IGNITE-8926 > URL: https://issues.apache.org/jira/browse/IGNITE-8926 > Project: Ignite > Issue Type: Bug > Components: general >Reporter: Mikhail Cherkasov >Assignee: Ilya Lantukh >Priority: Major > Attachments: DeadlockTest.java, file.jstack > > > > Please file the attached jstack file with a deadlock. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8939) Transaction string reprsentation unhandled exception
[ https://issues.apache.org/jira/browse/IGNITE-8939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgenii Zagumennov updated IGNITE-8939: --- Summary: Transaction string reprsentation unhandled exception (was: Error in binary meta data after RESTORE with wal_compaction) > Transaction string reprsentation unhandled exception > > > Key: IGNITE-8939 > URL: https://issues.apache.org/jira/browse/IGNITE-8939 > Project: Ignite > Issue Type: Bug > Components: binary >Reporter: Evgenii Zagumennov >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8939) Error in binary meta data after RESTORE with wal_compaction
[ https://issues.apache.org/jira/browse/IGNITE-8939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgenii Zagumennov updated IGNITE-8939: --- Description: (was: Steps to reproduce: # CREATE snapshot # RESTORE from snapshot # CHECK snapshot # Restart client nodes # Run some jobs on grid Node fails with exception: org.apache.ignite.binary.BinaryObjectException: Cannot find schema for object with compact footer [typeName=...] at org.apache.ignite.internal.binary.BinaryReaderExImpl.getOrCreateSchema(BinaryReaderExImpl.java:2033) at org.apache.ignite.internal.binary.BinaryReaderExImpl.(BinaryReaderExImpl.java:286) at org.apache.ignite.internal.binary.BinaryReaderExImpl.(BinaryReaderExImpl.java:185) at org.apache.ignite.internal.binary.BinaryObjectImpl.reader(BinaryObjectImpl.java:832) at org.apache.ignite.internal.binary.BinaryObjectImpl.reader(BinaryObjectImpl.java:846) at org.apache.ignite.internal.binary.BinaryObjectImpl.field(BinaryObjectImpl.java:626) at org.apache.ignite.internal.binary.BinaryObjectExImpl.toString(BinaryObjectExImpl.java:225) at org.apache.ignite.internal.binary.BinaryObjectExImpl.appendValue(BinaryObjectExImpl.java:280) at org.apache.ignite.internal.binary.BinaryObjectExImpl.toString(BinaryObjectExImpl.java:229) at org.apache.ignite.internal.binary.BinaryObjectExImpl.toString(BinaryObjectExImpl.java:186) *wlaModeEnabled = true*) > Error in binary meta data after RESTORE with wal_compaction > --- > > Key: IGNITE-8939 > URL: https://issues.apache.org/jira/browse/IGNITE-8939 > Project: Ignite > Issue Type: Bug > Components: binary >Reporter: Evgenii Zagumennov >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-2313) Need to add a mode to fail atomic operations within a transaction
[
https://issues.apache.org/jira/browse/IGNITE-2313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16533578#comment-16533578
]
Ryabov Dmitrii commented on IGNITE-2313:
[~agoncharuk], I made improvement suggested by Anton and described this
behaviour in {{withAllowAtomicOpsInTx()}} javadoc, can you look it?
[Upsource|https://reviews.ignite.apache.org/ignite/review/IGNT-CR-675]
> Need to add a mode to fail atomic operations within a transaction
> -
>
> Key: IGNITE-2313
> URL: https://issues.apache.org/jira/browse/IGNITE-2313
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Reporter: Dmitriy Setrakyan
>Assignee: Ryabov Dmitrii
>Priority: Major
> Fix For: 2.7
>
>
> Currently atomic operations within a transaction succeed without alarming a
> user that no transaction really occurs. We should add a mode to fail such
> operations (such mode should be turned off by default).
> New transaction configuration flag (default is {{false}}):
> {code}TransactionConfiguration.isAllowAtomicUpdatesInTransaction(){code}
> If the flag is violated, we should throw an exception with the following
> error message: {{Transaction spans operations on atomic cache (consider
> setting TransactionConfiguration.isAllowAttomicUpdatesInTransaction() flag to
> true)}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-8939) Error in binary meta data after RESTORE with wal_compaction
[ https://issues.apache.org/jira/browse/IGNITE-8939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgenii Zagumennov updated IGNITE-8939: --- Description: Steps to reproduce: # CREATE snapshot # RESTORE from snapshot # CHECK snapshot # Restart client nodes # Run some jobs on grid Node fails with exception: org.apache.ignite.binary.BinaryObjectException: Cannot find schema for object with compact footer [typeName=...] at org.apache.ignite.internal.binary.BinaryReaderExImpl.getOrCreateSchema(BinaryReaderExImpl.java:2033) at org.apache.ignite.internal.binary.BinaryReaderExImpl.(BinaryReaderExImpl.java:286) at org.apache.ignite.internal.binary.BinaryReaderExImpl.(BinaryReaderExImpl.java:185) at org.apache.ignite.internal.binary.BinaryObjectImpl.reader(BinaryObjectImpl.java:832) at org.apache.ignite.internal.binary.BinaryObjectImpl.reader(BinaryObjectImpl.java:846) at org.apache.ignite.internal.binary.BinaryObjectImpl.field(BinaryObjectImpl.java:626) at org.apache.ignite.internal.binary.BinaryObjectExImpl.toString(BinaryObjectExImpl.java:225) at org.apache.ignite.internal.binary.BinaryObjectExImpl.appendValue(BinaryObjectExImpl.java:280) at org.apache.ignite.internal.binary.BinaryObjectExImpl.toString(BinaryObjectExImpl.java:229) at org.apache.ignite.internal.binary.BinaryObjectExImpl.toString(BinaryObjectExImpl.java:186) *wlaModeEnabled = true* was: Steps to reproduce: # CREATE snapshot # RESTORE from snapshot # CHECK snapshot # Restart client nodes # Run some jobs on grid Node fails with exception: org.apache.ignite.binary.BinaryObjectException: Cannot find schema for object with compact footer [typeName=...] at org.apache.ignite.internal.binary.BinaryReaderExImpl.getOrCreateSchema(BinaryReaderExImpl.java:2033) at org.apache.ignite.internal.binary.BinaryReaderExImpl.(BinaryReaderExImpl.java:286) at org.apache.ignite.internal.binary.BinaryReaderExImpl.(BinaryReaderExImpl.java:185) at org.apache.ignite.internal.binary.BinaryObjectImpl.reader(BinaryObjectImpl.java:832) at org.apache.ignite.internal.binary.BinaryObjectImpl.reader(BinaryObjectImpl.java:846) at org.apache.ignite.internal.binary.BinaryObjectImpl.field(BinaryObjectImpl.java:626) at org.apache.ignite.internal.binary.BinaryObjectExImpl.toString(BinaryObjectExImpl.java:225) at org.apache.ignite.internal.binary.BinaryObjectExImpl.appendValue(BinaryObjectExImpl.java:280) at org.apache.ignite.internal.binary.BinaryObjectExImpl.toString(BinaryObjectExImpl.java:229) at org.apache.ignite.internal.binary.BinaryObjectExImpl.toString(BinaryObjectExImpl.java:186) > Error in binary meta data after RESTORE with wal_compaction > --- > > Key: IGNITE-8939 > URL: https://issues.apache.org/jira/browse/IGNITE-8939 > Project: Ignite > Issue Type: Bug > Components: binary >Reporter: Evgenii Zagumennov >Priority: Major > > Steps to reproduce: > # CREATE snapshot > # RESTORE from snapshot > # CHECK snapshot > # Restart client nodes > # Run some jobs on grid > Node fails with exception: > > org.apache.ignite.binary.BinaryObjectException: Cannot find schema for > object with compact footer [typeName=...] > at > org.apache.ignite.internal.binary.BinaryReaderExImpl.getOrCreateSchema(BinaryReaderExImpl.java:2033) > at > org.apache.ignite.internal.binary.BinaryReaderExImpl.(BinaryReaderExImpl.java:286) > at > org.apache.ignite.internal.binary.BinaryReaderExImpl.(BinaryReaderExImpl.java:185) > at > org.apache.ignite.internal.binary.BinaryObjectImpl.reader(BinaryObjectImpl.java:832) > at > org.apache.ignite.internal.binary.BinaryObjectImpl.reader(BinaryObjectImpl.java:846) > at > org.apache.ignite.internal.binary.BinaryObjectImpl.field(BinaryObjectImpl.java:626) > at > org.apache.ignite.internal.binary.BinaryObjectExImpl.toString(BinaryObjectExImpl.java:225) > at > org.apache.ignite.internal.binary.BinaryObjectExImpl.appendValue(BinaryObjectExImpl.java:280) > at > org.apache.ignite.internal.binary.BinaryObjectExImpl.toString(BinaryObjectExImpl.java:229) > at > org.apache.ignite.internal.binary.BinaryObjectExImpl.toString(BinaryObjectExImpl.java:186) > > *wlaModeEnabled = true* -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8939) Error in binary meta data after RESTORE with wal_compaction
Evgenii Zagumennov created IGNITE-8939: -- Summary: Error in binary meta data after RESTORE with wal_compaction Key: IGNITE-8939 URL: https://issues.apache.org/jira/browse/IGNITE-8939 Project: Ignite Issue Type: Bug Components: binary Reporter: Evgenii Zagumennov Steps to reproduce: # CREATE snapshot # RESTORE from snapshot # CHECK snapshot # Restart client nodes # Run some jobs on grid Node fails with exception: org.apache.ignite.binary.BinaryObjectException: Cannot find schema for object with compact footer [typeName=...] at org.apache.ignite.internal.binary.BinaryReaderExImpl.getOrCreateSchema(BinaryReaderExImpl.java:2033) at org.apache.ignite.internal.binary.BinaryReaderExImpl.(BinaryReaderExImpl.java:286) at org.apache.ignite.internal.binary.BinaryReaderExImpl.(BinaryReaderExImpl.java:185) at org.apache.ignite.internal.binary.BinaryObjectImpl.reader(BinaryObjectImpl.java:832) at org.apache.ignite.internal.binary.BinaryObjectImpl.reader(BinaryObjectImpl.java:846) at org.apache.ignite.internal.binary.BinaryObjectImpl.field(BinaryObjectImpl.java:626) at org.apache.ignite.internal.binary.BinaryObjectExImpl.toString(BinaryObjectExImpl.java:225) at org.apache.ignite.internal.binary.BinaryObjectExImpl.appendValue(BinaryObjectExImpl.java:280) at org.apache.ignite.internal.binary.BinaryObjectExImpl.toString(BinaryObjectExImpl.java:229) at org.apache.ignite.internal.binary.BinaryObjectExImpl.toString(BinaryObjectExImpl.java:186) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8938) file-decompressor thread termination should be handled with Failure handler
Andrey Gura created IGNITE-8938:
---
Summary: file-decompressor thread termination should be handled
with Failure handler
Key: IGNITE-8938
URL: https://issues.apache.org/jira/browse/IGNITE-8938
Project: Ignite
Issue Type: Bug
Reporter: Andrey Gura
Assignee: Andrey Gura
Fix For: 2.7
file-decompressor thread termination should be handled with Failure Handler
(IEP-14).
It doesn't work right now. Also exception handling in {{body()}} method should
be revised.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-8933) Fix web-console tests CI because of package-lock
[ https://issues.apache.org/jira/browse/IGNITE-8933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov updated IGNITE-8933: - Component/s: wizards > Fix web-console tests CI because of package-lock > > > Key: IGNITE-8933 > URL: https://issues.apache.org/jira/browse/IGNITE-8933 > Project: Ignite > Issue Type: Bug > Components: wizards >Reporter: Alexander Kalinin >Assignee: Alexey Kuznetsov >Priority: Major > Fix For: 2.7 > > > Current CI builds fail because of issues with npm and package-lock.json. To > overcome it we need to > * remove package-lock.json from VCS control. > * set dependencies versions to exact values by removing carets ^. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (IGNITE-8933) Fix web-console tests CI because of package-lock
[ https://issues.apache.org/jira/browse/IGNITE-8933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov closed IGNITE-8933. > Fix web-console tests CI because of package-lock > > > Key: IGNITE-8933 > URL: https://issues.apache.org/jira/browse/IGNITE-8933 > Project: Ignite > Issue Type: Bug > Components: wizards >Reporter: Alexander Kalinin >Assignee: Alexey Kuznetsov >Priority: Major > Fix For: 2.7 > > > Current CI builds fail because of issues with npm and package-lock.json. To > overcome it we need to > * remove package-lock.json from VCS control. > * set dependencies versions to exact values by removing carets ^. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8933) Fix web-console tests CI because of package-lock
[ https://issues.apache.org/jira/browse/IGNITE-8933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov updated IGNITE-8933: - Fix Version/s: 2.7 > Fix web-console tests CI because of package-lock > > > Key: IGNITE-8933 > URL: https://issues.apache.org/jira/browse/IGNITE-8933 > Project: Ignite > Issue Type: Bug >Reporter: Alexander Kalinin >Assignee: Alexey Kuznetsov >Priority: Major > Fix For: 2.7 > > > Current CI builds fail because of issues with npm and package-lock.json. To > overcome it we need to > * remove package-lock.json from VCS control. > * set dependencies versions to exact values by removing carets ^. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8827) Disable WAL during apply updates on recovery
[ https://issues.apache.org/jira/browse/IGNITE-8827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16533505#comment-16533505 ] Ilya Lantukh commented on IGNITE-8827: -- Thanks [~DmitriyGovorukhin], I don't see any other issues. > Disable WAL during apply updates on recovery > > > Key: IGNITE-8827 > URL: https://issues.apache.org/jira/browse/IGNITE-8827 > Project: Ignite > Issue Type: Bug >Reporter: Dmitriy Govorukhin >Assignee: Dmitriy Govorukhin >Priority: Major > Fix For: 2.7 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-8620) Remove intOrder and loc keys from node info in control.sh --tx utility
[ https://issues.apache.org/jira/browse/IGNITE-8620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16533498#comment-16533498 ] Ivan Daschinskiy edited comment on IGNITE-8620 at 7/5/18 10:39 AM: --- [~a-polyakov], [~ascherbakov] This fix looks good to me. was (Author: ivandasch): [~a-polyakov][~ascherbakov] This fix looks good to me. > Remove intOrder and loc keys from node info in control.sh --tx utility > -- > > Key: IGNITE-8620 > URL: https://issues.apache.org/jira/browse/IGNITE-8620 > Project: Ignite > Issue Type: Improvement >Reporter: Dmitry Sherstobitov >Assignee: Alexand Polyakov >Priority: Major > > For now this information displayed in control.sh utility for each node: > TcpDiscoveryNode [id=2ed402d5-b5a7-4ade-a77a-12c2feea95ec, > addrs=[0:0:0:0:0:0:0:1%lo, 127.0.0.1, 172.25.1.47], > sockAddrs=[/0:0:0:0:0:0:0:1%lo:0, /127.0.0.1:0, /172.25.1.47:0], discPort=0, > order=6, intOrder=6, lastExchangeTime=1526482701193, loc=false, > ver=2.5.1#20180510-sha1:ee417b82, isClient=true] > loc and intOrder values are internal information and there is not need to > display it > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8620) Remove intOrder and loc keys from node info in control.sh --tx utility
[ https://issues.apache.org/jira/browse/IGNITE-8620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16533498#comment-16533498 ] Ivan Daschinskiy commented on IGNITE-8620: -- [~a-polyakov][~ascherbakov] This fix looks good to me. > Remove intOrder and loc keys from node info in control.sh --tx utility > -- > > Key: IGNITE-8620 > URL: https://issues.apache.org/jira/browse/IGNITE-8620 > Project: Ignite > Issue Type: Improvement >Reporter: Dmitry Sherstobitov >Assignee: Alexand Polyakov >Priority: Major > > For now this information displayed in control.sh utility for each node: > TcpDiscoveryNode [id=2ed402d5-b5a7-4ade-a77a-12c2feea95ec, > addrs=[0:0:0:0:0:0:0:1%lo, 127.0.0.1, 172.25.1.47], > sockAddrs=[/0:0:0:0:0:0:0:1%lo:0, /127.0.0.1:0, /172.25.1.47:0], discPort=0, > order=6, intOrder=6, lastExchangeTime=1526482701193, loc=false, > ver=2.5.1#20180510-sha1:ee417b82, isClient=true] > loc and intOrder values are internal information and there is not need to > display it > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8745) Add ability to monitor TCP discovery ring information
[ https://issues.apache.org/jira/browse/IGNITE-8745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16533494#comment-16533494 ] Ivan Daschinskiy commented on IGNITE-8745: -- [~ezagumennov] Hi! I've looked over your changes. I have several remarks and I added some comments in your github PR. Also, there is no tests. You should ad test to TcpDiscoverySpiSelfTest and tests that your MBean attributes works. Also, TC run should be attached. > Add ability to monitor TCP discovery ring information > - > > Key: IGNITE-8745 > URL: https://issues.apache.org/jira/browse/IGNITE-8745 > Project: Ignite > Issue Type: Improvement >Reporter: Alexey Goncharuk >Assignee: Evgenii Zagumennov >Priority: Major > Time Spent: 16h > Remaining Estimate: 0h > > We should add the following modifications: > 1) Add a method on TCP discovery MBean to dump the ring structure on local > node and on all nodes in the grid > 2) Make tcp-disco-worker thread name reflect the node to which the local node > is connected > 3) Add a method on TCP discovery MBean to return current topology version -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8737) Improve checkpoint logging information
[ https://issues.apache.org/jira/browse/IGNITE-8737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16533492#comment-16533492 ] ASF GitHub Bot commented on IGNITE-8737: Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/4244 > Improve checkpoint logging information > -- > > Key: IGNITE-8737 > URL: https://issues.apache.org/jira/browse/IGNITE-8737 > Project: Ignite > Issue Type: Improvement >Reporter: Alexey Goncharuk >Assignee: Andrew Medvedev >Priority: Major > Fix For: 2.7 > > > 1) Move to INFO log rollover and log archivation events > 2) Make sure log rollover and archive errors are logged > 3) When checkpoint finishes, we need to print out which segments were fully > covered by this checkpoint in the "Checkpoint finished ..." message -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8753) Improve error message when requested topology version was preempted from Discovery Cache
[ https://issues.apache.org/jira/browse/IGNITE-8753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16533478#comment-16533478 ] Sergey Chugunov commented on IGNITE-8753: - [~yzhdanov], Yes, clear recommendation will help here, it may be worth adding current value of the setting to the error message as well. > Improve error message when requested topology version was preempted from > Discovery Cache > > > Key: IGNITE-8753 > URL: https://issues.apache.org/jira/browse/IGNITE-8753 > Project: Ignite > Issue Type: Improvement >Reporter: Sergey Chugunov >Priority: Major > > When a lot of nodes try to join cluster at the same time (which is common > when ZookeeperDiscoverySpi is used), size of Discovery Cache may be exhausted > so next node won't find topology version it needs to proceed with joining. > For now exception is thrown in this situation, we need to improve its message > with suggestion to check DISCOVERY_HISTORY setting. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8936) Remove AffinityAssignment#clientEventChange as not used
[ https://issues.apache.org/jira/browse/IGNITE-8936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-8936: Attachment: ClientEventChange (1).png > Remove AffinityAssignment#clientEventChange as not used > --- > > Key: IGNITE-8936 > URL: https://issues.apache.org/jira/browse/IGNITE-8936 > Project: Ignite > Issue Type: Task >Affects Versions: 2.7 >Reporter: Maxim Muzafarov >Priority: Minor > Labels: newbie > Attachments: ClientEventChange (1).png > > > We should try to keep Ignite project code as simple as possible. > Motivation: > http://apache-ignite-developers.2346864.n4.nabble.com/Cases-of-using-AffinityAssignment-clientEventChange-method-td32068.html -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8753) Improve error message when requested topology version was preempted from Discovery Cache
[
https://issues.apache.org/jira/browse/IGNITE-8753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16533466#comment-16533466
]
Yakov Zhdanov commented on IGNITE-8753:
---
Then the final one should be like the following:
{noformat}
Failed to resolve nodes topology (consider increasing value for
DISCOVERY_HISTORY system property) [cacheGrp=, topVer=, history=, snap=,
locNode=]
{noformat}
[~sergey-chugunov] agree?
> Improve error message when requested topology version was preempted from
> Discovery Cache
>
>
> Key: IGNITE-8753
> URL: https://issues.apache.org/jira/browse/IGNITE-8753
> Project: Ignite
> Issue Type: Improvement
>Reporter: Sergey Chugunov
>Priority: Major
>
> When a lot of nodes try to join cluster at the same time (which is common
> when ZookeeperDiscoverySpi is used), size of Discovery Cache may be exhausted
> so next node won't find topology version it needs to proceed with joining.
> For now exception is thrown in this situation, we need to improve its message
> with suggestion to check DISCOVERY_HISTORY setting.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-8797) Error during writeCheckpointEntry is not passed to failure handler during checkpoint finish
[
https://issues.apache.org/jira/browse/IGNITE-8797?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Gura updated IGNITE-8797:
Fix Version/s: 2.7
> Error during writeCheckpointEntry is not passed to failure handler during
> checkpoint finish
> ---
>
> Key: IGNITE-8797
> URL: https://issues.apache.org/jira/browse/IGNITE-8797
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexey Goncharuk
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.7
>
>
> I observed the following failure in Cache 3 suite:
> {code}
> [13:10:55]W: [org.apache.ignite:ignite-core] [2018-06-14
> 10:10:55,509][ERROR][db-checkpoint-thread-#138910%paged.PageEvictionMultinodeMixedRegionsTest2%][GridCacheDatabaseSharedManager]
> Failed to create checkpoint.
> [13:10:55]W: [org.apache.ignite:ignite-core] class
> org.apache.ignite.internal.processors.cache.persistence.file.PersistentStorageIOException:
> Failed to write checkpoint entry [ptr=FileWALPointer [idx=0, fileOff=219747,
> len=1947], cpTs=1528971054548, cpId=d8b42759-ca5e-4613-b091-ed0356b3915d,
> type=END]
> [13:10:55]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.writeCheckpointEntry(GridCacheDatabaseSharedManager.java:2757)
> [13:10:55]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.access$8100(GridCacheDatabaseSharedManager.java:178)
> [13:10:55]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$Checkpointer.markCheckpointEnd(GridCacheDatabaseSharedManager.java:3716)
> [13:10:55]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$Checkpointer.doCheckpoint(GridCacheDatabaseSharedManager.java:3277)
> [13:10:55]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$Checkpointer.body(GridCacheDatabaseSharedManager.java:3053)
> [13:10:55]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> [13:10:55]W: [org.apache.ignite:ignite-core]at
> java.lang.Thread.run(Thread.java:748)
> [13:10:55]W: [org.apache.ignite:ignite-core] Caused by:
> java.nio.file.NoSuchFileException:
> /data/teamcity/work/c182b70f2dfa6507/work/db/node03-c5dcc243-fc3c-4b2f-8002-81e88d8cff7d/cp/1528971054548-d8b42759-ca5e-4613-b091-ed0356b3915d-END.bin.tmp
> [13:10:55]W: [org.apache.ignite:ignite-core]at
> sun.nio.fs.UnixException.translateToIOException(UnixException.java:86)
> [13:10:55]W: [org.apache.ignite:ignite-core]at
> sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
> [13:10:55]W: [org.apache.ignite:ignite-core]at
> sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
> [13:10:55]W: [org.apache.ignite:ignite-core]at
> sun.nio.fs.UnixCopyFile.move(UnixCopyFile.java:409)
> [13:10:55]W: [org.apache.ignite:ignite-core]at
> sun.nio.fs.UnixFileSystemProvider.move(UnixFileSystemProvider.java:262)
> [13:10:55]W: [org.apache.ignite:ignite-core]at
> java.nio.file.Files.move(Files.java:1395)
> [13:10:55]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.writeCheckpointEntry(GridCacheDatabaseSharedManager.java:2752)
> [13:10:55]W: [org.apache.ignite:ignite-core]... 6 more
> [13:10:55]W: [org.apache.ignite:ignite-core] [2018-06-14
> 10:10:55,509][ERROR][db-checkpoint-thread-#138914%paged.PageEvictionMultinodeMixedRegionsTest3%][GridCacheDatabaseSharedManager]
> Failed to create checkpoint.
> {code}
> I see two issues here:
> 1) Some concurrent process is removing the work folder which results in the
> exception above
> 2) The checkpoint exception is not passed to the failure handler. This is due
> to a catch {{// TODO-ignite-db how to handle exception?}} in
> {{Checkpointer}}, which yields an uncompleted checkpoint future.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-8937) JVM Crash in C++ suites on Windows/Java 8 (in PageIO)
[
https://issues.apache.org/jira/browse/IGNITE-8937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Pavlov updated IGNITE-8937:
---
Labels: MakeTeamcityGreenAgain (was: )
> JVM Crash in C++ suites on Windows/Java 8 (in PageIO)
> -
>
> Key: IGNITE-8937
> URL: https://issues.apache.org/jira/browse/IGNITE-8937
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.7
>Reporter: Ilya Kasnacheev
>Assignee: Eduard Shangareev
>Priority: Major
> Labels: MakeTeamcityGreenAgain
>
> https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_PlatformCWindowsX64
> Builds of Platform C++ (Windows x64) and Platform C++ (Windows x86) fail
> almost every time with JVM Crash:
> {code}
> # A fatal error has been detected by the Java Runtime Environment:
> #
> # EXCEPTION_ACCESS_VIOLATION (0xc005) at pc=0x02537c64, pid=44768,
> tid=0x56c8
> #
> # JRE version: Java(TM) SE Runtime Environment (8.0_161-b12) (build
> 1.8.0_161-b12)
> # Java VM: Java HotSpot(TM) Server VM (25.161-b12 mixed mode windows-x86 )
> # Problematic frame:
> # J 2991 C2
> org.apache.ignite.internal.processors.cache.persistence.tree.io.PageIO.initNewPage(JJI)V
> (48 bytes) @ 0x02537c64 [0x02537c40+0x24]
> {code}
> Looks like incorrect usage of Unsafe.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-8937) JVM Crash in C++ suites on Windows/Java 8 (in PageIO)
Ilya Kasnacheev created IGNITE-8937:
---
Summary: JVM Crash in C++ suites on Windows/Java 8 (in PageIO)
Key: IGNITE-8937
URL: https://issues.apache.org/jira/browse/IGNITE-8937
Project: Ignite
Issue Type: Bug
Affects Versions: 2.7
Reporter: Ilya Kasnacheev
Assignee: Eduard Shangareev
https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_PlatformCWindowsX64
Builds of Platform C++ (Windows x64) and Platform C++ (Windows x86) fail almost
every time with JVM Crash:
{code}
# A fatal error has been detected by the Java Runtime Environment:
#
# EXCEPTION_ACCESS_VIOLATION (0xc005) at pc=0x02537c64, pid=44768,
tid=0x56c8
#
# JRE version: Java(TM) SE Runtime Environment (8.0_161-b12) (build
1.8.0_161-b12)
# Java VM: Java HotSpot(TM) Server VM (25.161-b12 mixed mode windows-x86 )
# Problematic frame:
# J 2991 C2
org.apache.ignite.internal.processors.cache.persistence.tree.io.PageIO.initNewPage(JJI)V
(48 bytes) @ 0x02537c64 [0x02537c40+0x24]
{code}
Looks like incorrect usage of Unsafe.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-8936) Remove AffinityAssignment#clientEventChange as not used
Maxim Muzafarov created IGNITE-8936: --- Summary: Remove AffinityAssignment#clientEventChange as not used Key: IGNITE-8936 URL: https://issues.apache.org/jira/browse/IGNITE-8936 Project: Ignite Issue Type: Task Affects Versions: 2.7 Reporter: Maxim Muzafarov We should try to keep Ignite project code as simple as possible. Motivation: http://apache-ignite-developers.2346864.n4.nabble.com/Cases-of-using-AffinityAssignment-clientEventChange-method-td32068.html -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8714) CacheEntryEvent.getOldValue should be available
[ https://issues.apache.org/jira/browse/IGNITE-8714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16533451#comment-16533451 ] Amelchev Nikita commented on IGNITE-8714: - [~sharpler], Yes, I will continue your work. > CacheEntryEvent.getOldValue should be available > --- > > Key: IGNITE-8714 > URL: https://issues.apache.org/jira/browse/IGNITE-8714 > Project: Ignite > Issue Type: Sub-task >Reporter: Alexander Menshikov >Assignee: Amelchev Nikita >Priority: Major > Labels: iep-21 > Fix For: 2.7 > > > A table is copied from speck changing discussion: > When CacheEntryListenerConfiguration#isOldValueRequired is *true*: > ||CacheEntryEvent Method||CreatedListener||UpdatedListener||Removed/Expired > Listener|| > |getValue()|_value_|_value_|_oldValue_| > |getOldValue()|null|_oldValue_|_oldValue_| > The last column is new behavior for #getValue(). > Сurrent master fails with this reason on following tests: > * CacheListenerTest.testFilteredListener > * CacheListenerTest.testCacheEntryListener > I have to say tests testFilteredListener and testCacheEntryListener also fail > in `afterTests` section because of IGNITE-8715, so PR will not change the > number of failed tests if ignite-8715 unfixed. But it will change the reason > – please see the log. > Please see also link on JCache TCK and speck 1.1.0 changes. > > *UPD:* > There are a lot of our tests wich going to break by this change. Also, we use > events in Services deployment, which will be affected too. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-8714) CacheEntryEvent.getOldValue should be available
[ https://issues.apache.org/jira/browse/IGNITE-8714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amelchev Nikita reassigned IGNITE-8714: --- Assignee: Amelchev Nikita (was: Anton Vinogradov) > CacheEntryEvent.getOldValue should be available > --- > > Key: IGNITE-8714 > URL: https://issues.apache.org/jira/browse/IGNITE-8714 > Project: Ignite > Issue Type: Sub-task >Reporter: Alexander Menshikov >Assignee: Amelchev Nikita >Priority: Major > Labels: iep-21 > Fix For: 2.7 > > > A table is copied from speck changing discussion: > When CacheEntryListenerConfiguration#isOldValueRequired is *true*: > ||CacheEntryEvent Method||CreatedListener||UpdatedListener||Removed/Expired > Listener|| > |getValue()|_value_|_value_|_oldValue_| > |getOldValue()|null|_oldValue_|_oldValue_| > The last column is new behavior for #getValue(). > Сurrent master fails with this reason on following tests: > * CacheListenerTest.testFilteredListener > * CacheListenerTest.testCacheEntryListener > I have to say tests testFilteredListener and testCacheEntryListener also fail > in `afterTests` section because of IGNITE-8715, so PR will not change the > number of failed tests if ignite-8715 unfixed. But it will change the reason > – please see the log. > Please see also link on JCache TCK and speck 1.1.0 changes. > > *UPD:* > There are a lot of our tests wich going to break by this change. Also, we use > events in Services deployment, which will be affected too. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8935) IgniteConfiguration dependents should have toString
Ilya Kasnacheev created IGNITE-8935: --- Summary: IgniteConfiguration dependents should have toString Key: IGNITE-8935 URL: https://issues.apache.org/jira/browse/IGNITE-8935 Project: Ignite Issue Type: Improvement Affects Versions: 2.5 Reporter: Ilya Kasnacheev Assignee: Ilya Kasnacheev Ignite configuration is printed on startup, but some classes which are usually referred do not have toString() implemented, leading to gems such as connectorCfg=org.apache.ignite.configuration.ConnectorConfiguration@7d8704ef Those classes should have toString implemented which will conform to https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines#CodingGuidelines-StringOutput -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8926) Deadlock in meta data registration
[ https://issues.apache.org/jira/browse/IGNITE-8926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Cherkasov updated IGNITE-8926: -- Attachment: file.jstack > Deadlock in meta data registration > -- > > Key: IGNITE-8926 > URL: https://issues.apache.org/jira/browse/IGNITE-8926 > Project: Ignite > Issue Type: Bug > Components: general >Reporter: Mikhail Cherkasov >Assignee: Ilya Lantukh >Priority: Major > Attachments: file.jstack > > > > Please file the attached jstack file with a deadlock. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8926) Deadlock in meta data registration
[ https://issues.apache.org/jira/browse/IGNITE-8926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Cherkasov updated IGNITE-8926: -- Attachment: (was: 11948_WorkdayFabricManager.jstack) > Deadlock in meta data registration > -- > > Key: IGNITE-8926 > URL: https://issues.apache.org/jira/browse/IGNITE-8926 > Project: Ignite > Issue Type: Bug > Components: general >Reporter: Mikhail Cherkasov >Assignee: Ilya Lantukh >Priority: Major > Attachments: file.jstack > > > > Please file the attached jstack file with a deadlock. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8180) ZookeeperDiscoverySpiTest#testQuorumRestore fails on TC
[
https://issues.apache.org/jira/browse/IGNITE-8180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16533430#comment-16533430
]
Amelchev Nikita commented on IGNITE-8180:
-
The issue ignite-8182 was resolved and now test suite doesn't have the problem
when zookeeper cluster restarting. I have checked this test on TC once again
and it OK
[100runs|https://ci.ignite.apache.org/viewLog.html?buildId=1453916=IgniteTests24Java8_ZooKeeperDiscovery1=testsInfo].
[~sergey-chugunov], could you review this issue?
> ZookeeperDiscoverySpiTest#testQuorumRestore fails on TC
> ---
>
> Key: IGNITE-8180
> URL: https://issues.apache.org/jira/browse/IGNITE-8180
> Project: Ignite
> Issue Type: Bug
> Components: zookeeper
>Reporter: Sergey Chugunov
>Assignee: Amelchev Nikita
>Priority: Major
> Labels: MakeTeamcityGreenAgain
>
> Test fails on TC with the following stack trace:
> {noformat}
> class org.apache.ignite.IgniteCheckedException: Failed to start manager:
> GridManagerAdapter [enabled=true,
> name=org.apache.ignite.internal.managers.discovery.GridDiscoveryManager]
> at
> org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:1698)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1007)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1977)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1720)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1148)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:646)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:882)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:845)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:833)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:799)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrids(GridAbstractTest.java:683)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.testQuorumRestore(ZookeeperDiscoverySpiTest.java:1077)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2080)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:140)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1995)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to start
> SPI: ZookeeperDiscoverySpi [zkRootPath=/apacheIgnite,
> zkConnectionString=127.0.0.1:40921,127.0.0.1:35014,127.0.0.1:38754,
> joinTimeout=0, sesTimeout=15000, clientReconnectDisabled=false,
> internalLsnr=null]
> at
> org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:300)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.start(GridDiscoveryManager.java:905)
> at
> org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:1693)
> ... 20 more
> Caused by: class org.apache.ignite.spi.IgniteSpiException: Failed to
> initialize Zookeeper nodes
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoveryImpl.initZkNodes(ZookeeperDiscoveryImpl.java:827)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoveryImpl.startJoin(ZookeeperDiscoveryImpl.java:957)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoveryImpl.joinTopology(ZookeeperDiscoveryImpl.java:775)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoveryImpl.startJoinAndWait(ZookeeperDiscoveryImpl.java:693)
> at
> org.apache.ignite.spi.discovery.zk.ZookeeperDiscoverySpi.spiStart(ZookeeperDiscoverySpi.java:471)
> at
> org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:297)
> ... 22 more
> Caused by:
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperClientFailedException:
> org.apache.zookeeper.KeeperException$ConnectionLossException: KeeperErrorCode
> = ConnectionLoss for /apacheIgnite
> at
>
[jira] [Reopened] (IGNITE-8322) Yardstick benchmark preloading option
[ https://issues.apache.org/jira/browse/IGNITE-8322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oleg Ostanin reopened IGNITE-8322: -- We need to fix the problem which is mentioned above. > Yardstick benchmark preloading option > - > > Key: IGNITE-8322 > URL: https://issues.apache.org/jira/browse/IGNITE-8322 > Project: Ignite > Issue Type: Improvement >Reporter: Oleg Ostanin >Assignee: Oleg Ostanin >Priority: Major > Fix For: 2.7 > > > Yardstick has no benchmarks with eviction on the disk (PDS). For that puspose > we need following: > 1. Make new configuration and put every cache into a separate date region: > atomic,tx,atomic-index,query,compute > 2. Add a new preload option for a benchmark: preload up to a size passed from > that option. There two options: > * total size of preload data (bytes) > * the size of data in memory against total size (percent) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-8546) Permission denied while copying OPTION_LIBS on Openshift
[ https://issues.apache.org/jira/browse/IGNITE-8546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Guseinov reassigned IGNITE-8546: -- Assignee: Roman Guseinov > Permission denied while copying OPTION_LIBS on Openshift > > > Key: IGNITE-8546 > URL: https://issues.apache.org/jira/browse/IGNITE-8546 > Project: Ignite > Issue Type: Bug > Components: build >Affects Versions: 2.4 > Environment: Server https://api.pro-us-east-1.openshift.com:443 > openshift v3.9.14 > kubernetes v1.9.1+a0ce1bc657 >Reporter: Roman Guseinov >Assignee: Roman Guseinov >Priority: Major > Attachments: Dockerfile > > > The issue happens when we try to deploy `apacheignite/ignite:2.4.0` on > Openshift with specified OPTION_LIBS env variable > "ignite-kubernetes,ignite-rest-http". > There is a workaround how to resolve this issue. Dockerfile is attached. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8934) LongJVMPauseDetector prints error on thread interruption when node stopping
[ https://issues.apache.org/jira/browse/IGNITE-8934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16533402#comment-16533402 ] ASF GitHub Bot commented on IGNITE-8934: GitHub user ezhuravl opened a pull request: https://github.com/apache/ignite/pull/4308 IGNITE-8934 remove error message when LongJVMPauseDetector stops You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-8934 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4308.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 #4308 commit 111dc822630490ee937f336941301af3cd091738 Author: ezhuravl Date: 2018-07-05T08:28:07Z IGNITE-8934 remove error message when LongJVMPauseDetector stops > LongJVMPauseDetector prints error on thread interruption when node stopping > --- > > Key: IGNITE-8934 > URL: https://issues.apache.org/jira/browse/IGNITE-8934 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.5 >Reporter: Evgenii Zhuravlev >Assignee: Evgenii Zhuravlev >Priority: Major > -- 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 ] ARomantsov updated IGNITE-8837: --- Fix Version/s: 2.7 > 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.7 > > 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] [Commented] (IGNITE-8180) ZookeeperDiscoverySpiTest#testQuorumRestore fails on TC
[
https://issues.apache.org/jira/browse/IGNITE-8180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16533398#comment-16533398
]
Vitaliy Biryukov commented on IGNITE-8180:
--
[~NSAmelchev], LGTM.
> ZookeeperDiscoverySpiTest#testQuorumRestore fails on TC
> ---
>
> Key: IGNITE-8180
> URL: https://issues.apache.org/jira/browse/IGNITE-8180
> Project: Ignite
> Issue Type: Bug
> Components: zookeeper
>Reporter: Sergey Chugunov
>Assignee: Amelchev Nikita
>Priority: Major
> Labels: MakeTeamcityGreenAgain
>
> Test fails on TC with the following stack trace:
> {noformat}
> class org.apache.ignite.IgniteCheckedException: Failed to start manager:
> GridManagerAdapter [enabled=true,
> name=org.apache.ignite.internal.managers.discovery.GridDiscoveryManager]
> at
> org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:1698)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1007)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1977)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1720)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1148)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:646)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:882)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:845)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:833)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:799)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrids(GridAbstractTest.java:683)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.testQuorumRestore(ZookeeperDiscoverySpiTest.java:1077)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2080)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:140)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1995)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to start
> SPI: ZookeeperDiscoverySpi [zkRootPath=/apacheIgnite,
> zkConnectionString=127.0.0.1:40921,127.0.0.1:35014,127.0.0.1:38754,
> joinTimeout=0, sesTimeout=15000, clientReconnectDisabled=false,
> internalLsnr=null]
> at
> org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:300)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.start(GridDiscoveryManager.java:905)
> at
> org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:1693)
> ... 20 more
> Caused by: class org.apache.ignite.spi.IgniteSpiException: Failed to
> initialize Zookeeper nodes
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoveryImpl.initZkNodes(ZookeeperDiscoveryImpl.java:827)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoveryImpl.startJoin(ZookeeperDiscoveryImpl.java:957)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoveryImpl.joinTopology(ZookeeperDiscoveryImpl.java:775)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoveryImpl.startJoinAndWait(ZookeeperDiscoveryImpl.java:693)
> at
> org.apache.ignite.spi.discovery.zk.ZookeeperDiscoverySpi.spiStart(ZookeeperDiscoverySpi.java:471)
> at
> org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:297)
> ... 22 more
> Caused by:
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperClientFailedException:
> org.apache.zookeeper.KeeperException$ConnectionLossException: KeeperErrorCode
> = ConnectionLoss for /apacheIgnite
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperClient.onZookeeperError(ZookeeperClient.java:758)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperClient.exists(ZookeeperClient.java:276)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoveryImpl.initZkNodes(ZookeeperDiscoveryImpl.java:789)
> ... 27 more
> Caused by:
[jira] [Created] (IGNITE-8934) LongJVMPauseDetector prints error on thread interruption when node stopping
Evgenii Zhuravlev created IGNITE-8934: - Summary: LongJVMPauseDetector prints error on thread interruption when node stopping Key: IGNITE-8934 URL: https://issues.apache.org/jira/browse/IGNITE-8934 Project: Ignite Issue Type: Bug Affects Versions: 2.5 Reporter: Evgenii Zhuravlev Assignee: Evgenii Zhuravlev -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (IGNITE-8703) JDBC thin: drop support of versions older than 2.5.0
[ https://issues.apache.org/jira/browse/IGNITE-8703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov closed IGNITE-8703. --- > JDBC thin: drop support of versions older than 2.5.0 > > > Key: IGNITE-8703 > URL: https://issues.apache.org/jira/browse/IGNITE-8703 > Project: Ignite > Issue Type: Task > Components: jdbc >Reporter: Vladimir Ozerov >Assignee: Vladimir Ozerov >Priority: Major > > As per our convention, we support forward and backward compatibility only > between two consecutive version. That is, for AI 2.6 we only need to support > 2.5 version. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8703) JDBC thin: drop support of versions older than 2.5.0
[ https://issues.apache.org/jira/browse/IGNITE-8703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-8703: Fix Version/s: (was: 2.7) > JDBC thin: drop support of versions older than 2.5.0 > > > Key: IGNITE-8703 > URL: https://issues.apache.org/jira/browse/IGNITE-8703 > Project: Ignite > Issue Type: Task > Components: jdbc >Reporter: Vladimir Ozerov >Assignee: Vladimir Ozerov >Priority: Major > > As per our convention, we support forward and backward compatibility only > between two consecutive version. That is, for AI 2.6 we only need to support > 2.5 version. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8361) Use discovery messages for service deployment
[ https://issues.apache.org/jira/browse/IGNITE-8361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16533385#comment-16533385 ] ASF GitHub Bot commented on IGNITE-8361: GitHub user daradurvs opened a pull request: https://github.com/apache/ignite/pull/4307 IGNITE-8361 Use discovery messages for service deployment You can merge this pull request into a Git repository by running: $ git pull https://github.com/daradurvs/ignite ignite-8361-rc Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4307.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 #4307 > Use discovery messages for service deployment > - > > Key: IGNITE-8361 > URL: https://issues.apache.org/jira/browse/IGNITE-8361 > Project: Ignite > Issue Type: Improvement > Components: managed services >Reporter: Denis Mekhanikov >Assignee: Vyacheslav Daradur >Priority: Major > Labels: iep-17 > Fix For: 2.7 > > > Service deployment should be based on discovery messages distribution. > The procedure is as follows: > # Deploying node sends a message with a service configuration. > # Coordinator calculates the assignments and sends them in another message. > # Nodes check, whether they are assigned to deploy any services, and do so, > if they are. > Utility cache won't be needed after these changes are made. All its mentions > should be removed from the code. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-8933) Fix web-console tests CI because of package-lock
[ https://issues.apache.org/jira/browse/IGNITE-8933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Kalinin reassigned IGNITE-8933: - Assignee: Alexander Kalinin (was: Alexey Kuznetsov) > Fix web-console tests CI because of package-lock > > > Key: IGNITE-8933 > URL: https://issues.apache.org/jira/browse/IGNITE-8933 > Project: Ignite > Issue Type: Bug >Reporter: Alexander Kalinin >Assignee: Alexander Kalinin >Priority: Major > > Current CI builds fail because of issues with npm and package-lock.json. To > overcome it we need to > * remove package-lock.json from VCS control. > * set dependencies versions to exact values by removing carets ^. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-8933) Fix web-console tests CI because of package-lock
[ https://issues.apache.org/jira/browse/IGNITE-8933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Kalinin reassigned IGNITE-8933: - Assignee: Alexey Kuznetsov (was: Alexander Kalinin) Fixed. Please review. > Fix web-console tests CI because of package-lock > > > Key: IGNITE-8933 > URL: https://issues.apache.org/jira/browse/IGNITE-8933 > Project: Ignite > Issue Type: Bug >Reporter: Alexander Kalinin >Assignee: Alexey Kuznetsov >Priority: Major > > Current CI builds fail because of issues with npm and package-lock.json. To > overcome it we need to > * remove package-lock.json from VCS control. > * set dependencies versions to exact values by removing carets ^. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-8933) Fix web-console tests CI because of package-lock
[ https://issues.apache.org/jira/browse/IGNITE-8933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Kalinin reassigned IGNITE-8933: - Assignee: Alexey Kuznetsov (was: Alexander Kalinin) > Fix web-console tests CI because of package-lock > > > Key: IGNITE-8933 > URL: https://issues.apache.org/jira/browse/IGNITE-8933 > Project: Ignite > Issue Type: Bug >Reporter: Alexander Kalinin >Assignee: Alexey Kuznetsov >Priority: Major > > Current CI builds fail because of issues with npm and package-lock.json. To > overcome it we need to > * remove package-lock.json from VCS control. > * set dependencies versions to exact values by removing carets ^. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Issue Comment Deleted] (IGNITE-8776) Eviction policy MBeans are never registered if evictionPolicyFactory is used
[ https://issues.apache.org/jira/browse/IGNITE-8776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] kcheng.mvp updated IGNITE-8776: --- Comment: was deleted (was: [~slukyanov] Thank you very much! The fix pretty much done, but I have an unclear and I posted in the forum. Can you have a check ? http://apache-ignite-developers.2346864.n4.nabble.com/Why-GridCacheEvictionManager-always-use-cfg-getEvictionPolicy-cfg-getEvictionPolicyFactory-even-ther-td32230.html) > Eviction policy MBeans are never registered if evictionPolicyFactory is used > > > Key: IGNITE-8776 > URL: https://issues.apache.org/jira/browse/IGNITE-8776 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.5 >Reporter: Stanislav Lukyanov >Assignee: kcheng.mvp >Priority: Minor > Labels: newbie > > Eviction policy MBeans, such as LruEvictionPolicyMBean, are never registered > if evictionPolicyFactory is set instead of evictionPolicy (the latter is > deprecated). > This happens because GridCacheProcessor::registerMbean attempts to find > either an *MBean interface or IgniteMBeanAware interface on the passed > object. It works for LruEvictionPolicy but not for LruEvictionPolicyFactory > (which doesn't implement these interfaces). > The code needs to be adjusted to handle factories correctly. > New tests are needed to make sure that all standard beans are registered > (IgniteKernalMbeansTest does that for kernal mbeans - need the same for cache > beans). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8776) Eviction policy MBeans are never registered if evictionPolicyFactory is used
[ https://issues.apache.org/jira/browse/IGNITE-8776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16533346#comment-16533346 ] kcheng.mvp commented on IGNITE-8776: [~slukyanov] I have raised PR, can you help me do the code review? https://github.com/apache/ignite/pull/4300 Thanks, kcmvp > Eviction policy MBeans are never registered if evictionPolicyFactory is used > > > Key: IGNITE-8776 > URL: https://issues.apache.org/jira/browse/IGNITE-8776 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.5 >Reporter: Stanislav Lukyanov >Assignee: kcheng.mvp >Priority: Minor > Labels: newbie > > Eviction policy MBeans, such as LruEvictionPolicyMBean, are never registered > if evictionPolicyFactory is set instead of evictionPolicy (the latter is > deprecated). > This happens because GridCacheProcessor::registerMbean attempts to find > either an *MBean interface or IgniteMBeanAware interface on the passed > object. It works for LruEvictionPolicy but not for LruEvictionPolicyFactory > (which doesn't implement these interfaces). > The code needs to be adjusted to handle factories correctly. > New tests are needed to make sure that all standard beans are registered > (IgniteKernalMbeansTest does that for kernal mbeans - need the same for cache > beans). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-8866) Need attempt to upload class until node leave or fail topology by discovery SPI
[
https://issues.apache.org/jira/browse/IGNITE-8866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Evgenii Zagumennov reassigned IGNITE-8866:
--
Assignee: Evgenii Zagumennov
> Need attempt to upload class until node leave or fail topology by discovery
> SPI
> ---
>
> Key: IGNITE-8866
> URL: https://issues.apache.org/jira/browse/IGNITE-8866
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Assignee: Evgenii Zagumennov
>Priority: Major
> Attachments: P2PClassDeploymentDelay.java
>
>
> After one fail attempt to upload a class, client code getting exception:
> {noformat}
> 10:04:46,253 INFO [stdout] (Thread-732) java.lang.NoClassDefFoundError:
> ru/sbt/deposit_pf_api/core/utils/DplUtils
> 10:04:46,253 INFO [stdout] (Thread-732) at
> ru.sbt.deposit_pf_api.comparators.CommonPredicate.nodeIdIgnite(CommonPredicate.java:225)
> 10:04:46,253 INFO [stdout] (Thread-732) at
> ru.sbt.deposit_pf_api.comparators.CommonPredicate.cacheEntities(CommonPredicate.java:191)
> 10:04:46,253 INFO [stdout] (Thread-732) at
> ru.sbt.deposit_pf_api.comparators.CommonPredicate.(CommonPredicate.java:116)
> {noformat}
> And log contains some related warnings:
> {noformat}
> 018-06-19 10:04:18.459 [WARN
> ][pub-#3308%DPL_GRID%DplGridNodeName%][o.a.i.i.m.d.GridDeploymentCommunication]
> Failed to receive peer response from node within duration
> [node=5861d763-a552-463e-817a-0742f7aad114, duration=5008]
> 2018-06-19 10:04:18.459 [WARN
> ][pub-#3308%DPL_GRID%DplGridNodeName%][o.a.i.i.m.d.GridDeploymentPerVersionStore]
> Failed to send class-loading request to node (is node alive?)
> [node=5861d763-a552-463e-817a-0742f7aad114,
> clsName=ru.sbt.deposit_pf_api.core.utils.DplUtils,
> clsPath=ru/sbt/deposit_pf_api/core/utils/DplUtils.class,
> clsLdrId=370f1361461-5861d763-a552-463e-817a-0742f7aad114,
> parentClsLdr=com.sbt.dpl.gridgain.ignite.NodeClassLoader@1ce4a752]
> {noformat}
> I think should to upload class through p2p until node present in topology.
> Look at the [^P2PClassDeploymentDelay.java] reproducer.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-8933) Fix web-console tests CI because of package-lock
[ https://issues.apache.org/jira/browse/IGNITE-8933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Kalinin reassigned IGNITE-8933: - Assignee: Alexander Kalinin > Fix web-console tests CI because of package-lock > > > Key: IGNITE-8933 > URL: https://issues.apache.org/jira/browse/IGNITE-8933 > Project: Ignite > Issue Type: Bug >Reporter: Alexander Kalinin >Assignee: Alexander Kalinin >Priority: Major > > Current CI builds fail because of issues with npm and package-lock.json. To > overcome it we need to > * remove package-lock.json from VCS control. > * set dependencies versions to exact values by removing carets ^. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-8900) SqlFieldsQuery provides incorrect result when item size exceeds page size
[ https://issues.apache.org/jira/browse/IGNITE-8900?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Kalinin reassigned IGNITE-8900: - Assignee: Alexander Kalinin > SqlFieldsQuery provides incorrect result when item size exceeds page size > - > > Key: IGNITE-8900 > URL: https://issues.apache.org/jira/browse/IGNITE-8900 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.4 >Reporter: Anton Kurbanov >Assignee: Alexander Kalinin >Priority: Blocker > Attachments: Main.java, Node.java > > > Start several server nodes, then start client, execute queries with value > range in where clause. Duplicate entries may be found, some entries may be > missing. > Results as an example: > expected 5 results but got back 3 results (query range 61002664327616 to > 610026643276160004), cache.getAll returned 5 entries. > expected 8 results but got back 7 results (query range 61002664327616 to > 610026643276160007), cache.getAll returned 8 entries. > Query results: [61002664327616, 610026643276160003, 610026643276160004, > 610026643276160005, 610026643276160005, 610026643276160006, > 610026643276160007] > Please find reproducer attached. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-8900) SqlFieldsQuery provides incorrect result when item size exceeds page size
[ https://issues.apache.org/jira/browse/IGNITE-8900?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Kalinin reassigned IGNITE-8900: - Assignee: (was: Alexander Kalinin) > SqlFieldsQuery provides incorrect result when item size exceeds page size > - > > Key: IGNITE-8900 > URL: https://issues.apache.org/jira/browse/IGNITE-8900 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.4 >Reporter: Anton Kurbanov >Priority: Blocker > Attachments: Main.java, Node.java > > > Start several server nodes, then start client, execute queries with value > range in where clause. Duplicate entries may be found, some entries may be > missing. > Results as an example: > expected 5 results but got back 3 results (query range 61002664327616 to > 610026643276160004), cache.getAll returned 5 entries. > expected 8 results but got back 7 results (query range 61002664327616 to > 610026643276160007), cache.getAll returned 8 entries. > Query results: [61002664327616, 610026643276160003, 610026643276160004, > 610026643276160005, 610026643276160005, 610026643276160006, > 610026643276160007] > Please find reproducer attached. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8933) Fix web-console tests CI because of package-lock
Alexander Kalinin created IGNITE-8933: - Summary: Fix web-console tests CI because of package-lock Key: IGNITE-8933 URL: https://issues.apache.org/jira/browse/IGNITE-8933 Project: Ignite Issue Type: Bug Reporter: Alexander Kalinin Current CI builds fail because of issues with npm and package-lock.json. To overcome it we need to * remove package-lock.json from VCS control. * set dependencies versions to exact values by removing carets ^. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
