[jira] [Assigned] (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 reassigned IGNITE-8946:
--
Assignee: Ivan Rakov
> 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
>Assignee: 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
> org.apache.ignite.internal.managers.co
[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
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPo
[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
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(Gr
[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
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPo
[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
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1
[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
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor
[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
java.util.con
[jira] [Commented] (IGNITE-8910) PagesList.takeEmptyPage may fail with AssertionError: type = 1
[
https://issues.apache.org/jira/browse/IGNITE-8910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16532659#comment-16532659
]
Ivan Rakov commented on IGNITE-8910:
Looks good. Merged to master.
> PagesList.takeEmptyPage may fail with AssertionError: type = 1
> --
>
> Key: IGNITE-8910
> URL: https://issues.apache.org/jira/browse/IGNITE-8910
> Project: Ignite
> Issue Type: Bug
>Reporter: Ivan Rakov
>Assignee: Dmitriy Sorokin
>Priority: Critical
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.7
>
>
> Even after IGNITE-8769 fix, we sometimes get an AssertionError from free list
> during update operation. Page with type PageIO#T_DATA appears in free list
> for some reason.
> Example hang on TC:
> https://ci.ignite.apache.org/viewLog.html?buildId=1442664&buildTypeId=IgniteTests24Java8_PdsIndexingWalRecovery
> Example stacktrace:
> {noformat}
> [15:59:26]W: [org.apache.ignite:ignite-indexing]
> java.lang.AssertionError: Assertion error on search row:
> org.apache.ignite.internal.processors.cache.tree.SearchRow@1e76dfc5
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.invoke(BPlusTree.java:1643)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.invoke(IgniteCacheOffheapManagerImpl.java:1272)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.invoke(GridCacheOffheapManager.java:1603)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.invoke(IgniteCacheOffheapManagerImpl.java:370)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.innerUpdate(GridCacheMapEntry.java:1755)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateSingle(GridDhtAtomicCache.java:2436)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.update(GridDhtAtomicCache.java:1898)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1740)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1630)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.sendSingleRequest(GridNearAtomicAbstractUpdateFuture.java:299)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.map(GridNearAtomicSingleUpdateFuture.java:483)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.mapOnTopology(GridNearAtomicSingleUpdateFuture.java:443)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.map(GridNearAtomicAbstractUpdateFuture.java:248)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.update0(GridDhtAtomicCache.java:1119)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.put0(GridDhtAtomicCache.java:609)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2428)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2405)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.put(IgniteCacheProxyImpl.java:1084)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.put(Gat
[jira] [Commented] (IGNITE-8747) Remove\RemoveAll method should not count expired entry as removed.
[ https://issues.apache.org/jira/browse/IGNITE-8747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16531630#comment-16531630 ] Ivan Rakov commented on IGNITE-8747: Changes merged to master under IGNITE-8681. Commit hash: a06c47f7e90005d342ab100270398e9c5ea5423d > Remove\RemoveAll method should not count expired entry as removed. > -- > > Key: IGNITE-8747 > URL: https://issues.apache.org/jira/browse/IGNITE-8747 > Project: Ignite > Issue Type: Bug > Components: cache >Reporter: Andrew Mashenkov >Assignee: Andrew Mashenkov >Priority: Major > Labels: MakeTeamcityGreenAgain, tck, test-failure > Fix For: 2.7 > > > We have 2 TCK 1.0 test that are passed due to we have eagerTtl=true by > default. > The reason is remove() return true even if an expired entry was removed. > Seems, we have to evict expired entry from cache on remove(), but do not > count it as removed. > java.lang.AssertionError > at > org.jsr107.tck.expiry.CacheExpiryTest.expire_whenAccessed(CacheExpiryTest.java:326) > java.lang.AssertionError: expected:<0> but was:<1> at > org.jsr107.tck.expiry.CacheExpiryTest.testCacheStatisticsRemoveAll(CacheExpiryTest.java:160) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8681) Using ExpiryPolicy with persistence causes significant slowdown.
[ https://issues.apache.org/jira/browse/IGNITE-8681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16531629#comment-16531629 ] Ivan Rakov commented on IGNITE-8681: Thanks for your contribution! Merged to master. > Using ExpiryPolicy with persistence causes significant slowdown. > > > Key: IGNITE-8681 > URL: https://issues.apache.org/jira/browse/IGNITE-8681 > Project: Ignite > Issue Type: Improvement > Components: cache >Reporter: Andrew Mashenkov >Assignee: Andrew Mashenkov >Priority: Critical > Labels: performance > Fix For: 2.7 > > > Almost all ignite operations calls CU.unwindEvicts() on finish to help to > evict expired entries. > In unwindEvicts(), threads iterate over all node partitions and check every > partition PendingTree for expired entries. This costs too much. > We already have a flag on per-cachegroup basis that indicated ExpiryPolicy is > used. It raised once expiring entry has been put to cache or we initialize > non-empty pending tree from persistence. > So, we have to optimize a case when there is no expired pending entries, but > pending tree is non-empty. > We can add some throttling on per-partition basis to reduce useless pending > tree lookups. > E.g. if there is nothing to clean, no thread should check partition during > next 100ms interval. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8910) PagesList.takeEmptyPage may fail with AssertionError: type = 1
[
https://issues.apache.org/jira/browse/IGNITE-8910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Rakov updated IGNITE-8910:
---
Priority: Critical (was: Major)
> PagesList.takeEmptyPage may fail with AssertionError: type = 1
> --
>
> Key: IGNITE-8910
> URL: https://issues.apache.org/jira/browse/IGNITE-8910
> Project: Ignite
> Issue Type: Bug
>Reporter: Ivan Rakov
>Assignee: Dmitriy Sorokin
>Priority: Critical
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.7
>
>
> Even after IGNITE-8769 fix, we sometimes get an AssertionError from free list
> during update operation. Page with type PageIO#T_DATA appears in free list
> for some reason.
> Example hang on TC:
> https://ci.ignite.apache.org/viewLog.html?buildId=1442664&buildTypeId=IgniteTests24Java8_PdsIndexingWalRecovery
> Example stacktrace:
> {noformat}
> [15:59:26]W: [org.apache.ignite:ignite-indexing]
> java.lang.AssertionError: Assertion error on search row:
> org.apache.ignite.internal.processors.cache.tree.SearchRow@1e76dfc5
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.invoke(BPlusTree.java:1643)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.invoke(IgniteCacheOffheapManagerImpl.java:1272)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.invoke(GridCacheOffheapManager.java:1603)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.invoke(IgniteCacheOffheapManagerImpl.java:370)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.innerUpdate(GridCacheMapEntry.java:1755)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateSingle(GridDhtAtomicCache.java:2436)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.update(GridDhtAtomicCache.java:1898)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1740)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1630)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.sendSingleRequest(GridNearAtomicAbstractUpdateFuture.java:299)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.map(GridNearAtomicSingleUpdateFuture.java:483)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.mapOnTopology(GridNearAtomicSingleUpdateFuture.java:443)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.map(GridNearAtomicAbstractUpdateFuture.java:248)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.update0(GridDhtAtomicCache.java:1119)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.put0(GridDhtAtomicCache.java:609)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2428)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2405)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.put(IgniteCacheProxyImpl.java:1084)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.put(GatewayProtectedCacheProxy.java:812)
> [15:59:26]W:
[jira] [Updated] (IGNITE-8910) PagesList.takeEmptyPage may fail with AssertionError: type = 1
[
https://issues.apache.org/jira/browse/IGNITE-8910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Rakov updated IGNITE-8910:
---
Fix Version/s: 2.7
> PagesList.takeEmptyPage may fail with AssertionError: type = 1
> --
>
> Key: IGNITE-8910
> URL: https://issues.apache.org/jira/browse/IGNITE-8910
> Project: Ignite
> Issue Type: Bug
>Reporter: Ivan Rakov
>Assignee: Dmitriy Sorokin
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.7
>
>
> Even after IGNITE-8769 fix, we sometimes get an AssertionError from free list
> during update operation. Page with type PageIO#T_DATA appears in free list
> for some reason.
> Example hang on TC:
> https://ci.ignite.apache.org/viewLog.html?buildId=1442664&buildTypeId=IgniteTests24Java8_PdsIndexingWalRecovery
> Example stacktrace:
> {noformat}
> [15:59:26]W: [org.apache.ignite:ignite-indexing]
> java.lang.AssertionError: Assertion error on search row:
> org.apache.ignite.internal.processors.cache.tree.SearchRow@1e76dfc5
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.invoke(BPlusTree.java:1643)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.invoke(IgniteCacheOffheapManagerImpl.java:1272)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.invoke(GridCacheOffheapManager.java:1603)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.invoke(IgniteCacheOffheapManagerImpl.java:370)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.innerUpdate(GridCacheMapEntry.java:1755)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateSingle(GridDhtAtomicCache.java:2436)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.update(GridDhtAtomicCache.java:1898)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1740)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1630)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.sendSingleRequest(GridNearAtomicAbstractUpdateFuture.java:299)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.map(GridNearAtomicSingleUpdateFuture.java:483)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.mapOnTopology(GridNearAtomicSingleUpdateFuture.java:443)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.map(GridNearAtomicAbstractUpdateFuture.java:248)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.update0(GridDhtAtomicCache.java:1119)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.put0(GridDhtAtomicCache.java:609)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2428)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2405)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.put(IgniteCacheProxyImpl.java:1084)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.put(GatewayProtectedCacheProxy.java:812)
> [15:59:26]W: [org.apac
[jira] [Updated] (IGNITE-8910) PagesList.takeEmptyPage may fail with AssertionError: type = 1
[
https://issues.apache.org/jira/browse/IGNITE-8910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Rakov updated IGNITE-8910:
---
Labels: MakeTeamcityGreenAgain (was: )
> PagesList.takeEmptyPage may fail with AssertionError: type = 1
> --
>
> Key: IGNITE-8910
> URL: https://issues.apache.org/jira/browse/IGNITE-8910
> Project: Ignite
> Issue Type: Bug
>Reporter: Ivan Rakov
>Assignee: Dmitriy Sorokin
>Priority: Major
> Labels: MakeTeamcityGreenAgain
>
> Even after IGNITE-8769 fix, we sometimes get an AssertionError from free list
> during update operation. Page with type PageIO#T_DATA appears in free list
> for some reason.
> Example hang on TC:
> https://ci.ignite.apache.org/viewLog.html?buildId=1442664&buildTypeId=IgniteTests24Java8_PdsIndexingWalRecovery
> Example stacktrace:
> {noformat}
> [15:59:26]W: [org.apache.ignite:ignite-indexing]
> java.lang.AssertionError: Assertion error on search row:
> org.apache.ignite.internal.processors.cache.tree.SearchRow@1e76dfc5
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.invoke(BPlusTree.java:1643)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.invoke(IgniteCacheOffheapManagerImpl.java:1272)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.invoke(GridCacheOffheapManager.java:1603)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.invoke(IgniteCacheOffheapManagerImpl.java:370)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.innerUpdate(GridCacheMapEntry.java:1755)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateSingle(GridDhtAtomicCache.java:2436)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.update(GridDhtAtomicCache.java:1898)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1740)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1630)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.sendSingleRequest(GridNearAtomicAbstractUpdateFuture.java:299)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.map(GridNearAtomicSingleUpdateFuture.java:483)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.mapOnTopology(GridNearAtomicSingleUpdateFuture.java:443)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.map(GridNearAtomicAbstractUpdateFuture.java:248)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.update0(GridDhtAtomicCache.java:1119)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.put0(GridDhtAtomicCache.java:609)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2428)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2405)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.put(IgniteCacheProxyImpl.java:1084)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.put(GatewayProtectedCacheProxy.java:812)
> [15:59:26]W: [org.apache.ignit
[jira] [Created] (IGNITE-8910) PagesList.takeEmptyPage may fail with AssertionError: type = 1
Ivan Rakov created IGNITE-8910:
--
Summary: PagesList.takeEmptyPage may fail with AssertionError:
type = 1
Key: IGNITE-8910
URL: https://issues.apache.org/jira/browse/IGNITE-8910
Project: Ignite
Issue Type: Bug
Reporter: Ivan Rakov
Assignee: Dmitriy Sorokin
Even after IGNITE-8769 fix, we sometimes get an AssertionError from free list
during update operation. Page with type PageIO#T_DATA appears in free list for
some reason.
Example hang on TC:
https://ci.ignite.apache.org/viewLog.html?buildId=1442664&buildTypeId=IgniteTests24Java8_PdsIndexingWalRecovery
Example stacktrace:
{noformat}
[15:59:26]W: [org.apache.ignite:ignite-indexing]
java.lang.AssertionError: Assertion error on search row:
org.apache.ignite.internal.processors.cache.tree.SearchRow@1e76dfc5
[15:59:26]W: [org.apache.ignite:ignite-indexing]at
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.invoke(BPlusTree.java:1643)
[15:59:26]W: [org.apache.ignite:ignite-indexing]at
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.invoke(IgniteCacheOffheapManagerImpl.java:1272)
[15:59:26]W: [org.apache.ignite:ignite-indexing]at
org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.invoke(GridCacheOffheapManager.java:1603)
[15:59:26]W: [org.apache.ignite:ignite-indexing]at
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.invoke(IgniteCacheOffheapManagerImpl.java:370)
[15:59:26]W: [org.apache.ignite:ignite-indexing]at
org.apache.ignite.internal.processors.cache.GridCacheMapEntry.innerUpdate(GridCacheMapEntry.java:1755)
[15:59:26]W: [org.apache.ignite:ignite-indexing]at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateSingle(GridDhtAtomicCache.java:2436)
[15:59:26]W: [org.apache.ignite:ignite-indexing]at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.update(GridDhtAtomicCache.java:1898)
[15:59:26]W: [org.apache.ignite:ignite-indexing]at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1740)
[15:59:26]W: [org.apache.ignite:ignite-indexing]at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1630)
[15:59:26]W: [org.apache.ignite:ignite-indexing]at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.sendSingleRequest(GridNearAtomicAbstractUpdateFuture.java:299)
[15:59:26]W: [org.apache.ignite:ignite-indexing]at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.map(GridNearAtomicSingleUpdateFuture.java:483)
[15:59:26]W: [org.apache.ignite:ignite-indexing]at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.mapOnTopology(GridNearAtomicSingleUpdateFuture.java:443)
[15:59:26]W: [org.apache.ignite:ignite-indexing]at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.map(GridNearAtomicAbstractUpdateFuture.java:248)
[15:59:26]W: [org.apache.ignite:ignite-indexing]at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.update0(GridDhtAtomicCache.java:1119)
[15:59:26]W: [org.apache.ignite:ignite-indexing]at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.put0(GridDhtAtomicCache.java:609)
[15:59:26]W: [org.apache.ignite:ignite-indexing]at
org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2428)
[15:59:26]W: [org.apache.ignite:ignite-indexing]at
org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2405)
[15:59:26]W: [org.apache.ignite:ignite-indexing]at
org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.put(IgniteCacheProxyImpl.java:1084)
[15:59:26]W: [org.apache.ignite:ignite-indexing]at
org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.put(GatewayProtectedCacheProxy.java:812)
[15:59:26]W: [org.apache.ignite:ignite-indexing]at
org.apache.ignite.internal.processors.cache.persistence.db.wal.IgniteWalRecoveryTest$2.call(IgniteWalRecoveryTest.java:551)
[15:59:26]W: [org.apache.ignite:ignite-indexing]at
org.apache.ignite.internal.processors.cache.persistence.db.wal.IgniteWalRecoveryTest$2.call(IgniteWalRecoveryTest.java:546)
[15:59:26]W:
[jira] [Commented] (IGNITE-8493) GridToStringBuilder fails with NPE deals with primitive arrays operations.
[ https://issues.apache.org/jira/browse/IGNITE-8493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16524952#comment-16524952 ] Ivan Rakov commented on IGNITE-8493: I can't find TC run for this PR; maybe it's too old and was cleaned from history. I've merged fresh master and rescheduled TC run. > GridToStringBuilder fails with NPE deals with primitive arrays operations. > -- > > Key: IGNITE-8493 > URL: https://issues.apache.org/jira/browse/IGNITE-8493 > Project: Ignite > Issue Type: Bug > Components: general >Affects Versions: 2.4 >Reporter: Stanilovsky Evgeny >Assignee: Stanilovsky Evgeny >Priority: Major > Fix For: 2.7 > > > GridToStringBuilder#arrayToString fails with NPE, if input is a primitive > array. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8742) Direct IO 2 suite is timed out by 'out of disk space' failure emulation test: WAL manager failure does not stoped execution
[
https://issues.apache.org/jira/browse/IGNITE-8742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Rakov updated IGNITE-8742:
---
Fix Version/s: 2.7
> Direct IO 2 suite is timed out by 'out of disk space' failure emulation test:
> WAL manager failure does not stoped execution
> ---
>
> Key: IGNITE-8742
> URL: https://issues.apache.org/jira/browse/IGNITE-8742
> Project: Ignite
> Issue Type: Test
> Components: persistence
>Reporter: Dmitriy Pavlov
>Assignee: Dmitriy Sorokin
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.7
>
>
> https://ci.ignite.apache.org/viewLog.html?buildId=1366882&tab=buildResultsDiv&buildTypeId=IgniteTests24Java8_PdsDirectIo2
> Test
> org.apache.ignite.internal.processors.cache.persistence.IgniteNativeIoWalFlushFsyncSelfTest#testFailAfterStart
> emulates problem with disc space using exception.
> In direct IO environment real IO with disk is performed, tmpfs is not used.
> Sometimes this error can come from rollover() of segment, failure handler
> reacted accordingly.
> {noformat}
> detected. Will be handled accordingly to configured handler [hnd=class
> o.a.i.failure.StopNodeFailureHandler, failureCtx=FailureContext
> [type=CRITICAL_ERROR, err=class o.a.i.i.pagemem.wal.StorageException: Unable
> to write]]
> class org.apache.ignite.internal.pagemem.wal.StorageException: Unable to write
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.FsyncModeFileWriteAheadLogManager$FileWriteHandle.writeBuffer(FsyncModeFileWriteAheadLogManager.java:2964)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.FsyncModeFileWriteAheadLogManager$FileWriteHandle.flush(FsyncModeFileWriteAheadLogManager.java:2640)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.FsyncModeFileWriteAheadLogManager$FileWriteHandle.flush(FsyncModeFileWriteAheadLogManager.java:2572)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.FsyncModeFileWriteAheadLogManager$FileWriteHandle.flushOrWait(FsyncModeFileWriteAheadLogManager.java:2525)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.FsyncModeFileWriteAheadLogManager$FileWriteHandle.close(FsyncModeFileWriteAheadLogManager.java:2795)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.FsyncModeFileWriteAheadLogManager$FileWriteHandle.access$700(FsyncModeFileWriteAheadLogManager.java:2340)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.FsyncModeFileWriteAheadLogManager.rollOver(FsyncModeFileWriteAheadLogManager.java:1029)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.FsyncModeFileWriteAheadLogManager.log(FsyncModeFileWriteAheadLogManager.java:673)
> {noformat}
> But test seems to be not able to stop, node stopper thread tries to stop
> cache, flush WAL. flush wait for rollover, which will never happen.
> {noformat}
> Thread [name="node-stopper", id=2836, state=WAITING, blockCnt=7, waitCnt=9]
> Lock
> [object=java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject@47f6473,
> ownerName=null, ownerId=-1]
> at sun.misc.Unsafe.park(Native Method)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitUninterruptibly(AbstractQueuedSynchronizer.java:1976)
> at o.a.i.i.util.IgniteUtils.awaitQuiet(IgniteUtils.java:7473)
> at
> o.a.i.i.processors.cache.persistence.wal.FsyncModeFileWriteAheadLogManager$FileWriteHandle.flushOrWait(FsyncModeFileWriteAheadLogManager.java:2546)
> at
> o.a.i.i.processors.cache.persistence.wal.FsyncModeFileWriteAheadLogManager$FileWriteHandle.fsync(FsyncModeFileWriteAheadLogManager.java:2750)
> at
> o.a.i.i.processors.cache.persistence.wal.FsyncModeFileWriteAheadLogManager$FileWriteHandle.access$2000(FsyncModeFileWriteAheadLogManager.java:2340)
> at
> o.a.i.i.processors.cache.persistence.wal.FsyncModeFileWriteAheadLogManager.flush(FsyncModeFileWriteAheadLogManager.java:699)
> at
> o.a.i.i.processors.cache.GridCacheProcessor.stopCache(GridCacheProcessor.java:1243)
> at
> o.a.i.i.processors.cache.GridCacheProcessor.stopCaches(GridCacheProcessor.java:969)
> at
> o.a.i.i.processors.cache.GridCacheProcessor.stop(GridCacheProcessor.java:943)
> at o.a.i.i.IgniteKernal.stop0(IgniteKernal.java:2289)
> at o.a.i.i.IgniteKernal.stop(IgniteKernal.java:2167)
> at o.a.i.i.IgnitionEx$IgniteNamedInstance.stop0(IgnitionEx.java:2588)
> - locked o.a.i.i.IgnitionEx$IgniteNamedInstance@90f6bfd
> at o.a.i.i.IgnitionEx
[jira] [Commented] (IGNITE-8749) Exception for "no space left" situation should be propagated to FailureHandler
[ https://issues.apache.org/jira/browse/IGNITE-8749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16518173#comment-16518173 ] Ivan Rakov commented on IGNITE-8749: [~cyberdemon], I've taken a look. Changes look good, TC looks good now. Merged to master. > Exception for "no space left" situation should be propagated to FailureHandler > -- > > Key: IGNITE-8749 > URL: https://issues.apache.org/jira/browse/IGNITE-8749 > Project: Ignite > Issue Type: Improvement > Components: persistence >Reporter: Sergey Chugunov >Assignee: Dmitriy Sorokin >Priority: Major > Fix For: 2.6 > > > For now if "no space left" situation is detected in > FileWriteAheadLogManager#formatFile method and corresponding exception is > thrown the exception doesn't get propagated to FailureHandler and node > continues working. > As "no space left" is a critical situation, corresponding exception should be > propagated to handler to make necessary actions. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8808) Improve control.sh --tx command to show local and remote transactions.
[ https://issues.apache.org/jira/browse/IGNITE-8808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16517258#comment-16517258 ] Ivan Rakov commented on IGNITE-8808: Please resolve conflicts between PR branch and master. > Improve control.sh --tx command to show local and remote transactions. > -- > > Key: IGNITE-8808 > URL: https://issues.apache.org/jira/browse/IGNITE-8808 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.5 >Reporter: Alexei Scherbakov >Assignee: Alexei Scherbakov >Priority: Major > Fix For: 2.6 > > > Currently --tx option for control.sh shows only transactions found on > near(initiating) nodes. > Due to various issues it's possible to have corresponding dht local and > remote transaction without near part. > Such transactions must be visible to utility. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8554) Cache metrics: expose metrics with rebalance info about keys
[ https://issues.apache.org/jira/browse/IGNITE-8554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16517227#comment-16517227 ] Ivan Rakov commented on IGNITE-8554: Merged to master. > Cache metrics: expose metrics with rebalance info about keys > > > Key: IGNITE-8554 > URL: https://issues.apache.org/jira/browse/IGNITE-8554 > Project: Ignite > Issue Type: Improvement > Components: cache >Reporter: Alexey Kuznetsov >Assignee: Ilya Lantukh >Priority: Major > Fix For: 2.6 > > > In order to show info about rebalance progress we need to expose > estimatedRebalancingKeys and rebalancedKeys metrics. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8798) Move transaction recovery logging to INFO level
[
https://issues.apache.org/jira/browse/IGNITE-8798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16517210#comment-16517210
]
Ivan Rakov commented on IGNITE-8798:
Thanks for your contribution! Merged to master.
> Move transaction recovery logging to INFO level
> ---
>
> Key: IGNITE-8798
> URL: https://issues.apache.org/jira/browse/IGNITE-8798
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexey Goncharuk
>Assignee: Evgenii Zagumennov
>Priority: Major
> Fix For: 2.6
>
>
> Currently we log transaction recovery state changes to {{DEBUG}}, however,
> this information is critically important for production deployment and
> incident analysis. I suggest to move corresponding logging
> ({{GridCacheTxRecoveryFuture}} and surrounding code) to {{INFO}} level.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8798) Move transaction recovery logging to INFO level
[
https://issues.apache.org/jira/browse/IGNITE-8798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16516907#comment-16516907
]
Ivan Rakov commented on IGNITE-8798:
Guys, I can't find a TC run for this change.
Let's wait for successful run before merging:
https://ci.ignite.apache.org/viewQueued.html?itemId=1404268
> Move transaction recovery logging to INFO level
> ---
>
> Key: IGNITE-8798
> URL: https://issues.apache.org/jira/browse/IGNITE-8798
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexey Goncharuk
>Assignee: Evgenii Zagumennov
>Priority: Major
>
> Currently we log transaction recovery state changes to {{DEBUG}}, however,
> this information is critically important for production deployment and
> incident analysis. I suggest to move corresponding logging
> ({{GridCacheTxRecoveryFuture}} and surrounding code) to {{INFO}} level.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8749) Exception for "no space left" situation should be propagated to FailureHandler
[ https://issues.apache.org/jira/browse/IGNITE-8749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16516873#comment-16516873 ] Ivan Rakov commented on IGNITE-8749: This fix seems to cause execution timeout of PDS 2 suite. Rollback commit: 29599901cd6bcd5a8aec003edc1538dbd66530af > Exception for "no space left" situation should be propagated to FailureHandler > -- > > Key: IGNITE-8749 > URL: https://issues.apache.org/jira/browse/IGNITE-8749 > Project: Ignite > Issue Type: Improvement > Components: persistence >Reporter: Sergey Chugunov >Assignee: Dmitriy Sorokin >Priority: Major > Fix For: 2.6 > > > For now if "no space left" situation is detected in > FileWriteAheadLogManager#formatFile method and corresponding exception is > thrown the exception doesn't get propagated to FailureHandler and node > continues working. > As "no space left" is a critical situation, corresponding exception should be > propagated to handler to make necessary actions. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8769) JVM crash in Basic1 suite in master branch on TC
[ https://issues.apache.org/jira/browse/IGNITE-8769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16515685#comment-16515685 ] Ivan Rakov commented on IGNITE-8769: Code changes look good, let's wait for successful TC run. > JVM crash in Basic1 suite in master branch on TC > > > Key: IGNITE-8769 > URL: https://issues.apache.org/jira/browse/IGNITE-8769 > Project: Ignite > Issue Type: Bug >Reporter: Sergey Chugunov >Assignee: Dmitriy Sorokin >Priority: Blocker > Labels: MakeTeamcityGreenAgain > Fix For: 2.6 > > > Latest build with crash: [TC > link|https://ci.ignite.apache.org/viewLog.html?buildId=1373991&tab=buildResultsDiv&buildTypeId=IgniteTests24Java8_Basic1] > There is another crash in the history: [TC > link|https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_Basic1&branch_IgniteTests24Java8=%3Cdefault%3E&tab=buildTypeStatusDiv] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8811) Create copies of basic TC suites with PDS delta checking framework enabled
[ https://issues.apache.org/jira/browse/IGNITE-8811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Rakov updated IGNITE-8811: --- Labels: MakeTeamcityGreenAgain (was: ) > Create copies of basic TC suites with PDS delta checking framework enabled > -- > > Key: IGNITE-8811 > URL: https://issues.apache.org/jira/browse/IGNITE-8811 > Project: Ignite > Issue Type: Bug > Components: persistence >Reporter: Ivan Rakov >Assignee: Ivan Rakov >Priority: Major > Labels: MakeTeamcityGreenAgain > > With having PDS delta checking framework implemented (IGNITE-8529), we should > add some copies of existing TC suites with system property that enables > self-check on checkpoint. > We can start with Full API and SQL suites. Please note that some tests may > fail with OOM as Ignite node with framework consumes x2 RAM. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8811) Create copies of basic TC suites with PDS delta checking framework enabled
[ https://issues.apache.org/jira/browse/IGNITE-8811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Rakov updated IGNITE-8811: --- Component/s: persistence > Create copies of basic TC suites with PDS delta checking framework enabled > -- > > Key: IGNITE-8811 > URL: https://issues.apache.org/jira/browse/IGNITE-8811 > Project: Ignite > Issue Type: Bug > Components: persistence >Reporter: Ivan Rakov >Assignee: Ivan Rakov >Priority: Major > Labels: MakeTeamcityGreenAgain > > With having PDS delta checking framework implemented (IGNITE-8529), we should > add some copies of existing TC suites with system property that enables > self-check on checkpoint. > We can start with Full API and SQL suites. Please note that some tests may > fail with OOM as Ignite node with framework consumes x2 RAM. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8811) Create copies of basic TC suites with PDS delta checking framework enabled
[ https://issues.apache.org/jira/browse/IGNITE-8811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Rakov updated IGNITE-8811: --- Environment: (was: With having PDS delta checking framework implemented (IGNITE-8529), we should add some copies of existing TC suites with system property that enables self-check on checkpoint. We can start with Full API and SQL suites. Please note that some tests may fail with OOM as Ignite node with framework consumes x2 RAM.) Description: With having PDS delta checking framework implemented (IGNITE-8529), we should add some copies of existing TC suites with system property that enables self-check on checkpoint. We can start with Full API and SQL suites. Please note that some tests may fail with OOM as Ignite node with framework consumes x2 RAM. > Create copies of basic TC suites with PDS delta checking framework enabled > -- > > Key: IGNITE-8811 > URL: https://issues.apache.org/jira/browse/IGNITE-8811 > Project: Ignite > Issue Type: Bug >Reporter: Ivan Rakov >Assignee: Ivan Rakov >Priority: Major > > With having PDS delta checking framework implemented (IGNITE-8529), we should > add some copies of existing TC suites with system property that enables > self-check on checkpoint. > We can start with Full API and SQL suites. Please note that some tests may > fail with OOM as Ignite node with framework consumes x2 RAM. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8811) Create copies of basic TC suites with PDS delta checking framework enabled
Ivan Rakov created IGNITE-8811: -- Summary: Create copies of basic TC suites with PDS delta checking framework enabled Key: IGNITE-8811 URL: https://issues.apache.org/jira/browse/IGNITE-8811 Project: Ignite Issue Type: Bug Environment: With having PDS delta checking framework implemented (IGNITE-8529), we should add some copies of existing TC suites with system property that enables self-check on checkpoint. We can start with Full API and SQL suites. Please note that some tests may fail with OOM as Ignite node with framework consumes x2 RAM. Reporter: Ivan Rakov Assignee: Ivan Rakov -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8529) Implement testing framework for checking WAL delta records consistency
[ https://issues.apache.org/jira/browse/IGNITE-8529?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16512774#comment-16512774 ] Ivan Rakov commented on IGNITE-8529: [~alex_pl], thanks for your contribution! Merged to master. > Implement testing framework for checking WAL delta records consistency > -- > > Key: IGNITE-8529 > URL: https://issues.apache.org/jira/browse/IGNITE-8529 > Project: Ignite > Issue Type: New Feature > Components: persistence >Reporter: Ivan Rakov >Assignee: Aleksey Plekhanov >Priority: Major > Fix For: 2.6 > > > We use sharp checkpointing of page memory in persistent mode. That implies > that we write two types of records to write-ahead log: logical (e.g. data > records) and phyisical (page snapshots + binary delta records). Physical > records are applied only when node crashes/stops during ongoing checkpoint. > We have the following invariant: checkpoint #(n-1) + all physical records = > checkpoint #n. > If correctness of physical records is broken, Ignite node may recover with > incorrect page memory state, which in turn can bring unexpected delayed > errors. However, consistency of physical records is poorly tested: only small > part of our autotests perform node restarts, and even less part of them > perform node stop when ongoing checkpoint is running. > We should implement abstract test that: > 1. Enforces checkpoint, freezes memory state at the moment of checkpoint. > 2. Performs necessary test load. > 3. Enforces checkpoint again, replays WAL and checks that page store at the > moment of previous checkpoint with all applied physical records exactly > equals to current checkpoint state. > Except for checking correctness, test framework should do the following: > 1. Gather statistics (like histogram) for types of wriiten physical records. > That will help us to know what types of physical records are covered by test. > 2. Visualize expected and actual page state (with all applied physical > records) if incorrect page state is detected. > Regarding implementation, I suppose we can use checkpoint listener mechanism > to freeze page memory state at the moment of checkpoint. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8783) Failover tests periodically cause hanging of the whole Data Structures suite on TC
[
https://issues.apache.org/jira/browse/IGNITE-8783?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Rakov updated IGNITE-8783:
---
Description:
History of suite runs:
https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_DataStructures&tab=buildTypeHistoryList&branch_IgniteTests24Java8=%3Cdefault%3E
Chance of suite hang is 18% in master (based on previous 50 runs).
Hang is always caused by one of the following failover tests:
{noformat}
GridCacheReplicatedDataStructuresFailoverSelfTest#testAtomicSequenceConstantTopologyChange
GridCachePartitionedDataStructuresFailoverSelfTest#testFairReentrantLockConstantTopologyChangeNonFailoverSafe
{noformat}
was:
History of suite runs:
https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_DataStructures&tab=buildTypeHistoryList&branch_IgniteTests24Java8=%3Cdefault%3E
Chance of suite hang is 18% in master (based on previous 50 runs).
One of the following failover tests is always a reason of hang:
{noformat}
GridCacheReplicatedDataStructuresFailoverSelfTest#testAtomicSequenceConstantTopologyChange
GridCachePartitionedDataStructuresFailoverSelfTest#testFairReentrantLockConstantTopologyChangeNonFailoverSafe
{noformat}
> Failover tests periodically cause hanging of the whole Data Structures suite
> on TC
> --
>
> Key: IGNITE-8783
> URL: https://issues.apache.org/jira/browse/IGNITE-8783
> Project: Ignite
> Issue Type: Bug
> Components: data structures
>Reporter: Ivan Rakov
>Priority: Major
> Labels: MakeTeamcityGreenAgain
>
> History of suite runs:
> https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_DataStructures&tab=buildTypeHistoryList&branch_IgniteTests24Java8=%3Cdefault%3E
> Chance of suite hang is 18% in master (based on previous 50 runs).
> Hang is always caused by one of the following failover tests:
> {noformat}
> GridCacheReplicatedDataStructuresFailoverSelfTest#testAtomicSequenceConstantTopologyChange
> GridCachePartitionedDataStructuresFailoverSelfTest#testFairReentrantLockConstantTopologyChangeNonFailoverSafe
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-8783) Failover tests periodically cause hanging of the whole Data Structures suite on TC
[
https://issues.apache.org/jira/browse/IGNITE-8783?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Rakov updated IGNITE-8783:
---
Description:
History of suite runs:
https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_DataStructures&tab=buildTypeHistoryList&branch_IgniteTests24Java8=%3Cdefault%3E
Chance of suite hang is 18% in master (based on previous 50 runs).
One of the following failover tests is always a reason of hang:
{noformat}
GridCacheReplicatedDataStructuresFailoverSelfTest#testAtomicSequenceConstantTopologyChange
GridCachePartitionedDataStructuresFailoverSelfTest#testFairReentrantLockConstantTopologyChangeNonFailoverSafe
{noformat}
was:
History of suite runs:
https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_DataStructures&tab=buildTypeHistoryList&branch_IgniteTests24Java8=%3Cdefault%3E
Chance of suite hang is 18% (based on previous 50 runs).
One of the following failover tests is always a reason of hang:
{noformat}
GridCacheReplicatedDataStructuresFailoverSelfTest#testAtomicSequenceConstantTopologyChange
GridCachePartitionedDataStructuresFailoverSelfTest#testFairReentrantLockConstantTopologyChangeNonFailoverSafe
{noformat}
> Failover tests periodically cause hanging of the whole Data Structures suite
> on TC
> --
>
> Key: IGNITE-8783
> URL: https://issues.apache.org/jira/browse/IGNITE-8783
> Project: Ignite
> Issue Type: Bug
> Components: data structures
>Reporter: Ivan Rakov
>Priority: Major
> Labels: MakeTeamcityGreenAgain
>
> History of suite runs:
> https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_DataStructures&tab=buildTypeHistoryList&branch_IgniteTests24Java8=%3Cdefault%3E
> Chance of suite hang is 18% in master (based on previous 50 runs).
> One of the following failover tests is always a reason of hang:
> {noformat}
> GridCacheReplicatedDataStructuresFailoverSelfTest#testAtomicSequenceConstantTopologyChange
> GridCachePartitionedDataStructuresFailoverSelfTest#testFairReentrantLockConstantTopologyChangeNonFailoverSafe
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-8783) Failover tests periodically cause hanging of the whole Data Structures suite on TC
[
https://issues.apache.org/jira/browse/IGNITE-8783?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Rakov updated IGNITE-8783:
---
Labels: MakeTeamcityGreenAgain (was: )
> Failover tests periodically cause hanging of the whole Data Structures suite
> on TC
> --
>
> Key: IGNITE-8783
> URL: https://issues.apache.org/jira/browse/IGNITE-8783
> Project: Ignite
> Issue Type: Bug
> Components: data structures
>Reporter: Ivan Rakov
>Priority: Major
> Labels: MakeTeamcityGreenAgain
>
> History of suite runs:
> https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_DataStructures&tab=buildTypeHistoryList&branch_IgniteTests24Java8=%3Cdefault%3E
> Chance of suite hang is 18% in master (based on previous 50 runs).
> Hang is always caused by one of the following failover tests:
> {noformat}
> GridCacheReplicatedDataStructuresFailoverSelfTest#testAtomicSequenceConstantTopologyChange
> GridCachePartitionedDataStructuresFailoverSelfTest#testFairReentrantLockConstantTopologyChangeNonFailoverSafe
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-8783) Failover tests periodically cause hanging of the whole Data Structures suite on TC
Ivan Rakov created IGNITE-8783:
--
Summary: Failover tests periodically cause hanging of the whole
Data Structures suite on TC
Key: IGNITE-8783
URL: https://issues.apache.org/jira/browse/IGNITE-8783
Project: Ignite
Issue Type: Bug
Components: data structures
Reporter: Ivan Rakov
History of suite runs:
https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_DataStructures&tab=buildTypeHistoryList&branch_IgniteTests24Java8=%3Cdefault%3E
Chance of suite hang is 18% (based on previous 50 runs).
One of the following failover tests is always a reason of hang:
{noformat}
GridCacheReplicatedDataStructuresFailoverSelfTest#testAtomicSequenceConstantTopologyChange
GridCachePartitionedDataStructuresFailoverSelfTest#testFairReentrantLockConstantTopologyChangeNonFailoverSafe
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-8747) Remove\RemoveAll method should not count expired entry as removed.
[ https://issues.apache.org/jira/browse/IGNITE-8747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Rakov updated IGNITE-8747: --- Fix Version/s: 2.6 > Remove\RemoveAll method should not count expired entry as removed. > -- > > Key: IGNITE-8747 > URL: https://issues.apache.org/jira/browse/IGNITE-8747 > Project: Ignite > Issue Type: Improvement > Components: cache >Reporter: Andrew Mashenkov >Assignee: Andrew Mashenkov >Priority: Major > Labels: MakeTeamcityGreenAgain, tck, test-failure > Fix For: 2.6 > > > We have 2 TCK 1.0 test that are passed due to we have eagerTtl=true by > default. > The reason is remove() return true even if an expired entry was removed. > Seems, we have to evict expired entry from cache on remove(), but do not > count it as removed. > java.lang.AssertionError > at > org.jsr107.tck.expiry.CacheExpiryTest.expire_whenAccessed(CacheExpiryTest.java:326) > java.lang.AssertionError: expected:<0> but was:<1> at > org.jsr107.tck.expiry.CacheExpiryTest.testCacheStatisticsRemoveAll(CacheExpiryTest.java:160) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8503) Fix wrong GridCacheMapEntry startVersion initialization.
[
https://issues.apache.org/jira/browse/IGNITE-8503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Rakov updated IGNITE-8503:
---
Fix Version/s: 2.6
> Fix wrong GridCacheMapEntry startVersion initialization.
>
>
> Key: IGNITE-8503
> URL: https://issues.apache.org/jira/browse/IGNITE-8503
> Project: Ignite
> Issue Type: Improvement
> Components: cache, persistence
>Reporter: Dmitriy Pavlov
>Assignee: Andrew Mashenkov
>Priority: Major
> Labels: MakeTeamcityGreenAgain, Muted_test, tck
> Fix For: 2.6
>
>
> GridCacheMapEntry initialize startVersion in wrong way.
> This leads to IgnitePdsWithTtlTest.testTtlIsAppliedAfterRestart failure and
> reason is "Entry which should be expired by TTL policy is available after
> grid restart."
>
> Test was added during https://issues.apache.org/jira/browse/IGNITE-5874
> development.
> This test restarts grid and checks all entries are not present in grid.
> But with high possiblity one from 7000 entries to be expired is resurrected
> instead and returned by cache get.
> {noformat}
> After timeout {{
> >>>
> >>> Cache memory stats [igniteInstanceName=db.IgnitePdsWithTtlTest0,
> >>> cache=expirableCache]
> >>> Cache size: 0
> >>> Cache partition topology stats
> >>> [igniteInstanceName=db.IgnitePdsWithTtlTest0, grp=group1]
> >>>
> >>> Cache event manager memory stats
> >>> [igniteInstanceName=db.IgnitePdsWithTtlTest0, cache=expirableCache,
> >>> stats=N/A]
> >>>
> >>> Query manager memory stats [igniteInstanceName=db.IgnitePdsWithTtlTest0,
> >>> cache=expirableCache]
> >>> threadsSize: 0
> >>> futsSize: 0
> >>>
> >>> TTL processor memory stats [igniteInstanceName=db.IgnitePdsWithTtlTest0,
> >>> cache=expirableCache]
> >>> pendingEntriesSize: 0
> }} After timeout
> {noformat}
> [https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=5798755758125626876&tab=testDetails&branch_IgniteTests24Java8=%3Cdefault%3E]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8757) idle_verify utility doesn't show both update counter and hash conflicts
[ https://issues.apache.org/jira/browse/IGNITE-8757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16511019#comment-16511019 ] Ivan Rakov commented on IGNITE-8757: TC: https://ci.ignite.apache.org/viewLog.html?buildId=1374429&tab=buildResultsDiv&buildTypeId=IgniteTests24Java8_RunAll > idle_verify utility doesn't show both update counter and hash conflicts > --- > > Key: IGNITE-8757 > URL: https://issues.apache.org/jira/browse/IGNITE-8757 > Project: Ignite > Issue Type: Bug >Reporter: Ivan Rakov >Assignee: Ivan Rakov >Priority: Major > > If there are two partitions in cluster, one with different update counters > and one with different data, idle_verify will show only partition with broken > counters. We should show both for better visibility. > We should also show notify user about rebalancing partitions that were > excluded from analysis. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8761) WAL fsync at rollover should be asynchronous in LOG_ONLY and BACKGROUND modes
Ivan Rakov created IGNITE-8761:
--
Summary: WAL fsync at rollover should be asynchronous in LOG_ONLY
and BACKGROUND modes
Key: IGNITE-8761
URL: https://issues.apache.org/jira/browse/IGNITE-8761
Project: Ignite
Issue Type: Improvement
Components: persistence
Reporter: Ivan Rakov
Fix For: 2.6
Transactions may periodically hang for a few seconds in LOG_ONLY or BACKGROUND
persistent modes. Thread dumps show that threads are hanging on syncing
previous WAL segment during rollover:
{noformat}
java.lang.Thread.State: RUNNABLE
at java.nio.MappedByteBuffer.force0(MappedByteBuffer.java:-1)
at java.nio.MappedByteBuffer.force(MappedByteBuffer.java:203)
at
org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileWriteHandle.close(FileWriteAheadLogManager.java:2843)
at
org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileWriteHandle.access$600(FileWriteAheadLogManager.java:2483)
at
org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.rollOver(FileWriteAheadLogManager.java:1094)
{noformat}
Waiting for this fsync is not necessary action to ensure crash recovery
guarantees. Instead of this, we should just perform fsyncs asychronously and
ensure that they are completed prior to next checkpoint start.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-8757) idle_verify utility doesn't show both update counter and hash conflicts
[ https://issues.apache.org/jira/browse/IGNITE-8757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Rakov updated IGNITE-8757: --- Description: If there are two partitions in cluster, one with different update counters and one with different data, idle_verify will show only partition with broken counters. We should show both for better visibility. We should also show notify user about rebalancing partitions that were excluded from analysis. was: If there are two partitions in cluster, one with different update counters and one with different data, idle_verify will show only partition with broken counters. We should show both for better visibility. > idle_verify utility doesn't show both update counter and hash conflicts > --- > > Key: IGNITE-8757 > URL: https://issues.apache.org/jira/browse/IGNITE-8757 > Project: Ignite > Issue Type: Bug >Reporter: Ivan Rakov >Assignee: Ivan Rakov >Priority: Major > > If there are two partitions in cluster, one with different update counters > and one with different data, idle_verify will show only partition with broken > counters. We should show both for better visibility. > We should also show notify user about rebalancing partitions that were > excluded from analysis. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8757) idle_verify utility doesn't show both update counter and hash conflicts
Ivan Rakov created IGNITE-8757: -- Summary: idle_verify utility doesn't show both update counter and hash conflicts Key: IGNITE-8757 URL: https://issues.apache.org/jira/browse/IGNITE-8757 Project: Ignite Issue Type: Bug Reporter: Ivan Rakov Assignee: Ivan Rakov If there are two partitions in cluster, one with different update counters and one with different data, idle_verify will show only partition with broken counters. We should show both for better visibility. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8735) Metastorage creates its own index partition
[ https://issues.apache.org/jira/browse/IGNITE-8735?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Rakov updated IGNITE-8735: --- Description: By design, all metastorage data should be stored in single partition with index = 0. However, allocatePageNoReuse is not overriden in MetastorageTree, which causes allocation of extra pages for the tree in index partition. (was: By design, all metastorage data should be stored in single partition with index = 0. However, allocatePageNoReuse is not overriden in MetastorageTree, which cause allocation of extra pages for the tree in index partition.) > Metastorage creates its own index partition > --- > > Key: IGNITE-8735 > URL: https://issues.apache.org/jira/browse/IGNITE-8735 > Project: Ignite > Issue Type: Bug > Components: persistence >Reporter: Ivan Rakov >Priority: Major > Fix For: 2.6 > > > By design, all metastorage data should be stored in single partition with > index = 0. However, allocatePageNoReuse is not overriden in MetastorageTree, > which causes allocation of extra pages for the tree in index partition. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8735) Metastorage creates its own index partition
Ivan Rakov created IGNITE-8735: -- Summary: Metastorage creates its own index partition Key: IGNITE-8735 URL: https://issues.apache.org/jira/browse/IGNITE-8735 Project: Ignite Issue Type: Bug Components: persistence Reporter: Ivan Rakov Fix For: 2.6 By design, all metastorage data should be stored in single partition with index = 0. However, allocatePageNoReuse is not overriden in MetastorageTree, which cause allocation of extra pages for the tree in index partition. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8681) Using ExpiryPolicy with persistence causes significant slowdown.
[ https://issues.apache.org/jira/browse/IGNITE-8681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16502257#comment-16502257 ] Ivan Rakov commented on IGNITE-8681: [~amashenkov], code changes look good. However, there are some suspicious test fails: IgniteClientNodesTestSuite: IgniteClientReconnectFailoverTest.testReconnectStreamerApi (fail rate 0,0%) org.jsr107.tck.expiry.CacheExpiryTest.expire_whenAccessed (fail rate 0,0%) org.jsr107.tck.expiry.CacheExpiryTest.testCacheStatisticsRemoveAll (fail rate 0,0%) While first one is probably flaky, last two failures look like real issues. > Using ExpiryPolicy with persistence causes significant slowdown. > > > Key: IGNITE-8681 > URL: https://issues.apache.org/jira/browse/IGNITE-8681 > Project: Ignite > Issue Type: Improvement > Components: cache >Reporter: Andrew Mashenkov >Assignee: Andrew Mashenkov >Priority: Critical > Labels: performance > Fix For: 2.6 > > > Almost all ignite operations calls CU.unwindEvicts() on finish to help to > evict expired entries. > In unwindEvicts(), threads iterate over all node partitions and check every > partition PendingTree for expired entries. This costs too much. > We already have a flag on per-cachegroup basis that indicated ExpiryPolicy is > used. It raised once expiring entry has been put to cache or we initialize > non-empty pending tree from persistence. > So, we have to optimize a case when there is no expired pending entries, but > pending tree is non-empty. > We can add some throttling on per-partition basis to reduce useless pending > tree lookups. > E.g. if there is nothing to clean, no thread should check partition during > next 100ms interval. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8691) Get rid of tests jar artifact in ignite-zookeeper module
[
https://issues.apache.org/jira/browse/IGNITE-8691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16501868#comment-16501868
]
Ivan Rakov commented on IGNITE-8691:
The fix doesn't make sense - test jar is not useless and can be referenced in
another test jars.
Fix is rolled back in master in commit 0f4d6fe8d46c6bdf948e261deb59298c96f3a5a5.
> Get rid of tests jar artifact in ignite-zookeeper module
>
>
> Key: IGNITE-8691
> URL: https://issues.apache.org/jira/browse/IGNITE-8691
> Project: Ignite
> Issue Type: Bug
> Components: zookeeper
>Affects Versions: 2.5
>Reporter: Pavel Kovalenko
>Assignee: Pavel Kovalenko
>Priority: Major
> Fix For: 2.6
>
>
> Currently Ignite building process produces
> {noformat}
> org/apache/ignite/ignite-zookeeper/2.X.X/ignite-zookeeper-2.X.X-tests.jar
> {noformat}
> artifact which seems to be useless and should be excluded as result of
> packaging.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8696) control.sh utility does not show atomicity mode
[ https://issues.apache.org/jira/browse/IGNITE-8696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16501788#comment-16501788 ] Ivan Rakov commented on IGNITE-8696: Dmitriy, I'm taking a look. > control.sh utility does not show atomicity mode > --- > > Key: IGNITE-8696 > URL: https://issues.apache.org/jira/browse/IGNITE-8696 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.5 >Reporter: Sergey Kosarev >Assignee: Sergey Kosarev >Priority: Minor > Fix For: 2.6 > > > In current implementation cache viewer list function: > ./control.sh --cache list > does not show atomicity mode for caches. Please add this to the output. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8682) Attempt to configure IGFS in persistent mode without specific data region ends with AssertionError
[
https://issues.apache.org/jira/browse/IGNITE-8682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16501631#comment-16501631
]
Ivan Rakov commented on IGNITE-8682:
[~agoncharuk], thanks for your review! Merged to master.
> Attempt to configure IGFS in persistent mode without specific data region
> ends with AssertionError
> --
>
> Key: IGNITE-8682
> URL: https://issues.apache.org/jira/browse/IGNITE-8682
> Project: Ignite
> Issue Type: Bug
>Reporter: Ivan Rakov
>Assignee: Ivan Rakov
>Priority: Major
> Fix For: 2.6
>
>
> If persistence is enabled and data region name is not specified in IGFS
> configuration, attempt to access IGFS internal cache results in the following
> error:
> {noformat}
> [00:40:03]W:java.lang.AssertionError
> [00:40:03]W: at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.allocatePage(PageMemoryImpl.java:463)
> [00:40:03]W: at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.allocateForTree(IgniteCacheOffheapManagerImpl.java:818)
> [00:40:03]W: at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.initPendingTree(IgniteCacheOffheapManagerImpl.java:164)
> [00:40:03]W: at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.onCacheStarted(IgniteCacheOffheapManagerImpl.java:151)
> [00:40:03]W: at
> org.apache.ignite.internal.processors.cache.CacheGroupContext.onCacheStarted(CacheGroupContext.java:283)
> [00:40:03]W: at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheStart(GridCacheProcessor.java:1965)
> [00:40:03]W: at
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.onCacheChangeRequest(CacheAffinitySharedManager.java:791)
> [00:40:03]W: at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onClusterStateChangeRequest(GridDhtPartitionsExchangeFuture.java:946)
> [00:40:03]W: at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:651)
> [00:40:03]W: at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body0(GridCachePartitionExchangeManager.java:2458)
> [00:40:03]W: at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2338)
> [00:40:03]W: at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> [00:40:03]W: at java.lang.Thread.run(Thread.java:748)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8682) Attempt to configure IGFS in persistent mode without specific data region ends with AssertionError
[
https://issues.apache.org/jira/browse/IGNITE-8682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16500431#comment-16500431
]
Ivan Rakov commented on IGNITE-8682:
[~agoncharuk], please take a look.
> Attempt to configure IGFS in persistent mode without specific data region
> ends with AssertionError
> --
>
> Key: IGNITE-8682
> URL: https://issues.apache.org/jira/browse/IGNITE-8682
> Project: Ignite
> Issue Type: Bug
>Reporter: Ivan Rakov
>Assignee: Ivan Rakov
>Priority: Major
> Fix For: 2.6
>
>
> If persistence is enabled and data region name is not specified in IGFS
> configuration, attempt to access IGFS internal cache results in the following
> error:
> {noformat}
> [00:40:03]W:java.lang.AssertionError
> [00:40:03]W: at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.allocatePage(PageMemoryImpl.java:463)
> [00:40:03]W: at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.allocateForTree(IgniteCacheOffheapManagerImpl.java:818)
> [00:40:03]W: at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.initPendingTree(IgniteCacheOffheapManagerImpl.java:164)
> [00:40:03]W: at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.onCacheStarted(IgniteCacheOffheapManagerImpl.java:151)
> [00:40:03]W: at
> org.apache.ignite.internal.processors.cache.CacheGroupContext.onCacheStarted(CacheGroupContext.java:283)
> [00:40:03]W: at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheStart(GridCacheProcessor.java:1965)
> [00:40:03]W: at
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.onCacheChangeRequest(CacheAffinitySharedManager.java:791)
> [00:40:03]W: at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onClusterStateChangeRequest(GridDhtPartitionsExchangeFuture.java:946)
> [00:40:03]W: at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:651)
> [00:40:03]W: at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body0(GridCachePartitionExchangeManager.java:2458)
> [00:40:03]W: at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2338)
> [00:40:03]W: at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> [00:40:03]W: at java.lang.Thread.run(Thread.java:748)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-8693) SQL JOIN between PARTITIONED and REPLICATED cache fails
[ https://issues.apache.org/jira/browse/IGNITE-8693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Rakov updated IGNITE-8693: --- Fix Version/s: 2.6 > SQL JOIN between PARTITIONED and REPLICATED cache fails > --- > > Key: IGNITE-8693 > URL: https://issues.apache.org/jira/browse/IGNITE-8693 > Project: Ignite > Issue Type: Bug >Reporter: Ilya Lantukh >Assignee: Ilya Lantukh >Priority: Major > Fix For: 2.6 > > > One case of such problem is reproduced by > IgniteCacheQueryNodeRestartTxSelfTest.testRestarts (IGNITE-7766). > If PARTITIONED cache has NodeFilter and is located on subset of REPLICATED > cache nodes, we might fail to execute SQL JOIN query with "Caches have > distinct sets of data nodes" error. Whether if will fail or not depends on > order of *cacheIds* List argument in > GridReduceQueryExecutor.stableDataNodes(...) - we will fail if first cacheId > is REPLICATED. The order depends on internal factors that are out of user's > control. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-8694) SQL JOIN between PARTITIONED and REPLICATED cache fails
[ https://issues.apache.org/jira/browse/IGNITE-8694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Rakov resolved IGNITE-8694. Resolution: Duplicate Clone of IGNITE-8693 > SQL JOIN between PARTITIONED and REPLICATED cache fails > --- > > Key: IGNITE-8694 > URL: https://issues.apache.org/jira/browse/IGNITE-8694 > Project: Ignite > Issue Type: Bug >Reporter: Ivan Rakov >Assignee: Ivan Rakov >Priority: Major > Fix For: 2.6 > > > We already have IGNITE-7766 where TC test fails due to the same problem. > Particular case with PARTITIONED and REPLICATED caches will be fixed under > this ticket, while rest of the work will be completed under IGNITE-7766. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7766) Ignite Queries 2: Test always failed IgniteCacheQueryNodeRestartTxSelfTest.testRestarts
[ https://issues.apache.org/jira/browse/IGNITE-7766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16500340#comment-16500340 ] Ivan Rakov commented on IGNITE-7766: Please note that particular case of this issue is fixed under IGNITE-8694. Test from description should pass after IGNITE-8694 merge. > Ignite Queries 2: Test always failed > IgniteCacheQueryNodeRestartTxSelfTest.testRestarts > --- > > Key: IGNITE-7766 > URL: https://issues.apache.org/jira/browse/IGNITE-7766 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Dmitriy Pavlov >Assignee: Evgenii Zagumennov >Priority: Major > Labels: MakeTeamcityGreenAgain > > Ignite Queries 2 > IgniteBinaryCacheQueryTestSuite2: > IgniteCacheQueryNodeRestartTxSelfTest.testRestarts (fail rate 76,1%) > IgniteCacheQueryNodeRestartTxSelfTest.testRestarts > Current failure: refs/heads/master #345 No changes 11 Feb 18 03:03 > junit.framework.AssertionFailedError: On large page size must retry. > Last runs fails with 100% probability. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8694) SQL JOIN between PARTITIONED and REPLICATED cache fails
[ https://issues.apache.org/jira/browse/IGNITE-8694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Rakov updated IGNITE-8694: --- Description: We already have IGNITE-7766 where TC test fails due to the same problem. Particular case with PARTITIONED and REPLICATED cache will be fixed under this ticket, while rest of the work will be completed under IGNITE-7766. was: We already have IGNITE-7766 where test fails due to the same problem. Particular case with PARTITIONED and REPLICATED cache will be fixed under this ticket, while rest of the work will be completed under IGNITE-7766. > SQL JOIN between PARTITIONED and REPLICATED cache fails > --- > > Key: IGNITE-8694 > URL: https://issues.apache.org/jira/browse/IGNITE-8694 > Project: Ignite > Issue Type: Bug >Reporter: Ivan Rakov >Assignee: Ivan Rakov >Priority: Major > Fix For: 2.6 > > > We already have IGNITE-7766 where TC test fails due to the same problem. > Particular case with PARTITIONED and REPLICATED cache will be fixed under > this ticket, while rest of the work will be completed under IGNITE-7766. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8694) SQL JOIN between PARTITIONED and REPLICATED cache fails
[ https://issues.apache.org/jira/browse/IGNITE-8694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Rakov updated IGNITE-8694: --- Description: We already have IGNITE-7766 where TC test fails due to the same problem. Particular case with PARTITIONED and REPLICATED caches will be fixed under this ticket, while rest of the work will be completed under IGNITE-7766. was: We already have IGNITE-7766 where TC test fails due to the same problem. Particular case with PARTITIONED and REPLICATED cache will be fixed under this ticket, while rest of the work will be completed under IGNITE-7766. > SQL JOIN between PARTITIONED and REPLICATED cache fails > --- > > Key: IGNITE-8694 > URL: https://issues.apache.org/jira/browse/IGNITE-8694 > Project: Ignite > Issue Type: Bug >Reporter: Ivan Rakov >Assignee: Ivan Rakov >Priority: Major > Fix For: 2.6 > > > We already have IGNITE-7766 where TC test fails due to the same problem. > Particular case with PARTITIONED and REPLICATED caches will be fixed under > this ticket, while rest of the work will be completed under IGNITE-7766. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8694) SQL JOIN between PARTITIONED and REPLICATED cache fails
Ivan Rakov created IGNITE-8694: -- Summary: SQL JOIN between PARTITIONED and REPLICATED cache fails Key: IGNITE-8694 URL: https://issues.apache.org/jira/browse/IGNITE-8694 Project: Ignite Issue Type: Bug Reporter: Ivan Rakov Assignee: Ivan Rakov Fix For: 2.6 We already have IGNITE-7766 where test fails due to the same problem. Particular case with PARTITIONED and REPLICATED cache will be fixed under this ticket, while rest of the work will be completed under IGNITE-7766. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8682) Attempt to configure IGFS in persistent mode without specific data region ends with AssertionError
[
https://issues.apache.org/jira/browse/IGNITE-8682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16500329#comment-16500329
]
Ivan Rakov commented on IGNITE-8682:
TC:
https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&branch_IgniteTests24Java8=pull%2F4108%2Fhead
> Attempt to configure IGFS in persistent mode without specific data region
> ends with AssertionError
> --
>
> Key: IGNITE-8682
> URL: https://issues.apache.org/jira/browse/IGNITE-8682
> Project: Ignite
> Issue Type: Bug
>Reporter: Ivan Rakov
>Assignee: Ivan Rakov
>Priority: Major
> Fix For: 2.6
>
>
> If persistence is enabled and data region name is not specified in IGFS
> configuration, attempt to access IGFS internal cache results in the following
> error:
> {noformat}
> [00:40:03]W:java.lang.AssertionError
> [00:40:03]W: at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.allocatePage(PageMemoryImpl.java:463)
> [00:40:03]W: at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.allocateForTree(IgniteCacheOffheapManagerImpl.java:818)
> [00:40:03]W: at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.initPendingTree(IgniteCacheOffheapManagerImpl.java:164)
> [00:40:03]W: at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.onCacheStarted(IgniteCacheOffheapManagerImpl.java:151)
> [00:40:03]W: at
> org.apache.ignite.internal.processors.cache.CacheGroupContext.onCacheStarted(CacheGroupContext.java:283)
> [00:40:03]W: at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheStart(GridCacheProcessor.java:1965)
> [00:40:03]W: at
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.onCacheChangeRequest(CacheAffinitySharedManager.java:791)
> [00:40:03]W: at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onClusterStateChangeRequest(GridDhtPartitionsExchangeFuture.java:946)
> [00:40:03]W: at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:651)
> [00:40:03]W: at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body0(GridCachePartitionExchangeManager.java:2458)
> [00:40:03]W: at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2338)
> [00:40:03]W: at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> [00:40:03]W: at java.lang.Thread.run(Thread.java:748)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8688) Pending tree is initialized outside of checkpoint lock
[
https://issues.apache.org/jira/browse/IGNITE-8688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1658#comment-1658
]
Ivan Rakov commented on IGNITE-8688:
Looks like the same issue as IGNITE-8682. We should probably close this after
IGNITE-8682 is fixed.
> Pending tree is initialized outside of checkpoint lock
> --
>
> Key: IGNITE-8688
> URL: https://issues.apache.org/jira/browse/IGNITE-8688
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.5
>Reporter: Pavel Kovalenko
>Assignee: Andrew Mashenkov
>Priority: Critical
> Fix For: 2.6
>
>
> This may lead to possible page corruption.
> {noformat}
> handled accordingly to configured handler [hnd=class
> o.a.i.failure.StopNodeOrHaltFailureHandler, failureCtx=FailureContext
> [type=SYSTEM_WORKER_TERMINATION, err=java.lang.AssertionError]]
> [00:11:56]W: [org.gridgain:gridgain-compatibility]
> java.lang.AssertionError
> [00:11:56]W: [org.gridgain:gridgain-compatibility] at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.allocatePage(PageMemoryImpl.java:463)
> [00:11:56]W: [org.gridgain:gridgain-compatibility] at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.allocateForTree(IgniteCacheOffheapManagerImpl.java:818)
> [00:11:56]W: [org.gridgain:gridgain-compatibility] at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.initPendingTree(IgniteCacheOffheapManagerImpl.java:164)
> [00:11:56]W: [org.gridgain:gridgain-compatibility] at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.onCacheStarted(IgniteCacheOffheapManagerImpl.java:151)
> [00:11:56]W: [org.gridgain:gridgain-compatibility] at
> org.apache.ignite.internal.processors.cache.CacheGroupContext.onCacheStarted(CacheGroupContext.java:283)
> [00:11:56]W: [org.gridgain:gridgain-compatibility] at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheStart(GridCacheProcessor.java:1965)
> [00:11:56]W: [org.gridgain:gridgain-compatibility] at
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.onCacheChangeRequest(CacheAffinitySharedManager.java:791)
> [00:11:56]W: [org.gridgain:gridgain-compatibility] at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onClusterStateChangeRequest(GridDhtPartitionsExchangeFuture.java:946)
> [00:11:56]W: [org.gridgain:gridgain-compatibility] at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:651)
> [00:11:56]W: [org.gridgain:gridgain-compatibility] at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body0(GridCachePartitionExchangeManager.java:2458)
> [00:11:56]W: [org.gridgain:gridgain-compatibility] at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2338)
> [00:11:56]W: [org.gridgain:gridgain-compatibility] at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> [00:11:56]W: [org.gridgain:gridgain-compatibility] at
> java.lang.Thread.run(Thread.java:748)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-8603) Add JMX-metric to cluster: baseline nodes
[
https://issues.apache.org/jira/browse/IGNITE-8603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16498143#comment-16498143
]
Ivan Rakov edited comment on IGNITE-8603 at 6/1/18 3:43 PM:
Thanks for your contribution! Merged to master.
was (Author: ivan.glukos):
Thanks for you contribution! Merged to master.
> Add JMX-metric to cluster: baseline nodes
> -
>
> Key: IGNITE-8603
> URL: https://issues.apache.org/jira/browse/IGNITE-8603
> Project: Ignite
> Issue Type: Improvement
>Reporter: Dmitriy Gladkikh
>Assignee: Dmitriy Gladkikh
>Priority: Major
> Fix For: 2.6
>
>
> Need to add a baseline nodes on JMX:
> {code:java}
> int org.apache.ignite.mxbean.ClusterMetricsMXBean#getTotalBaselineNodes
> int org.apache.ignite.mxbean.ClusterMetricsMXBean#getActiveBaselineNodes
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8603) Add JMX-metric to cluster: baseline nodes
[
https://issues.apache.org/jira/browse/IGNITE-8603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16498143#comment-16498143
]
Ivan Rakov commented on IGNITE-8603:
Thanks for you contribution! Merged to master.
> Add JMX-metric to cluster: baseline nodes
> -
>
> Key: IGNITE-8603
> URL: https://issues.apache.org/jira/browse/IGNITE-8603
> Project: Ignite
> Issue Type: Improvement
>Reporter: Dmitriy Gladkikh
>Assignee: Dmitriy Gladkikh
>Priority: Major
> Fix For: 2.6
>
>
> Need to add a baseline nodes on JMX:
> {code:java}
> int org.apache.ignite.mxbean.ClusterMetricsMXBean#getTotalBaselineNodes
> int org.apache.ignite.mxbean.ClusterMetricsMXBean#getActiveBaselineNodes
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-8682) Attempt to configure IGFS in persistent mode without specific data region ends with AssertionError
[
https://issues.apache.org/jira/browse/IGNITE-8682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Rakov reassigned IGNITE-8682:
--
Assignee: Ivan Rakov
> Attempt to configure IGFS in persistent mode without specific data region
> ends with AssertionError
> --
>
> Key: IGNITE-8682
> URL: https://issues.apache.org/jira/browse/IGNITE-8682
> Project: Ignite
> Issue Type: Bug
>Reporter: Ivan Rakov
>Assignee: Ivan Rakov
>Priority: Major
> Fix For: 2.6
>
>
> If persistence is enabled and data region name is not specified in IGFS
> configuration, attempt to access IGFS internal cache results in the following
> error:
> {noformat}
> [00:40:03]W:java.lang.AssertionError
> [00:40:03]W: at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.allocatePage(PageMemoryImpl.java:463)
> [00:40:03]W: at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.allocateForTree(IgniteCacheOffheapManagerImpl.java:818)
> [00:40:03]W: at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.initPendingTree(IgniteCacheOffheapManagerImpl.java:164)
> [00:40:03]W: at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.onCacheStarted(IgniteCacheOffheapManagerImpl.java:151)
> [00:40:03]W: at
> org.apache.ignite.internal.processors.cache.CacheGroupContext.onCacheStarted(CacheGroupContext.java:283)
> [00:40:03]W: at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheStart(GridCacheProcessor.java:1965)
> [00:40:03]W: at
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.onCacheChangeRequest(CacheAffinitySharedManager.java:791)
> [00:40:03]W: at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onClusterStateChangeRequest(GridDhtPartitionsExchangeFuture.java:946)
> [00:40:03]W: at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:651)
> [00:40:03]W: at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body0(GridCachePartitionExchangeManager.java:2458)
> [00:40:03]W: at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2338)
> [00:40:03]W: at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> [00:40:03]W: at java.lang.Thread.run(Thread.java:748)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-8682) Attempt to configure IGFS in persistent mode without specific data region ends with AssertionError
Ivan Rakov created IGNITE-8682:
--
Summary: Attempt to configure IGFS in persistent mode without
specific data region ends with AssertionError
Key: IGNITE-8682
URL: https://issues.apache.org/jira/browse/IGNITE-8682
Project: Ignite
Issue Type: Bug
Reporter: Ivan Rakov
If persistence is enabled and data region name is not specified in IGFS
configuration, attempt to access IGFS internal cache results in the following
error:
{noformat}
[00:40:03]W: java.lang.AssertionError
[00:40:03]W:at
org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.allocatePage(PageMemoryImpl.java:463)
[00:40:03]W:at
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.allocateForTree(IgniteCacheOffheapManagerImpl.java:818)
[00:40:03]W:at
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.initPendingTree(IgniteCacheOffheapManagerImpl.java:164)
[00:40:03]W:at
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.onCacheStarted(IgniteCacheOffheapManagerImpl.java:151)
[00:40:03]W:at
org.apache.ignite.internal.processors.cache.CacheGroupContext.onCacheStarted(CacheGroupContext.java:283)
[00:40:03]W:at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheStart(GridCacheProcessor.java:1965)
[00:40:03]W:at
org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.onCacheChangeRequest(CacheAffinitySharedManager.java:791)
[00:40:03]W:at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onClusterStateChangeRequest(GridDhtPartitionsExchangeFuture.java:946)
[00:40:03]W:at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:651)
[00:40:03]W:at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body0(GridCachePartitionExchangeManager.java:2458)
[00:40:03]W:at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2338)
[00:40:03]W:at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
[00:40:03]W:at java.lang.Thread.run(Thread.java:748)
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-8682) Attempt to configure IGFS in persistent mode without specific data region ends with AssertionError
[
https://issues.apache.org/jira/browse/IGNITE-8682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Rakov updated IGNITE-8682:
---
Fix Version/s: 2.6
> Attempt to configure IGFS in persistent mode without specific data region
> ends with AssertionError
> --
>
> Key: IGNITE-8682
> URL: https://issues.apache.org/jira/browse/IGNITE-8682
> Project: Ignite
> Issue Type: Bug
>Reporter: Ivan Rakov
>Priority: Major
> Fix For: 2.6
>
>
> If persistence is enabled and data region name is not specified in IGFS
> configuration, attempt to access IGFS internal cache results in the following
> error:
> {noformat}
> [00:40:03]W:java.lang.AssertionError
> [00:40:03]W: at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.allocatePage(PageMemoryImpl.java:463)
> [00:40:03]W: at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.allocateForTree(IgniteCacheOffheapManagerImpl.java:818)
> [00:40:03]W: at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.initPendingTree(IgniteCacheOffheapManagerImpl.java:164)
> [00:40:03]W: at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.onCacheStarted(IgniteCacheOffheapManagerImpl.java:151)
> [00:40:03]W: at
> org.apache.ignite.internal.processors.cache.CacheGroupContext.onCacheStarted(CacheGroupContext.java:283)
> [00:40:03]W: at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheStart(GridCacheProcessor.java:1965)
> [00:40:03]W: at
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.onCacheChangeRequest(CacheAffinitySharedManager.java:791)
> [00:40:03]W: at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onClusterStateChangeRequest(GridDhtPartitionsExchangeFuture.java:946)
> [00:40:03]W: at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:651)
> [00:40:03]W: at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body0(GridCachePartitionExchangeManager.java:2458)
> [00:40:03]W: at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2338)
> [00:40:03]W: at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> [00:40:03]W: at java.lang.Thread.run(Thread.java:748)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-8682) Attempt to configure IGFS in persistent mode without specific data region ends with AssertionError
[
https://issues.apache.org/jira/browse/IGNITE-8682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Rakov updated IGNITE-8682:
---
Description:
If persistence is enabled and data region name is not specified in IGFS
configuration, attempt to access IGFS internal cache results in the following
error:
{noformat}
[00:40:03]W: java.lang.AssertionError
[00:40:03]W:at
org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.allocatePage(PageMemoryImpl.java:463)
[00:40:03]W:at
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.allocateForTree(IgniteCacheOffheapManagerImpl.java:818)
[00:40:03]W:at
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.initPendingTree(IgniteCacheOffheapManagerImpl.java:164)
[00:40:03]W:at
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.onCacheStarted(IgniteCacheOffheapManagerImpl.java:151)
[00:40:03]W:at
org.apache.ignite.internal.processors.cache.CacheGroupContext.onCacheStarted(CacheGroupContext.java:283)
[00:40:03]W:at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheStart(GridCacheProcessor.java:1965)
[00:40:03]W:at
org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.onCacheChangeRequest(CacheAffinitySharedManager.java:791)
[00:40:03]W:at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onClusterStateChangeRequest(GridDhtPartitionsExchangeFuture.java:946)
[00:40:03]W:at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:651)
[00:40:03]W:at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body0(GridCachePartitionExchangeManager.java:2458)
[00:40:03]W:at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2338)
[00:40:03]W:at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
[00:40:03]W:at java.lang.Thread.run(Thread.java:748)
{noformat}
was:
If persistence is enabled and data region name is not specified in IGFS
configuration, attempt to access IGFS internal cache results in the following
error:
{noformat}
[00:40:03]W: java.lang.AssertionError
[00:40:03]W:at
org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.allocatePage(PageMemoryImpl.java:463)
[00:40:03]W:at
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.allocateForTree(IgniteCacheOffheapManagerImpl.java:818)
[00:40:03]W:at
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.initPendingTree(IgniteCacheOffheapManagerImpl.java:164)
[00:40:03]W:at
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.onCacheStarted(IgniteCacheOffheapManagerImpl.java:151)
[00:40:03]W:at
org.apache.ignite.internal.processors.cache.CacheGroupContext.onCacheStarted(CacheGroupContext.java:283)
[00:40:03]W:at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheStart(GridCacheProcessor.java:1965)
[00:40:03]W:at
org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.onCacheChangeRequest(CacheAffinitySharedManager.java:791)
[00:40:03]W:at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onClusterStateChangeRequest(GridDhtPartitionsExchangeFuture.java:946)
[00:40:03]W:at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:651)
[00:40:03]W:at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body0(GridCachePartitionExchangeManager.java:2458)
[00:40:03]W:at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2338)
[00:40:03]W:at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
[00:40:03]W:at java.lang.Thread.run(Thread.java:748)
{noformat}
> Attempt to configure IGFS in persistent mode without specific data region
> ends with AssertionError
> --
>
> Key: IGNITE-86
[jira] [Commented] (IGNITE-8659) Wrong FreeList usage in PendingTree may lead to page corruption.
[ https://issues.apache.org/jira/browse/IGNITE-8659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16496929#comment-16496929 ] Ivan Rakov commented on IGNITE-8659: Thanks, merged to master. > Wrong FreeList usage in PendingTree may lead to page corruption. > > > Key: IGNITE-8659 > URL: https://issues.apache.org/jira/browse/IGNITE-8659 > Project: Ignite > Issue Type: Bug > Components: persistence >Reporter: Andrew Mashenkov >Assignee: Andrew Mashenkov >Priority: Critical > Fix For: 2.6 > > > Per-partition pending trees uses common index freelist. > This make possible partition data pages will be used by indices and lead to > errors as pages have different structures. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-8476) AssertionError exception occurs when trying to remove node from baseline under loading
[
https://issues.apache.org/jira/browse/IGNITE-8476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16495547#comment-16495547
]
Ivan Rakov edited comment on IGNITE-8476 at 5/30/18 6:43 PM:
-
[~agoncharuk],
1 and 2 - fixed.
Regarding 3: I've added test that reproduces your scenario and it expectedly
failed. I've created IGNITE-8652 and linked it with the failing test.
I'll merge my changes if you approve.
was (Author: ivan.glukos):
[~agoncharuk],
1 and 2 - fixed.
Regarding 3: I've added test that reproduces your scenario and it expectedly
fails. I've created IGNITE-8652 and linked it with failing test.
I'll merge my changes if you approve.
> AssertionError exception occurs when trying to remove node from baseline
> under loading
> --
>
> Key: IGNITE-8476
> URL: https://issues.apache.org/jira/browse/IGNITE-8476
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Dmitry Sherstobitov
>Assignee: Ivan Rakov
>Priority: Blocker
> Fix For: 2.6
>
>
> Run 6 nodes, start loading (8 threads, 1000 2x cache.get() and 2x cache.put()
> in each thread per second)
> Kill 2 nodes and try to remove one node from baseline using
> control.sh --baseline remove node1
> control.sh --baseline version TOPOLOGY_VERSION
>
> Utility hangs or connected client may hangs, this assertion appears in log
> For transactional cache:
> {code:java}
> [16:32:58,960][SEVERE][sys-stripe-14-#15][G] Failed to execute runnable.
> java.lang.AssertionError: localNode = be945692-c750-4d72-b9a1-9ac4170ff125,
> dhtNodes = [ZookeeperClusterNode [id=810226e6-656a-460d-8069-ca7d2dd294ef,
> addrs=[172.17.0.1, 0:0:0:0:0:0:0:1%lo, 172.25.1.28, 127.0.0.1], order=1,
> loc=false, client=false], ZookeeperClusterNode
> [id=be945692-c750-4d72-b9a1-9ac4170ff125, addrs=[172.17.0.1, 172.25.1.28,
> 0:0:0:0:0:0:0:1%lo, 127.0.0.1], order=3, loc=true, client=false],
> ZookeeperClusterNode [id=db4503f6-9185-4673-b38c-8890dfa69511,
> addrs=[172.17.0.1, 172.25.1.37, 0:0:0:0:0:0:0:1%lo, 127.0.0.1], order=5,
> loc=false, client=false], ZookeeperClusterNode
> [id=3b8d8d4f-3513-4d39-a1fd-7ec5b15fc653, addrs=[172.17.0.1, 172.25.1.37,
> 127.0.0.1, 0:0:0:0:0:0:0:1%lo], order=4, loc=false, client=false],
> ZookeeperClusterNode [id=2bfc8c2e-2f47-4126-9cc4-6f017ce7efde,
> addrs=[172.17.0.1, 172.25.1.37, 0:0:0:0:0:0:0:1%lo, 127.0.0.1], order=6,
> loc=false, client=false]]
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.map(GridDhtTxPrepareFuture.java:1520)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.prepare0(GridDhtTxPrepareFuture.java:1239)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.mapIfLocked(GridDhtTxPrepareFuture.java:671)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.prepare(GridDhtTxPrepareFuture.java:1048)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxLocal.prepareAsync(GridDhtTxLocal.java:397)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.prepareNearTx(IgniteTxHandler.java:516)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processNearTxPrepareRequest0(IgniteTxHandler.java:150)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processNearTxPrepareRequest(IgniteTxHandler.java:135)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.access$000(IgniteTxHandler.java:97)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$1.apply(IgniteTxHandler.java:177)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$1.apply(IgniteTxHandler.java:175)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1054)
> 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.i
[jira] [Commented] (IGNITE-8476) AssertionError exception occurs when trying to remove node from baseline under loading
[
https://issues.apache.org/jira/browse/IGNITE-8476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16495547#comment-16495547
]
Ivan Rakov commented on IGNITE-8476:
[~agoncharuk],
1 and 2 - fixed.
Regarding 3: I've added test that reproduces your scenario and it expectedly
fails. I've created IGNITE-8652 and linked it with failing test.
I'll merge my changes if you approve.
> AssertionError exception occurs when trying to remove node from baseline
> under loading
> --
>
> Key: IGNITE-8476
> URL: https://issues.apache.org/jira/browse/IGNITE-8476
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Dmitry Sherstobitov
>Assignee: Ivan Rakov
>Priority: Blocker
> Fix For: 2.6
>
>
> Run 6 nodes, start loading (8 threads, 1000 2x cache.get() and 2x cache.put()
> in each thread per second)
> Kill 2 nodes and try to remove one node from baseline using
> control.sh --baseline remove node1
> control.sh --baseline version TOPOLOGY_VERSION
>
> Utility hangs or connected client may hangs, this assertion appears in log
> For transactional cache:
> {code:java}
> [16:32:58,960][SEVERE][sys-stripe-14-#15][G] Failed to execute runnable.
> java.lang.AssertionError: localNode = be945692-c750-4d72-b9a1-9ac4170ff125,
> dhtNodes = [ZookeeperClusterNode [id=810226e6-656a-460d-8069-ca7d2dd294ef,
> addrs=[172.17.0.1, 0:0:0:0:0:0:0:1%lo, 172.25.1.28, 127.0.0.1], order=1,
> loc=false, client=false], ZookeeperClusterNode
> [id=be945692-c750-4d72-b9a1-9ac4170ff125, addrs=[172.17.0.1, 172.25.1.28,
> 0:0:0:0:0:0:0:1%lo, 127.0.0.1], order=3, loc=true, client=false],
> ZookeeperClusterNode [id=db4503f6-9185-4673-b38c-8890dfa69511,
> addrs=[172.17.0.1, 172.25.1.37, 0:0:0:0:0:0:0:1%lo, 127.0.0.1], order=5,
> loc=false, client=false], ZookeeperClusterNode
> [id=3b8d8d4f-3513-4d39-a1fd-7ec5b15fc653, addrs=[172.17.0.1, 172.25.1.37,
> 127.0.0.1, 0:0:0:0:0:0:0:1%lo], order=4, loc=false, client=false],
> ZookeeperClusterNode [id=2bfc8c2e-2f47-4126-9cc4-6f017ce7efde,
> addrs=[172.17.0.1, 172.25.1.37, 0:0:0:0:0:0:0:1%lo, 127.0.0.1], order=6,
> loc=false, client=false]]
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.map(GridDhtTxPrepareFuture.java:1520)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.prepare0(GridDhtTxPrepareFuture.java:1239)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.mapIfLocked(GridDhtTxPrepareFuture.java:671)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.prepare(GridDhtTxPrepareFuture.java:1048)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxLocal.prepareAsync(GridDhtTxLocal.java:397)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.prepareNearTx(IgniteTxHandler.java:516)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processNearTxPrepareRequest0(IgniteTxHandler.java:150)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processNearTxPrepareRequest(IgniteTxHandler.java:135)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.access$000(IgniteTxHandler.java:97)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$1.apply(IgniteTxHandler.java:177)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$1.apply(IgniteTxHandler.java:175)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1054)
> 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.Thre
[jira] [Updated] (IGNITE-8652) Cache dynamically started from client while there are no affinity server nodes will be forever considered in-memory
[
https://issues.apache.org/jira/browse/IGNITE-8652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Rakov updated IGNITE-8652:
---
Description:
We implemented stealing data storage configuration from affinity server node
during initialization of dynamic cache on client (IGNITE-8476). Though, if
there are no affinity nodes at the moment of cache start, client will consider
cache as in-memory even when affinity node will proper data storage
configuration (telling that it's actually persistent cache) will appear.
That means cache operations on client may fail with the same error:
{noformat}
java.lang.AssertionError: Wrong ready topology version for invalid partitions
response
{noformat}
Reproduced by
ClientAffinityAssignmentWithBaselineTest#testDynamicCacheStartNoAffinityNodes
should pass after the fix.
was:
We implemented stealing data storage configuration from affinity server node
during initialization of dynamic cache on client (IGNITE-8476). Though, if
there are no affinity nodes at the moment of cache start, client will consider
cache as in-memory even when affinity node will proper data storage
configuration (telling that it's actually persistent cache) will appear.
That means, cache operations on client may fail with the same error:
{noformat}
java.lang.AssertionError: Wrong ready topology version for invalid partitions
response
{noformat}
Reproduced by
ClientAffinityAssignmentWithBaselineTest#testDynamicCacheStartNoAffinityNodes
should pass after the fix.
> Cache dynamically started from client while there are no affinity server
> nodes will be forever considered in-memory
> ---
>
> Key: IGNITE-8652
> URL: https://issues.apache.org/jira/browse/IGNITE-8652
> Project: Ignite
> Issue Type: Bug
>Reporter: Ivan Rakov
>Priority: Major
> Labels: IEP-4, Phase-2
> Fix For: 2.6
>
>
> We implemented stealing data storage configuration from affinity server node
> during initialization of dynamic cache on client (IGNITE-8476). Though, if
> there are no affinity nodes at the moment of cache start, client will
> consider cache as in-memory even when affinity node will proper data storage
> configuration (telling that it's actually persistent cache) will appear.
> That means cache operations on client may fail with the same error:
> {noformat}
> java.lang.AssertionError: Wrong ready topology version for invalid partitions
> response
> {noformat}
> Reproduced by
> ClientAffinityAssignmentWithBaselineTest#testDynamicCacheStartNoAffinityNodes
> should pass after the fix.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-8652) Cache dynamically started from client while there are no affinity server nodes will be forever considered in-memory
[
https://issues.apache.org/jira/browse/IGNITE-8652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Rakov updated IGNITE-8652:
---
Description:
We implemented stealing data storage configuration from affinity server node
during initialization of dynamic cache on client (IGNITE-8476). Though, if
there are no affinity nodes at the moment of cache start, client will consider
cache as in-memory even when affinity node will proper data storage
configuration (telling that it's actually persistent cache) will appear.
That means cache operations on client may fail with the same error:
{noformat}
java.lang.AssertionError: Wrong ready topology version for invalid partitions
response
{noformat}
ClientAffinityAssignmentWithBaselineTest#testDynamicCacheStartNoAffinityNodes
should pass after the fix.
was:
We implemented stealing data storage configuration from affinity server node
during initialization of dynamic cache on client (IGNITE-8476). Though, if
there are no affinity nodes at the moment of cache start, client will consider
cache as in-memory even when affinity node will proper data storage
configuration (telling that it's actually persistent cache) will appear.
That means cache operations on client may fail with the same error:
{noformat}
java.lang.AssertionError: Wrong ready topology version for invalid partitions
response
{noformat}
Reproduced by
ClientAffinityAssignmentWithBaselineTest#testDynamicCacheStartNoAffinityNodes
should pass after the fix.
> Cache dynamically started from client while there are no affinity server
> nodes will be forever considered in-memory
> ---
>
> Key: IGNITE-8652
> URL: https://issues.apache.org/jira/browse/IGNITE-8652
> Project: Ignite
> Issue Type: Bug
>Reporter: Ivan Rakov
>Priority: Major
> Labels: IEP-4, Phase-2
> Fix For: 2.6
>
>
> We implemented stealing data storage configuration from affinity server node
> during initialization of dynamic cache on client (IGNITE-8476). Though, if
> there are no affinity nodes at the moment of cache start, client will
> consider cache as in-memory even when affinity node will proper data storage
> configuration (telling that it's actually persistent cache) will appear.
> That means cache operations on client may fail with the same error:
> {noformat}
> java.lang.AssertionError: Wrong ready topology version for invalid partitions
> response
> {noformat}
> ClientAffinityAssignmentWithBaselineTest#testDynamicCacheStartNoAffinityNodes
> should pass after the fix.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-8652) Cache dynamically started from client while there are no affinity server nodes will be forever considered in-memory
[
https://issues.apache.org/jira/browse/IGNITE-8652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Rakov updated IGNITE-8652:
---
Description:
We implemented stealing data storage configuration from affinity server node
during initialization of dynamic cache on client (IGNITE-8476). Though, if
there are no affinity nodes at the moment of cache start, client will consider
cache as in-memory even when affinity node will proper data storage
configuration (telling that it's actually persistent cache) will appear.
That means, cache operations on client may fail with the same error:
{noformat}
java.lang.AssertionError: Wrong ready topology version for invalid partitions
response
{noformat}
Reproduced by
ClientAffinityAssignmentWithBaselineTest#testDynamicCacheStartNoAffinityNodes
should pass after the fix.
was:
We implemented stealing data storage configuration from affinity server node
during initialization of dynamic cache on client (IGNITE-8476). Thought, if
there are no affinity nodes at the moment of cache start, client will consider
cache as in-memory even when affinity node will proper data storage
configuration (telling that it's actually persistent cache) will appear.
That means, cache operations on client may fail with the same error:
{noformat}
java.lang.AssertionError: Wrong ready topology version for invalid partitions
response
{noformat}
Reproduced by
ClientAffinityAssignmentWithBaselineTest#testDynamicCacheStartNoAffinityNodes
should pass after the fix.
> Cache dynamically started from client while there are no affinity server
> nodes will be forever considered in-memory
> ---
>
> Key: IGNITE-8652
> URL: https://issues.apache.org/jira/browse/IGNITE-8652
> Project: Ignite
> Issue Type: Bug
>Reporter: Ivan Rakov
>Priority: Major
> Labels: IEP-4, Phase-2
> Fix For: 2.6
>
>
> We implemented stealing data storage configuration from affinity server node
> during initialization of dynamic cache on client (IGNITE-8476). Though, if
> there are no affinity nodes at the moment of cache start, client will
> consider cache as in-memory even when affinity node will proper data storage
> configuration (telling that it's actually persistent cache) will appear.
> That means, cache operations on client may fail with the same error:
> {noformat}
> java.lang.AssertionError: Wrong ready topology version for invalid partitions
> response
> {noformat}
> Reproduced by
> ClientAffinityAssignmentWithBaselineTest#testDynamicCacheStartNoAffinityNodes
> should pass after the fix.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-8652) Cache dynamically started from client while there are no affinity server nodes will be forever considered in-memory
[
https://issues.apache.org/jira/browse/IGNITE-8652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Rakov updated IGNITE-8652:
---
Summary: Cache dynamically started from client while there are no affinity
server nodes will be forever considered in-memory (was: Cache dynamically
started from client while there are no affinity server nodes will be considered
in-memory forever)
> Cache dynamically started from client while there are no affinity server
> nodes will be forever considered in-memory
> ---
>
> Key: IGNITE-8652
> URL: https://issues.apache.org/jira/browse/IGNITE-8652
> Project: Ignite
> Issue Type: Bug
>Reporter: Ivan Rakov
>Priority: Major
> Labels: IEP-4, Phase-2
> Fix For: 2.6
>
>
> We implemented stealing data storage configuration from affinity server node
> during initialization of dynamic cache on client (IGNITE-8476). Thought, if
> there are no affinity nodes at the moment of cache start, client will
> consider cache as in-memory even when affinity node will proper data storage
> configuration (telling that it's actually persistent cache) will appear.
> That means, cache operations on client may fail with the same error:
> {noformat}
> java.lang.AssertionError: Wrong ready topology version for invalid partitions
> response
> {noformat}
> Reproduced by
> ClientAffinityAssignmentWithBaselineTest#testDynamicCacheStartNoAffinityNodes
> should pass after the fix.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-8652) Cache dynamically started from client while there are no affinity server nodes will be considered in-memory forever
[
https://issues.apache.org/jira/browse/IGNITE-8652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Rakov updated IGNITE-8652:
---
Summary: Cache dynamically started from client while there are no affinity
server nodes will be considered in-memory forever (was: Cache dynamically
started from client while there are no affinity server nodes will be considered
in-memory)
> Cache dynamically started from client while there are no affinity server
> nodes will be considered in-memory forever
> ---
>
> Key: IGNITE-8652
> URL: https://issues.apache.org/jira/browse/IGNITE-8652
> Project: Ignite
> Issue Type: Bug
>Reporter: Ivan Rakov
>Priority: Major
> Labels: IEP-4, Phase-2
> Fix For: 2.6
>
>
> We implemented stealing data storage configuration from affinity server node
> during initialization of dynamic cache on client (IGNITE-8476). Thought, if
> there are no affinity nodes at the moment of cache start, client will
> consider cache as in-memory even when affinity node will proper data storage
> configuration (telling that it's actually persistent cache) will appear.
> That means, cache operations on client may fail with the same error:
> {noformat}
> java.lang.AssertionError: Wrong ready topology version for invalid partitions
> response
> {noformat}
> Reproduced by
> ClientAffinityAssignmentWithBaselineTest#testDynamicCacheStartNoAffinityNodes
> should pass after the fix.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-8652) Cache dynamically started from client while there are no affinity server nodes will be considered in-memory
Ivan Rakov created IGNITE-8652:
--
Summary: Cache dynamically started from client while there are no
affinity server nodes will be considered in-memory
Key: IGNITE-8652
URL: https://issues.apache.org/jira/browse/IGNITE-8652
Project: Ignite
Issue Type: Bug
Reporter: Ivan Rakov
Fix For: 2.6
We implemented stealing data storage configuration from affinity server node
during initialization of dynamic cache on client (IGNITE-8476). Thought, if
there are no affinity nodes at the moment of cache start, client will consider
cache as in-memory even when affinity node will proper data storage
configuration (telling that it's actually persistent cache) will appear.
That means, cache operations on client may fail with the same error:
{noformat}
java.lang.AssertionError: Wrong ready topology version for invalid partitions
response
{noformat}
Reproduced by
ClientAffinityAssignmentWithBaselineTest#testDynamicCacheStartNoAffinityNodes
should pass after the fix.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-8524) Document consistency check utilities
[ https://issues.apache.org/jira/browse/IGNITE-8524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16495385#comment-16495385 ] Ivan Rakov edited comment on IGNITE-8524 at 5/30/18 4:24 PM: - [~dmagda], please check https://apacheignite-tools.readme.io/v2.5/docs/control-script. I've added description of list, seq and groups commands. I've also moved info about consistency check and contention detection commands. Please replace duplicate information in https://apacheignite.readme.io/docs/consistency-check-utilities page with links to the corresponding sections of "Control Script". I also discovered that there are still some undocumented options in ./control.sh script. There's ./control.sh --tx command that allows to view and manage active transactions (it can even kill hanging transaction). It has a lot of options which should be thoroughly documented. If we are going to expose this functionality to the wider community, please create a separate ticket for this activity. was (Author: ivan.glukos): [~dmagda], please check https://apacheignite-tools.readme.io/v2.5/docs/control-script. I've added description of list, seq and groups commands. I've also moved info about consistency check and contention detection commands. Please replace duplicate information in https://apacheignite.readme.io/docs/consistency-check-utilities page with links to the corresponding sections of "Control Script". I also discovered that there are still some undocumented options in ./control.sh script. There's ./control.sh --tx command allows to view and manage active transactions (it can even kill hanging transaction). It has a lot of options which should be thoroughly documented. If we are going to expose this functionality to the wider community, please create a separate ticket for this activity. > Document consistency check utilities > > > Key: IGNITE-8524 > URL: https://issues.apache.org/jira/browse/IGNITE-8524 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Denis Magda >Assignee: Ivan Rakov >Priority: Critical > Fix For: 2.5 > > > Ignite 2.5 will go with special consistency check utilities that, for > instance, ensure that the data stays consistent across backups, indexes are > correct and many other things. More details can be taken from here: > * https://issues.apache.org/jira/browse/IGNITE-8277 > * https://issues.apache.org/jira/browse/IGNITE-7467 > Here is an empty page that is created for the documentation: > https://apacheignite.readme.io/docs/consistency-check-utilities -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-8524) Document consistency check utilities
[ https://issues.apache.org/jira/browse/IGNITE-8524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16495385#comment-16495385 ] Ivan Rakov edited comment on IGNITE-8524 at 5/30/18 4:24 PM: - [~dmagda], please check https://apacheignite-tools.readme.io/v2.5/docs/control-script. I've added description of list, seq and groups commands. I've also moved info about consistency check and contention detection commands. Please replace duplicate information in https://apacheignite.readme.io/docs/consistency-check-utilities page with links to the corresponding sections of "Control Script". I also discovered that there are still some undocumented options in ./control.sh script. There's ./control.sh --tx command that allows to view and manage active transactions (it can even kill hanging transaction). It has a lot of options that should be thoroughly documented. If we are going to expose this functionality to the wider community, please create a separate ticket for this activity. was (Author: ivan.glukos): [~dmagda], please check https://apacheignite-tools.readme.io/v2.5/docs/control-script. I've added description of list, seq and groups commands. I've also moved info about consistency check and contention detection commands. Please replace duplicate information in https://apacheignite.readme.io/docs/consistency-check-utilities page with links to the corresponding sections of "Control Script". I also discovered that there are still some undocumented options in ./control.sh script. There's ./control.sh --tx command that allows to view and manage active transactions (it can even kill hanging transaction). It has a lot of options which should be thoroughly documented. If we are going to expose this functionality to the wider community, please create a separate ticket for this activity. > Document consistency check utilities > > > Key: IGNITE-8524 > URL: https://issues.apache.org/jira/browse/IGNITE-8524 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Denis Magda >Assignee: Ivan Rakov >Priority: Critical > Fix For: 2.5 > > > Ignite 2.5 will go with special consistency check utilities that, for > instance, ensure that the data stays consistent across backups, indexes are > correct and many other things. More details can be taken from here: > * https://issues.apache.org/jira/browse/IGNITE-8277 > * https://issues.apache.org/jira/browse/IGNITE-7467 > Here is an empty page that is created for the documentation: > https://apacheignite.readme.io/docs/consistency-check-utilities -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-8524) Document consistency check utilities
[ https://issues.apache.org/jira/browse/IGNITE-8524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16495385#comment-16495385 ] Ivan Rakov edited comment on IGNITE-8524 at 5/30/18 4:22 PM: - [~dmagda], please check https://apacheignite-tools.readme.io/v2.5/docs/control-script. I've added description of list, seq and groups commands. I've also moved info about consistency check and contention detection commands. Please replace duplicate information in https://apacheignite.readme.io/docs/consistency-check-utilities page with links to the corresponding sections of "Control Script". I also discovered that there are still some undocumented options in ./control.sh script. There's ./control.sh --tx command allows to view and manage active transactions (it can even kill hanging transaction). It has a lot of options which should be thoroughly documented. If we are going to expose this functionality to the wider community, please create a separate ticket for this activity. was (Author: ivan.glukos): [~dmagda], please check https://apacheignite-tools.readme.io/v2.5/docs/control-script. I've added description of list, seq and groups commands. I've also moved info about consistency check and contention detection commands. Please replace duplicate information in https://apacheignite.readme.io/docs/consistency-check-utilities page with links to the corresponding sections of "Control Script". I also discovered that there are still some undocumented options of ./control.sh. There's ./control.sh --tx command allows to view and manage active transactions (it can even kill hanging transaction). > Document consistency check utilities > > > Key: IGNITE-8524 > URL: https://issues.apache.org/jira/browse/IGNITE-8524 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Denis Magda >Assignee: Ivan Rakov >Priority: Critical > Fix For: 2.5 > > > Ignite 2.5 will go with special consistency check utilities that, for > instance, ensure that the data stays consistent across backups, indexes are > correct and many other things. More details can be taken from here: > * https://issues.apache.org/jira/browse/IGNITE-8277 > * https://issues.apache.org/jira/browse/IGNITE-7467 > Here is an empty page that is created for the documentation: > https://apacheignite.readme.io/docs/consistency-check-utilities -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-8524) Document consistency check utilities
[ https://issues.apache.org/jira/browse/IGNITE-8524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16495385#comment-16495385 ] Ivan Rakov edited comment on IGNITE-8524 at 5/30/18 4:20 PM: - [~dmagda], please check https://apacheignite-tools.readme.io/v2.5/docs/control-script. I've added description of list, seq and groups commands. I've also moved info about consistency check and contention detection commands. Please replace duplicate information in https://apacheignite.readme.io/docs/consistency-check-utilities page with links to the corresponding sections of "Control Script". I also discovered that there are still some undocumented options of ./control.sh. There's ./control.sh --tx command allows to view and manage active transactions (it can even kill hanging transaction). was (Author: ivan.glukos): [~dmagda], please check https://apacheignite-tools.readme.io/v2.5/docs/control-script. I've added description of list, seq and groups commands. I've also moved info about consistency check and contention detection commands. Please replace duplicate information in https://apacheignite.readme.io/docs/consistency-check-utilities page with links to the corresponding sections of "Control Script". I also discovered that there are still some undocumented optoins of ./control.sh. There's ./control.sh --tx command allows to view and manage active transactions (it can even kill hanging transaction). > Document consistency check utilities > > > Key: IGNITE-8524 > URL: https://issues.apache.org/jira/browse/IGNITE-8524 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Denis Magda >Assignee: Ivan Rakov >Priority: Critical > Fix For: 2.5 > > > Ignite 2.5 will go with special consistency check utilities that, for > instance, ensure that the data stays consistent across backups, indexes are > correct and many other things. More details can be taken from here: > * https://issues.apache.org/jira/browse/IGNITE-8277 > * https://issues.apache.org/jira/browse/IGNITE-7467 > Here is an empty page that is created for the documentation: > https://apacheignite.readme.io/docs/consistency-check-utilities -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-8524) Document consistency check utilities
[ https://issues.apache.org/jira/browse/IGNITE-8524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16495385#comment-16495385 ] Ivan Rakov edited comment on IGNITE-8524 at 5/30/18 4:19 PM: - [~dmagda], please check https://apacheignite-tools.readme.io/v2.5/docs/control-script. I've added description of list, seq and groups commands. I've also moved info about consistency check and contention detection commands. Please replace duplicate information in https://apacheignite.readme.io/docs/consistency-check-utilities page with links to the corresponding sections of "Control Script". I also discovered that there are still some undocumented optoins of ./control.sh. There's ./control.sh --tx command allows to view and manage active transactions (it can even kill hanging transaction). was (Author: ivan.glukos): [~dmagda], please check https://apacheignite-tools.readme.io/v2.5/docs/control-script. I've added description of list, seq and groups commands. I've also moved info about consistency check and contention detection commands. Please replace duplicate information in https://apacheignite.readme.io/docs/consistency-check-utilities page by links to the sections of "Control Script". I also discovered that there are still some undocumented optoins of ./control.sh. There's ./control.sh --tx command allows to view and manage active transactions (it can even kill hanging transaction). > Document consistency check utilities > > > Key: IGNITE-8524 > URL: https://issues.apache.org/jira/browse/IGNITE-8524 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Denis Magda >Assignee: Ivan Rakov >Priority: Critical > Fix For: 2.5 > > > Ignite 2.5 will go with special consistency check utilities that, for > instance, ensure that the data stays consistent across backups, indexes are > correct and many other things. More details can be taken from here: > * https://issues.apache.org/jira/browse/IGNITE-8277 > * https://issues.apache.org/jira/browse/IGNITE-7467 > Here is an empty page that is created for the documentation: > https://apacheignite.readme.io/docs/consistency-check-utilities -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8524) Document consistency check utilities
[ https://issues.apache.org/jira/browse/IGNITE-8524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16495385#comment-16495385 ] Ivan Rakov commented on IGNITE-8524: [~dmagda], please check https://apacheignite-tools.readme.io/v2.5/docs/control-script. I've added description of list, seq and groups commands. I've also moved info about consistency check and contention detection commands. Please replace duplicate information in https://apacheignite.readme.io/docs/consistency-check-utilities page by links to the sections of "Control Script". I also discovered that there are still some undocumented optoins of ./control.sh. There's ./control.sh --tx command allows to view and manage active transactions (it can even kill hanging transaction). > Document consistency check utilities > > > Key: IGNITE-8524 > URL: https://issues.apache.org/jira/browse/IGNITE-8524 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Denis Magda >Assignee: Ivan Rakov >Priority: Critical > Fix For: 2.5 > > > Ignite 2.5 will go with special consistency check utilities that, for > instance, ensure that the data stays consistent across backups, indexes are > correct and many other things. More details can be taken from here: > * https://issues.apache.org/jira/browse/IGNITE-8277 > * https://issues.apache.org/jira/browse/IGNITE-7467 > Here is an empty page that is created for the documentation: > https://apacheignite.readme.io/docs/consistency-check-utilities -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8646) Setting different MAC addresses to nodes in test environment causes mass test fail
Ivan Rakov created IGNITE-8646: -- Summary: Setting different MAC addresses to nodes in test environment causes mass test fail Key: IGNITE-8646 URL: https://issues.apache.org/jira/browse/IGNITE-8646 Project: Ignite Issue Type: Bug Reporter: Ivan Rakov Fix For: 2.6 There are some parts of logic in Ignite that check whether two nodes are actually hosted on the same physical machine (e.g. excludeNeighbors flag in affinity function, load balancing for replicated cache, etc) and choose the appropriate behavior. These part can be tracked by usages of IgniteNodeAttributes#ATTR_MACS attribute. I've tried to emulate distributed environment in tests by overriding ATTR_MACS with random UUID. This caused mass consistency failures in basic and Full API tests. We should investigate this: probably, many bugs are hidden by the fact that nodes are always started on the same physical machine in our TeamCity tests. PR with macs override: https://github.com/apache/ignite/pull/4084 TC run: https://ci.ignite.apache.org/viewLog.html?buildId=1342076&tab=buildResultsDiv&buildTypeId=IgniteTests24Java8_RunAll -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8646) Setting different MAC addresses to nodes in test environment causes mass test fail
[ https://issues.apache.org/jira/browse/IGNITE-8646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Rakov updated IGNITE-8646: --- Affects Version/s: 2.5 > Setting different MAC addresses to nodes in test environment causes mass test > fail > -- > > Key: IGNITE-8646 > URL: https://issues.apache.org/jira/browse/IGNITE-8646 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.5 >Reporter: Ivan Rakov >Priority: Major > Fix For: 2.6 > > > There are some parts of logic in Ignite that check whether two nodes are > actually hosted on the same physical machine (e.g. excludeNeighbors flag in > affinity function, load balancing for replicated cache, etc) and choose the > appropriate behavior. These part can be tracked by usages of > IgniteNodeAttributes#ATTR_MACS attribute. > I've tried to emulate distributed environment in tests by overriding > ATTR_MACS with random UUID. This caused mass consistency failures in basic > and Full API tests. We should investigate this: probably, many bugs are > hidden by the fact that nodes are always started on the same physical machine > in our TeamCity tests. > PR with macs override: https://github.com/apache/ignite/pull/4084 > TC run: > https://ci.ignite.apache.org/viewLog.html?buildId=1342076&tab=buildResultsDiv&buildTypeId=IgniteTests24Java8_RunAll -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8476) AssertionError exception occurs when trying to remove node from baseline under loading
[
https://issues.apache.org/jira/browse/IGNITE-8476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Rakov updated IGNITE-8476:
---
Fix Version/s: 2.6
> AssertionError exception occurs when trying to remove node from baseline
> under loading
> --
>
> Key: IGNITE-8476
> URL: https://issues.apache.org/jira/browse/IGNITE-8476
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Dmitry Sherstobitov
>Assignee: Ivan Rakov
>Priority: Blocker
> Fix For: 2.6
>
>
> Run 6 nodes, start loading (8 threads, 1000 2x cache.get() and 2x cache.put()
> in each thread per second)
> Kill 2 nodes and try to remove one node from baseline using
> control.sh --baseline remove node1
> control.sh --baseline version TOPOLOGY_VERSION
>
> Utility hangs or connected client may hangs, this assertion appears in log
> For transactional cache:
> {code:java}
> [16:32:58,960][SEVERE][sys-stripe-14-#15][G] Failed to execute runnable.
> java.lang.AssertionError: localNode = be945692-c750-4d72-b9a1-9ac4170ff125,
> dhtNodes = [ZookeeperClusterNode [id=810226e6-656a-460d-8069-ca7d2dd294ef,
> addrs=[172.17.0.1, 0:0:0:0:0:0:0:1%lo, 172.25.1.28, 127.0.0.1], order=1,
> loc=false, client=false], ZookeeperClusterNode
> [id=be945692-c750-4d72-b9a1-9ac4170ff125, addrs=[172.17.0.1, 172.25.1.28,
> 0:0:0:0:0:0:0:1%lo, 127.0.0.1], order=3, loc=true, client=false],
> ZookeeperClusterNode [id=db4503f6-9185-4673-b38c-8890dfa69511,
> addrs=[172.17.0.1, 172.25.1.37, 0:0:0:0:0:0:0:1%lo, 127.0.0.1], order=5,
> loc=false, client=false], ZookeeperClusterNode
> [id=3b8d8d4f-3513-4d39-a1fd-7ec5b15fc653, addrs=[172.17.0.1, 172.25.1.37,
> 127.0.0.1, 0:0:0:0:0:0:0:1%lo], order=4, loc=false, client=false],
> ZookeeperClusterNode [id=2bfc8c2e-2f47-4126-9cc4-6f017ce7efde,
> addrs=[172.17.0.1, 172.25.1.37, 0:0:0:0:0:0:0:1%lo, 127.0.0.1], order=6,
> loc=false, client=false]]
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.map(GridDhtTxPrepareFuture.java:1520)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.prepare0(GridDhtTxPrepareFuture.java:1239)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.mapIfLocked(GridDhtTxPrepareFuture.java:671)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.prepare(GridDhtTxPrepareFuture.java:1048)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxLocal.prepareAsync(GridDhtTxLocal.java:397)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.prepareNearTx(IgniteTxHandler.java:516)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processNearTxPrepareRequest0(IgniteTxHandler.java:150)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processNearTxPrepareRequest(IgniteTxHandler.java:135)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.access$000(IgniteTxHandler.java:97)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$1.apply(IgniteTxHandler.java:177)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$1.apply(IgniteTxHandler.java:175)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1054)
> 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:748){code}
> For atomic cache:
> {code:java}
> [18:40:12,858][SEVERE][sys-stripe-10-#11][GridCacheIoManager] Failed to
> process message [senderId=9fde40b1-3b21-49de-b1ad-cdd0d9d902e5,
> messageType=class
> o.a.i.i.processors.
[jira] [Comment Edited] (IGNITE-8476) AssertionError exception occurs when trying to remove node from baseline under loading
[
https://issues.apache.org/jira/browse/IGNITE-8476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16494955#comment-16494955
]
Ivan Rakov edited comment on IGNITE-8476 at 5/30/18 9:57 AM:
-
[~agoncharuk], please review the following PR:
https://github.com/apache/ignite/pull/4085
It's fix without MAC address override for all tests.
TC run:
https://ci.ignite.apache.org/viewLog.html?buildId=1343348&tab=buildResultsDiv&buildTypeId=IgniteTests24Java8_RunAll
was (Author: ivan.glukos):
[~agoncharuk], please review the following PR:
https://github.com/apache/ignite/pull/4085
It's fix without MAC adress override for all tests.
TC run:
https://ci.ignite.apache.org/viewLog.html?buildId=1343348&tab=buildResultsDiv&buildTypeId=IgniteTests24Java8_RunAll
> AssertionError exception occurs when trying to remove node from baseline
> under loading
> --
>
> Key: IGNITE-8476
> URL: https://issues.apache.org/jira/browse/IGNITE-8476
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Dmitry Sherstobitov
>Assignee: Ivan Rakov
>Priority: Blocker
> Fix For: 2.6
>
>
> Run 6 nodes, start loading (8 threads, 1000 2x cache.get() and 2x cache.put()
> in each thread per second)
> Kill 2 nodes and try to remove one node from baseline using
> control.sh --baseline remove node1
> control.sh --baseline version TOPOLOGY_VERSION
>
> Utility hangs or connected client may hangs, this assertion appears in log
> For transactional cache:
> {code:java}
> [16:32:58,960][SEVERE][sys-stripe-14-#15][G] Failed to execute runnable.
> java.lang.AssertionError: localNode = be945692-c750-4d72-b9a1-9ac4170ff125,
> dhtNodes = [ZookeeperClusterNode [id=810226e6-656a-460d-8069-ca7d2dd294ef,
> addrs=[172.17.0.1, 0:0:0:0:0:0:0:1%lo, 172.25.1.28, 127.0.0.1], order=1,
> loc=false, client=false], ZookeeperClusterNode
> [id=be945692-c750-4d72-b9a1-9ac4170ff125, addrs=[172.17.0.1, 172.25.1.28,
> 0:0:0:0:0:0:0:1%lo, 127.0.0.1], order=3, loc=true, client=false],
> ZookeeperClusterNode [id=db4503f6-9185-4673-b38c-8890dfa69511,
> addrs=[172.17.0.1, 172.25.1.37, 0:0:0:0:0:0:0:1%lo, 127.0.0.1], order=5,
> loc=false, client=false], ZookeeperClusterNode
> [id=3b8d8d4f-3513-4d39-a1fd-7ec5b15fc653, addrs=[172.17.0.1, 172.25.1.37,
> 127.0.0.1, 0:0:0:0:0:0:0:1%lo], order=4, loc=false, client=false],
> ZookeeperClusterNode [id=2bfc8c2e-2f47-4126-9cc4-6f017ce7efde,
> addrs=[172.17.0.1, 172.25.1.37, 0:0:0:0:0:0:0:1%lo, 127.0.0.1], order=6,
> loc=false, client=false]]
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.map(GridDhtTxPrepareFuture.java:1520)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.prepare0(GridDhtTxPrepareFuture.java:1239)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.mapIfLocked(GridDhtTxPrepareFuture.java:671)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.prepare(GridDhtTxPrepareFuture.java:1048)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxLocal.prepareAsync(GridDhtTxLocal.java:397)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.prepareNearTx(IgniteTxHandler.java:516)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processNearTxPrepareRequest0(IgniteTxHandler.java:150)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processNearTxPrepareRequest(IgniteTxHandler.java:135)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.access$000(IgniteTxHandler.java:97)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$1.apply(IgniteTxHandler.java:177)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$1.apply(IgniteTxHandler.java:175)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1054)
> 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.manage
[jira] [Commented] (IGNITE-8476) AssertionError exception occurs when trying to remove node from baseline under loading
[
https://issues.apache.org/jira/browse/IGNITE-8476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16494955#comment-16494955
]
Ivan Rakov commented on IGNITE-8476:
[~agoncharuk], please review the following PR:
https://github.com/apache/ignite/pull/4085
It's fix without MAC adress override for all tests.
TC run:
https://ci.ignite.apache.org/viewLog.html?buildId=1343348&tab=buildResultsDiv&buildTypeId=IgniteTests24Java8_RunAll
> AssertionError exception occurs when trying to remove node from baseline
> under loading
> --
>
> Key: IGNITE-8476
> URL: https://issues.apache.org/jira/browse/IGNITE-8476
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Dmitry Sherstobitov
>Assignee: Ivan Rakov
>Priority: Blocker
> Fix For: 2.6
>
>
> Run 6 nodes, start loading (8 threads, 1000 2x cache.get() and 2x cache.put()
> in each thread per second)
> Kill 2 nodes and try to remove one node from baseline using
> control.sh --baseline remove node1
> control.sh --baseline version TOPOLOGY_VERSION
>
> Utility hangs or connected client may hangs, this assertion appears in log
> For transactional cache:
> {code:java}
> [16:32:58,960][SEVERE][sys-stripe-14-#15][G] Failed to execute runnable.
> java.lang.AssertionError: localNode = be945692-c750-4d72-b9a1-9ac4170ff125,
> dhtNodes = [ZookeeperClusterNode [id=810226e6-656a-460d-8069-ca7d2dd294ef,
> addrs=[172.17.0.1, 0:0:0:0:0:0:0:1%lo, 172.25.1.28, 127.0.0.1], order=1,
> loc=false, client=false], ZookeeperClusterNode
> [id=be945692-c750-4d72-b9a1-9ac4170ff125, addrs=[172.17.0.1, 172.25.1.28,
> 0:0:0:0:0:0:0:1%lo, 127.0.0.1], order=3, loc=true, client=false],
> ZookeeperClusterNode [id=db4503f6-9185-4673-b38c-8890dfa69511,
> addrs=[172.17.0.1, 172.25.1.37, 0:0:0:0:0:0:0:1%lo, 127.0.0.1], order=5,
> loc=false, client=false], ZookeeperClusterNode
> [id=3b8d8d4f-3513-4d39-a1fd-7ec5b15fc653, addrs=[172.17.0.1, 172.25.1.37,
> 127.0.0.1, 0:0:0:0:0:0:0:1%lo], order=4, loc=false, client=false],
> ZookeeperClusterNode [id=2bfc8c2e-2f47-4126-9cc4-6f017ce7efde,
> addrs=[172.17.0.1, 172.25.1.37, 0:0:0:0:0:0:0:1%lo, 127.0.0.1], order=6,
> loc=false, client=false]]
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.map(GridDhtTxPrepareFuture.java:1520)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.prepare0(GridDhtTxPrepareFuture.java:1239)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.mapIfLocked(GridDhtTxPrepareFuture.java:671)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.prepare(GridDhtTxPrepareFuture.java:1048)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxLocal.prepareAsync(GridDhtTxLocal.java:397)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.prepareNearTx(IgniteTxHandler.java:516)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processNearTxPrepareRequest0(IgniteTxHandler.java:150)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processNearTxPrepareRequest(IgniteTxHandler.java:135)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.access$000(IgniteTxHandler.java:97)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$1.apply(IgniteTxHandler.java:177)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$1.apply(IgniteTxHandler.java:175)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1054)
> 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$S
[jira] [Commented] (IGNITE-8603) Add JMX-metric to cluster: baseline nodes
[
https://issues.apache.org/jira/browse/IGNITE-8603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16494019#comment-16494019
]
Ivan Rakov commented on IGNITE-8603:
[~dgladkikh], some comments:
1. Code style
1.1. #getTotalBaselineNodes and #getActiveBaselineNodes in
ClusterLocalNodeMetricsMXBeanImpl class lack {@inheritDoc}
1.2. Semantic units of #getTotalBaselineNodes body should be separated by blank
lines - check "Whitespaces and empty lines" section of
https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines
1.3. One-liner in #getTotalBaselineNodes body shouldn't be enclosed in curly
braces, see "Braces and Identation" section
1.4. Points 1.2 and 1.3 relate to ClusterMetricsMXBeanImpl as well
2. I think, it would be good to add test case when non-baseline server node is
present in the cluster
3. ClusterBaselineNodesMetricsSelfTest is not included in any test suite
4. Please schedule Run All on public TeamCity and attach link here
> Add JMX-metric to cluster: baseline nodes
> -
>
> Key: IGNITE-8603
> URL: https://issues.apache.org/jira/browse/IGNITE-8603
> Project: Ignite
> Issue Type: Improvement
>Reporter: Dmitriy Gladkikh
>Assignee: Dmitriy Gladkikh
>Priority: Major
> Fix For: 2.6
>
>
> Need to add a baseline nodes on JMX:
> {code:java}
> int org.apache.ignite.mxbean.ClusterMetricsMXBean#getTotalBaselineNodes
> int org.apache.ignite.mxbean.ClusterMetricsMXBean#getActiveBaselineNodes
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8524) Document consistency check utilities
[ https://issues.apache.org/jira/browse/IGNITE-8524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16492750#comment-16492750 ] Ivan Rakov commented on IGNITE-8524: [~dmagda], thanks, I have the access now. > Document consistency check utilities > > > Key: IGNITE-8524 > URL: https://issues.apache.org/jira/browse/IGNITE-8524 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Denis Magda >Assignee: Ivan Rakov >Priority: Critical > Fix For: 2.5 > > > Ignite 2.5 will go with special consistency check utilities that, for > instance, ensure that the data stays consistent across backups, indexes are > correct and many other things. More details can be taken from here: > * https://issues.apache.org/jira/browse/IGNITE-8277 > * https://issues.apache.org/jira/browse/IGNITE-7467 > Here is an empty page that is created for the documentation: > https://apacheignite.readme.io/docs/consistency-check-utilities -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8625) Dynamic SQL index recreate after cache clear may result in AssertionError or JVM crash
[ https://issues.apache.org/jira/browse/IGNITE-8625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Rakov updated IGNITE-8625: --- Description: After recreation of previously dropped SQL index (in persistent mode), root page of new index B+ tree may contain links to data entries from previous index tree. If these entries were removed or relocated to another data page, attempt to dereference these links may throw AssertionError or even cause JVM crash. Patch with reproducer is attached. P.S. Please note that with IGNITE-4958 fix old invalid links may refer to non-data page - it might have been recycled into page with any other type. Such case will cause AssertionError on page read lock attempt. Rolling back IGNITE-4958 may help with debugging. was: After recreation of previously dropped SQL index (in persistent mode), root page of new index B+ tree may contain links to data entries from previous index tree. If these entries were removed or relocated to another data page, attempt to dereference these links may throw AssertionError or even cause JVM crash. Patch with reproducer is attached. Please note that with IGNITE-4958 fix old invalid links may refer to non-data page - it might have been recycled into page with any other type. Such case will cause AssertionError on page read lock attempt. Rolling back of IGNITE-4958 may help with debugging. > Dynamic SQL index recreate after cache clear may result in AssertionError or > JVM crash > -- > > Key: IGNITE-8625 > URL: https://issues.apache.org/jira/browse/IGNITE-8625 > Project: Ignite > Issue Type: Bug > Components: persistence, sql >Reporter: Ivan Rakov >Assignee: Alexey Stelmak >Priority: Critical > Fix For: 2.6 > > Attachments: dyn_idx_reproducer.patch > > > After recreation of previously dropped SQL index (in persistent mode), root > page of new index B+ tree may contain links to data entries from previous > index tree. If these entries were removed or relocated to another data page, > attempt to dereference these links may throw AssertionError or even cause JVM > crash. > Patch with reproducer is attached. > P.S. Please note that with IGNITE-4958 fix old invalid links may refer to > non-data page - it might have been recycled into page with any other type. > Such case will cause AssertionError on page read lock attempt. Rolling back > IGNITE-4958 may help with debugging. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8625) Dynamic SQL index recreate after cache clear may result in AssertionError or JVM crash
[ https://issues.apache.org/jira/browse/IGNITE-8625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Rakov updated IGNITE-8625: --- Description: After recreation of previously dropped SQL index (in persistent mode), root page of new index B+ tree may contain links to data entries from previous index tree. If these entries were removed or relocated to another data page, attempt to dereference these links may throw AssertionError or even cause JVM crash. Patch with reproducer is attached. Please note that with IGNITE-4958 fix old invalid links may refer to non-data page - it might have been recycled into page with any other type. Such case will cause AssertionError on page read lock attempt. Rolling back of IGNITE-4958 may help with debugging. was: After recreation of previously dropped SQL index (in persistent mode), root page of new index B+ tree may contain links to data entries from previous index tree. If these entries were removed or relocated to another data page, attempt to dereference these links may throw AssertionError or even cause JVM crash. Patch with reproducer is attached. Please note that with IGNITE-4958 fix old invalid links may refer to non-data page - it may have been recycled into page with any other type. Such case will cause AssertionError on page read lock attempt. Rolling back of IGNITE-4958 may help with debugging. > Dynamic SQL index recreate after cache clear may result in AssertionError or > JVM crash > -- > > Key: IGNITE-8625 > URL: https://issues.apache.org/jira/browse/IGNITE-8625 > Project: Ignite > Issue Type: Bug > Components: persistence, sql >Reporter: Ivan Rakov >Assignee: Alexey Stelmak >Priority: Critical > Fix For: 2.6 > > Attachments: dyn_idx_reproducer.patch > > > After recreation of previously dropped SQL index (in persistent mode), root > page of new index B+ tree may contain links to data entries from previous > index tree. If these entries were removed or relocated to another data page, > attempt to dereference these links may throw AssertionError or even cause JVM > crash. > Patch with reproducer is attached. > Please note that with IGNITE-4958 fix old invalid links may refer to non-data > page - it might have been recycled into page with any other type. Such case > will cause AssertionError on page read lock attempt. Rolling back of > IGNITE-4958 may help with debugging. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8625) Dynamic SQL index recreate after cache clear may result in AssertionError or JVM crash
[ https://issues.apache.org/jira/browse/IGNITE-8625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Rakov updated IGNITE-8625: --- Description: After recreation of previously dropped SQL index (in persistent mode), root page of new index B+ tree may contain links to data entries from previous index tree. If these entries were removed or relocated to another data page, attempt to dereference these links may throw AssertionError or even cause JVM crash. Patch with reproducer is attached. Please note that with IGNITE-4958 fix old invalid links may refer to non-data page - it may have been recycled into page with any other type. Such case will cause AssertionError on page read lock attempt. Rolling back of IGNITE-4958 may help with debugging. was: After recreation of previously dropped SQL index (in persistent mode), root page of new index B+ tree may contain links to data entries from previous index tree. If these entries were removed or relocated to another data page, attempt to dereference these links may throw AssertionError or even cause JVM crash. Patch with reproducer is attached. > Dynamic SQL index recreate after cache clear may result in AssertionError or > JVM crash > -- > > Key: IGNITE-8625 > URL: https://issues.apache.org/jira/browse/IGNITE-8625 > Project: Ignite > Issue Type: Bug > Components: persistence, sql >Reporter: Ivan Rakov >Assignee: Alexey Stelmak >Priority: Critical > Fix For: 2.6 > > Attachments: dyn_idx_reproducer.patch > > > After recreation of previously dropped SQL index (in persistent mode), root > page of new index B+ tree may contain links to data entries from previous > index tree. If these entries were removed or relocated to another data page, > attempt to dereference these links may throw AssertionError or even cause JVM > crash. > Patch with reproducer is attached. > Please note that with IGNITE-4958 fix old invalid links may refer to non-data > page - it may have been recycled into page with any other type. Such case > will cause AssertionError on page read lock attempt. Rolling back of > IGNITE-4958 may help with debugging. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-8625) Dynamic SQL index recreate after cache clear may result in AssertionError or JVM crash
[ https://issues.apache.org/jira/browse/IGNITE-8625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Rakov reassigned IGNITE-8625: -- Assignee: Alexey Stelmak > Dynamic SQL index recreate after cache clear may result in AssertionError or > JVM crash > -- > > Key: IGNITE-8625 > URL: https://issues.apache.org/jira/browse/IGNITE-8625 > Project: Ignite > Issue Type: Bug > Components: persistence, sql >Reporter: Ivan Rakov >Assignee: Alexey Stelmak >Priority: Critical > Fix For: 2.6 > > Attachments: dyn_idx_reproducer.patch > > > After recreation of previously dropped SQL index (in persistent mode), root > page of new index B+ tree may contain links to data entries from previous > index tree. If these entries were removed or relocated to another data page, > attempt to dereference these links may throw AssertionError or even cause JVM > crash. > Patch with reproducer is attached. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8625) Dynamic SQL index recreate after cache clear may result in AssertionError or JVM crash
[ https://issues.apache.org/jira/browse/IGNITE-8625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Rakov updated IGNITE-8625: --- Component/s: sql persistence > Dynamic SQL index recreate after cache clear may result in AssertionError or > JVM crash > -- > > Key: IGNITE-8625 > URL: https://issues.apache.org/jira/browse/IGNITE-8625 > Project: Ignite > Issue Type: Bug > Components: persistence, sql >Reporter: Ivan Rakov >Assignee: Alexey Stelmak >Priority: Critical > Fix For: 2.6 > > Attachments: dyn_idx_reproducer.patch > > > After recreation of previously dropped SQL index (in persistent mode), root > page of new index B+ tree may contain links to data entries from previous > index tree. If these entries were removed or relocated to another data page, > attempt to dereference these links may throw AssertionError or even cause JVM > crash. > Patch with reproducer is attached. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8625) Dynamic SQL index recreate after cache clear may result in AssertionError or JVM crash
[ https://issues.apache.org/jira/browse/IGNITE-8625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Rakov updated IGNITE-8625: --- Description: After recreation of previously dropped SQL index (in persistent mode), root page of new index B+ tree may contain links to data entries from previous index tree. If there entries were removed or relocated to another data page, attempt to dereference these links may throw AssertionError or even cause JVM crash. Patch with reproducer is attached. was: After recreation of previously dropped SQL index (in persistent mode), root page of new index B+ tree may contain links to data entries from previous index tree. If they were removed or relocated to another data page, attempt to dereference these links may throw AssertionError or even cause JVM crash. Patch with reproducer is attached. > Dynamic SQL index recreate after cache clear may result in AssertionError or > JVM crash > -- > > Key: IGNITE-8625 > URL: https://issues.apache.org/jira/browse/IGNITE-8625 > Project: Ignite > Issue Type: Bug >Reporter: Ivan Rakov >Priority: Major > Fix For: 2.6 > > Attachments: dyn_idx_reproducer.patch > > > After recreation of previously dropped SQL index (in persistent mode), root > page of new index B+ tree may contain links to data entries from previous > index tree. If there entries were removed or relocated to another data page, > attempt to dereference these links may throw AssertionError or even cause JVM > crash. > Patch with reproducer is attached. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8625) Dynamic SQL index recreate after cache clear may result in AssertionError or JVM crash
[ https://issues.apache.org/jira/browse/IGNITE-8625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Rakov updated IGNITE-8625: --- Priority: Critical (was: Major) > Dynamic SQL index recreate after cache clear may result in AssertionError or > JVM crash > -- > > Key: IGNITE-8625 > URL: https://issues.apache.org/jira/browse/IGNITE-8625 > Project: Ignite > Issue Type: Bug >Reporter: Ivan Rakov >Priority: Critical > Fix For: 2.6 > > Attachments: dyn_idx_reproducer.patch > > > After recreation of previously dropped SQL index (in persistent mode), root > page of new index B+ tree may contain links to data entries from previous > index tree. If these entries were removed or relocated to another data page, > attempt to dereference these links may throw AssertionError or even cause JVM > crash. > Patch with reproducer is attached. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8625) Dynamic SQL index recreate after cache clear may result in AssertionError or JVM crash
[ https://issues.apache.org/jira/browse/IGNITE-8625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Rakov updated IGNITE-8625: --- Description: After recreation of previously dropped SQL index (in persistent mode), root page of new index B+ tree may contain links to data entries from previous index tree. If these entries were removed or relocated to another data page, attempt to dereference these links may throw AssertionError or even cause JVM crash. Patch with reproducer is attached. was: After recreation of previously dropped SQL index (in persistent mode), root page of new index B+ tree may contain links to data entries from previous index tree. If there entries were removed or relocated to another data page, attempt to dereference these links may throw AssertionError or even cause JVM crash. Patch with reproducer is attached. > Dynamic SQL index recreate after cache clear may result in AssertionError or > JVM crash > -- > > Key: IGNITE-8625 > URL: https://issues.apache.org/jira/browse/IGNITE-8625 > Project: Ignite > Issue Type: Bug >Reporter: Ivan Rakov >Priority: Major > Fix For: 2.6 > > Attachments: dyn_idx_reproducer.patch > > > After recreation of previously dropped SQL index (in persistent mode), root > page of new index B+ tree may contain links to data entries from previous > index tree. If these entries were removed or relocated to another data page, > attempt to dereference these links may throw AssertionError or even cause JVM > crash. > Patch with reproducer is attached. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8625) Dynamic SQL index recreate after cache clear may result in AssertionError or JVM crash
[ https://issues.apache.org/jira/browse/IGNITE-8625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Rakov updated IGNITE-8625: --- Description: After recreation of previously dropped SQL index (in persistent mode), root page of new index B+ tree may contain links to data entries from previous index tree. If they were removed or relocated to another data page, attempt to dereference these links may throw AssertionError or even cause JVM crash. Patch with reproducer is attached. was: After recreation of previously dropped SQL index, root page of new index B+ tree may contain links to data entries from previous index tree. If they were removed or relocated to another data page, attempt to dereference these links may throw AssertionError or even cause JVM crash. Patch with reproducer is attached. > Dynamic SQL index recreate after cache clear may result in AssertionError or > JVM crash > -- > > Key: IGNITE-8625 > URL: https://issues.apache.org/jira/browse/IGNITE-8625 > Project: Ignite > Issue Type: Bug >Reporter: Ivan Rakov >Priority: Major > Fix For: 2.6 > > Attachments: dyn_idx_reproducer.patch > > > After recreation of previously dropped SQL index (in persistent mode), root > page of new index B+ tree may contain links to data entries from previous > index tree. If they were removed or relocated to another data page, attempt > to dereference these links may throw AssertionError or even cause JVM crash. > Patch with reproducer is attached. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8625) Dynamic SQL index recreate after cache clear may result in AssertionError or JVM crash
[ https://issues.apache.org/jira/browse/IGNITE-8625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Rakov updated IGNITE-8625: --- Attachment: dyn_idx_reproducer.patch > Dynamic SQL index recreate after cache clear may result in AssertionError or > JVM crash > -- > > Key: IGNITE-8625 > URL: https://issues.apache.org/jira/browse/IGNITE-8625 > Project: Ignite > Issue Type: Bug >Reporter: Ivan Rakov >Priority: Major > Fix For: 2.6 > > Attachments: dyn_idx_reproducer.patch > > > After recreation of previously dropped SQL index, root page of new index B+ > tree may contain links to data entries from previous index tree. If they were > removed or relocated to another data page, attempt to dereference these links > may throw AssertionError or even cause JVM crash. > Patch with reproducer is attached. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8625) Dynamic SQL index recreate after cache clear may result in AssertionError or JVM crash
Ivan Rakov created IGNITE-8625: -- Summary: Dynamic SQL index recreate after cache clear may result in AssertionError or JVM crash Key: IGNITE-8625 URL: https://issues.apache.org/jira/browse/IGNITE-8625 Project: Ignite Issue Type: Bug Reporter: Ivan Rakov Fix For: 2.6 After recreation of previously dropped SQL index, root page of new index B+ tree may contain links to data entries from previous index tree. If they were removed or relocated to another data page, attempt to dereference these links may throw AssertionError or even cause JVM crash. Patch with reproducer is attached. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8529) Implement testing framework for checking WAL delta records consistency
[ https://issues.apache.org/jira/browse/IGNITE-8529?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Rakov updated IGNITE-8529: --- Description: We use sharp checkpointing of page memory in persistent mode. That implies that we write two types of records to write-ahead log: logical (e.g. data records) and phyisical (page snapshots + binary delta records). Physical records are applied only when node crashes/stops during ongoing checkpoint. We have the following invariant: checkpoint #(n-1) + all physical records = checkpoint #n. If correctness of physical records is broken, Ignite node may recover with incorrect page memory state, which in turn can bring unexpected delayed errors. However, consistency of physical records is poorly tested: only small part of our autotests perform node restarts, and even less part of them perform node stop when ongoing checkpoint is running. We should implement abstract test that: 1. Enforces checkpoint, freezes memory state at the moment of checkpoint. 2. Performs necessary test load. 3. Enforces checkpoint again, replays WAL and checks that page store at the moment of previous checkpoint with all applied physical records exactly equals to current checkpoint state. Except for checking correctness, test framework should do the following: 1. Gather statistics (like histogram) for types of wriiten physical records. That will help us to know what types of physical records are covered by test. 2. Visualize expected and actual page state (with all applied physical records) if incorrect page state is detected. Regarding implementation, I suppose we can use checkpoint listener mechanism to freeze page memory state at the moment of checkpoint. was: We use sharp checkpointing of page memory in persistent mode. That implies that we write two types of record to write-ahead log: logical (e.g. data records) and phyisical (page snapshots + binary delta records). Physical records are applied only when node crashes/stops during ongoing checkpoint. We have the following invariant: checkpoint #(n-1) + all physical records = checkpoint #n. If correctness of physical records is broken, Ignite node may recover with incorrect page memory state, which in turn can bring unexpected delayed errors. However, consistency of physical records is poorly tested: only small part of our autotests perform node restarts, and even less part of them perform node stop when ongoing checkpoint is running. We should implement abstract test that: 1. Enforces checkpoint, freezes memory state at the moment of checkpoint. 2. Performs necessary test load. 3. Enforces checkpoint again, replays WAL and checks that page store at the moment of previous checkpoint with all applied physical records exactly equals to current checkpoint state. Except for checking correctness, test framework should do the following: 1. Gather statistics (like histogram) for types of wriiten physical records. That will help us to know what types of physical records are covered by test. 2. Visualize expected and actual page state (with all applied physical records) if incorrect page state is detected. Regarding implementation, I suppose we can use checkpoint listener mechanism to freeze page memory state at the moment of checkpoint. > Implement testing framework for checking WAL delta records consistency > -- > > Key: IGNITE-8529 > URL: https://issues.apache.org/jira/browse/IGNITE-8529 > Project: Ignite > Issue Type: New Feature > Components: persistence >Reporter: Ivan Rakov >Assignee: Aleksey Plekhanov >Priority: Major > Fix For: 2.6 > > > We use sharp checkpointing of page memory in persistent mode. That implies > that we write two types of records to write-ahead log: logical (e.g. data > records) and phyisical (page snapshots + binary delta records). Physical > records are applied only when node crashes/stops during ongoing checkpoint. > We have the following invariant: checkpoint #(n-1) + all physical records = > checkpoint #n. > If correctness of physical records is broken, Ignite node may recover with > incorrect page memory state, which in turn can bring unexpected delayed > errors. However, consistency of physical records is poorly tested: only small > part of our autotests perform node restarts, and even less part of them > perform node stop when ongoing checkpoint is running. > We should implement abstract test that: > 1. Enforces checkpoint, freezes memory state at the moment of checkpoint. > 2. Performs necessary test load. > 3. Enforces checkpoint again, replays WAL and checks that page store at the > moment of previous checkpoint with all applied physical records exactly > equals to current checkpoint state. > Except for checking correctness, test framew
[jira] [Comment Edited] (IGNITE-8524) Document consistency check utilities
[ https://issues.apache.org/jira/browse/IGNITE-8524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16489127#comment-16489127 ] Ivan Rakov edited comment on IGNITE-8524 at 5/24/18 3:22 PM: - [~dmagda], please take a look. P. S. In addition to the described consistency check options, ./control.sh --cache subcommand allows to: 1. View existing atomic sequences with ./control.sh --cache seq 2. View list of working caches along with their parameters with ./control.sh --cache caches 3. View info about cache groups with ./control.sh --cache groups These commands doesn't relate to consistency checks, but can be helpful in understanding what's going in the cluster. Should I document them on the same page? was (Author: ivan.glukos): [~dmagda], please take a look. P. S. In addition to the described consistency check options, ./control.sh --cache subcommand allows to: 1. View existing atomic sequences with ./control.sh --cache seq 2. View list of working caches along with their parameters with ./control.sh --cache caches 3. View info about cache groups with ./control.sh --cache groups These commands doesn't relate to consistency checks, but can be helpful in understanding what's going in cluster. Should I document them on the same page? > Document consistency check utilities > > > Key: IGNITE-8524 > URL: https://issues.apache.org/jira/browse/IGNITE-8524 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Denis Magda >Assignee: Ivan Rakov >Priority: Critical > Fix For: 2.5 > > > Ignite 2.5 will go with special consistency check utilities that, for > instance, ensure that the data stays consistent across backups, indexes are > correct and many other things. More details can be taken from here: > * https://issues.apache.org/jira/browse/IGNITE-8277 > * https://issues.apache.org/jira/browse/IGNITE-7467 > Here is an empty page that is created for the documentation: > https://apacheignite.readme.io/docs/consistency-check-utilities -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-8524) Document consistency check utilities
[ https://issues.apache.org/jira/browse/IGNITE-8524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16489127#comment-16489127 ] Ivan Rakov edited comment on IGNITE-8524 at 5/24/18 3:21 PM: - [~dmagda], please take a look. P. S. In addition to the described consistency check options, ./control.sh --cache subcommand allows to: 1. View existing atomic sequences with ./control.sh --cache seq 2. View list of working caches along with their parameters with ./control.sh --cache caches 3. View info about cache groups with ./control.sh --cache groups These commands doesn't relate to consistency checks, but can be helpful in understanding what's going in cluster. Should I document them on the same page? was (Author: ivan.glukos): [~dmagda], please take a look. P. S. Except for described consistency check options, ./control.sh --cache subcommand allows to: 1. View existing atomic sequences with ./control.sh --cache seq 2. View list of working caches along with their parameters with ./control.sh --cache caches 3. View info about cache groups with ./control.sh --cache groups These commands doesn't relate to consistency checks, but can be helpful in understanding what's going in cluster. Should I document them on the same page? > Document consistency check utilities > > > Key: IGNITE-8524 > URL: https://issues.apache.org/jira/browse/IGNITE-8524 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Denis Magda >Assignee: Ivan Rakov >Priority: Critical > Fix For: 2.5 > > > Ignite 2.5 will go with special consistency check utilities that, for > instance, ensure that the data stays consistent across backups, indexes are > correct and many other things. More details can be taken from here: > * https://issues.apache.org/jira/browse/IGNITE-8277 > * https://issues.apache.org/jira/browse/IGNITE-7467 > Here is an empty page that is created for the documentation: > https://apacheignite.readme.io/docs/consistency-check-utilities -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-8524) Document consistency check utilities
[ https://issues.apache.org/jira/browse/IGNITE-8524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16489127#comment-16489127 ] Ivan Rakov edited comment on IGNITE-8524 at 5/24/18 3:21 PM: - [~dmagda], please take a look. P. S. Except for described consistency check options, ./control.sh --cache subcommand allows to: 1. View existing atomic sequences with ./control.sh --cache seq 2. View list of working caches along with their parameters with ./control.sh --cache caches 3. View info about cache groups with ./control.sh --cache groups These commands doesn't relate to consistency checks, but can be helpful in understanding what's going in cluster. Should I document them on the same page? was (Author: ivan.glukos): [~dmagda], please take a look. P. S. Except for described consistency check options, ./control.sh --cache subcommand allows to: 1. View existing atomic sequences with ./control.sh --cache seq 2. View list of working caches along with their parameters with ./control.sh --cache caches 3. View info about cache groups with ./control.sh --cache groups These commands doesn't relate to consistency checks, but can be helpful in understanding what's going in cluster. Should I document them in the same page? > Document consistency check utilities > > > Key: IGNITE-8524 > URL: https://issues.apache.org/jira/browse/IGNITE-8524 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Denis Magda >Assignee: Ivan Rakov >Priority: Critical > Fix For: 2.5 > > > Ignite 2.5 will go with special consistency check utilities that, for > instance, ensure that the data stays consistent across backups, indexes are > correct and many other things. More details can be taken from here: > * https://issues.apache.org/jira/browse/IGNITE-8277 > * https://issues.apache.org/jira/browse/IGNITE-7467 > Here is an empty page that is created for the documentation: > https://apacheignite.readme.io/docs/consistency-check-utilities -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-8524) Document consistency check utilities
[ https://issues.apache.org/jira/browse/IGNITE-8524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16489127#comment-16489127 ] Ivan Rakov edited comment on IGNITE-8524 at 5/24/18 3:20 PM: - [~dmagda], please take a look. P. S. Except for described consistency check options, ./control.sh --cache subcommand allows to: 1. View existing atomic sequences with ./control.sh --cache seq 2. View list of working caches along with their parameters with ./control.sh --cache caches 3. View info about cache groups with ./control.sh --cache groups These commands doesn't relate to consistency checks, but can be helpful in understanding what's going in cluster. Should I document them in the same page? was (Author: ivan.glukos): [~dmagda], please take a look. > Document consistency check utilities > > > Key: IGNITE-8524 > URL: https://issues.apache.org/jira/browse/IGNITE-8524 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Denis Magda >Assignee: Ivan Rakov >Priority: Critical > Fix For: 2.5 > > > Ignite 2.5 will go with special consistency check utilities that, for > instance, ensure that the data stays consistent across backups, indexes are > correct and many other things. More details can be taken from here: > * https://issues.apache.org/jira/browse/IGNITE-8277 > * https://issues.apache.org/jira/browse/IGNITE-7467 > Here is an empty page that is created for the documentation: > https://apacheignite.readme.io/docs/consistency-check-utilities -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8560) Update index validation utility to use statistical check approach
[
https://issues.apache.org/jira/browse/IGNITE-8560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16489189#comment-16489189
]
Ivan Rakov commented on IGNITE-8560:
Thanks, merged to master.
> Update index validation utility to use statistical check approach
> -
>
> Key: IGNITE-8560
> URL: https://issues.apache.org/jira/browse/IGNITE-8560
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexey Goncharuk
>Assignee: Sergey Chugunov
>Priority: Major
> Fix For: 2.6
>
>
> Currently, the check index feature of {{control.sh}} scans the full data set
> which has N * logN complexity. On large data sets this takes too long to
> complete.
> To mitigate this, I suggest to add an option
> * to check either first K entries
> * to check each Kth entry
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8524) Document consistency check utilities
[ https://issues.apache.org/jira/browse/IGNITE-8524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16489127#comment-16489127 ] Ivan Rakov commented on IGNITE-8524: [~dmagda], please take a look. > Document consistency check utilities > > > Key: IGNITE-8524 > URL: https://issues.apache.org/jira/browse/IGNITE-8524 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Denis Magda >Assignee: Ivan Rakov >Priority: Critical > Fix For: 2.5 > > > Ignite 2.5 will go with special consistency check utilities that, for > instance, ensure that the data stays consistent across backups, indexes are > correct and many other things. More details can be taken from here: > * https://issues.apache.org/jira/browse/IGNITE-8277 > * https://issues.apache.org/jira/browse/IGNITE-7467 > Here is an empty page that is created for the documentation: > https://apacheignite.readme.io/docs/consistency-check-utilities -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8594) Make error messages in validate_indexes command report more informative
Ivan Rakov created IGNITE-8594:
--
Summary: Make error messages in validate_indexes command report
more informative
Key: IGNITE-8594
URL: https://issues.apache.org/jira/browse/IGNITE-8594
Project: Ignite
Issue Type: Improvement
Reporter: Ivan Rakov
Assignee: Ivan Rakov
Fix For: 2.6
In case index is broken and contains links to missing items in data pages,
validate_indexes command will show "Item not found" messages in report:
{noformat}
IndexValidationIssue [key=null, cacheName=cache_group_1_028, idxName=_key_PK],
class java.lang.IllegalStateException: Item not found: 65
IndexValidationIssue [key=null, cacheName=cache_group_1_028, idxName=_key_PK],
class java.lang.IllegalStateException: Item not found: 15
SQL Index [cache=cache_group_1_028, idx=LONG__VAL_IDX]
ValidateIndexesPartitionResult [consistentId=node2, sqlIdxName=LONG__VAL_IDX]
IndexValidationIssue [key=null, cacheName=cache_group_1_028,
idxName=LONG__VAL_IDX], class java.lang.IllegalStateException: Item not found:
60
IndexValidationIssue [key=null, cacheName=cache_group_1_028,
idxName=LONG__VAL_IDX], class java.lang.IllegalStateException: Item not found:
65
IndexValidationIssue [key=null, cacheName=cache_group_1_028,
idxName=LONG__VAL_IDX], class java.lang.IllegalStateException: Item not found:
65
IndexValidationIssue [key=null, cacheName=cache_group_1_028,
idxName=LONG__VAL_IDX], class java.lang.IllegalStateException: Item not found:
15
{noformat}
It would be better to explain what is happening: key is present in SQL index,
but missing in corresponding data page.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
