[jira] [Updated] (IGNITE-8617) Node Discovery Using AWS Application ELB
[ https://issues.apache.org/jira/browse/IGNITE-8617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uday Kale updated IGNITE-8617: -- Fix Version/s: 2.7 > Node Discovery Using AWS Application ELB > > > Key: IGNITE-8617 > URL: https://issues.apache.org/jira/browse/IGNITE-8617 > Project: Ignite > Issue Type: New Feature > Components: aws >Reporter: Uday Kale >Assignee: Dmitriy Pavlov >Priority: Major > Fix For: 2.7 > > > Support for Node discovery using AWS Application ELB. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8911) While cache is restarting it's possible to start new cache with this name
[ https://issues.apache.org/jira/browse/IGNITE-8911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16551138#comment-16551138 ] Eduard Shangareev commented on IGNITE-8911: --- PR is https://github.com/apache/ignite/pull/4291 > While cache is restarting it's possible to start new cache with this name > - > > Key: IGNITE-8911 > URL: https://issues.apache.org/jira/browse/IGNITE-8911 > Project: Ignite > Issue Type: Bug >Reporter: Eduard Shangareev >Assignee: Eduard Shangareev >Priority: Major > > We have the state "restarting" for caches when we certainly now that these > caches would start at some moment in future. But we could start new cache > with the same name. > Plus, NPE is throwing when we try to get proxy for such caches (in > "restarting" state). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9046) Actualize dependency versions for Cassandra Cache Store
Dmitriy Pavlov created IGNITE-9046: -- Summary: Actualize dependency versions for Cassandra Cache Store Key: IGNITE-9046 URL: https://issues.apache.org/jira/browse/IGNITE-9046 Project: Ignite Issue Type: Improvement Reporter: Dmitriy Pavlov Fix For: 2.7 It is suggested A. to update commons-beanutils version. It can be done using property commons-beanutils.version in pom.xml: change 1.9.2 to latest version, currently it is 1.9.3 http://central.maven.org/maven2/commons-beanutils/commons-beanutils/1.9.3/commons-beanutils-1.9.3.pom B. Update Netty Project netty.version (currently 4.0.33.Final) Upgrade at least to 4.0.37.Final or later or to 4.1.1.Final or later It is required to run RunAll to check all tests passed, check full build locally using build.sh. Probably it is required to run release step to make sure release candidate can be prepared. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-5518) Rework test on join active/inactive node
[ https://issues.apache.org/jira/browse/IGNITE-5518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Govorukhin reassigned IGNITE-5518: -- Assignee: (was: Dmitriy Govorukhin) > Rework test on join active/inactive node > - > > Key: IGNITE-5518 > URL: https://issues.apache.org/jira/browse/IGNITE-5518 > Project: Ignite > Issue Type: Task >Reporter: Dmitriy Govorukhin >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-7847) Increase of total owning partition count after rebalance
[ https://issues.apache.org/jira/browse/IGNITE-7847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Govorukhin reassigned IGNITE-7847: -- Assignee: (was: Dmitriy Govorukhin) > Increase of total owning partition count after rebalance > > > Key: IGNITE-7847 > URL: https://issues.apache.org/jira/browse/IGNITE-7847 > Project: Ignite > Issue Type: Bug > Components: general >Affects Versions: 2.4 >Reporter: Alexander Belyak >Priority: Critical > Fix For: 2.7 > > > 1) Start 3 nodes with persistence enabled > 2) Activate grid > 3) Create cache with 1 backup and remember owning partition count on node1 > 4) Stop node2, set BLT and note that local owning partitions on node1 > increased (to total number of partitions on cache) > 5) Start node, set BLT and waitRebalance and > Expected: owning partitions count on node1 became as on step 3 > Actual: owning partitions count on node1 still equals to step 4 value -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9039) AssertionError on cache stop
[
https://issues.apache.org/jira/browse/IGNITE-9039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eduard Shangareev updated IGNITE-9039:
--
Fix Version/s: 2.7
> AssertionError on cache stop
>
>
> Key: IGNITE-9039
> URL: https://issues.apache.org/jira/browse/IGNITE-9039
> Project: Ignite
> Issue Type: Bug
>Reporter: Eduard Shangareev
>Assignee: Eduard Shangareev
>Priority: Major
> Fix For: 2.7
>
>
> It was introduced by IGNITE-8955:
> {code}
> [2018-07-20 13:24:39,190][INFO
> ][exchange-worker-#38%db.CheckpointBufferDeadlockTest0%][root]
> [GridStringLogger echo] class org.apache.ignite.IgniteCheckedException:
> Compound exception for CountDownFuture. at
> org.apache.ignite.internal.util.future.CountDownFuture.addError(CountDownFuture.java:72)
> at
> org.apache.ignite.internal.util.future.CountDownFuture.onDone(CountDownFuture.java:46)
> at
> org.apache.ignite.internal.util.future.CountDownFuture.onDone(CountDownFuture.java:28)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:462)
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl$ClearSegmentRunnable.run(PageMemoryImpl.java:2757)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> Suppressed: java.lang.AssertionError: Release pinned page: FullPageId
> [pageId=00013c43, effectivePageId=3c43, grpId=-1778028968]
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl$PagePool.releaseFreePage(PageMemoryImpl.java:1787)
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl$PagePool.access$1900(PageMemoryImpl.java:1659)
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl$ClearSegmentRunnable.run(PageMemoryImpl.java:2748)
> ... 3 more
> Suppressed: java.lang.AssertionError: Release pinned page: FullPageId
> [pageId=000128bc, effectivePageId=28bc, grpId=-1778028968]
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl$PagePool.releaseFreePage(PageMemoryImpl.java:1787)
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl$PagePool.access$1900(PageMemoryImpl.java:1659)
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl$ClearSegmentRunnable.run(PageMemoryImpl.java:2748)
> ... 3 more
> Suppressed: java.lang.AssertionError: Release pinned page: FullPageId
> [pageId=00013f1a, effectivePageId=3f1a, grpId=-1778028968]
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl$PagePool.releaseFreePage(PageMemoryImpl.java:1787)
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl$PagePool.access$1900(PageMemoryImpl.java:1659)
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl$ClearSegmentRunnable.run(PageMemoryImpl.java:2748)
> ... 3 more
> Suppressed: java.lang.AssertionError: Release pinned page: FullPageId
> [pageId=00012eb9, effectivePageId=2eb9, grpId=-1778028968]
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl$PagePool.releaseFreePage(PageMemoryImpl.java:1787)
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl$PagePool.access$1900(PageMemoryImpl.java:1659)
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl$ClearSegmentRunnable.run(PageMemoryImpl.java:2748)
> ... 3 more
> Suppressed: java.lang.AssertionError: Release pinned page: FullPageId
> [pageId=000120f2, effectivePageId=20f2, grpId=-1778028968]
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl$PagePool.releaseFreePage(PageMemoryImpl.java:1787)
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl$PagePool.access$1900(PageMemoryImpl.java:1659)
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl$ClearSegmentRunnable.run(PageMemoryImpl.java:2748)
> ... 3 more
> Suppressed: java.lang.AssertionError: Release pinned page: FullPageId
> [pageId=000115e9, effectivePageId=15e9,
[jira] [Updated] (IGNITE-9045) TxRecord is logged to WAL during node stop procedure
[ https://issues.apache.org/jira/browse/IGNITE-9045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Chugunov updated IGNITE-9045: Component/s: persistence > TxRecord is logged to WAL during node stop procedure > > > Key: IGNITE-9045 > URL: https://issues.apache.org/jira/browse/IGNITE-9045 > Project: Ignite > Issue Type: Bug > Components: persistence >Affects Versions: 2.6 >Reporter: Sergey Chugunov >Priority: Major > Fix For: 2.7 > > > When *IGNITE_WAL_LOG_TX_RECORDS* flag is set to true special TxRecords are > logged to WAL on changes of transaction state. > It turned out that during node stop transaction futures (e.g. > GridDhtTxPrepareFuture) change transaction state which is logged to WAL. > This situation may violate transactional consistency and should be fixed: no > writes to WAL should be issued during node stop. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9045) TxRecord is logged to WAL during node stop procedure
Sergey Chugunov created IGNITE-9045: --- Summary: TxRecord is logged to WAL during node stop procedure Key: IGNITE-9045 URL: https://issues.apache.org/jira/browse/IGNITE-9045 Project: Ignite Issue Type: Bug Affects Versions: 2.6 Reporter: Sergey Chugunov Fix For: 2.7 When *IGNITE_WAL_LOG_TX_RECORDS* flag is set to true special TxRecords are logged to WAL on changes of transaction state. It turned out that during node stop transaction futures (e.g. GridDhtTxPrepareFuture) change transaction state which is logged to WAL. This situation may violate transactional consistency and should be fixed: no writes to WAL should be issued during node stop. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9039) AssertionError on cache stop
[
https://issues.apache.org/jira/browse/IGNITE-9039?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16550868#comment-16550868
]
ASF GitHub Bot commented on IGNITE-9039:
Github user asfgit closed the pull request at:
https://github.com/apache/ignite/pull/4390
> AssertionError on cache stop
>
>
> Key: IGNITE-9039
> URL: https://issues.apache.org/jira/browse/IGNITE-9039
> Project: Ignite
> Issue Type: Bug
>Reporter: Eduard Shangareev
>Assignee: Eduard Shangareev
>Priority: Major
>
> It was introduced by IGNITE-8955:
> {code}
> [2018-07-20 13:24:39,190][INFO
> ][exchange-worker-#38%db.CheckpointBufferDeadlockTest0%][root]
> [GridStringLogger echo] class org.apache.ignite.IgniteCheckedException:
> Compound exception for CountDownFuture. at
> org.apache.ignite.internal.util.future.CountDownFuture.addError(CountDownFuture.java:72)
> at
> org.apache.ignite.internal.util.future.CountDownFuture.onDone(CountDownFuture.java:46)
> at
> org.apache.ignite.internal.util.future.CountDownFuture.onDone(CountDownFuture.java:28)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:462)
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl$ClearSegmentRunnable.run(PageMemoryImpl.java:2757)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> Suppressed: java.lang.AssertionError: Release pinned page: FullPageId
> [pageId=00013c43, effectivePageId=3c43, grpId=-1778028968]
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl$PagePool.releaseFreePage(PageMemoryImpl.java:1787)
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl$PagePool.access$1900(PageMemoryImpl.java:1659)
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl$ClearSegmentRunnable.run(PageMemoryImpl.java:2748)
> ... 3 more
> Suppressed: java.lang.AssertionError: Release pinned page: FullPageId
> [pageId=000128bc, effectivePageId=28bc, grpId=-1778028968]
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl$PagePool.releaseFreePage(PageMemoryImpl.java:1787)
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl$PagePool.access$1900(PageMemoryImpl.java:1659)
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl$ClearSegmentRunnable.run(PageMemoryImpl.java:2748)
> ... 3 more
> Suppressed: java.lang.AssertionError: Release pinned page: FullPageId
> [pageId=00013f1a, effectivePageId=3f1a, grpId=-1778028968]
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl$PagePool.releaseFreePage(PageMemoryImpl.java:1787)
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl$PagePool.access$1900(PageMemoryImpl.java:1659)
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl$ClearSegmentRunnable.run(PageMemoryImpl.java:2748)
> ... 3 more
> Suppressed: java.lang.AssertionError: Release pinned page: FullPageId
> [pageId=00012eb9, effectivePageId=2eb9, grpId=-1778028968]
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl$PagePool.releaseFreePage(PageMemoryImpl.java:1787)
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl$PagePool.access$1900(PageMemoryImpl.java:1659)
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl$ClearSegmentRunnable.run(PageMemoryImpl.java:2748)
> ... 3 more
> Suppressed: java.lang.AssertionError: Release pinned page: FullPageId
> [pageId=000120f2, effectivePageId=20f2, grpId=-1778028968]
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl$PagePool.releaseFreePage(PageMemoryImpl.java:1787)
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl$PagePool.access$1900(PageMemoryImpl.java:1659)
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl$ClearSegmentRunnable.run(PageMemoryImpl.java:2748)
> ... 3 more
> Suppressed: java.lang.AssertionError: Release pinned page:
[jira] [Commented] (IGNITE-9040) StopNodeFailureHandler is not able to stop node correctly on node segmentation
[
https://issues.apache.org/jira/browse/IGNITE-9040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16550827#comment-16550827
]
ASF GitHub Bot commented on IGNITE-9040:
GitHub user sergey-chugunov-1985 opened a pull request:
https://github.com/apache/ignite/pull/4395
IGNITE-9040 new FailureHandler for node segmentation special case, test for
the root cause error
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-9040
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/4395.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #4395
commit 1a76eab2912f7b8925c051c76763e87511d4
Author: Sergey Chugunov
Date: 2018-07-20T14:27:05Z
IGNITE-9040 new FailureHandler for node segmentation special case, test for
the root cause error
> StopNodeFailureHandler is not able to stop node correctly on node segmentation
> --
>
> Key: IGNITE-9040
> URL: https://issues.apache.org/jira/browse/IGNITE-9040
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.6
>Reporter: Sergey Chugunov
>Assignee: Sergey Chugunov
>Priority: Major
> Fix For: 2.7
>
>
> When flag *IGNITE_WAL_LOG_TX_RECORDS* is set up special TxRecords are logged
> to WAL even on node stop.
> With STOP segmentation policy *StopNodeFailureHandler* is used to stop the
> segmented node and it marks node's state as invalid. As a result all write
> requests to WAL get failed.
> So as part of stop-on-segmentation procedure node needs to log Tx but it
> cannot as its state is marked as invalid. This leads to stop procedure
> finishing incorrectly, some threads started by the node are not cleaned up.
> Exception example:
> {noformat}
> [2018-07-20 13:35:36,358][ERROR][node-stopper][ZookeeperDiscoverySpiTest0]
> Failed to pre-stop processor: GridProcessorAdapter []
> class org.apache.ignite.IgniteException: Failed to log TxRecord: TxRecord
> [state=PREPARED, nearXidVer=GridCacheVersion [topVer=143562918,
> order=1532082921780, nodeOrder=3], writeVer=GridCacheVersion
> [topVer=143562918, order=1532082921781, nodeOrder=1], super=TimeStampRecord
> [timestamp=1532082936349]]
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxAdapter.state(IgniteTxAdapter.java:1132)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxAdapter.state(IgniteTxAdapter.java:968)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.onComplete(GridDhtTxPrepareFuture.java:983)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.onDone(GridDhtTxPrepareFuture.java:717)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.onDone(GridDhtTxPrepareFuture.java:105)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:462)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMvccManager.cancelClientFutures(GridCacheMvccManager.java:425)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMvccManager.onStop(GridCacheMvccManager.java:410)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.onKernalStop(GridCacheProcessor.java:984)
> at org.apache.ignite.internal.IgniteKernal.stop0(IgniteKernal.java:2134)
> at org.apache.ignite.internal.IgniteKernal.stop(IgniteKernal.java:2082)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop0(IgnitionEx.java:2595)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop(IgnitionEx.java:2558)
> at org.apache.ignite.internal.IgnitionEx.stop(IgnitionEx.java:374)
> at
> org.apache.ignite.failure.StopNodeFailureHandler$1.run(StopNodeFailureHandler.java:36)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: class org.apache.ignite.internal.pagemem.wal.StorageException:
> Failed to perform WAL operation (environment was invalidated by a previous
> error)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.checkNode(FileWriteAheadLogManager.java:1504)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.access$6100(FileWriteAheadLogManager.java:143)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileWriteHandle.addRecord(FileWriteAheadLogManager.java:2611)
> at
>
[jira] [Created] (IGNITE-9044) Update scala dependency version in Apache Ignite
Dmitriy Pavlov created IGNITE-9044: -- Summary: Update scala dependency version in Apache Ignite Key: IGNITE-9044 URL: https://issues.apache.org/jira/browse/IGNITE-9044 Project: Ignite Issue Type: Improvement Reporter: Dmitriy Pavlov Fix For: 2.7 *ignite-scalar* scala.library.version=2.11.8, need to be at least 2.11.12 or newer. *ignite-scalar_2.10* scala210.library.version 2.10.6, need to be at least 2.10.7, probably newer *visor 2.10* scala210.jline.version = 2.10.4 , need to be at least 2.10.7, probably newer Probably impact would be wider. We need at least run run-all, local build.sh and optionally release candate step on TC. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8866) Need attempt to upload class until node leave or fail topology by discovery SPI
[
https://issues.apache.org/jira/browse/IGNITE-8866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16550783#comment-16550783
]
Stanilovsky Evgeny commented on IGNITE-8866:
what about TC run ?
> Need attempt to upload class until node leave or fail topology by discovery
> SPI
> ---
>
> Key: IGNITE-8866
> URL: https://issues.apache.org/jira/browse/IGNITE-8866
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Assignee: Evgenii Zagumennov
>Priority: Major
> Attachments: P2PClassDeploymentDelay.java
>
>
> After one fail attempt to upload a class, client code getting exception:
> {noformat}
> 10:04:46,253 INFO [stdout] (Thread-732) java.lang.NoClassDefFoundError:
> ru/sbt/deposit_pf_api/core/utils/DplUtils
> 10:04:46,253 INFO [stdout] (Thread-732) at
> ru.sbt.deposit_pf_api.comparators.CommonPredicate.nodeIdIgnite(CommonPredicate.java:225)
> 10:04:46,253 INFO [stdout] (Thread-732) at
> ru.sbt.deposit_pf_api.comparators.CommonPredicate.cacheEntities(CommonPredicate.java:191)
> 10:04:46,253 INFO [stdout] (Thread-732) at
> ru.sbt.deposit_pf_api.comparators.CommonPredicate.(CommonPredicate.java:116)
> {noformat}
> And log contains some related warnings:
> {noformat}
> 018-06-19 10:04:18.459 [WARN
> ][pub-#3308%DPL_GRID%DplGridNodeName%][o.a.i.i.m.d.GridDeploymentCommunication]
> Failed to receive peer response from node within duration
> [node=5861d763-a552-463e-817a-0742f7aad114, duration=5008]
> 2018-06-19 10:04:18.459 [WARN
> ][pub-#3308%DPL_GRID%DplGridNodeName%][o.a.i.i.m.d.GridDeploymentPerVersionStore]
> Failed to send class-loading request to node (is node alive?)
> [node=5861d763-a552-463e-817a-0742f7aad114,
> clsName=ru.sbt.deposit_pf_api.core.utils.DplUtils,
> clsPath=ru/sbt/deposit_pf_api/core/utils/DplUtils.class,
> clsLdrId=370f1361461-5861d763-a552-463e-817a-0742f7aad114,
> parentClsLdr=com.sbt.dpl.gridgain.ignite.NodeClassLoader@1ce4a752]
> {noformat}
> I think should to upload class through p2p until node present in topology.
> Look at the [^P2PClassDeploymentDelay.java] reproducer.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-9043) Map field is registered as Object in BinaryType
Denis Mekhanikov created IGNITE-9043:
Summary: Map field is registered as Object in BinaryType
Key: IGNITE-9043
URL: https://issues.apache.org/jira/browse/IGNITE-9043
Project: Ignite
Issue Type: Bug
Components: binary
Affects Versions: 2.6
Reporter: Denis Mekhanikov
Assignee: Denis Mekhanikov
Fix For: 2.7
When a binary type is registered during first insertion without use of
BinaryObject, then fields of type {{Map}} are registered as {{Object}}-s.
It leads to inconvenience in further usage of this type over {{BinaryObject}}
interface.
The following code results in an exception:
{code:java}
public static void main(String[] args) {
Ignite ignite = Ignition.start("config/ignite.xml");
IgniteCache cache = ignite.getOrCreateCache("cache");
cache.put(1, new ExamplePojo());
BinaryObject val = cache.withKeepBinary().get(1);
Map map = val.field("map");
map.put(1, "1");
BinaryObjectBuilder bldr = val.toBuilder();
bldr.setField("map", map);
bldr.build(); // Throws exception.
}
static class ExamplePojo {
Map map = new HashMap<>();
}
{code}
Stacktrace:
{noformat}
Exception in thread "main" class
org.apache.ignite.binary.BinaryObjectException: Wrong value has been set
[typeName=binary.BinaryObjectMapExample$ExamplePojo, fieldName=map,
fieldType=Object, assignedValueType=Map]
at
org.apache.ignite.internal.binary.builder.BinaryObjectBuilderImpl.checkMetadata(BinaryObjectBuilderImpl.java:428)
at
org.apache.ignite.internal.binary.builder.BinaryObjectBuilderImpl.serializeTo(BinaryObjectBuilderImpl.java:223)
at
org.apache.ignite.internal.binary.builder.BinaryObjectBuilderImpl.build(BinaryObjectBuilderImpl.java:183)
at binary.BinaryObjectMapExample.main(BinaryObjectMapExample.java:26)
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9041) AssertionError in TcpCommunicationSpi
[ https://issues.apache.org/jira/browse/IGNITE-9041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16550756#comment-16550756 ] Alexey Stelmak commented on IGNITE-9041: TC: https://ci.ignite.apache.org/viewLog.html?buildId=1522871=buildResultsDiv=IgniteTests24Java8_Cache6 > AssertionError in TcpCommunicationSpi > - > > Key: IGNITE-9041 > URL: https://issues.apache.org/jira/browse/IGNITE-9041 > Project: Ignite > Issue Type: Bug >Reporter: Alexey Stelmak >Assignee: Alexey Stelmak >Priority: Critical > > Tests (cache 6 suite): > PartitionedAtomicCacheGetsDistributionTest.testGetAllRequestsDistribution > > PartitionedAtomicCacheGetsDistributionTest.testGetAllRequestsGeneratorDistribution > PartitionedAtomicCacheGetsDistributionTest.testGetRequestsDistribution > > PartitionedAtomicCacheGetsDistributionTest.testGetRequestsGeneratorDistribution -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-8920) Node should be failed when during tx finish indices are corrupted.
[ https://issues.apache.org/jira/browse/IGNITE-8920?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Kovalenko reassigned IGNITE-8920: --- Assignee: Pavel Kovalenko > Node should be failed when during tx finish indices are corrupted. > -- > > Key: IGNITE-8920 > URL: https://issues.apache.org/jira/browse/IGNITE-8920 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.5 >Reporter: Ivan Daschinskiy >Assignee: Pavel Kovalenko >Priority: Major > Fix For: 2.7 > > > While transaction is processed after receiving finish request > (IgniteTxHandler.finish) , node should be failed by FailureHandler if page > content of indices is corrupted. Currently this case is not handled properly > and cause to long running transactions over the grid. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8866) Need attempt to upload class until node leave or fail topology by discovery SPI
[
https://issues.apache.org/jira/browse/IGNITE-8866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16550744#comment-16550744
]
Evgenii Zagumennov commented on IGNITE-8866:
I guess, sending requests untill a node leave the topology is a wrong way.
Resource node may not respond because of GC-pause or another reason, but number
of requests will grow. I've added to
GridDeploymentCommunication#sendResourceRequest ability to retry to send
request. Number of retries is definable.
> Need attempt to upload class until node leave or fail topology by discovery
> SPI
> ---
>
> Key: IGNITE-8866
> URL: https://issues.apache.org/jira/browse/IGNITE-8866
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Assignee: Evgenii Zagumennov
>Priority: Major
> Attachments: P2PClassDeploymentDelay.java
>
>
> After one fail attempt to upload a class, client code getting exception:
> {noformat}
> 10:04:46,253 INFO [stdout] (Thread-732) java.lang.NoClassDefFoundError:
> ru/sbt/deposit_pf_api/core/utils/DplUtils
> 10:04:46,253 INFO [stdout] (Thread-732) at
> ru.sbt.deposit_pf_api.comparators.CommonPredicate.nodeIdIgnite(CommonPredicate.java:225)
> 10:04:46,253 INFO [stdout] (Thread-732) at
> ru.sbt.deposit_pf_api.comparators.CommonPredicate.cacheEntities(CommonPredicate.java:191)
> 10:04:46,253 INFO [stdout] (Thread-732) at
> ru.sbt.deposit_pf_api.comparators.CommonPredicate.(CommonPredicate.java:116)
> {noformat}
> And log contains some related warnings:
> {noformat}
> 018-06-19 10:04:18.459 [WARN
> ][pub-#3308%DPL_GRID%DplGridNodeName%][o.a.i.i.m.d.GridDeploymentCommunication]
> Failed to receive peer response from node within duration
> [node=5861d763-a552-463e-817a-0742f7aad114, duration=5008]
> 2018-06-19 10:04:18.459 [WARN
> ][pub-#3308%DPL_GRID%DplGridNodeName%][o.a.i.i.m.d.GridDeploymentPerVersionStore]
> Failed to send class-loading request to node (is node alive?)
> [node=5861d763-a552-463e-817a-0742f7aad114,
> clsName=ru.sbt.deposit_pf_api.core.utils.DplUtils,
> clsPath=ru/sbt/deposit_pf_api/core/utils/DplUtils.class,
> clsLdrId=370f1361461-5861d763-a552-463e-817a-0742f7aad114,
> parentClsLdr=com.sbt.dpl.gridgain.ignite.NodeClassLoader@1ce4a752]
> {noformat}
> I think should to upload class through p2p until node present in topology.
> Look at the [^P2PClassDeploymentDelay.java] reproducer.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-8559) WAL rollOver can be blocked by WAL iterator reservation
[
https://issues.apache.org/jira/browse/IGNITE-8559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton Kalashnikov reassigned IGNITE-8559:
-
Assignee: Anton Kalashnikov (was: Sergey Chugunov)
> WAL rollOver can be blocked by WAL iterator reservation
> ---
>
> Key: IGNITE-8559
> URL: https://issues.apache.org/jira/browse/IGNITE-8559
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexey Goncharuk
>Assignee: Anton Kalashnikov
>Priority: Critical
> Fix For: 2.7
>
>
> I've got the following thread dump from one of the Ignite nodes (only
> meaningful threads are kept for simplicity)
> WAL archiver is waiting for locked segment release
> TX commit is waiting for WAL rollover
> WAL rollover is blocked by the archiver
> Exchange is blocked by TX commit
> {code}
> "sys-stripe-55-#56%GRID%GridNodeName%" #246 daemon prio=5 os_prio=0
> tid=0x7fdd1eeff000 nid=0x164252 waiting on condition [0x7fdb36eec000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x7fe0a5e96278> (a
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitUninterruptibly(AbstractQueuedSynchronizer.java:1976)
> at
> org.apache.ignite.internal.util.IgniteUtils.awaitQuiet(IgniteUtils.java:7400)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileWriteHandle.awaitNext(FileWriteAheadLogManager.java:2819)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileWriteHandle.access$2900(FileWriteAheadLogManager.java:2390)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.rollOver(FileWriteAheadLogManager.java:1065)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.log(FileWriteAheadLogManager.java:715)
> at
> org.gridgain.grid.internal.processors.cache.database.snapshot.GridCacheSnapshotManager.onChangeTrackerPage(GridCacheSnapshotManager.java:2436)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$9.applyx(GridCacheDatabaseSharedManager.java:942)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$9.applyx(GridCacheDatabaseSharedManager.java:935)
> at
> org.apache.ignite.internal.util.lang.GridInClosure3X.apply(GridInClosure3X.java:34)
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.writeUnlockPage(PageMemoryImpl.java:1341)
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.writeUnlock(PageMemoryImpl.java:415)
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.writeUnlock(PageMemoryImpl.java:409)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.util.PageHandler.writeUnlock(PageHandler.java:377)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.util.PageHandler.writePage(PageHandler.java:287)
> at
> org.apache.ignite.internal.processors.cache.persistence.DataStructure.write(DataStructure.java:282)
> at
> org.apache.ignite.internal.processors.cache.persistence.freelist.AbstractFreeList.insertDataRow(AbstractFreeList.java:509)
> at
> org.apache.ignite.internal.processors.cache.persistence.RowStore.addRow(RowStore.java:102)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.createRow(IgniteCacheOffheapManagerImpl.java:1252)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.createRow(GridCacheOffheapManager.java:1370)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry$UpdateClosure.call(GridCacheMapEntry.java:4429)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry$UpdateClosure.call(GridCacheMapEntry.java:4374)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Invoke.invokeClosure(BPlusTree.java:3083)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Invoke.access$6200(BPlusTree.java:2977)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.invokeDown(BPlusTree.java:1726)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.invokeDown(BPlusTree.java:1703)
> at
>
[jira] [Issue Comment Deleted] (IGNITE-9041) AssertionError in TcpCommunicationSpi
[ https://issues.apache.org/jira/browse/IGNITE-9041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Stelmak updated IGNITE-9041: --- Comment: was deleted (was: PR: https://github.com/apache/ignite/pull/4392) > AssertionError in TcpCommunicationSpi > - > > Key: IGNITE-9041 > URL: https://issues.apache.org/jira/browse/IGNITE-9041 > Project: Ignite > Issue Type: Bug >Reporter: Alexey Stelmak >Assignee: Alexey Stelmak >Priority: Critical > > Tests (cache 6 suite): > PartitionedAtomicCacheGetsDistributionTest.testGetAllRequestsDistribution > > PartitionedAtomicCacheGetsDistributionTest.testGetAllRequestsGeneratorDistribution > PartitionedAtomicCacheGetsDistributionTest.testGetRequestsDistribution > > PartitionedAtomicCacheGetsDistributionTest.testGetRequestsGeneratorDistribution -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9041) AssertionError in TcpCommunicationSpi
[ https://issues.apache.org/jira/browse/IGNITE-9041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Stelmak updated IGNITE-9041: --- Description: Tests (cache 6 suite): PartitionedAtomicCacheGetsDistributionTest.testGetAllRequestsDistribution PartitionedAtomicCacheGetsDistributionTest.testGetAllRequestsGeneratorDistribution PartitionedAtomicCacheGetsDistributionTest.testGetRequestsDistribution PartitionedAtomicCacheGetsDistributionTest.testGetRequestsGeneratorDistribution was: Tests: PartitionedAtomicCacheGetsDistributionTest.testGetAllRequestsDistribution PartitionedAtomicCacheGetsDistributionTest.testGetAllRequestsGeneratorDistribution PartitionedAtomicCacheGetsDistributionTest.testGetRequestsDistribution PartitionedAtomicCacheGetsDistributionTest.testGetRequestsGeneratorDistribution > AssertionError in TcpCommunicationSpi > - > > Key: IGNITE-9041 > URL: https://issues.apache.org/jira/browse/IGNITE-9041 > Project: Ignite > Issue Type: Bug >Reporter: Alexey Stelmak >Assignee: Alexey Stelmak >Priority: Critical > > Tests (cache 6 suite): > PartitionedAtomicCacheGetsDistributionTest.testGetAllRequestsDistribution > > PartitionedAtomicCacheGetsDistributionTest.testGetAllRequestsGeneratorDistribution > PartitionedAtomicCacheGetsDistributionTest.testGetRequestsDistribution > > PartitionedAtomicCacheGetsDistributionTest.testGetRequestsGeneratorDistribution -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9041) AssertionError in TcpCommunicationSpi
[ https://issues.apache.org/jira/browse/IGNITE-9041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Stelmak updated IGNITE-9041: --- Description: Tests: PartitionedAtomicCacheGetsDistributionTest.testGetAllRequestsDistribution PartitionedAtomicCacheGetsDistributionTest.testGetAllRequestsGeneratorDistribution PartitionedAtomicCacheGetsDistributionTest.testGetRequestsDistribution PartitionedAtomicCacheGetsDistributionTest.testGetRequestsGeneratorDistribution > AssertionError in TcpCommunicationSpi > - > > Key: IGNITE-9041 > URL: https://issues.apache.org/jira/browse/IGNITE-9041 > Project: Ignite > Issue Type: Bug >Reporter: Alexey Stelmak >Assignee: Alexey Stelmak >Priority: Critical > > Tests: > PartitionedAtomicCacheGetsDistributionTest.testGetAllRequestsDistribution > PartitionedAtomicCacheGetsDistributionTest.testGetAllRequestsGeneratorDistribution > PartitionedAtomicCacheGetsDistributionTest.testGetRequestsDistribution > PartitionedAtomicCacheGetsDistributionTest.testGetRequestsGeneratorDistribution -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8866) Need attempt to upload class until node leave or fail topology by discovery SPI
[
https://issues.apache.org/jira/browse/IGNITE-8866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16550736#comment-16550736
]
ASF GitHub Bot commented on IGNITE-8866:
GitHub user ezagumennov opened a pull request:
https://github.com/apache/ignite/pull/4393
IGNITE-8866 Retries to upload class
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-8866
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/4393.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #4393
commit 40dc0cca5e010b8e75d15b6eab8e8978423ec4d4
Author: ezagumennov
Date: 2018-07-20T12:36:33Z
IGNITE-8866 Retries to upload class
> Need attempt to upload class until node leave or fail topology by discovery
> SPI
> ---
>
> Key: IGNITE-8866
> URL: https://issues.apache.org/jira/browse/IGNITE-8866
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Assignee: Evgenii Zagumennov
>Priority: Major
> Attachments: P2PClassDeploymentDelay.java
>
>
> After one fail attempt to upload a class, client code getting exception:
> {noformat}
> 10:04:46,253 INFO [stdout] (Thread-732) java.lang.NoClassDefFoundError:
> ru/sbt/deposit_pf_api/core/utils/DplUtils
> 10:04:46,253 INFO [stdout] (Thread-732) at
> ru.sbt.deposit_pf_api.comparators.CommonPredicate.nodeIdIgnite(CommonPredicate.java:225)
> 10:04:46,253 INFO [stdout] (Thread-732) at
> ru.sbt.deposit_pf_api.comparators.CommonPredicate.cacheEntities(CommonPredicate.java:191)
> 10:04:46,253 INFO [stdout] (Thread-732) at
> ru.sbt.deposit_pf_api.comparators.CommonPredicate.(CommonPredicate.java:116)
> {noformat}
> And log contains some related warnings:
> {noformat}
> 018-06-19 10:04:18.459 [WARN
> ][pub-#3308%DPL_GRID%DplGridNodeName%][o.a.i.i.m.d.GridDeploymentCommunication]
> Failed to receive peer response from node within duration
> [node=5861d763-a552-463e-817a-0742f7aad114, duration=5008]
> 2018-06-19 10:04:18.459 [WARN
> ][pub-#3308%DPL_GRID%DplGridNodeName%][o.a.i.i.m.d.GridDeploymentPerVersionStore]
> Failed to send class-loading request to node (is node alive?)
> [node=5861d763-a552-463e-817a-0742f7aad114,
> clsName=ru.sbt.deposit_pf_api.core.utils.DplUtils,
> clsPath=ru/sbt/deposit_pf_api/core/utils/DplUtils.class,
> clsLdrId=370f1361461-5861d763-a552-463e-817a-0742f7aad114,
> parentClsLdr=com.sbt.dpl.gridgain.ignite.NodeClassLoader@1ce4a752]
> {noformat}
> I think should to upload class through p2p until node present in topology.
> Look at the [^P2PClassDeploymentDelay.java] reproducer.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-9035) Update log4j 2x version in Apache Ignite
[
https://issues.apache.org/jira/browse/IGNITE-9035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryabov Dmitrii reassigned IGNITE-9035:
--
Assignee: Ryabov Dmitrii
> Update log4j 2x version in Apache Ignite
>
>
> Key: IGNITE-9035
> URL: https://issues.apache.org/jira/browse/IGNITE-9035
> Project: Ignite
> Issue Type: Improvement
>Reporter: Dmitriy Pavlov
>Assignee: Ryabov Dmitrii
>Priority: Major
> Fix For: 2.7
>
>
> It is suggested to update log4j 2x version to log4j 2.8.2 or later.
> {noformat}
>
> org.apache.logging.log4j
> log4j
> 2.8.2
> pom
>
> {noformat}
> It is required to run RunAll to check all tests passed.
> Probably it is required to run release step to make sure release candidate
> can be prepared.
> This will affect at least ignite-log4j2, ignite-spark and probably other
> modules.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-9041) AssertionError in TcpCommunicationSpi
[ https://issues.apache.org/jira/browse/IGNITE-9041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Stelmak reassigned IGNITE-9041: -- Assignee: Alexey Stelmak > AssertionError in TcpCommunicationSpi > - > > Key: IGNITE-9041 > URL: https://issues.apache.org/jira/browse/IGNITE-9041 > Project: Ignite > Issue Type: Bug >Reporter: Alexey Stelmak >Assignee: Alexey Stelmak >Priority: Critical > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9041) AssertionError in TcpCommunicationSpi
[ https://issues.apache.org/jira/browse/IGNITE-9041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16550721#comment-16550721 ] Alexey Stelmak commented on IGNITE-9041: PR: https://github.com/apache/ignite/pull/4392 > AssertionError in TcpCommunicationSpi > - > > Key: IGNITE-9041 > URL: https://issues.apache.org/jira/browse/IGNITE-9041 > Project: Ignite > Issue Type: Bug >Reporter: Alexey Stelmak >Priority: Critical > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9041) AssertionError in TcpCommunicationSpi
[ https://issues.apache.org/jira/browse/IGNITE-9041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16550720#comment-16550720 ] ASF GitHub Bot commented on IGNITE-9041: GitHub user SpiderRus opened a pull request: https://github.com/apache/ignite/pull/4392 IGNITE-9041 AssertionError in TcpCommunicationSpi You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-9041 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4392.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #4392 commit e0af6ae9246225bdf4c179cca48ccd12a249f67f Author: Alexey Stelmak Date: 2018-07-20T12:10:32Z IGNITE-9041 > AssertionError in TcpCommunicationSpi > - > > Key: IGNITE-9041 > URL: https://issues.apache.org/jira/browse/IGNITE-9041 > Project: Ignite > Issue Type: Bug >Reporter: Alexey Stelmak >Priority: Critical > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9042) Transaction with small timeout may lead to inconsistent partition state
[ https://issues.apache.org/jira/browse/IGNITE-9042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Govorukhin updated IGNITE-9042: --- Component/s: cache > Transaction with small timeout may lead to inconsistent partition state > --- > > Key: IGNITE-9042 > URL: https://issues.apache.org/jira/browse/IGNITE-9042 > Project: Ignite > Issue Type: Bug > Components: cache >Reporter: Dmitriy Govorukhin >Assignee: Dmitriy Govorukhin >Priority: Critical > Fix For: 2.7 > > Attachments: Reproducer.java > > > The transaction with a small timeout may lead to inconsistent partition > state. > Reproducer in attached. > Problem in GridDhtTxPrepareFuture.sendPrepareRequests() if timeout will > reached during iteration over tx.dhtMap().values() we do not send > GridDhtTxPrepareRequest for some backups, it lead that backup will not know > anything about transaction and will not participate in commit. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9042) Transaction with small timeout may lead to inconsistent partition state
[ https://issues.apache.org/jira/browse/IGNITE-9042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Govorukhin updated IGNITE-9042: --- Description: The transaction with a small timeout may lead to inconsistent partition state. Reproducer in attached. Problem in GridDhtTxPrepareFuture.sendPrepareRequests() if timeout will reached during iteration over tx.dhtMap().values() we do not send GridDhtTxPrepareRequest for some backups, it lead that backup will not know anything about transaction and will not participate in commit. was: The transaction with a small timeout may lead to inconsistent partition state. Reproducer in attached. Problem in GridDhtTxPrepareFuture.sendPrepareRequests() if timeout will reached during iteration over tx.dhtMap().values() we do not send GridDhtTxPrepareRequest for some backups, it lead that backup will not know any think about transaction and will not participate in commit. > Transaction with small timeout may lead to inconsistent partition state > --- > > Key: IGNITE-9042 > URL: https://issues.apache.org/jira/browse/IGNITE-9042 > Project: Ignite > Issue Type: Bug >Reporter: Dmitriy Govorukhin >Assignee: Dmitriy Govorukhin >Priority: Critical > Fix For: 2.7 > > Attachments: Reproducer.java > > > The transaction with a small timeout may lead to inconsistent partition > state. > Reproducer in attached. > Problem in GridDhtTxPrepareFuture.sendPrepareRequests() if timeout will > reached during iteration over tx.dhtMap().values() we do not send > GridDhtTxPrepareRequest for some backups, it lead that backup will not know > anything about transaction and will not participate in commit. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-9042) Transaction with small timeout may lead to inconsistent partition state
[ https://issues.apache.org/jira/browse/IGNITE-9042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Govorukhin reassigned IGNITE-9042: -- Assignee: Dmitriy Govorukhin > Transaction with small timeout may lead to inconsistent partition state > --- > > Key: IGNITE-9042 > URL: https://issues.apache.org/jira/browse/IGNITE-9042 > Project: Ignite > Issue Type: Bug >Reporter: Dmitriy Govorukhin >Assignee: Dmitriy Govorukhin >Priority: Critical > Fix For: 2.7 > > Attachments: Reproducer.java > > > The transaction with a small timeout may lead to inconsistent partition > state. > Reproducer in attached. > Problem in GridDhtTxPrepareFuture.sendPrepareRequests() if timeout will > reached during iteration over tx.dhtMap().values() we do not send > GridDhtTxPrepareRequest for some backups, it lead that backup will not know > any think about transaction and will not participate in commit. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9042) Transaction with small timeout may lead to inconsistent partition state
[ https://issues.apache.org/jira/browse/IGNITE-9042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Govorukhin updated IGNITE-9042: --- Fix Version/s: 2.7 > Transaction with small timeout may lead to inconsistent partition state > --- > > Key: IGNITE-9042 > URL: https://issues.apache.org/jira/browse/IGNITE-9042 > Project: Ignite > Issue Type: Bug >Reporter: Dmitriy Govorukhin >Priority: Critical > Fix For: 2.7 > > Attachments: Reproducer.java > > > The transaction with a small timeout may lead to inconsistent partition > state. > Reproducer in attached. > Problem in GridDhtTxPrepareFuture.sendPrepareRequests() if timeout will > reached during iteration over tx.dhtMap().values() we do not send > GridDhtTxPrepareRequest for some backups, it lead that backup will not know > any think about transaction and will not participate in commit. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9042) Transaction with small timeout may lead to inconsistent partition state
Dmitriy Govorukhin created IGNITE-9042: -- Summary: Transaction with small timeout may lead to inconsistent partition state Key: IGNITE-9042 URL: https://issues.apache.org/jira/browse/IGNITE-9042 Project: Ignite Issue Type: Bug Reporter: Dmitriy Govorukhin Attachments: Reproducer.java The transaction with a small timeout may lead to inconsistent partition state. Reproducer in attached. Problem in GridDhtTxPrepareFuture.sendPrepareRequests() if timeout will reached during iteration over tx.dhtMap().values() we do not send GridDhtTxPrepareRequest for some backups, it lead that backup will not know any think about transaction and will not participate in commit. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9041) AssertionError in TcpCommunicationSpi
Alexey Stelmak created IGNITE-9041: -- Summary: AssertionError in TcpCommunicationSpi Key: IGNITE-9041 URL: https://issues.apache.org/jira/browse/IGNITE-9041 Project: Ignite Issue Type: Bug Reporter: Alexey Stelmak -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (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:comment-tabpanel=16550706#comment-16550706
]
Pavel Kovalenko commented on IGNITE-8783:
-
[~avinogradov] I've checked TC, no suspicious failures have observed. Overall
fix looks good, no objections from my side. Ready to merge.
> 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
>Assignee: Anton Vinogradov
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.7
>
>
> History of suite runs:
> https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_DataStructures=buildTypeHistoryList_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] [Assigned] (IGNITE-6343) Index is not used properly if changing sort order.
[
https://issues.apache.org/jira/browse/IGNITE-6343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roman Kondakov reassigned IGNITE-6343:
--
Assignee: (was: Roman Kondakov)
> Index is not used properly if changing sort order.
> --
>
> Key: IGNITE-6343
> URL: https://issues.apache.org/jira/browse/IGNITE-6343
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Affects Versions: 2.0
>Reporter: Alexei Scherbakov
>Priority: Major
> Labels: performance
>
> Unit test reproducer:
> {noformat}
> /*
> * Licensed to the Apache Software Foundation (ASF) under one or more
> * contributor license agreements. See the NOTICE file distributed with
> * this work for additional information regarding copyright ownership.
> * The ASF licenses this file to You under the Apache License, Version 2.0
> * (the "License"); you may not use this file except in compliance with
> * the License. You may obtain a copy of the License at
> *
> * http://www.apache.org/licenses/LICENSE-2.0
> *
> * Unless required by applicable law or agreed to in writing, software
> * distributed under the License is distributed on an "AS IS" BASIS,
> * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
> * See the License for the specific language governing permissions and
> * limitations under the License.
> */
> package org.apache.ignite.internal.processors.cache;
> import java.util.Calendar;
> import java.util.Collections;
> import java.util.Date;
> import java.util.LinkedHashMap;
> import java.util.List;
> import org.apache.ignite.IgniteCache;
> import org.apache.ignite.cache.CacheMode;
> import org.apache.ignite.cache.QueryEntity;
> import org.apache.ignite.cache.QueryIndex;
> import org.apache.ignite.cache.QueryIndexType;
> import org.apache.ignite.cache.query.SqlFieldsQuery;
> import org.apache.ignite.configuration.CacheConfiguration;
> import org.apache.ignite.configuration.IgniteConfiguration;
> import org.apache.ignite.configuration.MemoryConfiguration;
> import org.apache.ignite.configuration.MemoryPolicyConfiguration;
> import org.apache.ignite.internal.util.typedef.internal.U;
> import org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi;
> import org.apache.ignite.spi.discovery.tcp.ipfinder.TcpDiscoveryIpFinder;
> import org.apache.ignite.spi.discovery.tcp.ipfinder.vm.TcpDiscoveryVmIpFinder;
> import org.apache.ignite.testframework.junits.common.GridCommonAbstractTest;
> import static org.apache.ignite.cache.CacheMode.PARTITIONED;
> import static org.apache.ignite.cache.CacheWriteSynchronizationMode.FULL_SYNC;
> import static java.util.Calendar.*;
> /**
> * Tests for cache query results serialization.
> */
> public class GridCacheQueryIndexUsageSelfTest extends GridCommonAbstractTest {
> /** */
> private static final int GRID_CNT = 1;
> /** */
> private static final String CACHE_NAME = "A";
> /** */
> private static final CacheMode CACHE_MODE = PARTITIONED;
> /** */
> private static TcpDiscoveryIpFinder ipFinder = new
> TcpDiscoveryVmIpFinder(true);
> /** {@inheritDoc} */
> @Override protected void beforeTest() throws Exception {
> startGridsMultiThreaded(GRID_CNT);
> }
> /** {@inheritDoc} */
> @Override protected void afterTest() throws Exception {
> stopAllGrids();
> }
> /** {@inheritDoc} */
> @Override protected IgniteConfiguration getConfiguration(String
> igniteInstanceName) throws Exception {
> IgniteConfiguration cfg = super.getConfiguration(igniteInstanceName);
> MemoryPolicyConfiguration mpcfg = new MemoryPolicyConfiguration();
> //mpcfg.setMaxSize(2 * 1024 * 1024 * 1024L);
> mpcfg.setName("def");
> MemoryConfiguration mcfg = new MemoryConfiguration();
> mcfg.setDefaultMemoryPolicyName("def");
> mcfg.setMemoryPolicies(mpcfg);
> cfg.setMemoryConfiguration(mcfg);
> TcpDiscoverySpi disco = new TcpDiscoverySpi();
> disco.setIpFinder(ipFinder);
> cfg.setDiscoverySpi(disco);
> CacheConfiguration cacheCfg = defaultCacheConfiguration();
> cacheCfg.setName(CACHE_NAME);
> cacheCfg.setCacheMode(CACHE_MODE);
> cacheCfg.setWriteSynchronizationMode(FULL_SYNC);
> QueryEntity qe = new QueryEntity();
> qe.setKeyType(Long.class.getName());
> qe.setValueType(IndexedValue.class.getName());
> LinkedHashMap fields = U.newLinkedHashMap(3);
> fields.put("id", Long.class.getName());
> fields.put("startDate", Date.class.getName());
> qe.setFields(fields);
> QueryIndex idx = new QueryIndex();
> idx.setIndexType(QueryIndexType.SORTED);
> LinkedHashMap idxFields = U.newLinkedHashMap(3);
>
[jira] [Assigned] (IGNITE-6085) SQL: JOIN with multiple conditions is extremely slow
[
https://issues.apache.org/jira/browse/IGNITE-6085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roman Kondakov reassigned IGNITE-6085:
--
Assignee: (was: Roman Kondakov)
> SQL: JOIN with multiple conditions is extremely slow
>
>
> Key: IGNITE-6085
> URL: https://issues.apache.org/jira/browse/IGNITE-6085
> Project: Ignite
> Issue Type: Task
> Components: sql
>Affects Versions: 2.1
>Reporter: Vladimir Ozerov
>Priority: Major
> Labels: performance
>
> Consider the following query:
> {code}
> SELECT ... FROM A a
> INNER JOIN B b ON b.id = a.foreign_id1 OR b.id = a.foreign_id2
> {code}
> In this case H2 cannot use indexes on {{foreign_id1}} or {{foreign_id2}}
> columns and query execution takes extraordinary time. Known workaround for a
> problem is to apply multiple JOINs, e.g.:
> {code}
> SELECT ... FROM A a
> LEFT OUTER JOIN B b1 ON b1.id = a.foreign_id1
> LEFT OUTER JOIN B b2 ON b2.id = a.foreign_id2
> WHERE b1.id IS NOT NULL AND b2.id IS NOT NULL
> {code}
> On a single real-world scenario it improved exeution time by a factor of 500
> (from 4s to 80ms).
> Something is terribly wrong here. Probably, H2 cannot perform necessary query
> re-write, or cannot understand how to use index. Let's find a way to fix that.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9021) [ML] Refactor vectors to dence/sparse
[ https://issues.apache.org/jira/browse/IGNITE-9021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16550691#comment-16550691 ] ASF GitHub Bot commented on IGNITE-9021: Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/4385 > [ML] Refactor vectors to dence/sparse > -- > > Key: IGNITE-9021 > URL: https://issues.apache.org/jira/browse/IGNITE-9021 > Project: Ignite > Issue Type: Improvement > Components: ml >Reporter: Yury Babak >Assignee: Aleksey Zinoviev >Priority: Major > Fix For: 2.7 > > > We want to remove all unused implementations of Vector interface. Same for > matrices. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8915) NPE during executing local SqlQuery from client node
[
https://issues.apache.org/jira/browse/IGNITE-8915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16550692#comment-16550692
]
ASF GitHub Bot commented on IGNITE-8915:
Github user asfgit closed the pull request at:
https://github.com/apache/ignite/pull/4378
> NPE during executing local SqlQuery from client node
>
>
> Key: IGNITE-8915
> URL: https://issues.apache.org/jira/browse/IGNITE-8915
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Vyacheslav Daradur
>Assignee: Nikolay Izhikov
>Priority: Major
> Fix For: 2.7
>
> Attachments: IgniteCacheReplicatedClientLocalQuerySelfTest.java
>
>
> NPE when trying to execute {{SqlQuery}} with {{setLocal(true)}} from client
> node.
> [Reproducer|^IgniteCacheReplicatedClientLocalQuerySelfTest.java].
> UPD:
> Right behavior:
> Local query should be forbidden and a sensible exception should be thrown if
> it is executed on client node.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8188) Batching operations should perform check for ZooKeeper request max size
[ https://issues.apache.org/jira/browse/IGNITE-8188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16550684#comment-16550684 ] Amelchev Nikita commented on IGNITE-8188: - [~sergey-chugunov] I have investigated _ZookeeperDiscoverySpiTest.testCommunicationFailureResolve_CachesInfo1_ test. The fail reason is _getChildrenIfPathExists_ method throws NoNode exception. This is in _deleteFutureData_ method where I have removed catching exception after review. I suggest revert it and resolve this problem in IGNITE-8189. I have updated this PR. What do you think? > Batching operations should perform check for ZooKeeper request max size > --- > > Key: IGNITE-8188 > URL: https://issues.apache.org/jira/browse/IGNITE-8188 > Project: Ignite > Issue Type: Improvement > Components: zookeeper >Reporter: Sergey Chugunov >Assignee: Amelchev Nikita >Priority: Major > Fix For: 2.7 > > > As ZooKeeper documentation > [says|https://zookeeper.apache.org/doc/r3.4.3/api/org/apache/zookeeper/ZooKeeper.html#multi(java.lang.Iterable)] > batching *multi* operation has a limit for size of a single request. > ZookeeperClient batching methods *createAll* and *deleteAll* should check > this limit and fall back to execute operations one by one. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8892) Iterating over large dataset via ScanQuery can fails with OOME.
[ https://issues.apache.org/jira/browse/IGNITE-8892?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stanilovsky Evgeny updated IGNITE-8892: --- Attachment: list-master.jfr list-8892.jfr > Iterating over large dataset via ScanQuery can fails with OOME. > --- > > Key: IGNITE-8892 > URL: https://issues.apache.org/jira/browse/IGNITE-8892 > Project: Ignite > Issue Type: Bug > Components: cache >Reporter: Andrew Mashenkov >Assignee: Andrew Mashenkov >Priority: Critical > Labels: OutOfMemoryError > Fix For: 2.7 > > Attachments: ScanQueryOOM.java, list-8892.jfr, list-master.jfr > > > Seems, iterating over query iterator (ScanQuery at least, but may be other > affected as well) on client node cause memory leakage. > The use case is quite simple. > Start server and client. Put much data into cache, then iterate over all > entries via ScanQuery. > Looks like JVM crashed due to OOM as GridCacheDistributedQueryFuture.allCol > map contains to many entries. > I've put 15kk entries into cache and client failed with OOM after iterating > over 10kk entry. > In heapdump I observer 10kk GridCacheDistributedQueryFuture entries. > We have to check if collection cleared correctly and it is really need to > collect all entries. > PFA repro. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8892) Iterating over large dataset via ScanQuery can fails with OOME.
[ https://issues.apache.org/jira/browse/IGNITE-8892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16550678#comment-16550678 ] Stanilovsky Evgeny commented on IGNITE-8892: i append additional test, and collect jfr from master and this branch test run. > Iterating over large dataset via ScanQuery can fails with OOME. > --- > > Key: IGNITE-8892 > URL: https://issues.apache.org/jira/browse/IGNITE-8892 > Project: Ignite > Issue Type: Bug > Components: cache >Reporter: Andrew Mashenkov >Assignee: Andrew Mashenkov >Priority: Critical > Labels: OutOfMemoryError > Fix For: 2.7 > > Attachments: ScanQueryOOM.java, list-8892.jfr, list-master.jfr > > > Seems, iterating over query iterator (ScanQuery at least, but may be other > affected as well) on client node cause memory leakage. > The use case is quite simple. > Start server and client. Put much data into cache, then iterate over all > entries via ScanQuery. > Looks like JVM crashed due to OOM as GridCacheDistributedQueryFuture.allCol > map contains to many entries. > I've put 15kk entries into cache and client failed with OOM after iterating > over 10kk entry. > In heapdump I observer 10kk GridCacheDistributedQueryFuture entries. > We have to check if collection cleared correctly and it is really need to > collect all entries. > PFA repro. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8892) Iterating over large dataset via ScanQuery can fails with OOME.
[ https://issues.apache.org/jira/browse/IGNITE-8892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16550677#comment-16550677 ] ASF GitHub Bot commented on IGNITE-8892: GitHub user zstan opened a pull request: https://github.com/apache/ignite/pull/4391 IGNITE-8892 add additional test. You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-8892-zstan Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4391.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #4391 commit 36f743f739e34fada7db2826827e1aea1136b7a8 Author: Andrey V. Mashenkov Date: 2018-06-28T14:45:06Z ignite-8892: Get rid of CacheQuery.keepAll flag. commit 0ffd92dac85f5a7e75a1902b2b20ff643b058b4a Author: Evgeny Stanilovskiy Date: 2018-07-20T09:33:46Z IGNITE-8892 add additional test. > Iterating over large dataset via ScanQuery can fails with OOME. > --- > > Key: IGNITE-8892 > URL: https://issues.apache.org/jira/browse/IGNITE-8892 > Project: Ignite > Issue Type: Bug > Components: cache >Reporter: Andrew Mashenkov >Assignee: Andrew Mashenkov >Priority: Critical > Labels: OutOfMemoryError > Fix For: 2.7 > > Attachments: ScanQueryOOM.java > > > Seems, iterating over query iterator (ScanQuery at least, but may be other > affected as well) on client node cause memory leakage. > The use case is quite simple. > Start server and client. Put much data into cache, then iterate over all > entries via ScanQuery. > Looks like JVM crashed due to OOM as GridCacheDistributedQueryFuture.allCol > map contains to many entries. > I've put 15kk entries into cache and client failed with OOM after iterating > over 10kk entry. > In heapdump I observer 10kk GridCacheDistributedQueryFuture entries. > We have to check if collection cleared correctly and it is really need to > collect all entries. > PFA repro. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9040) StopNodeFailureHandler is not able to stop node correctly on node segmentation
[
https://issues.apache.org/jira/browse/IGNITE-9040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Chugunov updated IGNITE-9040:
Description:
When flag *IGNITE_WAL_LOG_TX_RECORDS* is set up special TxRecords are logged to
WAL even on node stop.
With STOP segmentation policy *StopNodeFailureHandler* is used to stop the
segmented node and it marks node's state as invalid. As a result all write
requests to WAL get failed.
So as part of stop-on-segmentation procedure node needs to log Tx but it cannot
as its state is marked as invalid. This leads to stop procedure finishing
incorrectly, some threads started by the node are not cleaned up.
Exception example:
{noformat}
[2018-07-20 13:35:36,358][ERROR][node-stopper][ZookeeperDiscoverySpiTest0]
Failed to pre-stop processor: GridProcessorAdapter []
class org.apache.ignite.IgniteException: Failed to log TxRecord: TxRecord
[state=PREPARED, nearXidVer=GridCacheVersion [topVer=143562918,
order=1532082921780, nodeOrder=3], writeVer=GridCacheVersion [topVer=143562918,
order=1532082921781, nodeOrder=1], super=TimeStampRecord
[timestamp=1532082936349]]
at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxAdapter.state(IgniteTxAdapter.java:1132)
at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxAdapter.state(IgniteTxAdapter.java:968)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.onComplete(GridDhtTxPrepareFuture.java:983)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.onDone(GridDhtTxPrepareFuture.java:717)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.onDone(GridDhtTxPrepareFuture.java:105)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:462)
at
org.apache.ignite.internal.processors.cache.GridCacheMvccManager.cancelClientFutures(GridCacheMvccManager.java:425)
at
org.apache.ignite.internal.processors.cache.GridCacheMvccManager.onStop(GridCacheMvccManager.java:410)
at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.onKernalStop(GridCacheProcessor.java:984)
at org.apache.ignite.internal.IgniteKernal.stop0(IgniteKernal.java:2134)
at org.apache.ignite.internal.IgniteKernal.stop(IgniteKernal.java:2082)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop0(IgnitionEx.java:2595)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop(IgnitionEx.java:2558)
at org.apache.ignite.internal.IgnitionEx.stop(IgnitionEx.java:374)
at
org.apache.ignite.failure.StopNodeFailureHandler$1.run(StopNodeFailureHandler.java:36)
at java.lang.Thread.run(Thread.java:745)
Caused by: class org.apache.ignite.internal.pagemem.wal.StorageException:
Failed to perform WAL operation (environment was invalidated by a previous
error)
at
org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.checkNode(FileWriteAheadLogManager.java:1504)
at
org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.access$6100(FileWriteAheadLogManager.java:143)
at
org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileWriteHandle.addRecord(FileWriteAheadLogManager.java:2611)
at
org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileWriteHandle.access$1500(FileWriteAheadLogManager.java:2521)
at
org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.log(FileWriteAheadLogManager.java:758)
at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxAdapter.state(IgniteTxAdapter.java:1127)
... 15 more
{noformat}
was:
When flag *IGNITE_WAL_LOG_TX_RECORDS* is set up special TxRecords are logged to
WAL even on node stop.
With STOP segmentation policy *StopNodeFailureHandler* is used to stop the
segmented node and it marks node's state as invalid. As a result all write
requests to WAL get failed.
So as part of stop-on-segmentation procedure node needs to log Tx but it cannot
as its state is marked as invalid. This leads to stop procedure finishing
incorrectly, some threads started by the node are not cleaned up.
> StopNodeFailureHandler is not able to stop node correctly on node segmentation
> --
>
> Key: IGNITE-9040
> URL: https://issues.apache.org/jira/browse/IGNITE-9040
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.6
>Reporter: Sergey Chugunov
>Assignee: Sergey Chugunov
>Priority: Major
> Fix For: 2.7
>
>
> When flag *IGNITE_WAL_LOG_TX_RECORDS* is set up
[jira] [Created] (IGNITE-9040) StopNodeFailureHandler is not able to stop node correctly on node segmentation
Sergey Chugunov created IGNITE-9040: --- Summary: StopNodeFailureHandler is not able to stop node correctly on node segmentation Key: IGNITE-9040 URL: https://issues.apache.org/jira/browse/IGNITE-9040 Project: Ignite Issue Type: Bug Affects Versions: 2.6 Reporter: Sergey Chugunov Assignee: Sergey Chugunov Fix For: 2.7 When flag *IGNITE_WAL_LOG_TX_RECORDS* is set up special TxRecords are logged to WAL even on node stop. With STOP segmentation policy *StopNodeFailureHandler* is used to stop the segmented node and it marks node's state as invalid. As a result all write requests to WAL get failed. So as part of stop-on-segmentation procedure node needs to log Tx but it cannot as its state is marked as invalid. This leads to stop procedure finishing incorrectly, some threads started by the node are not cleaned up. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9039) AssertionError on cache stop
[
https://issues.apache.org/jira/browse/IGNITE-9039?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16550649#comment-16550649
]
Eduard Shangareev commented on IGNITE-9039:
---
Cache 7 - https://ci.ignite.apache.org/viewQueued.html?itemId=1522634
Run All -
https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_RunAll_IgniteTests24Java8=pull%2F4390%2Fhead=buildTypeStatusDiv
> AssertionError on cache stop
>
>
> Key: IGNITE-9039
> URL: https://issues.apache.org/jira/browse/IGNITE-9039
> Project: Ignite
> Issue Type: Bug
>Reporter: Eduard Shangareev
>Assignee: Eduard Shangareev
>Priority: Major
>
> It was introduced by IGNITE-8955:
> {code}
> [2018-07-20 13:24:39,190][INFO
> ][exchange-worker-#38%db.CheckpointBufferDeadlockTest0%][root]
> [GridStringLogger echo] class org.apache.ignite.IgniteCheckedException:
> Compound exception for CountDownFuture. at
> org.apache.ignite.internal.util.future.CountDownFuture.addError(CountDownFuture.java:72)
> at
> org.apache.ignite.internal.util.future.CountDownFuture.onDone(CountDownFuture.java:46)
> at
> org.apache.ignite.internal.util.future.CountDownFuture.onDone(CountDownFuture.java:28)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:462)
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl$ClearSegmentRunnable.run(PageMemoryImpl.java:2757)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> Suppressed: java.lang.AssertionError: Release pinned page: FullPageId
> [pageId=00013c43, effectivePageId=3c43, grpId=-1778028968]
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl$PagePool.releaseFreePage(PageMemoryImpl.java:1787)
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl$PagePool.access$1900(PageMemoryImpl.java:1659)
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl$ClearSegmentRunnable.run(PageMemoryImpl.java:2748)
> ... 3 more
> Suppressed: java.lang.AssertionError: Release pinned page: FullPageId
> [pageId=000128bc, effectivePageId=28bc, grpId=-1778028968]
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl$PagePool.releaseFreePage(PageMemoryImpl.java:1787)
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl$PagePool.access$1900(PageMemoryImpl.java:1659)
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl$ClearSegmentRunnable.run(PageMemoryImpl.java:2748)
> ... 3 more
> Suppressed: java.lang.AssertionError: Release pinned page: FullPageId
> [pageId=00013f1a, effectivePageId=3f1a, grpId=-1778028968]
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl$PagePool.releaseFreePage(PageMemoryImpl.java:1787)
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl$PagePool.access$1900(PageMemoryImpl.java:1659)
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl$ClearSegmentRunnable.run(PageMemoryImpl.java:2748)
> ... 3 more
> Suppressed: java.lang.AssertionError: Release pinned page: FullPageId
> [pageId=00012eb9, effectivePageId=2eb9, grpId=-1778028968]
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl$PagePool.releaseFreePage(PageMemoryImpl.java:1787)
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl$PagePool.access$1900(PageMemoryImpl.java:1659)
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl$ClearSegmentRunnable.run(PageMemoryImpl.java:2748)
> ... 3 more
> Suppressed: java.lang.AssertionError: Release pinned page: FullPageId
> [pageId=000120f2, effectivePageId=20f2, grpId=-1778028968]
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl$PagePool.releaseFreePage(PageMemoryImpl.java:1787)
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl$PagePool.access$1900(PageMemoryImpl.java:1659)
> at
>
[jira] [Commented] (IGNITE-9039) AssertionError on cache stop
[
https://issues.apache.org/jira/browse/IGNITE-9039?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16550637#comment-16550637
]
ASF GitHub Bot commented on IGNITE-9039:
GitHub user EdShangGG opened a pull request:
https://github.com/apache/ignite/pull/4390
IGNITE-9039 AssertionError on cache stop
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-9039
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/4390.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #4390
commit a9cc8fbc0541b32c65e373f566777cebb33aac57
Author: Eduard Shangareev
Date: 2018-07-20T10:38:27Z
IGNITE-9039 AssertionError on cache stop
> AssertionError on cache stop
>
>
> Key: IGNITE-9039
> URL: https://issues.apache.org/jira/browse/IGNITE-9039
> Project: Ignite
> Issue Type: Bug
>Reporter: Eduard Shangareev
>Assignee: Eduard Shangareev
>Priority: Major
>
> It was introduced by IGNITE-8955:
> {code}
> [2018-07-20 13:24:39,190][INFO
> ][exchange-worker-#38%db.CheckpointBufferDeadlockTest0%][root]
> [GridStringLogger echo] class org.apache.ignite.IgniteCheckedException:
> Compound exception for CountDownFuture. at
> org.apache.ignite.internal.util.future.CountDownFuture.addError(CountDownFuture.java:72)
> at
> org.apache.ignite.internal.util.future.CountDownFuture.onDone(CountDownFuture.java:46)
> at
> org.apache.ignite.internal.util.future.CountDownFuture.onDone(CountDownFuture.java:28)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:462)
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl$ClearSegmentRunnable.run(PageMemoryImpl.java:2757)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> Suppressed: java.lang.AssertionError: Release pinned page: FullPageId
> [pageId=00013c43, effectivePageId=3c43, grpId=-1778028968]
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl$PagePool.releaseFreePage(PageMemoryImpl.java:1787)
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl$PagePool.access$1900(PageMemoryImpl.java:1659)
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl$ClearSegmentRunnable.run(PageMemoryImpl.java:2748)
> ... 3 more
> Suppressed: java.lang.AssertionError: Release pinned page: FullPageId
> [pageId=000128bc, effectivePageId=28bc, grpId=-1778028968]
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl$PagePool.releaseFreePage(PageMemoryImpl.java:1787)
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl$PagePool.access$1900(PageMemoryImpl.java:1659)
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl$ClearSegmentRunnable.run(PageMemoryImpl.java:2748)
> ... 3 more
> Suppressed: java.lang.AssertionError: Release pinned page: FullPageId
> [pageId=00013f1a, effectivePageId=3f1a, grpId=-1778028968]
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl$PagePool.releaseFreePage(PageMemoryImpl.java:1787)
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl$PagePool.access$1900(PageMemoryImpl.java:1659)
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl$ClearSegmentRunnable.run(PageMemoryImpl.java:2748)
> ... 3 more
> Suppressed: java.lang.AssertionError: Release pinned page: FullPageId
> [pageId=00012eb9, effectivePageId=2eb9, grpId=-1778028968]
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl$PagePool.releaseFreePage(PageMemoryImpl.java:1787)
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl$PagePool.access$1900(PageMemoryImpl.java:1659)
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl$ClearSegmentRunnable.run(PageMemoryImpl.java:2748)
> ... 3 more
> Suppressed: java.lang.AssertionError: Release pinned page: FullPageId
>
[jira] [Commented] (IGNITE-8705) CacheMBStatisticsBeanTest.testClear failed
[ https://issues.apache.org/jira/browse/IGNITE-8705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16550636#comment-16550636 ] Ryabov Dmitrii commented on IGNITE-8705: Code looks good. Tests are ok. > CacheMBStatisticsBeanTest.testClear failed > -- > > Key: IGNITE-8705 > URL: https://issues.apache.org/jira/browse/IGNITE-8705 > Project: Ignite > Issue Type: Sub-task >Reporter: Alexander Menshikov >Assignee: Denis Garus >Priority: Major > Labels: iep-21 > Fix For: 2.7 > > > JCache TCK 1.1 now have test for CacheClusterMetricsMXBeanImpl#clear(), but > we currently throw UnsupportedOperationException. > *UPD1:* > There are two options how we can fix the problem: > # May be we can use local MXBean for this test. > # Add the way to clean metrics on cluster. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9038) Node join serialization defaults
[ https://issues.apache.org/jira/browse/IGNITE-9038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16550627#comment-16550627 ] Dmitry Karachentsev commented on IGNITE-9038: - [PR 4389 | https://github.com/apache/ignite/pull/4389] > Node join serialization defaults > > > Key: IGNITE-9038 > URL: https://issues.apache.org/jira/browse/IGNITE-9038 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.6 >Reporter: Dmitry Karachentsev >Assignee: Dmitry Karachentsev >Priority: Major > Fix For: 2.7 > > > staticallyConfigured flag in CacheJoinNodeDiscoveryData.CacheInfo should be > true by default to keep it consistent to previous protocol. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9039) AssertionError on cache stop
Eduard Shangareev created IGNITE-9039:
-
Summary: AssertionError on cache stop
Key: IGNITE-9039
URL: https://issues.apache.org/jira/browse/IGNITE-9039
Project: Ignite
Issue Type: Bug
Reporter: Eduard Shangareev
Assignee: Eduard Shangareev
It was introduced by IGNITE-8955:
{code}
[2018-07-20 13:24:39,190][INFO
][exchange-worker-#38%db.CheckpointBufferDeadlockTest0%][root]
[GridStringLogger echo] class org.apache.ignite.IgniteCheckedException:
Compound exception for CountDownFuture. at
org.apache.ignite.internal.util.future.CountDownFuture.addError(CountDownFuture.java:72)
at
org.apache.ignite.internal.util.future.CountDownFuture.onDone(CountDownFuture.java:46)
at
org.apache.ignite.internal.util.future.CountDownFuture.onDone(CountDownFuture.java:28)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:462)
at
org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl$ClearSegmentRunnable.run(PageMemoryImpl.java:2757)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Suppressed: java.lang.AssertionError: Release pinned page: FullPageId
[pageId=00013c43, effectivePageId=3c43, grpId=-1778028968]
at
org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl$PagePool.releaseFreePage(PageMemoryImpl.java:1787)
at
org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl$PagePool.access$1900(PageMemoryImpl.java:1659)
at
org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl$ClearSegmentRunnable.run(PageMemoryImpl.java:2748)
... 3 more
Suppressed: java.lang.AssertionError: Release pinned page: FullPageId
[pageId=000128bc, effectivePageId=28bc, grpId=-1778028968]
at
org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl$PagePool.releaseFreePage(PageMemoryImpl.java:1787)
at
org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl$PagePool.access$1900(PageMemoryImpl.java:1659)
at
org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl$ClearSegmentRunnable.run(PageMemoryImpl.java:2748)
... 3 more
Suppressed: java.lang.AssertionError: Release pinned page: FullPageId
[pageId=00013f1a, effectivePageId=3f1a, grpId=-1778028968]
at
org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl$PagePool.releaseFreePage(PageMemoryImpl.java:1787)
at
org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl$PagePool.access$1900(PageMemoryImpl.java:1659)
at
org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl$ClearSegmentRunnable.run(PageMemoryImpl.java:2748)
... 3 more
Suppressed: java.lang.AssertionError: Release pinned page: FullPageId
[pageId=00012eb9, effectivePageId=2eb9, grpId=-1778028968]
at
org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl$PagePool.releaseFreePage(PageMemoryImpl.java:1787)
at
org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl$PagePool.access$1900(PageMemoryImpl.java:1659)
at
org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl$ClearSegmentRunnable.run(PageMemoryImpl.java:2748)
... 3 more
Suppressed: java.lang.AssertionError: Release pinned page: FullPageId
[pageId=000120f2, effectivePageId=20f2, grpId=-1778028968]
at
org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl$PagePool.releaseFreePage(PageMemoryImpl.java:1787)
at
org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl$PagePool.access$1900(PageMemoryImpl.java:1659)
at
org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl$ClearSegmentRunnable.run(PageMemoryImpl.java:2748)
... 3 more
Suppressed: java.lang.AssertionError: Release pinned page: FullPageId
[pageId=000115e9, effectivePageId=15e9, grpId=-1778028968]
at
org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl$PagePool.releaseFreePage(PageMemoryImpl.java:1787)
at
[jira] [Created] (IGNITE-9038) Node join serialization defaults
Dmitry Karachentsev created IGNITE-9038: --- Summary: Node join serialization defaults Key: IGNITE-9038 URL: https://issues.apache.org/jira/browse/IGNITE-9038 Project: Ignite Issue Type: Bug Components: cache Affects Versions: 2.6 Reporter: Dmitry Karachentsev Assignee: Dmitry Karachentsev Fix For: 2.7 staticallyConfigured flag in CacheJoinNodeDiscoveryData.CacheInfo should be true by default to keep it consistent to previous protocol. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8900) SqlFieldsQuery provides incorrect result when item size exceeds page size
[
https://issues.apache.org/jira/browse/IGNITE-8900?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16550508#comment-16550508
]
Alexey Goncharuk commented on IGNITE-8900:
--
[~ilantukh],
I see the following tests failing in the branch compared to master, can you
please take a look?
{code}
IgnitePdsWithIndexingCoreTestSuite:
IgnitePdsAtomicCacheHistoricalRebalancingTest.testForceRebalance (fail rate
0,0%)
IgnitePdsWithIndexingCoreTestSuite:
IgnitePdsAtomicCacheHistoricalRebalancingTest.testRebalancingOnRestart
(fail rate 0,0%)
IgnitePdsWithIndexingCoreTestSuite:
IgnitePdsAtomicCacheHistoricalRebalancingTest.testRebalancingOnRestartAfterCheckpoint
(fail rate 0,0%)
{code}
> SqlFieldsQuery provides incorrect result when item size exceeds page size
> -
>
> Key: IGNITE-8900
> URL: https://issues.apache.org/jira/browse/IGNITE-8900
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.4
>Reporter: Anton Kurbanov
>Assignee: Ilya Lantukh
>Priority: Blocker
> Attachments: Main.java, Node.java
>
>
> Start several server nodes, then start client, execute queries with value
> range in where clause. Duplicate entries may be found, some entries may be
> missing.
> Results as an example:
> expected 5 results but got back 3 results (query range 61002664327616 to
> 610026643276160004), cache.getAll returned 5 entries.
> expected 8 results but got back 7 results (query range 61002664327616 to
> 610026643276160007), cache.getAll returned 8 entries.
> Query results: [61002664327616, 610026643276160003, 610026643276160004,
> 610026643276160005, 610026643276160005, 610026643276160006,
> 610026643276160007]
> Please find reproducer attached.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8926) Deadlock in meta data registration
[
https://issues.apache.org/jira/browse/IGNITE-8926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16550507#comment-16550507
]
Alexey Goncharuk commented on IGNITE-8926:
--
[~ilantukh],
I see consistent failures of the following .NET tests:
{code}
exe: CacheAbstractTest.TestInvoke (fail rate 0,0%)
exe: CacheAbstractTest.TestInvokeAll (fail rate 0,0%)
exe: CacheAbstractTest.TestInvokeAllAsync (fail rate 0,0%)
exe: CacheAbstractTest.TestInvokeAsync (fail rate 0,0%)
exe: CacheAbstractTest.TestInvoke (fail rate 0,0%)
exe: CacheAbstractTest.TestInvokeAll (fail rate 0,0%)
exe: CacheAbstractTest.TestInvokeAllAsync (fail rate 0,0%)
exe: CacheAbstractTest.TestInvokeAsync (fail rate 0,0%)
exe: CacheAbstractTest.TestInvoke (fail rate 0,0%)
exe: CacheAbstractTest.TestInvokeAll (fail rate 0,0%)
exe: CacheAbstractTest.TestInvokeAllAsync (fail rate 0,0%)
exe: CacheAbstractTest.TestInvokeAsync (fail rate 0,0%)
{code}
Can you please take a look?
> Deadlock in meta data registration
> --
>
> Key: IGNITE-8926
> URL: https://issues.apache.org/jira/browse/IGNITE-8926
> Project: Ignite
> Issue Type: Bug
> Components: general
>Reporter: Mikhail Cherkasov
>Assignee: Ilya Lantukh
>Priority: Major
> Attachments: DeadlockTest.java, file.jstack
>
>
>
> Please file the attached jstack file with a deadlock.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-8552) Unable to use date as primary key
[
https://issues.apache.org/jira/browse/IGNITE-8552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16550495#comment-16550495
]
Sergey Kozlov edited comment on IGNITE-8552 at 7/20/18 8:35 AM:
There's the another effect after issued {{CREATE TABLE t1 (id DATE NOT NULL
..., PRIMARY KEY (id))}}
Try to create new table ({{CREATE TABLE t1 (id INT NOT NULL, name VARCHAR,
PRIMARY KEY (id))}}) causes in sqlline hung and the node prints out exception:
{noformat}
java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
at java.util.ArrayList.rangeCheck(ArrayList.java:653)
at java.util.ArrayList.get(ArrayList.java:429)
at
org.apache.ignite.internal.processors.cache.CacheGroupContext.singleCacheContext(CacheGroupContext.java:385)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLocalPartition.(GridDhtLocalPartitio
n.java:198)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl.getOrCreatePartition
(GridDhtPartitionTopologyImpl.java:812)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl.initPartitions(GridD
htPartitionTopologyImpl.java:368)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl.beforeExchange(GridD
htPartitionTopologyImpl.java:543)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.distrib
utedExchange(GridDhtPartitionsExchangeFuture.java:1141)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(Gr
idDhtPartitionsExchangeFuture.java:712)
at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body0(GridCacheP
artitionExchangeManager.java:2419)
at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePa
rtitionExchangeManager.java:2299)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
at java.lang.Thread.run(Thread.java:745)
{noformat}
was (Author: skozlov):
There's the another effect after issued {{CREATE TABLE t1 (id DATE NOT NULL
..., PRIMARY KEY (id))}}
Try to create new table ({{CREATE TABLE t1 (id INT NOT NULL, name VARCHAR,
PRIMARY KEY (id))}}) causes in sqlline hung and the node prints out exception:
{format}
java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
at java.util.ArrayList.rangeCheck(ArrayList.java:653)
at java.util.ArrayList.get(ArrayList.java:429)
at
org.apache.ignite.internal.processors.cache.CacheGroupContext.singleCacheContext(CacheGroupContext.java:385)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLocalPartition.(GridDhtLocalPartitio
n.java:198)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl.getOrCreatePartition
(GridDhtPartitionTopologyImpl.java:812)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl.initPartitions(GridD
htPartitionTopologyImpl.java:368)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl.beforeExchange(GridD
htPartitionTopologyImpl.java:543)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.distrib
utedExchange(GridDhtPartitionsExchangeFuture.java:1141)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(Gr
idDhtPartitionsExchangeFuture.java:712)
at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body0(GridCacheP
artitionExchangeManager.java:2419)
at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePa
rtitionExchangeManager.java:2299)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
at java.lang.Thread.run(Thread.java:745)
{format}
> Unable to use date as primary key
> -
>
> Key: IGNITE-8552
> URL: https://issues.apache.org/jira/browse/IGNITE-8552
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.4
>Reporter: Pavel Vinokurov
>Assignee: Vladimir Ozerov
>Priority: Blocker
> Fix For: 2.7
>
>
> It' is unable to create cache via ddl:
> create table tab(id date primary key, date_field date);
> Result:
> ERROR CacheAffinitySharedManager - Failed to initialize cache. Will try to
> rollback cache start routine. [cacheName=SQL_PUBLIC_T3]
> class org.apache.ignite.IgniteCheckedException: Failed to find value class in
>
[jira] [Commented] (IGNITE-8552) Unable to use date as primary key
[
https://issues.apache.org/jira/browse/IGNITE-8552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16550495#comment-16550495
]
Sergey Kozlov commented on IGNITE-8552:
---
There's the another effect after issued {{CREATE TABLE t1 (id DATE NOT NULL
..., PRIMARY KEY (id))}}
Try to create new table ({{CREATE TABLE t1 (id INT NOT NULL, name VARCHAR,
PRIMARY KEY (id))}}) causes in sqlline hung and the node prints out exception:
{format}
java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
at java.util.ArrayList.rangeCheck(ArrayList.java:653)
at java.util.ArrayList.get(ArrayList.java:429)
at
org.apache.ignite.internal.processors.cache.CacheGroupContext.singleCacheContext(CacheGroupContext.java:385)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLocalPartition.(GridDhtLocalPartitio
n.java:198)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl.getOrCreatePartition
(GridDhtPartitionTopologyImpl.java:812)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl.initPartitions(GridD
htPartitionTopologyImpl.java:368)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl.beforeExchange(GridD
htPartitionTopologyImpl.java:543)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.distrib
utedExchange(GridDhtPartitionsExchangeFuture.java:1141)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(Gr
idDhtPartitionsExchangeFuture.java:712)
at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body0(GridCacheP
artitionExchangeManager.java:2419)
at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePa
rtitionExchangeManager.java:2299)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
at java.lang.Thread.run(Thread.java:745)
{format}
> Unable to use date as primary key
> -
>
> Key: IGNITE-8552
> URL: https://issues.apache.org/jira/browse/IGNITE-8552
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.4
>Reporter: Pavel Vinokurov
>Assignee: Vladimir Ozerov
>Priority: Blocker
> Fix For: 2.7
>
>
> It' is unable to create cache via ddl:
> create table tab(id date primary key, date_field date);
> Result:
> ERROR CacheAffinitySharedManager - Failed to initialize cache. Will try to
> rollback cache start routine. [cacheName=SQL_PUBLIC_T3]
> class org.apache.ignite.IgniteCheckedException: Failed to find value class in
> the node classpath (use default marshaller to enable binary objects) :
> SQL_PUBLIC_T3_e90848b2_fe30_4adb_a934_6e13ca0eb409
> at
> org.apache.ignite.internal.processors.query.QueryUtils.typeForQueryEntity(QueryUtils.java:426)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (IGNITE-6190) SQL query fails silently if Set is passed as a parameter
[
https://issues.apache.org/jira/browse/IGNITE-6190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roman Shtykh closed IGNITE-6190.
> SQL query fails silently if Set is passed as a parameter
>
>
> Key: IGNITE-6190
> URL: https://issues.apache.org/jira/browse/IGNITE-6190
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Denis Magda
>Assignee: Roman Shtykh
>Priority: Major
> Labels: usability
> Attachments: TestIgniteQuery.zip
>
>
> Seems like the SqlQuery API does not like {{Set}} as the input parameter.
> While this query doesn't work (the Set is used as an input):
> {code}
> public Map getAccountsForLe(Set leId) {
> SqlQuery query =
> new SqlQuery(Account.class, "from Account join
> table(id varchar = ?) i on Account.clientLegalEntityId = i.id")
> .setArgs(leId);
> Map results = new HashMap<>();
> _cache.query(query).getAll().stream().forEach(e ->
> results.put(e.getKey(), e.getValue()));
> return results;
> }
> {code}
> This one works well (the Set is converted to Array explicitly):
> {code}
> public Map getAccountsForLe(Set leId) {
> SqlQuery query =
> new SqlQuery(Account.class, "from Account join
> table(id varchar = ?) i on Account.clientLegalEntityId = i.id")
> .setArgs(leId.toArray());
> Map results = new HashMap<>();
> _cache.query(query).getAll().stream().forEach(e ->
> results.put(e.getKey(), e.getValue()));
> return results;
> }
> {code}
> The fact that it fails silently is an issue. IMHO there should be some
> validation to alert the calling code that the type specified is not valid or
> the set has to be transformed to the array on the fly.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (IGNITE-6190) SQL query fails silently if Set is passed as a parameter
[
https://issues.apache.org/jira/browse/IGNITE-6190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roman Shtykh resolved IGNITE-6190.
--
Resolution: Won't Fix
> SQL query fails silently if Set is passed as a parameter
>
>
> Key: IGNITE-6190
> URL: https://issues.apache.org/jira/browse/IGNITE-6190
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Denis Magda
>Assignee: Roman Shtykh
>Priority: Major
> Labels: usability
> Attachments: TestIgniteQuery.zip
>
>
> Seems like the SqlQuery API does not like {{Set}} as the input parameter.
> While this query doesn't work (the Set is used as an input):
> {code}
> public Map getAccountsForLe(Set leId) {
> SqlQuery query =
> new SqlQuery(Account.class, "from Account join
> table(id varchar = ?) i on Account.clientLegalEntityId = i.id")
> .setArgs(leId);
> Map results = new HashMap<>();
> _cache.query(query).getAll().stream().forEach(e ->
> results.put(e.getKey(), e.getValue()));
> return results;
> }
> {code}
> This one works well (the Set is converted to Array explicitly):
> {code}
> public Map getAccountsForLe(Set leId) {
> SqlQuery query =
> new SqlQuery(Account.class, "from Account join
> table(id varchar = ?) i on Account.clientLegalEntityId = i.id")
> .setArgs(leId.toArray());
> Map results = new HashMap<>();
> _cache.query(query).getAll().stream().forEach(e ->
> results.put(e.getKey(), e.getValue()));
> return results;
> }
> {code}
> The fact that it fails silently is an issue. IMHO there should be some
> validation to alert the calling code that the type specified is not valid or
> the set has to be transformed to the array on the fly.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-9037) Apache Pulsar intergration
Roman Shtykh created IGNITE-9037: Summary: Apache Pulsar intergration Key: IGNITE-9037 URL: https://issues.apache.org/jira/browse/IGNITE-9037 Project: Ignite Issue Type: New Feature Components: streaming Reporter: Roman Shtykh Streamer integration with [https://pulsar.incubator.apache.org/] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-9037) Apache Pulsar intergration
[ https://issues.apache.org/jira/browse/IGNITE-9037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Shtykh reassigned IGNITE-9037: Assignee: Yoko Tabira > Apache Pulsar intergration > -- > > Key: IGNITE-9037 > URL: https://issues.apache.org/jira/browse/IGNITE-9037 > Project: Ignite > Issue Type: New Feature > Components: streaming >Reporter: Roman Shtykh >Assignee: Yoko Tabira >Priority: Major > > Streamer integration with [https://pulsar.incubator.apache.org/] > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8131) ZookeeperDiscoverySpiTest#testClientReconnectSessionExpire* tests fail on TC
[
https://issues.apache.org/jira/browse/IGNITE-8131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16550352#comment-16550352
]
Denis Garus commented on IGNITE-8131:
-
[~sergey-chugunov]
I've made changes to the main PR and added the link to the TC RunAll build.
Everything looks good to me.
> ZookeeperDiscoverySpiTest#testClientReconnectSessionExpire* tests fail on TC
>
>
> Key: IGNITE-8131
> URL: https://issues.apache.org/jira/browse/IGNITE-8131
> Project: Ignite
> Issue Type: Bug
> Components: zookeeper
>Reporter: Sergey Chugunov
>Assignee: Denis Garus
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.7
>
> Attachments: ZK_client_reconnect_failure.log,
> ZK_client_reconnect_success.log
>
>
> Two tests always fail on TC with the assertion
> {noformat}
> junit.framework.AssertionFailedError: Failed to wait for disconnect/reconnect
> event.
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.waitReconnectEvent(ZookeeperDiscoverySpiTest.java:4221)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.reconnectClientNodes(ZookeeperDiscoverySpiTest.java:4183)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.clientReconnectSessionExpire(ZookeeperDiscoverySpiTest.java:2231)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.testClientReconnectSessionExpire1_1(ZookeeperDiscoverySpiTest.java:2206)
> {noformat}
> from client disconnect/reconnect events check. Obviously client doesn't
> generate these events as it supposed to do.
> (TC runs can be found
> [here|https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_IgniteZooKeeperDiscovery_IgniteTests24Java8=pull%2F3730%2Fhead=buildTypeStatusDiv]).
> It is possible to reproduce test failure locally as well, but with low
> probability: one failure for 50 or even 300 successful executions.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-8958) Web console: upgrade to AngularJS 1.7
[ https://issues.apache.org/jira/browse/IGNITE-8958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vasiliy Sisko reassigned IGNITE-8958: - Assignee: Andrey Novikov (was: Vasiliy Sisko) > Web console: upgrade to AngularJS 1.7 > - > > Key: IGNITE-8958 > URL: https://issues.apache.org/jira/browse/IGNITE-8958 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Ilya Borisov >Assignee: Andrey Novikov >Priority: Minor > Attachments: ignite-8958-1.png > > Original Estimate: 48h > Time Spent: 4.5h > Remaining Estimate: 43.5h > > AngularJS 1.7 provides more features that will improve migration to Angular, > so let's update and fix any issues that will probably occur along the way. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-5798) Logging Ignite configuration at startup
[ https://issues.apache.org/jira/browse/IGNITE-5798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16550331#comment-16550331 ] ASF GitHub Bot commented on IGNITE-5798: Github user 1vanan closed the pull request at: https://github.com/apache/ignite/pull/2957 > Logging Ignite configuration at startup > --- > > Key: IGNITE-5798 > URL: https://issues.apache.org/jira/browse/IGNITE-5798 > Project: Ignite > Issue Type: Improvement >Reporter: Alexandr Kuramshin >Assignee: Ivan Fedotov >Priority: Major > Labels: easyfix, newbie > Fix For: 2.5 > > > I've found that IgniteConfiguration is not logged even when > -DIGNITE_QUIET=false > When we starting Ignite with path to the xml, or InputStream, we have to > ensure, that all configuration options were properly read. And also we would > like to know actual values of uninitialized configuration properties (default > values), which will be set only after Ignite get started. > Monitoring tools, like Visor or WebConsole, do not show all configuration > options. And even though they will be updated to show all properties, when > new configuration options appear, then tools update will be needed. > Logging IgniteConfiguration at startup gives a possibility to ensure that the > right grid configuration has been applied and leads to better user support > based on log analyzing. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8420) "Unignore" Web console unit tests
[ https://issues.apache.org/jira/browse/IGNITE-8420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Kalinin updated IGNITE-8420: -- Remaining Estimate: 32h (was: 96h) Original Estimate: 32h (was: 96h) > "Unignore" Web console unit tests > - > > Key: IGNITE-8420 > URL: https://issues.apache.org/jira/browse/IGNITE-8420 > Project: Ignite > Issue Type: Test > Components: wizards >Reporter: Alexander Kalinin >Assignee: Alexander Kalinin >Priority: Major > Original Estimate: 32h > Remaining Estimate: 32h > > Currently he have about 40 muted tests in web console front-end. They should > revised, and updated an or removed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8420) "Unignore" Web console unit tests
[ https://issues.apache.org/jira/browse/IGNITE-8420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Kalinin updated IGNITE-8420: -- Remaining Estimate: 96h Original Estimate: 96h > "Unignore" Web console unit tests > - > > Key: IGNITE-8420 > URL: https://issues.apache.org/jira/browse/IGNITE-8420 > Project: Ignite > Issue Type: Test > Components: wizards >Reporter: Alexander Kalinin >Assignee: Alexander Kalinin >Priority: Major > Original Estimate: 96h > Remaining Estimate: 96h > > Currently he have about 40 muted tests in web console front-end. They should > revised, and updated an or removed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8420) "Unignore" Web console unit tests
[ https://issues.apache.org/jira/browse/IGNITE-8420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16550290#comment-16550290 ] Alexander Kalinin commented on IGNITE-8420: --- Also we need to move tests from tests/unit directory to specific folders and remove webpack glob for tests. > "Unignore" Web console unit tests > - > > Key: IGNITE-8420 > URL: https://issues.apache.org/jira/browse/IGNITE-8420 > Project: Ignite > Issue Type: Test > Components: wizards >Reporter: Alexander Kalinin >Assignee: Alexander Kalinin >Priority: Major > > Currently he have about 40 muted tests in web console front-end. They should > revised, and updated an or removed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
