[jira] [Closed] (IGNITE-9594) Regression in release build for ignite-zookeeper module
[ https://issues.apache.org/jira/browse/IGNITE-9594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov closed IGNITE-9594. Tests passed. Build now contains required files. Merged to master. > Regression in release build for ignite-zookeeper module > --- > > Key: IGNITE-9594 > URL: https://issues.apache.org/jira/browse/IGNITE-9594 > Project: Ignite > Issue Type: Bug > Components: zookeeper >Reporter: Alexey Kuznetsov >Assignee: Alexey Kuznetsov >Priority: Critical > Fix For: 2.7 > > > In IGNITE-9073 from pom.xml of ignite-zookeeper jackson-core-asl & > jackson-mapper-asl > were removed and that leads to ClassNotFound errors at runtime if ignite node > uses TcpDiscoveryZookeeperIpFinder and started from binary build. > > We need to return that dependencies back, because Ignite binary build logic > ignore transient dependencies. > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9594) Regression in release build for ignite-zookeeper module
[ https://issues.apache.org/jira/browse/IGNITE-9594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov updated IGNITE-9594: - Component/s: zookeeper > Regression in release build for ignite-zookeeper module > --- > > Key: IGNITE-9594 > URL: https://issues.apache.org/jira/browse/IGNITE-9594 > Project: Ignite > Issue Type: Bug > Components: zookeeper >Reporter: Alexey Kuznetsov >Assignee: Alexey Kuznetsov >Priority: Critical > Fix For: 2.7 > > > In IGNITE-9073 from pom.xml of ignite-zookeeper jackson-core-asl & > jackson-mapper-asl > were removed and that leads to ClassNotFound errors at runtime if ignite node > uses TcpDiscoveryZookeeperIpFinder and started from binary build. > > We need to return that dependencies back, because Ignite binary build logic > ignore transient dependencies. > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9594) Regression in release build for ignite-zookeeper module
[ https://issues.apache.org/jira/browse/IGNITE-9594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov updated IGNITE-9594: - Priority: Critical (was: Major) > Regression in release build for ignite-zookeeper module > --- > > Key: IGNITE-9594 > URL: https://issues.apache.org/jira/browse/IGNITE-9594 > Project: Ignite > Issue Type: Bug >Reporter: Alexey Kuznetsov >Assignee: Alexey Kuznetsov >Priority: Critical > Fix For: 2.7 > > > In IGNITE-9073 from pom.xml of ignite-zookeeper jackson-core-asl & > jackson-mapper-asl > were removed and that leads to ClassNotFound errors at runtime if ignite node > uses TcpDiscoveryZookeeperIpFinder and started from binary build. > > We need to return that dependencies back, because Ignite binary build logic > ignore transient dependencies. > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7618) validateCache synchronously waits for state change
[
https://issues.apache.org/jira/browse/IGNITE-7618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16615410#comment-16615410
]
ASF GitHub Bot commented on IGNITE-7618:
Github user asfgit closed the pull request at:
https://github.com/apache/ignite/pull/4733
> validateCache synchronously waits for state change
> --
>
> Key: IGNITE-7618
> URL: https://issues.apache.org/jira/browse/IGNITE-7618
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.4
>Reporter: Alexey Goncharuk
>Assignee: Ivan Bessonov
>Priority: Major
> Fix For: 2.8
>
>
> Currently, we call publicApiActiveState(waitForTransition=true) in
> GridDhtTopologyFutureAdapter#validateCache. This is incorrect, because the
> cluster state is updated from discovery thread, and mapping may be happening
> on a previous topology version. We must capture the cluster active state flag
> to the exchange future (I believe we already have all the mechanics for this
> in ExchangeActions class) and validate the state in the exchange future
> itself, without touching ClusterStateProcessor.
> Below is an example of a deadlock happened because of synchronous wait:
> {code}
> "db-checkpoint-thread-#12318%database.IgniteDbBaselineTopologySelfTest0%"
> #15498 prio=5 os_prio=0 tid=0x7fa173e80800 nid=0x3d08 waiting on
> condition [0x7fa2069a8000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x0007abfc16e8> (a
> java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:870)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1199)
> at
> java.util.concurrent.locks.ReentrantReadWriteLock$WriteLock.lock(ReentrantReadWriteLock.java:943)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$Checkpointer.markCheckpointBegin(GridCacheDatabaseSharedManager.java:2991)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$Checkpointer.doCheckpoint(GridCacheDatabaseSharedManager.java:2797)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$Checkpointer.body(GridCacheDatabaseSharedManager.java:2722)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:745)
> "snapshot-scheduler-restats-#12202%database.IgniteDbBaselineTopologySelfTest0%"
> #15332 prio=5 os_prio=0 tid=0x7fa228143000 nid=0x3c65 waiting on
> condition [0x7fa2be919000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:177)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:140)
> at
> org.apache.ignite.internal.processors.cluster.GridClusterStateProcessor.publicApiActiveState(GridClusterStateProcessor.java:194)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTopologyFutureAdapter.validateCache(GridDhtTopologyFutureAdapter.java:83)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.colocated.GridDhtColocatedLockFuture.mapOnTopology(GridDhtColocatedLockFuture.java:787)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.colocated.GridDhtColocatedLockFuture.map(GridDhtColocatedLockFuture.java:763)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.colocated.GridDhtColocatedCache.lockAllAsync(GridDhtColocatedCache.java:646)
> at
> org.apache.ignite.internal.processors.cache.distributed.GridDistributedCacheAdapter.txLockAsync(GridDistributedCacheAdapter.java:109)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.getAllAsync(GridNearTxLocal.java:1723)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.colocated.GridDhtColocatedCache$4.op(GridDhtColocatedCache.java:197)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter$AsyncOp.op(GridCacheAdapter.java:5140)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.asyncOp(GridCacheAdapter.java:4275)
> at
>
[jira] [Comment Edited] (IGNITE-7618) validateCache synchronously waits for state change
[
https://issues.apache.org/jira/browse/IGNITE-7618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16615409#comment-16615409
]
Dmitriy Govorukhin edited comment on IGNITE-7618 at 9/14/18 9:28 PM:
-
[~ibessonov], [~Jokser] Thanks for your work, changes are merged into master.
was (Author: dmitriygovorukhin):
[~ibessonov][~Jokser] Thanks for your work, changes are merged into master.
> validateCache synchronously waits for state change
> --
>
> Key: IGNITE-7618
> URL: https://issues.apache.org/jira/browse/IGNITE-7618
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.4
>Reporter: Alexey Goncharuk
>Assignee: Ivan Bessonov
>Priority: Major
> Fix For: 2.8
>
>
> Currently, we call publicApiActiveState(waitForTransition=true) in
> GridDhtTopologyFutureAdapter#validateCache. This is incorrect, because the
> cluster state is updated from discovery thread, and mapping may be happening
> on a previous topology version. We must capture the cluster active state flag
> to the exchange future (I believe we already have all the mechanics for this
> in ExchangeActions class) and validate the state in the exchange future
> itself, without touching ClusterStateProcessor.
> Below is an example of a deadlock happened because of synchronous wait:
> {code}
> "db-checkpoint-thread-#12318%database.IgniteDbBaselineTopologySelfTest0%"
> #15498 prio=5 os_prio=0 tid=0x7fa173e80800 nid=0x3d08 waiting on
> condition [0x7fa2069a8000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x0007abfc16e8> (a
> java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:870)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1199)
> at
> java.util.concurrent.locks.ReentrantReadWriteLock$WriteLock.lock(ReentrantReadWriteLock.java:943)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$Checkpointer.markCheckpointBegin(GridCacheDatabaseSharedManager.java:2991)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$Checkpointer.doCheckpoint(GridCacheDatabaseSharedManager.java:2797)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$Checkpointer.body(GridCacheDatabaseSharedManager.java:2722)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:745)
> "snapshot-scheduler-restats-#12202%database.IgniteDbBaselineTopologySelfTest0%"
> #15332 prio=5 os_prio=0 tid=0x7fa228143000 nid=0x3c65 waiting on
> condition [0x7fa2be919000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:177)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:140)
> at
> org.apache.ignite.internal.processors.cluster.GridClusterStateProcessor.publicApiActiveState(GridClusterStateProcessor.java:194)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTopologyFutureAdapter.validateCache(GridDhtTopologyFutureAdapter.java:83)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.colocated.GridDhtColocatedLockFuture.mapOnTopology(GridDhtColocatedLockFuture.java:787)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.colocated.GridDhtColocatedLockFuture.map(GridDhtColocatedLockFuture.java:763)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.colocated.GridDhtColocatedCache.lockAllAsync(GridDhtColocatedCache.java:646)
> at
> org.apache.ignite.internal.processors.cache.distributed.GridDistributedCacheAdapter.txLockAsync(GridDistributedCacheAdapter.java:109)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.getAllAsync(GridNearTxLocal.java:1723)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.colocated.GridDhtColocatedCache$4.op(GridDhtColocatedCache.java:197)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter$AsyncOp.op(Gri
[jira] [Commented] (IGNITE-7618) validateCache synchronously waits for state change
[
https://issues.apache.org/jira/browse/IGNITE-7618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16615409#comment-16615409
]
Dmitriy Govorukhin commented on IGNITE-7618:
[~ibessonov][~Jokser] Thanks for your work, changes are merged into master.
> validateCache synchronously waits for state change
> --
>
> Key: IGNITE-7618
> URL: https://issues.apache.org/jira/browse/IGNITE-7618
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.4
>Reporter: Alexey Goncharuk
>Assignee: Ivan Bessonov
>Priority: Major
> Fix For: 2.8
>
>
> Currently, we call publicApiActiveState(waitForTransition=true) in
> GridDhtTopologyFutureAdapter#validateCache. This is incorrect, because the
> cluster state is updated from discovery thread, and mapping may be happening
> on a previous topology version. We must capture the cluster active state flag
> to the exchange future (I believe we already have all the mechanics for this
> in ExchangeActions class) and validate the state in the exchange future
> itself, without touching ClusterStateProcessor.
> Below is an example of a deadlock happened because of synchronous wait:
> {code}
> "db-checkpoint-thread-#12318%database.IgniteDbBaselineTopologySelfTest0%"
> #15498 prio=5 os_prio=0 tid=0x7fa173e80800 nid=0x3d08 waiting on
> condition [0x7fa2069a8000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x0007abfc16e8> (a
> java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:870)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1199)
> at
> java.util.concurrent.locks.ReentrantReadWriteLock$WriteLock.lock(ReentrantReadWriteLock.java:943)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$Checkpointer.markCheckpointBegin(GridCacheDatabaseSharedManager.java:2991)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$Checkpointer.doCheckpoint(GridCacheDatabaseSharedManager.java:2797)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$Checkpointer.body(GridCacheDatabaseSharedManager.java:2722)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:745)
> "snapshot-scheduler-restats-#12202%database.IgniteDbBaselineTopologySelfTest0%"
> #15332 prio=5 os_prio=0 tid=0x7fa228143000 nid=0x3c65 waiting on
> condition [0x7fa2be919000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:177)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:140)
> at
> org.apache.ignite.internal.processors.cluster.GridClusterStateProcessor.publicApiActiveState(GridClusterStateProcessor.java:194)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTopologyFutureAdapter.validateCache(GridDhtTopologyFutureAdapter.java:83)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.colocated.GridDhtColocatedLockFuture.mapOnTopology(GridDhtColocatedLockFuture.java:787)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.colocated.GridDhtColocatedLockFuture.map(GridDhtColocatedLockFuture.java:763)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.colocated.GridDhtColocatedCache.lockAllAsync(GridDhtColocatedCache.java:646)
> at
> org.apache.ignite.internal.processors.cache.distributed.GridDistributedCacheAdapter.txLockAsync(GridDistributedCacheAdapter.java:109)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.getAllAsync(GridNearTxLocal.java:1723)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.colocated.GridDhtColocatedCache$4.op(GridDhtColocatedCache.java:197)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter$AsyncOp.op(GridCacheAdapter.java:5140)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.asyncOp(GridCacheAdapter.java:4275)
> at
> org.apache.i
[jira] [Commented] (IGNITE-8241) Docs: Triggering automatic rebalancing if the whole baseline topology is not recovered
[ https://issues.apache.org/jira/browse/IGNITE-8241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16615218#comment-16615218 ] Eugene Miretsky commented on IGNITE-8241: - [~pgarg] : Where do you run this code? On a separate management node? What if that node goes down? > Docs: Triggering automatic rebalancing if the whole baseline topology is not > recovered > -- > > Key: IGNITE-8241 > URL: https://issues.apache.org/jira/browse/IGNITE-8241 > Project: Ignite > Issue Type: Task > Components: documentation >Affects Versions: 2.4 >Reporter: Denis Magda >Assignee: Prachi Garg >Priority: Critical > Fix For: 2.5 > > Attachments: BaselineWatcher.java > > > The ticket is created as a result of the following discussion: > http://apache-ignite-developers.2346864.n4.nabble.com/Triggering-rebalancing-on-timeout-or-manually-if-the-baseline-topology-is-not-reassembled-td29299.html > The rebalancing doesn't happen if one of the nodes goes down, > thus, shrinking the baseline topology. It complies with our assumption that > the node should be recovered soon and there is no need to waste > CPU/memory/networking resources of the cluster shifting the data around. > However, there are always edge cases. I was reasonably asked how to trigger > the rebalancing within the baseline topology manually or on timeout if: > * It's not expected that the failed node would be resurrected in the >nearest time and > * It's not likely that that node will be replaced by the other one. > Until we embedd special facilities in the baseline topology that would > consider such situations we can document the following workaround. A user > application/tool/script has to subscribe to node_left events and remove the > failed node from the baseline topology in some time. Once the node is > removed, the baseline topology will be changed, and the rebalancing will be > kicked off. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8879) Blinking baseline node sometimes unable to connect to cluster
[
https://issues.apache.org/jira/browse/IGNITE-8879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16615208#comment-16615208
]
ASF GitHub Bot commented on IGNITE-8879:
GitHub user vldpyatkov opened a pull request:
https://github.com/apache/ignite/pull/4764
IGNITE-8879 Blinking baseline node sometimes unable to connect to clu…
…ster
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-10919
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/4764.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 #4764
commit 1f3d38848ebdc0d145b58e15d0d6749ca55d9c61
Author: vd-pyatkov
Date: 2018-09-14T18:28:26Z
IGNITE-8879 Blinking baseline node sometimes unable to connect to cluster
> Blinking baseline node sometimes unable to connect to cluster
> -
>
> Key: IGNITE-8879
> URL: https://issues.apache.org/jira/browse/IGNITE-8879
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Dmitry Sherstobitov
>Assignee: Vladislav Pyatkov
>Priority: Critical
> Attachments: IGNITE-8879.zip
>
>
> Almost the same scenario as in IGNITE-8874 but node left baseline while
> blinking
> All caches with 2 backups
> 4 nodes in cluster
> # Start cluster, load data
> # Start transactional loading (8 threads, 100 ops/second put/get in each op)
> # Repeat 10 times: kill one node, remove from baseline, start node again
> (*with no LFS clean*), wait for rebalance
> # Check idle_verify, check data corruption
>
> At some point killed node unable to start and join cluster because of error
> (Attachments info: grid.1.node2.X.log - blinking node logs, X - iteration
> counter from step 3)
> {code:java}
> 080ee8-END.bin]
> [2018-06-26 19:01:43,039][INFO ][main][PageMemoryImpl] Started page memory
> [memoryAllocated=100.0 MiB, pages=24800, tableSize=1.9 MiB,
> checkpointBuffer=100.0 MiB]
> [2018-06-26 19:01:43,039][INFO ][main][GridCacheDatabaseSharedManager]
> Checking memory state [lastValidPos=FileWALPointer [idx=0, fileOff=583691,
> len=119], lastMarked=FileWALPointer [idx=0, fileOff=583691, len=119],
> lastCheckpointId=7fca4dbb-8f01-4b63-95e2-43283b080ee8]
> [2018-06-26 19:01:43,050][INFO ][main][GridCacheDatabaseSharedManager] Found
> last checkpoint marker [cpId=7fca4dbb-8f01-4b63-95e2-43283b080ee8,
> pos=FileWALPointer [idx=0, fileOff=583691, len=119]]
> [2018-06-26 19:01:43,082][INFO ][main][FileWriteAheadLogManager] Stopping WAL
> iteration due to an exception: EOF at position [100] expected to read [1]
> bytes, ptr=FileWALPointer [idx=0, fileOff=100, len=0]
> [2018-06-26 19:01:43,219][WARN ][main][FileWriteAheadLogManager] WAL segment
> tail is reached. [ Expected next state: {Index=19,Offset=794017}, Actual
> state : {Index=3602879702215753728,Offset=775434544} ]
> [2018-06-26 19:01:43,243][INFO ][main][GridCacheDatabaseSharedManager]
> Applying lost cache updates since last checkpoint record
> [lastMarked=FileWALPointer [idx=0, fileOff=583691, len=119],
> lastCheckpointId=7fca4dbb-8f01-4b63-95e2-43283b080ee8]
> [2018-06-26 19:01:43,246][INFO ][main][FileWriteAheadLogManager] Stopping WAL
> iteration due to an exception: EOF at position [100] expected to read [1]
> bytes, ptr=FileWALPointer [idx=0, fileOff=100, len=0]
> [2018-06-26 19:01:43,336][WARN ][main][FileWriteAheadLogManager] WAL segment
> tail is reached. [ Expected next state: {Index=19,Offset=794017}, Actual
> state : {Index=3602879702215753728,Offset=775434544} ]
> [2018-06-26 19:01:43,336][INFO ][main][GridCacheDatabaseSharedManager]
> Finished applying WAL changes [updatesApplied=0, time=101ms]
> [2018-06-26 19:01:43,450][INFO
> ][main][GridSnapshotAwareClusterStateProcessorImpl] Restoring history for
> BaselineTopology[id=4]
> [2018-06-26 19:01:43,454][ERROR][main][IgniteKernal] Exception during start
> processors, node will be stopped and close connections
> class org.apache.ignite.IgniteCheckedException: Failed to start processor:
> GridProcessorAdapter []
> at
> org.apache.ignite.internal.IgniteKernal.startProcessor(IgniteKernal.java:1769)
> at
> org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1001)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2020)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1725)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1153)
> at
> org.apache.ignite.internal.IgnitionEx.startConfigurations(IgnitionEx
[jira] [Commented] (IGNITE-8545) If queryParallelism in nodes' caches configurations differ, query may hang, assert or return incomplete results
[
https://issues.apache.org/jira/browse/IGNITE-8545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16615188#comment-16615188
]
Aleksey Chetaev commented on IGNITE-8545:
-
{panel:title=Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Data Structures{color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=1812431]]
*
GridCachePartitionedDataStructuresFailoverSelfTest.testFairReentrantLockConstantTopologyChangeNonFailoverSafe
(last started)
{color:#d04437}Cache (Restarts) 1{color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=1812423]]
* GridCacheReplicatedNodeRestartSelfTest.testRestartWithPutTenNodesTwoBackups
(last started)
{color:#d04437}Queries 1{color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=1842358]]
* IgniteBinaryCacheQueryTestSuite: SchemaExchangeSelfTest.testDynamicRestarts -
0,0% fails in last 100 master runs.
{color:#d04437}PDS (Direct IO) 2{color} [[tests
3|https://ci.ignite.apache.org/viewLog.html?buildId=1812402]]
* IgnitePdsNativeIoTestSuite2:
IgniteNativeIoPdsRecoveryAfterFileCorruptionTest.testPageRecoveryAfterFileCorruption
- 1,7% fails in last 100 master runs.
{color:#d04437}Cache (Failover) 1{color} [[tests
5|https://ci.ignite.apache.org/viewLog.html?buildId=1812418]]
* IgniteCacheFailoverTestSuite:
IgniteChangingBaselineUpCacheRemoveFailoverTest.testPutAndRemove - 1,8% fails
in last 100 master runs.
* IgniteCacheFailoverTestSuite:
IgniteChangingBaselineUpCacheRemoveFailoverTest.testPutAndRemovePessimisticTx -
1,8% fails in last 100 master runs.
{color:#d04437}PDS 1{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=1812405]]
* IgnitePdsTestSuite:
IgnitePdsDestroyCacheWithoutCheckpointsTest.testDestroyCachesAbruptlyWithoutCheckpoints
- 0,0% fails in last 100 master runs.
{color:#d04437}Continuous Query 2{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=1812357]]
* IgniteCacheQuerySelfTestSuite4:
CacheContinuousQueryFailoverAtomicSelfTest.testOneBackupClientUpdate - 0,0%
fails in last 100 master runs.
{panel}
[TeamCity Run
All|http://ci.ignite.apache.org/viewLog.html?buildId=1812446&buildTypeId=IgniteTests24Java8_RunAll]
> If queryParallelism in nodes' caches configurations differ, query may hang,
> assert or return incomplete results
> ---
>
> Key: IGNITE-8545
> URL: https://issues.apache.org/jira/browse/IGNITE-8545
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.6
>Reporter: Ilya Kasnacheev
>Assignee: Maxim Pudov
>Priority: Critical
> Fix For: 2.7
>
> Attachments: IgniteSqlSplitterQueryParallelismTest.java
>
>
> I imagine it should not. See the attached file.
> It happens both with client nodes and with server nodes.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9588) Separate page for JIRA, GitHub actions
[
https://issues.apache.org/jira/browse/IGNITE-9588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16615154#comment-16615154
]
ASF GitHub Bot commented on IGNITE-9588:
asfgit closed pull request #10: IGNITE-9588 Separate page for JIRA, GitHub
actions
URL: https://github.com/apache/ignite-teamcity-bot/pull/10
This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:
As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):
diff --git
a/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/ITcHelper.java
b/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/ITcHelper.java
index 69df43d..1077a0e 100644
--- a/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/ITcHelper.java
+++ b/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/ITcHelper.java
@@ -59,4 +59,14 @@
Collection getServerIds();
List getTrackedBranchesIds();
+
+/**
+ * @param srvId Server id.
+ * @param prov Credentials.
+ * @param buildTypeId Suite name.
+ * @param branchForTc Branch for TeamCity.
+ * @param ticket JIRA ticket full name.
+ * @return {@code True} if JIRA was notified.
+ */
+boolean notifyJira(String srvId, ICredentialsProv prov, String
buildTypeId, String branchForTc, String ticket);
}
diff --git
a/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/ITeamcity.java
b/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/ITeamcity.java
index 8201f5c..6a475a4 100644
--- a/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/ITeamcity.java
+++ b/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/ITeamcity.java
@@ -287,11 +287,11 @@ default SingleBuildRunCtx loadTestsAndProblems(@Nonnull
Build build, @Deprecated
PullRequest getPullRequest(String branch);
/**
- * @param ticket JIRA ticket name.
+ * @param ticket JIRA ticket full name.
* @param comment Comment to be placed in the ticket conversation.
* @return {@code True} if ticket was succesfully commented. Otherwise -
{@code false}.
*/
-boolean commentJiraTicket(String ticket, String comment);
+boolean sendJiraComment(String ticket, String comment);
default void setAuthData(String user, String password) {
diff --git
a/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/IgnitePersistentTeamcity.java
b/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/IgnitePersistentTeamcity.java
index 1e10d78..7f17075 100644
---
a/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/IgnitePersistentTeamcity.java
+++
b/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/IgnitePersistentTeamcity.java
@@ -853,8 +853,8 @@ public void setExecutor(ExecutorService executor) {
}
/** {@inheritDoc} */
-@Override public boolean commentJiraTicket(String ticket, String comment) {
-return teamcity.commentJiraTicket(ticket, comment);
+@Override public boolean sendJiraComment(String ticket, String comment) {
+return teamcity.sendJiraComment(ticket, comment);
}
/** {@inheritDoc} */
diff --git
a/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/IgniteTeamcityHelper.java
b/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/IgniteTeamcityHelper.java
index 249a72a..f55222e 100644
---
a/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/IgniteTeamcityHelper.java
+++
b/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/IgniteTeamcityHelper.java
@@ -176,7 +176,7 @@ public IgniteTeamcityHelper(@Nullable String tcName) {
}
/** {@inheritDoc} */
-@Override public boolean commentJiraTicket(String ticket, String comment) {
+@Override public boolean sendJiraComment(String ticket, String comment) {
try {
String url = "https://issues.apache.org/jira/rest/api/2/issue/"; +
ticket + "/comment";
@@ -195,6 +195,7 @@ public IgniteTeamcityHelper(@Nullable String tcName) {
@Override public PullRequest getPullRequest(String branchForTc) {
String id = null;
+// Get PR id from string "pull//head"
for (int i = 5; i < branchForTc.length(); i++) {
char c = branchForTc.charAt(i);
diff --git
a/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/TcHelper.java
b/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/TcHelper.java
index a95483b..de0e7ea 100644
--- a/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/TcHelper.java
+++ b/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/TcHelper.java
@@ -20,16 +20,26 @@
import com.google.common.base.Strings;
import com.google.common.cache.Cache;
import com.google.common.cache.CacheBuilder;
+import java.util.ArrayList;
+import java.util.LinkedHashMap;
import java.util.List;
+import java.util.Map;
import org.
[jira] [Commented] (IGNITE-6716) Document "Affinity key backups mismatch" resolution steps
[
https://issues.apache.org/jira/browse/IGNITE-6716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16615108#comment-16615108
]
matt hoffman commented on IGNITE-6716:
--
Documenting the properties that must be the same is helpful, I guess, but
that's not the root if this issue. In this case, all nodes have identical
configuration – the Ignite configuration is done in code, and all nodes have
identical code deployed. No property involving anything like # of replicas or #
of backups can be different between nodes.
> Document "Affinity key backups mismatch" resolution steps
> -
>
> Key: IGNITE-6716
> URL: https://issues.apache.org/jira/browse/IGNITE-6716
> Project: Ignite
> Issue Type: Improvement
> Components: documentation
>Reporter: Nicholas DiPiazza
>Assignee: Artem Budnikov
>Priority: Major
> Fix For: 2.8
>
>
> Please see the issue below:
> https://stackoverflow.com/questions/46894435/how-do-i-fix-affinity-key-backups-in-cache-configuration
> results in this error:
> {code}
> org.apache.ignite.IgniteCheckedException: Affinity key backups mismatch (fix
> affinity key backups in cache configuration or set
> -DIGNITE_SKIP_CONFIGURATION_CONSISTENCY_CHECK=true system property)
> {code}
> Can someone help me get the steps in order to fix this issue? we should add
> it to the documentation somewhere.
> # What causes this error?
> # How to fix this error?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9392) CacheAsyncOperationsFailoverTxTest hangs on TC
[
https://issues.apache.org/jira/browse/IGNITE-9392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16615104#comment-16615104
]
ASF GitHub Bot commented on IGNITE-9392:
Github user asfgit closed the pull request at:
https://github.com/apache/ignite/pull/4625
> CacheAsyncOperationsFailoverTxTest hangs on TC
> --
>
> Key: IGNITE-9392
> URL: https://issues.apache.org/jira/browse/IGNITE-9392
> Project: Ignite
> Issue Type: Bug
>Reporter: Ilya Lantukh
>Assignee: Ilya Lantukh
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.7
>
>
> Exchange worker hangs while waiting for partition release:
> {code}
> [13:42:50] : [Step 3/4] Thread
> [name="exchange-worker-#214881%distributed.CacheAsyncOperationsFailoverTxTest0%",
> id=245275, state=TIMED_WAITING, blockCnt=135, waitCnt=176]
> [13:42:50] : [Step 3/4] at sun.misc.Unsafe.park(Native Method)
> [13:42:50] : [Step 3/4] at
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:338)
> [13:42:50] : [Step 3/4] at
> o.a.i.i.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:217)
> [13:42:50] : [Step 3/4] at
> o.a.i.i.util.future.GridFutureAdapter.get(GridFutureAdapter.java:159)
> [13:42:50] : [Step 3/4] at
> o.a.i.i.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.waitPartitionRelease(GridDhtPartitionsExchangeFuture.java:1367)
> [13:42:50] : [Step 3/4] at
> o.a.i.i.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.distributedExchange(GridDhtPartitionsExchangeFuture.java:1211)
> [13:42:50] : [Step 3/4] at
> o.a.i.i.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:752)
> [13:42:50] : [Step 3/4] at
> o.a.i.i.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body0(GridCachePartitionExchangeManager.java:2525)
> [13:42:50] : [Step 3/4] at
> o.a.i.i.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2405)
> [13:42:50] : [Step 3/4] at
> o.a.i.i.util.worker.GridWorker.run(GridWorker.java:110)
> [13:42:50] : [Step 3/4] at java.lang.Thread.run(Thread.java:748)
> {code}
> At that moment there are lots of pending transactions and one pending TX
> finish future:
> {code}
> [13:43:14]W: [org.apache.ignite:ignite-core] [2018-08-27
> 10:43:14,632][WARN
> ][exchange-worker-#214881%distributed.CacheAsyncOperationsFailoverTxTest0%][diagnostic]
> Failed to wait for partition map exchange [topVer=AffinityTopologyVersion
> [topVer=37, minorTopVer=0], node=98909049-bca4-4cba-b659-768ccfe0].
> Dumping pending objects that might be the cause:
> [13:43:14]W: [org.apache.ignite:ignite-core] [2018-08-27
> 10:43:14,632][WARN
> ][exchange-worker-#214881%distributed.CacheAsyncOperationsFailoverTxTest0%][diagnostic]
> Ready affinity version: AffinityTopologyVersion [topVer=36, minorTopVer=0]
> [13:43:14]W: [org.apache.ignite:ignite-core] [2018-08-27
> 10:43:14,633][WARN
> ][exchange-worker-#214881%distributed.CacheAsyncOperationsFailoverTxTest0%][diagnostic]
> Last exchange future: GridDhtPartitionsExchangeFuture
> [firstDiscoEvt=DiscoveryEvent [evtNode=TcpDiscoveryNode
> [id=387bab47-9542-4d98-8dda-03e3a3f3, addrs=ArrayList [127.0.0.1],
> sockAddrs=HashSet [/127.0.0.1:47503], discPort=47503, order=4, intOrder=4,
> lastExchangeTime=1535366199108, loc=false, ver=2.7.0#20180824-sha1:b0175cf6,
> isClient=false], topVer=37, nodeId8=98909049, msg=Node left: TcpDiscoveryNode
> [id=387bab47-9542-4d98-8dda-03e3a3f3, addrs=ArrayList [127.0.0.1],
> sockAddrs=HashSet [/127.0.0.1:47503], discPort=47503, order=4, intOrder=4,
> lastExchangeTime=1535366199108, loc=false, ver=2.7.0#20180824-sha1:b0175cf6,
> isClient=false], type=NODE_LEFT, tstamp=1535366275135], crd=TcpDiscoveryNode
> [id=98909049-bca4-4cba-b659-768ccfe0, addrs=ArrayList [127.0.0.1],
> sockAddrs=HashSet [/127.0.0.1:47500], discPort=47500, order=1, intOrder=1,
> lastExchangeTime=1535366575460, loc=true, ver=2.7.0#20180824-sha1:b0175cf6,
> isClient=false], exchId=GridDhtPartitionExchangeId
> [topVer=AffinityTopologyVersion [topVer=37, minorTopVer=0],
> discoEvt=DiscoveryEvent [evtNode=TcpDiscoveryNode
> [id=387bab47-9542-4d98-8dda-03e3a3f3, addrs=ArrayList [127.0.0.1],
> sockAddrs=HashSet [/127.0.0.1:47503], discPort=47503, order=4, intOrder=4,
> lastExchangeTime=1535366199108, loc=false, ver=2.7.0#20180824-sha1:b0175cf6,
> isClient=false], topVer=37, nodeId8=98909049, msg=Node left: TcpDiscoveryNode
> [id=387bab47-9542-4d98-8dda-03e3a3f3, addrs=ArrayList [127.0.0.1],
> sockA
[jira] [Commented] (IGNITE-9588) Separate page for JIRA, GitHub actions
[ https://issues.apache.org/jira/browse/IGNITE-9588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16615087#comment-16615087 ] ASF GitHub Bot commented on IGNITE-9588: SomeFire opened a new pull request #10: IGNITE-9588 Separate page for JIRA, GitHub actions URL: https://github.com/apache/ignite-teamcity-bot/pull/10 This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Separate page for JIRA, GitHub actions > -- > > Key: IGNITE-9588 > URL: https://issues.apache.org/jira/browse/IGNITE-9588 > Project: Ignite > Issue Type: Sub-task >Reporter: Ryabov Dmitrii >Assignee: Ryabov Dmitrii >Priority: Major > > To separate JIRA and GitHub actions from other action on index page we need > to create an additional page, opened by tab on the panel with Home and > Compare Builds. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Issue Comment Deleted] (IGNITE-6826) Change default DiscoverySpi ipFinder type for examples
[
https://issues.apache.org/jira/browse/IGNITE-6826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryabov Dmitrii updated IGNITE-6826:
---
Comment: was deleted
(was: {panel:title=Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Platform C++ (Linux Clang){color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=1849476]]
{color:#d04437}Platform C++ (Linux){color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=1849422]]
{color:#d04437}ZooKeeper (Discovery) 2{color} [[tests
7|https://ci.ignite.apache.org/viewLog.html?buildId=1849421]]
* ZookeeperDiscoverySpiTestSuite2:
IgniteCachePutRetryTransactionalSelfTest.testAtomicLongRetries - 0,0% fails in
last 100 master runs.
* ZookeeperDiscoverySpiTestSuite2:
IgniteCachePutRetryTransactionalSelfTest.testExplicitTransactionRetriesEvictionEnabled
- 0,0% fails in last 100 master runs.
* ZookeeperDiscoverySpiTestSuite2:
IgniteCachePutRetryTransactionalSelfTest.testExplicitTransactionRetriesSingleValue
- 0,0% fails in last 100 master runs.
* ZookeeperDiscoverySpiTestSuite2:
IgniteCachePutRetryTransactionalSelfTest.testOriginatingNodeFailureForcesOnePhaseCommitDataCleanup
- 0,0% fails in last 100 master runs.
* ZookeeperDiscoverySpiTestSuite2:
IgniteCachePutRetryTransactionalSelfTest.testPutAsync - 0,0% fails in last 100
master runs.
* ZookeeperDiscoverySpiTestSuite2:
IgniteCachePutRetryTransactionalSelfTest.testPutAsyncStoreEnabled - 0,0% fails
in last 100 master runs.
{color:#d04437}Queries (Binary Objects Simple Mapper){color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=1849381]]
* IgniteBinarySimpleNameMapperCacheQueryTestSuite:
GridCacheFullTextQuerySelfTest.testLocalTextQueryWithKeepBinary - 0,0% fails in
last 100 master runs.
{color:#d04437}Binary Objects (Simple Mapper Compute Grid){color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=1849380]]
* IgniteBinaryObjectsSimpleNameMapperComputeGridTestSuite:
GridJobStealingSelfTest.testTwoJobs - 0,0% fails in last 100 master runs.
{color:#d04437}ZooKeeper (Discovery) 1{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=1849420]]
* ZookeeperDiscoverySpiTestSuite1:
ZookeeperDiscoverySpiTest.testDisconnectOnServersLeft_5 - 0,0% fails in last
100 master runs.
{color:#d04437}Continuous Query 1{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=1849387]]
* IgniteCacheQuerySelfTestSuite3:
CacheContinuousQueryAsyncFilterListenerTest.testNonDeadLockInFilterReplicatedJCacheApi
- 0,0% fails in last 100 master runs.
{color:#d04437}PDS (Direct IO) 1{color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=1849432]]
* IgnitePdsNativeIoTestSuite: IgniteDbPutGetWithCacheStoreTest.testReadThrough
- 0,0% fails in last 100 master runs.
{color:#d04437}Basic 1{color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=1849474]]
* IgniteBasicTestSuite: BPlusTreeReuseSelfTest.testMassiveRemove2_false - 0,0%
fails in last 100 master runs.
{panel}
[TeamCity Run
All|http://ci.ignite.apache.org/viewLog.html?buildId=1849477&buildTypeId=IgniteTests24Java8_RunAll])
> Change default DiscoverySpi ipFinder type for examples
> --
>
> Key: IGNITE-6826
> URL: https://issues.apache.org/jira/browse/IGNITE-6826
> Project: Ignite
> Issue Type: Improvement
> Components: examples
>Affects Versions: 2.3
>Reporter: Alexey Popov
>Assignee: Ryabov Dmitrii
>Priority: Major
> Labels: newbie
> Fix For: 2.7
>
>
> It is better to change multicast ipFinder to static (vm) ipFinder for java
> examples, .NET examples and C++ examples.
> http://apache-ignite-developers.2346864.n4.nabble.com/ipFinder-configuration-for-Samples-td23818.html
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-6826) Change default DiscoverySpi ipFinder type for examples
[
https://issues.apache.org/jira/browse/IGNITE-6826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16615058#comment-16615058
]
Ryabov Dmitrii commented on IGNITE-6826:
{panel:title=Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Platform C++ (Linux Clang){color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=1849476]]
{color:#d04437}Platform C++ (Linux){color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=1849422]]
{color:#d04437}ZooKeeper (Discovery) 2{color} [[tests
7|https://ci.ignite.apache.org/viewLog.html?buildId=1849421]]
* ZookeeperDiscoverySpiTestSuite2:
IgniteCachePutRetryTransactionalSelfTest.testAtomicLongRetries - 0,0% fails in
last 100 master runs.
* ZookeeperDiscoverySpiTestSuite2:
IgniteCachePutRetryTransactionalSelfTest.testExplicitTransactionRetriesEvictionEnabled
- 0,0% fails in last 100 master runs.
* ZookeeperDiscoverySpiTestSuite2:
IgniteCachePutRetryTransactionalSelfTest.testExplicitTransactionRetriesSingleValue
- 0,0% fails in last 100 master runs.
* ZookeeperDiscoverySpiTestSuite2:
IgniteCachePutRetryTransactionalSelfTest.testOriginatingNodeFailureForcesOnePhaseCommitDataCleanup
- 0,0% fails in last 100 master runs.
* ZookeeperDiscoverySpiTestSuite2:
IgniteCachePutRetryTransactionalSelfTest.testPutAsync - 0,0% fails in last 100
master runs.
* ZookeeperDiscoverySpiTestSuite2:
IgniteCachePutRetryTransactionalSelfTest.testPutAsyncStoreEnabled - 0,0% fails
in last 100 master runs.
{color:#d04437}Queries (Binary Objects Simple Mapper){color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=1849381]]
* IgniteBinarySimpleNameMapperCacheQueryTestSuite:
GridCacheFullTextQuerySelfTest.testLocalTextQueryWithKeepBinary - 0,0% fails in
last 100 master runs.
{color:#d04437}Binary Objects (Simple Mapper Compute Grid){color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=1849380]]
* IgniteBinaryObjectsSimpleNameMapperComputeGridTestSuite:
GridJobStealingSelfTest.testTwoJobs - 0,0% fails in last 100 master runs.
{color:#d04437}ZooKeeper (Discovery) 1{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=1849420]]
* ZookeeperDiscoverySpiTestSuite1:
ZookeeperDiscoverySpiTest.testDisconnectOnServersLeft_5 - 0,0% fails in last
100 master runs.
{color:#d04437}Continuous Query 1{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=1849387]]
* IgniteCacheQuerySelfTestSuite3:
CacheContinuousQueryAsyncFilterListenerTest.testNonDeadLockInFilterReplicatedJCacheApi
- 0,0% fails in last 100 master runs.
{color:#d04437}PDS (Direct IO) 1{color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=1849432]]
* IgnitePdsNativeIoTestSuite: IgniteDbPutGetWithCacheStoreTest.testReadThrough
- 0,0% fails in last 100 master runs.
{color:#d04437}Basic 1{color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=1849474]]
* IgniteBasicTestSuite: BPlusTreeReuseSelfTest.testMassiveRemove2_false - 0,0%
fails in last 100 master runs.
{panel}
[TeamCity Run
All|http://ci.ignite.apache.org/viewLog.html?buildId=1849477&buildTypeId=IgniteTests24Java8_RunAll]
> Change default DiscoverySpi ipFinder type for examples
> --
>
> Key: IGNITE-6826
> URL: https://issues.apache.org/jira/browse/IGNITE-6826
> Project: Ignite
> Issue Type: Improvement
> Components: examples
>Affects Versions: 2.3
>Reporter: Alexey Popov
>Assignee: Ryabov Dmitrii
>Priority: Major
> Labels: newbie
> Fix For: 2.7
>
>
> It is better to change multicast ipFinder to static (vm) ipFinder for java
> examples, .NET examples and C++ examples.
> http://apache-ignite-developers.2346864.n4.nabble.com/ipFinder-configuration-for-Samples-td23818.html
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9487) REST: getall can only output keys as scalars
[
https://issues.apache.org/jira/browse/IGNITE-9487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16615053#comment-16615053
]
ASF GitHub Bot commented on IGNITE-9487:
Github user alamar closed the pull request at:
https://github.com/apache/ignite/pull/4718
> REST: getall can only output keys as scalars
>
>
> Key: IGNITE-9487
> URL: https://issues.apache.org/jira/browse/IGNITE-9487
> Project: Ignite
> Issue Type: Improvement
> Components: rest
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Kasnacheev
>Priority: Major
>
> Regardless of what ConnectorMessageInterceptor does, `getall' command can
> only output key as string or number, and not as JSON object as values can.
> This is because output format is as follows:
> {code}
> {"successStatus":0,"affinityNodeId":null,"sessionToken":null,"response":{"CustomType
> [idHash=1588995554, hash=34706515, key=111]":{"val":"111"},"CustomType
> [idHash=978025370, hash=30386820, key=222]":{"val":"222"}},"error":null}
> {code}
> The desired output format may look like:
> {code}
> {"successStatus":0,"affinityNodeId":null,"sessionToken":null,"response":[{"key":{"key":111},"value":{"val":"111"}},{"key":{"key":222},"value":{"val":"222"}}],"error":null}
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Issue Comment Deleted] (IGNITE-6826) Change default DiscoverySpi ipFinder type for examples
[
https://issues.apache.org/jira/browse/IGNITE-6826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryabov Dmitrii updated IGNITE-6826:
---
Comment: was deleted
(was: {panel:title=Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Platform C++ (Linux Clang){color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=1849476]]
{color:#d04437}Platform C++ (Linux){color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=1849422]]
{color:#d04437}ZooKeeper (Discovery) 2{color} [[tests
7|https://ci.ignite.apache.org/viewLog.html?buildId=1849421]]
* ZookeeperDiscoverySpiTestSuite2:
IgniteCachePutRetryTransactionalSelfTest.testAtomicLongRetries - 0,0% fails in
last 100 master runs.
* ZookeeperDiscoverySpiTestSuite2:
IgniteCachePutRetryTransactionalSelfTest.testExplicitTransactionRetriesEvictionEnabled
- 0,0% fails in last 100 master runs.
* ZookeeperDiscoverySpiTestSuite2:
IgniteCachePutRetryTransactionalSelfTest.testExplicitTransactionRetriesSingleValue
- 0,0% fails in last 100 master runs.
* ZookeeperDiscoverySpiTestSuite2:
IgniteCachePutRetryTransactionalSelfTest.testOriginatingNodeFailureForcesOnePhaseCommitDataCleanup
- 0,0% fails in last 100 master runs.
* ZookeeperDiscoverySpiTestSuite2:
IgniteCachePutRetryTransactionalSelfTest.testPutAsync - 0,0% fails in last 100
master runs.
* ZookeeperDiscoverySpiTestSuite2:
IgniteCachePutRetryTransactionalSelfTest.testPutAsyncStoreEnabled - 0,0% fails
in last 100 master runs.
{color:#d04437}Queries (Binary Objects Simple Mapper){color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=1849381]]
* IgniteBinarySimpleNameMapperCacheQueryTestSuite:
GridCacheFullTextQuerySelfTest.testLocalTextQueryWithKeepBinary - 0,0% fails in
last 100 master runs.
{color:#d04437}Binary Objects (Simple Mapper Compute Grid){color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=1849380]]
* IgniteBinaryObjectsSimpleNameMapperComputeGridTestSuite:
GridJobStealingSelfTest.testTwoJobs - 0,0% fails in last 100 master runs.
{color:#d04437}ZooKeeper (Discovery) 1{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=1849420]]
* ZookeeperDiscoverySpiTestSuite1:
ZookeeperDiscoverySpiTest.testDisconnectOnServersLeft_5 - 0,0% fails in last
100 master runs.
{color:#d04437}Continuous Query 1{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=1849387]]
* IgniteCacheQuerySelfTestSuite3:
CacheContinuousQueryAsyncFilterListenerTest.testNonDeadLockInFilterReplicatedJCacheApi
- 0,0% fails in last 100 master runs.
{color:#d04437}PDS (Direct IO) 1{color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=1849432]]
* IgnitePdsNativeIoTestSuite: IgniteDbPutGetWithCacheStoreTest.testReadThrough
- 0,0% fails in last 100 master runs.
{color:#d04437}Basic 1{color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=1849474]]
* IgniteBasicTestSuite: BPlusTreeReuseSelfTest.testMassiveRemove2_false - 0,0%
fails in last 100 master runs.
{panel}
[TeamCity Run
All|http://ci.ignite.apache.org/viewLog.html?buildId=1849477&buildTypeId=IgniteTests24Java8_RunAll])
> Change default DiscoverySpi ipFinder type for examples
> --
>
> Key: IGNITE-6826
> URL: https://issues.apache.org/jira/browse/IGNITE-6826
> Project: Ignite
> Issue Type: Improvement
> Components: examples
>Affects Versions: 2.3
>Reporter: Alexey Popov
>Assignee: Ryabov Dmitrii
>Priority: Major
> Labels: newbie
> Fix For: 2.7
>
>
> It is better to change multicast ipFinder to static (vm) ipFinder for java
> examples, .NET examples and C++ examples.
> http://apache-ignite-developers.2346864.n4.nabble.com/ipFinder-configuration-for-Samples-td23818.html
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-6826) Change default DiscoverySpi ipFinder type for examples
[
https://issues.apache.org/jira/browse/IGNITE-6826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16615050#comment-16615050
]
Ryabov Dmitrii commented on IGNITE-6826:
{panel:title=Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Platform C++ (Linux Clang){color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=1849476]]
{color:#d04437}Platform C++ (Linux){color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=1849422]]
{color:#d04437}ZooKeeper (Discovery) 2{color} [[tests
7|https://ci.ignite.apache.org/viewLog.html?buildId=1849421]]
* ZookeeperDiscoverySpiTestSuite2:
IgniteCachePutRetryTransactionalSelfTest.testAtomicLongRetries - 0,0% fails in
last 100 master runs.
* ZookeeperDiscoverySpiTestSuite2:
IgniteCachePutRetryTransactionalSelfTest.testExplicitTransactionRetriesEvictionEnabled
- 0,0% fails in last 100 master runs.
* ZookeeperDiscoverySpiTestSuite2:
IgniteCachePutRetryTransactionalSelfTest.testExplicitTransactionRetriesSingleValue
- 0,0% fails in last 100 master runs.
* ZookeeperDiscoverySpiTestSuite2:
IgniteCachePutRetryTransactionalSelfTest.testOriginatingNodeFailureForcesOnePhaseCommitDataCleanup
- 0,0% fails in last 100 master runs.
* ZookeeperDiscoverySpiTestSuite2:
IgniteCachePutRetryTransactionalSelfTest.testPutAsync - 0,0% fails in last 100
master runs.
* ZookeeperDiscoverySpiTestSuite2:
IgniteCachePutRetryTransactionalSelfTest.testPutAsyncStoreEnabled - 0,0% fails
in last 100 master runs.
{color:#d04437}Queries (Binary Objects Simple Mapper){color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=1849381]]
* IgniteBinarySimpleNameMapperCacheQueryTestSuite:
GridCacheFullTextQuerySelfTest.testLocalTextQueryWithKeepBinary - 0,0% fails in
last 100 master runs.
{color:#d04437}Binary Objects (Simple Mapper Compute Grid){color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=1849380]]
* IgniteBinaryObjectsSimpleNameMapperComputeGridTestSuite:
GridJobStealingSelfTest.testTwoJobs - 0,0% fails in last 100 master runs.
{color:#d04437}ZooKeeper (Discovery) 1{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=1849420]]
* ZookeeperDiscoverySpiTestSuite1:
ZookeeperDiscoverySpiTest.testDisconnectOnServersLeft_5 - 0,0% fails in last
100 master runs.
{color:#d04437}Continuous Query 1{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=1849387]]
* IgniteCacheQuerySelfTestSuite3:
CacheContinuousQueryAsyncFilterListenerTest.testNonDeadLockInFilterReplicatedJCacheApi
- 0,0% fails in last 100 master runs.
{color:#d04437}PDS (Direct IO) 1{color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=1849432]]
* IgnitePdsNativeIoTestSuite: IgniteDbPutGetWithCacheStoreTest.testReadThrough
- 0,0% fails in last 100 master runs.
{color:#d04437}Basic 1{color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=1849474]]
* IgniteBasicTestSuite: BPlusTreeReuseSelfTest.testMassiveRemove2_false - 0,0%
fails in last 100 master runs.
{panel}
[TeamCity Run
All|http://ci.ignite.apache.org/viewLog.html?buildId=1849477&buildTypeId=IgniteTests24Java8_RunAll]
> Change default DiscoverySpi ipFinder type for examples
> --
>
> Key: IGNITE-6826
> URL: https://issues.apache.org/jira/browse/IGNITE-6826
> Project: Ignite
> Issue Type: Improvement
> Components: examples
>Affects Versions: 2.3
>Reporter: Alexey Popov
>Assignee: Ryabov Dmitrii
>Priority: Major
> Labels: newbie
> Fix For: 2.7
>
>
> It is better to change multicast ipFinder to static (vm) ipFinder for java
> examples, .NET examples and C++ examples.
> http://apache-ignite-developers.2346864.n4.nabble.com/ipFinder-configuration-for-Samples-td23818.html
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-7618) validateCache synchronously waits for state change
[
https://issues.apache.org/jira/browse/IGNITE-7618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16615048#comment-16615048
]
Pavel Kovalenko commented on IGNITE-7618:
-
[~ibessonov] Thank you for contribution. Now it looks good.
[~DmitriyGovorukhin] could you please commit the change?
> validateCache synchronously waits for state change
> --
>
> Key: IGNITE-7618
> URL: https://issues.apache.org/jira/browse/IGNITE-7618
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.4
>Reporter: Alexey Goncharuk
>Assignee: Ivan Bessonov
>Priority: Major
> Fix For: 2.8
>
>
> Currently, we call publicApiActiveState(waitForTransition=true) in
> GridDhtTopologyFutureAdapter#validateCache. This is incorrect, because the
> cluster state is updated from discovery thread, and mapping may be happening
> on a previous topology version. We must capture the cluster active state flag
> to the exchange future (I believe we already have all the mechanics for this
> in ExchangeActions class) and validate the state in the exchange future
> itself, without touching ClusterStateProcessor.
> Below is an example of a deadlock happened because of synchronous wait:
> {code}
> "db-checkpoint-thread-#12318%database.IgniteDbBaselineTopologySelfTest0%"
> #15498 prio=5 os_prio=0 tid=0x7fa173e80800 nid=0x3d08 waiting on
> condition [0x7fa2069a8000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x0007abfc16e8> (a
> java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:870)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1199)
> at
> java.util.concurrent.locks.ReentrantReadWriteLock$WriteLock.lock(ReentrantReadWriteLock.java:943)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$Checkpointer.markCheckpointBegin(GridCacheDatabaseSharedManager.java:2991)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$Checkpointer.doCheckpoint(GridCacheDatabaseSharedManager.java:2797)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$Checkpointer.body(GridCacheDatabaseSharedManager.java:2722)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:745)
> "snapshot-scheduler-restats-#12202%database.IgniteDbBaselineTopologySelfTest0%"
> #15332 prio=5 os_prio=0 tid=0x7fa228143000 nid=0x3c65 waiting on
> condition [0x7fa2be919000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:177)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:140)
> at
> org.apache.ignite.internal.processors.cluster.GridClusterStateProcessor.publicApiActiveState(GridClusterStateProcessor.java:194)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTopologyFutureAdapter.validateCache(GridDhtTopologyFutureAdapter.java:83)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.colocated.GridDhtColocatedLockFuture.mapOnTopology(GridDhtColocatedLockFuture.java:787)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.colocated.GridDhtColocatedLockFuture.map(GridDhtColocatedLockFuture.java:763)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.colocated.GridDhtColocatedCache.lockAllAsync(GridDhtColocatedCache.java:646)
> at
> org.apache.ignite.internal.processors.cache.distributed.GridDistributedCacheAdapter.txLockAsync(GridDistributedCacheAdapter.java:109)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.getAllAsync(GridNearTxLocal.java:1723)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.colocated.GridDhtColocatedCache$4.op(GridDhtColocatedCache.java:197)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter$AsyncOp.op(GridCacheAdapter.java:5140)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.asyncOp(GridCacheAdapter.j
[jira] [Created] (IGNITE-9605) Implicit mvcc transaction could use completed one instead of starting new
Ivan Pavlukhin created IGNITE-9605: -- Summary: Implicit mvcc transaction could use completed one instead of starting new Key: IGNITE-9605 URL: https://issues.apache.org/jira/browse/IGNITE-9605 Project: Ignite Issue Type: Bug Components: mvcc Reporter: Ivan Pavlukhin It is possible that statement executed outside of explicit transaction uses completed one explicit transaction from ThreadLocal and fails. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9604) Implicit mvcc transaction could use completed one instead of starting new
Ivan Pavlukhin created IGNITE-9604: -- Summary: Implicit mvcc transaction could use completed one instead of starting new Key: IGNITE-9604 URL: https://issues.apache.org/jira/browse/IGNITE-9604 Project: Ignite Issue Type: Bug Components: mvcc Reporter: Ivan Pavlukhin It is possible that statement executed outside of explicit transaction uses completed one explicit transaction from ThreadLocal and fails. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9398) Reduce time on processing CustomDiscoveryMessage by discovery message worker
[
https://issues.apache.org/jira/browse/IGNITE-9398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16614970#comment-16614970
]
ASF GitHub Bot commented on IGNITE-9398:
Github user asfgit closed the pull request at:
https://github.com/apache/ignite/pull/4636
> Reduce time on processing CustomDiscoveryMessage by discovery message worker
>
>
> Key: IGNITE-9398
> URL: https://issues.apache.org/jira/browse/IGNITE-9398
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.4, 2.5, 2.6
>Reporter: Pavel Kovalenko
>Assignee: Pavel Kovalenko
>Priority: Major
> Fix For: 2.7
>
>
> Processing discovery CustomMessage may take significant values of time
> (0.5-0.7 seconds) before sending to next node in the topology. This
> significantly accumulates the total time of PME if topology has multiple
> nodes.
> Let X = time of processing discovery message by discovery-msg-worker on each
> node before sending to next node.
> Let N = number of nodes in the topology.
> Then the minimal total time of exchange will be:
> T = N * X
> We shouldn't make heavy actions when process discovery message. Best solution
> will be separated thread that will do it, while discovery-msg-worker will
> just pass a message to that thread and send a message immediately to another
> node in topology.
> This affects both TcpDiscoverySpi and ZkDiscoverySpi.
> {noformat}
> [11:59:33,134][INFO][tcp-disco-msg-worker-#2][TcpDiscoverySpi] Enqueued
> message type = TcpDiscoveryCustomEventMessage id =
> e4b542b6561-a38dfe31-dcfd-430b-acb3-5a531db4197e time = 0
> [11:59:33,537][INFO][tcp-disco-msg-worker-#2][GridSnapshotAwareClusterStateProcessorImpl]
> Received activate request with BaselineTopology[id=0]
> [11:59:33,549][INFO][tcp-disco-msg-worker-#2][GridSnapshotAwareClusterStateProcessorImpl]
> Started state transition: true
> [11:59:33,752][INFO][exchange-worker-#62][time] Started exchange init
> [topVer=AffinityTopologyVersion [topVer=110, minorTopVer=1], crd=true,
> evt=DISCOVERY_CUSTOM_EVT, evtNode=a38dfe31-dcfd-430b-acb3-5a531db4197e,
> customEvt=ChangeGlobalStateMessage
> [id=cea542b6561-47395de6-c204-4576-a0a3-99ec53d41ac3,
> reqId=5b651439-7a6a-43fc-9cb0-d646c3380576,
> initiatingNodeId=a38dfe31-dcfd-430b-acb3-5a531db4197e, activate=true,
> baselineTopology=BaselineTopology [id=0, branchingHash=-69412111965,
> branchingType='New BaselineTopology', baselineNodes=[node42, node43, node44,
> node45, node46, node47, node48, node49, node50, node51, node52, node53,
> node54, node55, node56, node57, node58, node59, node1, node4, node5, node2,
> node3, node8, node9, node6, node7, node60, node61, node62, node63, node64,
> node65, node66, node67, node68, node69, node70, node71, node72, node73,
> node74, node75, node76, node77, node78, node79, node80, node81, node82,
> node83, node84, node85, node86, node87, node88, node89, node90, node91,
> node92, node93, node94, node95, node96, node97, node10, node98, node11,
> node99, node12, node13, node14, node15, node16, node100, node17, node18,
> node19, node108, node107, node106, node105, node104, node103, node102,
> node101, node109, node20, node21, node22, node23, node24, node25, node26,
> node27, node28, node29, node110, node30, node31, node32, node33, node34,
> node35, node36, node37, node38, node39, node40, node41]],
> forceChangeBaselineTopology=false, timestamp=1535101173015], allowMerge=false]
> [11:59:33,753][INFO][exchange-worker-#62][GridDhtPartitionsExchangeFuture]
> Start activation process [nodeId=1906b9c3-73f4-4c30-85cc-cf6b99c3bab9,
> client=false, topVer=AffinityTopologyVersion [topVer=110, minorTopVer=1]]
> [11:59:33,756][INFO][exchange-worker-#62][FilePageStoreManager] Resolved page
> store work directory:
> /storage/ssd/avolkov/tiden/snapshots-180824-114937/test_pitr/ignite.server.1/work/db/node1
> [11:59:33,756][INFO][exchange-worker-#62][FileWriteAheadLogManager] Resolved
> write ahead log work directory:
> /storage/ssd/avolkov/tiden/snapshots-180824-114937/test_pitr/ignite.server.1/work/db/wal/node1
> [11:59:33,756][INFO][exchange-worker-#62][FileWriteAheadLogManager] Resolved
> write ahead log archive directory:
> /storage/ssd/avolkov/tiden/snapshots-180824-114937/test_pitr/ignite.server.1/work/db/wal/archive/node1
> [11:59:33,757][INFO][exchange-worker-#62][FileWriteAheadLogManager] Started
> write-ahead log manager [mode=LOG_ONLY]
> [11:59:33,763][INFO][tcp-disco-msg-worker-#2][TcpDiscoverySpi] Processed
> message type = TcpDiscoveryCustomEventMessage id =
> e4b542b6561-a38dfe31-dcfd-430b-acb3-5a531db4197e time = 629
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-7618) validateCache synchronously waits for state change
[
https://issues.apache.org/jira/browse/IGNITE-7618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16614927#comment-16614927
]
Ivan Bessonov commented on IGNITE-7618:
---
[~Jokser] Thank you for the review. I made "clusterIsActive" field volatile, so
I guess it might be closed.
> validateCache synchronously waits for state change
> --
>
> Key: IGNITE-7618
> URL: https://issues.apache.org/jira/browse/IGNITE-7618
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.4
>Reporter: Alexey Goncharuk
>Assignee: Ivan Bessonov
>Priority: Major
> Fix For: 2.8
>
>
> Currently, we call publicApiActiveState(waitForTransition=true) in
> GridDhtTopologyFutureAdapter#validateCache. This is incorrect, because the
> cluster state is updated from discovery thread, and mapping may be happening
> on a previous topology version. We must capture the cluster active state flag
> to the exchange future (I believe we already have all the mechanics for this
> in ExchangeActions class) and validate the state in the exchange future
> itself, without touching ClusterStateProcessor.
> Below is an example of a deadlock happened because of synchronous wait:
> {code}
> "db-checkpoint-thread-#12318%database.IgniteDbBaselineTopologySelfTest0%"
> #15498 prio=5 os_prio=0 tid=0x7fa173e80800 nid=0x3d08 waiting on
> condition [0x7fa2069a8000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x0007abfc16e8> (a
> java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:870)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1199)
> at
> java.util.concurrent.locks.ReentrantReadWriteLock$WriteLock.lock(ReentrantReadWriteLock.java:943)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$Checkpointer.markCheckpointBegin(GridCacheDatabaseSharedManager.java:2991)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$Checkpointer.doCheckpoint(GridCacheDatabaseSharedManager.java:2797)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$Checkpointer.body(GridCacheDatabaseSharedManager.java:2722)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:745)
> "snapshot-scheduler-restats-#12202%database.IgniteDbBaselineTopologySelfTest0%"
> #15332 prio=5 os_prio=0 tid=0x7fa228143000 nid=0x3c65 waiting on
> condition [0x7fa2be919000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:177)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:140)
> at
> org.apache.ignite.internal.processors.cluster.GridClusterStateProcessor.publicApiActiveState(GridClusterStateProcessor.java:194)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTopologyFutureAdapter.validateCache(GridDhtTopologyFutureAdapter.java:83)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.colocated.GridDhtColocatedLockFuture.mapOnTopology(GridDhtColocatedLockFuture.java:787)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.colocated.GridDhtColocatedLockFuture.map(GridDhtColocatedLockFuture.java:763)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.colocated.GridDhtColocatedCache.lockAllAsync(GridDhtColocatedCache.java:646)
> at
> org.apache.ignite.internal.processors.cache.distributed.GridDistributedCacheAdapter.txLockAsync(GridDistributedCacheAdapter.java:109)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.getAllAsync(GridNearTxLocal.java:1723)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.colocated.GridDhtColocatedCache$4.op(GridDhtColocatedCache.java:197)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter$AsyncOp.op(GridCacheAdapter.java:5140)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.asyncOp(GridCacheAdapter.java:4275)
>
[jira] [Created] (IGNITE-9603) Cache proxy flags are not (de)serialized
Alexey Goncharuk created IGNITE-9603:
Summary: Cache proxy flags are not (de)serialized
Key: IGNITE-9603
URL: https://issues.apache.org/jira/browse/IGNITE-9603
Project: Ignite
Issue Type: Bug
Reporter: Alexey Goncharuk
The following code will fail with {{ClassNotFoundException}} assuming that
cache contains a complex object with key {{1}}.
IgniteCache cache = ignite.cache(CACHE_NAME).withKeepBinary();
ignite.compute().broadcast(() -> {
cache.get(1);
});
The {{withKeepBinary()}} flag is not serialized into the closure and causes the
{{cache.get(1)}} to attempt to deserialize cache read result.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9599) Add ability to manage compression level for compressed WAL archives
[ https://issues.apache.org/jira/browse/IGNITE-9599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16614887#comment-16614887 ] Alexand Polyakov commented on IGNITE-9599: -- If need JMX control use https://github.com/apache/ignite/pull/4763 > Add ability to manage compression level for compressed WAL archives > --- > > Key: IGNITE-9599 > URL: https://issues.apache.org/jira/browse/IGNITE-9599 > Project: Ignite > Issue Type: Improvement >Reporter: Andrey Kalinin >Assignee: Alexand Polyakov >Priority: Minor > > In some cases, WAL compression performance is not sufficient, i.e. new > archives accumulate faster than old ones are compressed. > We did some tests: the file size of 1GB is compressed at the default > compression level for 1 minute, the output file size is ~120MB. > After that, the compression rate was tested with compression-level=-1: 1 GB > file is compressed in 13 seconds, the output file size is ~125MB. > So we need add an option to change the default compression level in the > ignite configuration file. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7618) validateCache synchronously waits for state change
[
https://issues.apache.org/jira/browse/IGNITE-7618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16614843#comment-16614843
]
Pavel Kovalenko commented on IGNITE-7618:
-
[~ibessonov] I reviewed your change and think that "clusterIsActivate" should
be either volatile or final to make sure that we will not have visibility
problems. Overall look good.
> validateCache synchronously waits for state change
> --
>
> Key: IGNITE-7618
> URL: https://issues.apache.org/jira/browse/IGNITE-7618
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.4
>Reporter: Alexey Goncharuk
>Assignee: Ivan Bessonov
>Priority: Major
> Fix For: 2.8
>
>
> Currently, we call publicApiActiveState(waitForTransition=true) in
> GridDhtTopologyFutureAdapter#validateCache. This is incorrect, because the
> cluster state is updated from discovery thread, and mapping may be happening
> on a previous topology version. We must capture the cluster active state flag
> to the exchange future (I believe we already have all the mechanics for this
> in ExchangeActions class) and validate the state in the exchange future
> itself, without touching ClusterStateProcessor.
> Below is an example of a deadlock happened because of synchronous wait:
> {code}
> "db-checkpoint-thread-#12318%database.IgniteDbBaselineTopologySelfTest0%"
> #15498 prio=5 os_prio=0 tid=0x7fa173e80800 nid=0x3d08 waiting on
> condition [0x7fa2069a8000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x0007abfc16e8> (a
> java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:870)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1199)
> at
> java.util.concurrent.locks.ReentrantReadWriteLock$WriteLock.lock(ReentrantReadWriteLock.java:943)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$Checkpointer.markCheckpointBegin(GridCacheDatabaseSharedManager.java:2991)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$Checkpointer.doCheckpoint(GridCacheDatabaseSharedManager.java:2797)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$Checkpointer.body(GridCacheDatabaseSharedManager.java:2722)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:745)
> "snapshot-scheduler-restats-#12202%database.IgniteDbBaselineTopologySelfTest0%"
> #15332 prio=5 os_prio=0 tid=0x7fa228143000 nid=0x3c65 waiting on
> condition [0x7fa2be919000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:177)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:140)
> at
> org.apache.ignite.internal.processors.cluster.GridClusterStateProcessor.publicApiActiveState(GridClusterStateProcessor.java:194)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTopologyFutureAdapter.validateCache(GridDhtTopologyFutureAdapter.java:83)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.colocated.GridDhtColocatedLockFuture.mapOnTopology(GridDhtColocatedLockFuture.java:787)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.colocated.GridDhtColocatedLockFuture.map(GridDhtColocatedLockFuture.java:763)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.colocated.GridDhtColocatedCache.lockAllAsync(GridDhtColocatedCache.java:646)
> at
> org.apache.ignite.internal.processors.cache.distributed.GridDistributedCacheAdapter.txLockAsync(GridDistributedCacheAdapter.java:109)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.getAllAsync(GridNearTxLocal.java:1723)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.colocated.GridDhtColocatedCache$4.op(GridDhtColocatedCache.java:197)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter$AsyncOp.op(GridCacheAdapter.java:5140)
> at
> org.apache.ignite.inte
[jira] [Assigned] (IGNITE-9602) Transaction timeout setter could break GridTimeoutProcessor behavior
[
https://issues.apache.org/jira/browse/IGNITE-9602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexei Scherbakov reassigned IGNITE-9602:
-
Assignee: Alexei Scherbakov
> Transaction timeout setter could break GridTimeoutProcessor behavior
>
>
> Key: IGNITE-9602
> URL: https://issues.apache.org/jira/browse/IGNITE-9602
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.7
>Reporter: Ivan Pavlukhin
>Assignee: Alexei Scherbakov
>Priority: Major
> Attachments: TimeoutBugReproducer.java
>
>
> Current transaction API provides setter method for transaction timeout. It is
> possible to run transaction as follows:
> {code:java}
> try (Transaction tx = ign.transactions().txStart()) {
> tx.timeout(TimeUnit.MINUTES.toMillis(10));
> ...
> }
> {code}
> If default timeout is configured to smaller timeout value then it is possible
> that transaction will be added to the head of timeout queue. Changing timeout
> after that to some big number will lead to situation when head of timeout
> queue contains not smallest timeout end time value, totally breaking
> invariant of that queue. It could lead to a different negative consequences.
> From delaying other tasks in timeout processor until mentioned transaction
> completes or timeouts to completely stalling timeout processor progress
> (broken queue invariant could lead to impossibility to remove objects from
> it). (java.util.concurrent.ConcurrentSkipListMap is used under the hood of
> the timeout queue)
> Actually {{GridNearTxLocal.timeout}} setter tries to reset timeout but does
> it improperly. It looks like that behavior was broken not long ago.
> Reproducer is attached.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9465) Node.js client: improve complex object flags processing
[ https://issues.apache.org/jira/browse/IGNITE-9465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16614835#comment-16614835 ] ekaterina.vergizova commented on IGNITE-9465: - TC tests result: https://ci.ignite.apache.org/viewLog.html?buildId=1867902&tab=buildResultsDiv&buildTypeId=IgniteTests24Java8_ThinClientNodeJs > Node.js client: improve complex object flags processing > --- > > Key: IGNITE-9465 > URL: https://issues.apache.org/jira/browse/IGNITE-9465 > Project: Ignite > Issue Type: Bug > Components: thin client >Reporter: Alexey Kosenchuk >Assignee: ekaterina.vergizova >Priority: Major > Fix For: 2.7 > > > 1) fix the issue in the full schema support > 2) do not throw exception when object with HAS_RAW_DATA flag is received > 3) support OFFSET_*_BYTE flags/optimizations when writing data -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9602) Transaction timeout setter could break GridTimeoutProcessor behavior
[
https://issues.apache.org/jira/browse/IGNITE-9602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Pavlukhin updated IGNITE-9602:
---
Description:
Current transaction API provides setter method for transaction timeout. It is
possible to run transaction as follows:
{code:java}
try (Transaction tx = ign.transactions().txStart()) {
tx.timeout(TimeUnit.MINUTES.toMillis(10));
...
}
{code}
If default timeout is configured to smaller timeout value then it is possible
that transaction will be added to the head of timeout queue. Changing timeout
after that to some big number will lead to situation when head of timeout queue
contains not smallest timeout end time value, totally breaking invariant of
that queue. It could lead to a different negative consequences. From delaying
other tasks in timeout processor until mentioned transaction completes or
timeouts to completely stalling timeout processor progress (broken queue
invariant could lead to impossibility to remove objects from it).
(java.util.concurrent.ConcurrentSkipListMap is used under the hood of the
timeout queue)
Actually {{GridNearTxLocal.timeout}} setter tries to reset timeout but does it
improperly. It looks like that behavior was broken not long ago.
Reproducer is attached.
was:
Current transaction API provides setter method for transaction timeout. It is
possible to run transaction as follows:
{code:java}
try (Transaction tx = ign.transactions().txStart()) {
tx.timeout(TimeUnit.MINUTES.toMillis(10));
...
}
{code}
If default timeout is configured to smaller timeout value then it is possible
that transaction will be added to the head of timeout queue. Changing timeout
after that to some big number will lead to situation when head of timeout queue
contains not smallest timeout end time value, totally breaking invariant of
that queue. It could lead to a different negative consequences. From delaying
other tasks in timeout processor until mentioned transaction completes or
timeouts to completely stalling timeout processor progress (broken queue
invariant could lead to impossibility to remove objects from it).
(java.util.concurrent.ConcurrentSkipListMap is used under the hood of the
timeout queue)
Actually it looks like {{GridNearTxLocal.timeout}} setter tries to reset
timeout but does it improperly.
Reproducer is attached.
> Transaction timeout setter could break GridTimeoutProcessor behavior
>
>
> Key: IGNITE-9602
> URL: https://issues.apache.org/jira/browse/IGNITE-9602
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.7
>Reporter: Ivan Pavlukhin
>Priority: Major
> Attachments: TimeoutBugReproducer.java
>
>
> Current transaction API provides setter method for transaction timeout. It is
> possible to run transaction as follows:
> {code:java}
> try (Transaction tx = ign.transactions().txStart()) {
> tx.timeout(TimeUnit.MINUTES.toMillis(10));
> ...
> }
> {code}
> If default timeout is configured to smaller timeout value then it is possible
> that transaction will be added to the head of timeout queue. Changing timeout
> after that to some big number will lead to situation when head of timeout
> queue contains not smallest timeout end time value, totally breaking
> invariant of that queue. It could lead to a different negative consequences.
> From delaying other tasks in timeout processor until mentioned transaction
> completes or timeouts to completely stalling timeout processor progress
> (broken queue invariant could lead to impossibility to remove objects from
> it). (java.util.concurrent.ConcurrentSkipListMap is used under the hood of
> the timeout queue)
> Actually {{GridNearTxLocal.timeout}} setter tries to reset timeout but does
> it improperly. It looks like that behavior was broken not long ago.
> Reproducer is attached.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9602) Transaction timeout setter could break GridTimeoutProcessor behavior
[
https://issues.apache.org/jira/browse/IGNITE-9602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Pavlukhin updated IGNITE-9602:
---
Description:
Current transaction API provides setter method for transaction timeout. It is
possible to run transaction as follows:
{code:java}
try (Transaction tx = ign.transactions().txStart()) {
tx.timeout(TimeUnit.MINUTES.toMillis(10));
...
}
{code}
If default timeout is configured to smaller timeout value then it is possible
that transaction will be added to the head of timeout queue. Changing timeout
after that to some big number will lead to situation when head of timeout queue
contains not smallest timeout end time value, totally breaking invariant of
that queue. It could lead to a different negative consequences. From delaying
other tasks in timeout processor until mentioned transaction completes or
timeouts to completely stalling timeout processor progress (broken queue
invariant could lead to impossibility to remove objects from it).
(java.util.concurrent.ConcurrentSkipListMap is used under the hood of the
timeout queue)
Actually it looks like {{GridNearTxLocal.timeout}} setter tries to reset
timeout but does it improperly.
Reproducer is attached.
was:
Current transaction API provides setter method for transaction timeout. It is
possible to run transaction as follows:
{code:java}
try (Transaction tx = ign.transactions().txStart()) {
tx.timeout(TimeUnit.MINUTES.toMillis(10));
...
}
{code}
If default timeout is configured to smaller timeout value then it is possible
that transaction will be added to the head of timeout queue. Changing timeout
after that to some big number will lead to situation when head of timeout queue
contains not smallest timeout end time value, totally breaking invariant of
that queue. It could lead to a different negative consequences. From delaying
other tasks in timeout processor until mentioned transaction completes or
timeouts to completely stalling timeout processor progress (broken queue
invariant could lead to impossibility to remove objects from it).
(java.util.concurrent.ConcurrentSkipListMap is used under the hood of the
timeout queue)
Actually it looks like {{GridNearTxLocal.timeout}} setter tries to reset
timeout properly but does it improperly.
Reproducer is attached.
> Transaction timeout setter could break GridTimeoutProcessor behavior
>
>
> Key: IGNITE-9602
> URL: https://issues.apache.org/jira/browse/IGNITE-9602
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.7
>Reporter: Ivan Pavlukhin
>Priority: Major
> Attachments: TimeoutBugReproducer.java
>
>
> Current transaction API provides setter method for transaction timeout. It is
> possible to run transaction as follows:
> {code:java}
> try (Transaction tx = ign.transactions().txStart()) {
> tx.timeout(TimeUnit.MINUTES.toMillis(10));
> ...
> }
> {code}
> If default timeout is configured to smaller timeout value then it is possible
> that transaction will be added to the head of timeout queue. Changing timeout
> after that to some big number will lead to situation when head of timeout
> queue contains not smallest timeout end time value, totally breaking
> invariant of that queue. It could lead to a different negative consequences.
> From delaying other tasks in timeout processor until mentioned transaction
> completes or timeouts to completely stalling timeout processor progress
> (broken queue invariant could lead to impossibility to remove objects from
> it). (java.util.concurrent.ConcurrentSkipListMap is used under the hood of
> the timeout queue)
> Actually it looks like {{GridNearTxLocal.timeout}} setter tries to reset
> timeout but does it improperly.
> Reproducer is attached.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9602) Transaction timeout setter could break GridTimeoutProcessor behavior
[
https://issues.apache.org/jira/browse/IGNITE-9602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Pavlukhin updated IGNITE-9602:
---
Description:
Current transaction API provides setter method for transaction timeout. It is
possible to run transaction as follows:
{code:java}
try (Transaction tx = ign.transactions().txStart()) {
tx.timeout(TimeUnit.MINUTES.toMillis(10));
...
}
{code}
If default timeout is configured to smaller timeout value then it is possible
that transaction will be added to the head of timeout queue. Changing timeout
after that to some big number will lead to situation when head of timeout queue
contains not smallest timeout end time value, totally breaking invariant of
that queue. It could lead to a different negative consequences. From delaying
other tasks in timeout processor until mentioned transaction completes or
timeouts to completely stalling timeout processor progress (broken queue
invariant could lead to impossibility to remove objects from it).
(java.util.concurrent.ConcurrentSkipListMap is used under the hood of the
timeout queue)
Actually it looks like {{GridNearTxLocal.timeout}} setter tries to reset
timeout properly but does it improperly.
Reproducer is attached.
was:
Current transaction API provides setter method for transaction timeout. It is
possible to run transaction as follows:
{code:java}
try (Transaction tx = ign.transactions().txStart()) {
tx.timeout(TimeUnit.MINUTES.toMillis(10));
...
}
{code}
If default timeout is configured to smaller timeout value then it is possible
that transaction will be added to the head of timeout queue. Changing timeout
after that to some big number will lead to situation when head of timeout queue
contains not smallest timeout end time value, totally breaking invariant of
that queue. It could lead to a different negative consequences. From delaying
other tasks in timeout processor until mentioned transaction completes or
timeouts to completely stalling timeout processor progress (broken queue
invariant could lead to impossibility to remove objects from it).
(java.util.concurrent.ConcurrentSkipListMap is used under the hood of the
timeout queue)
Actually it looks like {{GridNearTxLocal.timeout}} setter tries to do timeout
reset properly but does it improperly.
Reproducer is attached.
> Transaction timeout setter could break GridTimeoutProcessor behavior
>
>
> Key: IGNITE-9602
> URL: https://issues.apache.org/jira/browse/IGNITE-9602
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.7
>Reporter: Ivan Pavlukhin
>Priority: Major
> Attachments: TimeoutBugReproducer.java
>
>
> Current transaction API provides setter method for transaction timeout. It is
> possible to run transaction as follows:
> {code:java}
> try (Transaction tx = ign.transactions().txStart()) {
> tx.timeout(TimeUnit.MINUTES.toMillis(10));
> ...
> }
> {code}
> If default timeout is configured to smaller timeout value then it is possible
> that transaction will be added to the head of timeout queue. Changing timeout
> after that to some big number will lead to situation when head of timeout
> queue contains not smallest timeout end time value, totally breaking
> invariant of that queue. It could lead to a different negative consequences.
> From delaying other tasks in timeout processor until mentioned transaction
> completes or timeouts to completely stalling timeout processor progress
> (broken queue invariant could lead to impossibility to remove objects from
> it). (java.util.concurrent.ConcurrentSkipListMap is used under the hood of
> the timeout queue)
> Actually it looks like {{GridNearTxLocal.timeout}} setter tries to reset
> timeout properly but does it improperly.
> Reproducer is attached.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9602) Transaction timeout setter could break GridTimeoutProcessor behavior
[
https://issues.apache.org/jira/browse/IGNITE-9602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Pavlukhin updated IGNITE-9602:
---
Description:
Current transaction API provides setter method for transaction timeout. It is
possible to run transaction as follows:
{code:java}
try (Transaction tx = ign.transactions().txStart()) {
tx.timeout(TimeUnit.MINUTES.toMillis(10));
...
}
{code}
If default timeout is configured to smaller timeout value then it is possible
that transaction will be added to the head of timeout queue. Changing timeout
after that to some big number will lead to situation when head of timeout queue
contains not smallest timeout end time value, totally breaking invariant of
that queue. It could lead to a different negative consequences. From delaying
other tasks in timeout processor until mentioned transaction completes or
timeouts to completely stalling timeout processor progress (broken queue
invariant could lead to impossibility to remove objects from it).
(java.util.concurrent.ConcurrentSkipListMap is used under the hood of the
timeout queue)
Actually it looks like {{GridNearTxLocal.timeout}} setter tries to do timeout
reset properly but does it improperly.
Reproducer is attached.
> Transaction timeout setter could break GridTimeoutProcessor behavior
>
>
> Key: IGNITE-9602
> URL: https://issues.apache.org/jira/browse/IGNITE-9602
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.7
>Reporter: Ivan Pavlukhin
>Priority: Major
> Attachments: TimeoutBugReproducer.java
>
>
> Current transaction API provides setter method for transaction timeout. It is
> possible to run transaction as follows:
> {code:java}
> try (Transaction tx = ign.transactions().txStart()) {
> tx.timeout(TimeUnit.MINUTES.toMillis(10));
> ...
> }
> {code}
> If default timeout is configured to smaller timeout value then it is possible
> that transaction will be added to the head of timeout queue. Changing timeout
> after that to some big number will lead to situation when head of timeout
> queue contains not smallest timeout end time value, totally breaking
> invariant of that queue. It could lead to a different negative consequences.
> From delaying other tasks in timeout processor until mentioned transaction
> completes or timeouts to completely stalling timeout processor progress
> (broken queue invariant could lead to impossibility to remove objects from
> it). (java.util.concurrent.ConcurrentSkipListMap is used under the hood of
> the timeout queue)
> Actually it looks like {{GridNearTxLocal.timeout}} setter tries to do timeout
> reset properly but does it improperly.
> Reproducer is attached.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9602) Transaction timeout setter could break GridTimeoutProcessor behavior
[
https://issues.apache.org/jira/browse/IGNITE-9602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Pavlukhin updated IGNITE-9602:
---
Attachment: TimeoutBugReproducer.java
> Transaction timeout setter could break GridTimeoutProcessor behavior
>
>
> Key: IGNITE-9602
> URL: https://issues.apache.org/jira/browse/IGNITE-9602
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.7
>Reporter: Ivan Pavlukhin
>Priority: Major
> Attachments: TimeoutBugReproducer.java
>
>
> Current transaction API provides setter method for transaction timeout. It is
> possible to run transaction as follows:
> {code:java}
> try (Transaction tx = ign.transactions().txStart()) {
> tx.timeout(TimeUnit.MINUTES.toMillis(10));
> ...
> }
> {code}
> If default timeout is configured to smaller timeout value then it is possible
> that transaction will be added to the head of timeout queue. Changing timeout
> after that to some big number will lead to situation when head of timeout
> queue contains not smallest timeout end time value, totally breaking
> invariant of that queue. It could lead to a different negative consequences.
> From delaying other tasks in timeout processor until mentioned transaction
> completes or timeouts to completely stalling timeout processor progress
> (broken queue invariant could lead to impossibility to remove objects from
> it). (java.util.concurrent.ConcurrentSkipListMap is used under the hood of
> the timeout queue)
> Actually it looks like {{GridNearTxLocal.timeout}} setter tries to do timeout
> reset properly but does it improperly.
> Reproducer is attached.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-9602) Transaction timeout setter could break GridTimeoutProcessor behavior
Ivan Pavlukhin created IGNITE-9602: -- Summary: Transaction timeout setter could break GridTimeoutProcessor behavior Key: IGNITE-9602 URL: https://issues.apache.org/jira/browse/IGNITE-9602 Project: Ignite Issue Type: Bug Components: cache Affects Versions: 2.7 Reporter: Ivan Pavlukhin -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9392) CacheAsyncOperationsFailoverTxTest hangs on TC
[
https://issues.apache.org/jira/browse/IGNITE-9392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16614799#comment-16614799
]
Ilya Lantukh commented on IGNITE-9392:
--
Done.
> CacheAsyncOperationsFailoverTxTest hangs on TC
> --
>
> Key: IGNITE-9392
> URL: https://issues.apache.org/jira/browse/IGNITE-9392
> Project: Ignite
> Issue Type: Bug
>Reporter: Ilya Lantukh
>Assignee: Ilya Lantukh
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.7
>
>
> Exchange worker hangs while waiting for partition release:
> {code}
> [13:42:50] : [Step 3/4] Thread
> [name="exchange-worker-#214881%distributed.CacheAsyncOperationsFailoverTxTest0%",
> id=245275, state=TIMED_WAITING, blockCnt=135, waitCnt=176]
> [13:42:50] : [Step 3/4] at sun.misc.Unsafe.park(Native Method)
> [13:42:50] : [Step 3/4] at
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:338)
> [13:42:50] : [Step 3/4] at
> o.a.i.i.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:217)
> [13:42:50] : [Step 3/4] at
> o.a.i.i.util.future.GridFutureAdapter.get(GridFutureAdapter.java:159)
> [13:42:50] : [Step 3/4] at
> o.a.i.i.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.waitPartitionRelease(GridDhtPartitionsExchangeFuture.java:1367)
> [13:42:50] : [Step 3/4] at
> o.a.i.i.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.distributedExchange(GridDhtPartitionsExchangeFuture.java:1211)
> [13:42:50] : [Step 3/4] at
> o.a.i.i.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:752)
> [13:42:50] : [Step 3/4] at
> o.a.i.i.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body0(GridCachePartitionExchangeManager.java:2525)
> [13:42:50] : [Step 3/4] at
> o.a.i.i.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2405)
> [13:42:50] : [Step 3/4] at
> o.a.i.i.util.worker.GridWorker.run(GridWorker.java:110)
> [13:42:50] : [Step 3/4] at java.lang.Thread.run(Thread.java:748)
> {code}
> At that moment there are lots of pending transactions and one pending TX
> finish future:
> {code}
> [13:43:14]W: [org.apache.ignite:ignite-core] [2018-08-27
> 10:43:14,632][WARN
> ][exchange-worker-#214881%distributed.CacheAsyncOperationsFailoverTxTest0%][diagnostic]
> Failed to wait for partition map exchange [topVer=AffinityTopologyVersion
> [topVer=37, minorTopVer=0], node=98909049-bca4-4cba-b659-768ccfe0].
> Dumping pending objects that might be the cause:
> [13:43:14]W: [org.apache.ignite:ignite-core] [2018-08-27
> 10:43:14,632][WARN
> ][exchange-worker-#214881%distributed.CacheAsyncOperationsFailoverTxTest0%][diagnostic]
> Ready affinity version: AffinityTopologyVersion [topVer=36, minorTopVer=0]
> [13:43:14]W: [org.apache.ignite:ignite-core] [2018-08-27
> 10:43:14,633][WARN
> ][exchange-worker-#214881%distributed.CacheAsyncOperationsFailoverTxTest0%][diagnostic]
> Last exchange future: GridDhtPartitionsExchangeFuture
> [firstDiscoEvt=DiscoveryEvent [evtNode=TcpDiscoveryNode
> [id=387bab47-9542-4d98-8dda-03e3a3f3, addrs=ArrayList [127.0.0.1],
> sockAddrs=HashSet [/127.0.0.1:47503], discPort=47503, order=4, intOrder=4,
> lastExchangeTime=1535366199108, loc=false, ver=2.7.0#20180824-sha1:b0175cf6,
> isClient=false], topVer=37, nodeId8=98909049, msg=Node left: TcpDiscoveryNode
> [id=387bab47-9542-4d98-8dda-03e3a3f3, addrs=ArrayList [127.0.0.1],
> sockAddrs=HashSet [/127.0.0.1:47503], discPort=47503, order=4, intOrder=4,
> lastExchangeTime=1535366199108, loc=false, ver=2.7.0#20180824-sha1:b0175cf6,
> isClient=false], type=NODE_LEFT, tstamp=1535366275135], crd=TcpDiscoveryNode
> [id=98909049-bca4-4cba-b659-768ccfe0, addrs=ArrayList [127.0.0.1],
> sockAddrs=HashSet [/127.0.0.1:47500], discPort=47500, order=1, intOrder=1,
> lastExchangeTime=1535366575460, loc=true, ver=2.7.0#20180824-sha1:b0175cf6,
> isClient=false], exchId=GridDhtPartitionExchangeId
> [topVer=AffinityTopologyVersion [topVer=37, minorTopVer=0],
> discoEvt=DiscoveryEvent [evtNode=TcpDiscoveryNode
> [id=387bab47-9542-4d98-8dda-03e3a3f3, addrs=ArrayList [127.0.0.1],
> sockAddrs=HashSet [/127.0.0.1:47503], discPort=47503, order=4, intOrder=4,
> lastExchangeTime=1535366199108, loc=false, ver=2.7.0#20180824-sha1:b0175cf6,
> isClient=false], topVer=37, nodeId8=98909049, msg=Node left: TcpDiscoveryNode
> [id=387bab47-9542-4d98-8dda-03e3a3f3, addrs=ArrayList [127.0.0.1],
> sockAddrs=HashSet [/127.0.0.1:47503], discPort=47503, order=4, intOrder=4,
> lastExchangeTime=1535
[jira] [Updated] (IGNITE-9601) Write rollover WAL record as the last record in current segment
[ https://issues.apache.org/jira/browse/IGNITE-9601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Kuznetsov updated IGNITE-9601: - Description: Currently, rollover WAL record gets to the next segment when being logged. Moreover, the implementation allows data races, and rollover record is not necessarily the first record in the next segment. We are to add an option to logging facility to allow writing rollover record to the end of the current segment; subsequent records should get to the next segment then. (was: Currently, rollover WAL record gets to the next segment when being logged. Moreover, the implementation does allows data races, and rollover record is not necessarily the first record in the next segment. We are to add an option to logging facility to allow writing rollover record to the end of the current segment; subsequent records should get to the next segment then.) > Write rollover WAL record as the last record in current segment > --- > > Key: IGNITE-9601 > URL: https://issues.apache.org/jira/browse/IGNITE-9601 > Project: Ignite > Issue Type: Task >Affects Versions: 2.6 >Reporter: Andrey Kuznetsov >Assignee: Andrey Kuznetsov >Priority: Major > Fix For: 2.8 > > > Currently, rollover WAL record gets to the next segment when being logged. > Moreover, the implementation allows data races, and rollover record is not > necessarily the first record in the next segment. We are to add an option to > logging facility to allow writing rollover record to the end of the current > segment; subsequent records should get to the next segment then. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9601) Write rollover WAL record as the last record in current segment
[ https://issues.apache.org/jira/browse/IGNITE-9601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16614794#comment-16614794 ] ASF GitHub Bot commented on IGNITE-9601: GitHub user andrey-kuznetsov opened a pull request: https://github.com/apache/ignite/pull/4762 IGNITE-9601 Writing rollover record to the end of current segment. You can merge this pull request into a Git repository by running: $ git pull https://github.com/andrey-kuznetsov/ignite ignite-9601 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4762.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 #4762 commit 13a1dfea64e5974f0014930a08bcf58d239f0428 Author: Andrey Kuznetsov Date: 2018-09-14T12:50:47Z IGNITE-9601 Writing rollover record to the end of current segment. > Write rollover WAL record as the last record in current segment > --- > > Key: IGNITE-9601 > URL: https://issues.apache.org/jira/browse/IGNITE-9601 > Project: Ignite > Issue Type: Task >Affects Versions: 2.6 >Reporter: Andrey Kuznetsov >Assignee: Andrey Kuznetsov >Priority: Major > Fix For: 2.8 > > > Currently, rollover WAL record gets to the next segment when being logged. > Moreover, the implementation does allows data races, and rollover record is > not necessarily the first record in the next segment. We are to add an option > to logging facility to allow writing rollover record to the end of the > current segment; subsequent records should get to the next segment then. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9558) Avoid changing AffinityTopologyVersion on client connect when possible
[ https://issues.apache.org/jira/browse/IGNITE-9558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16614791#comment-16614791 ] ASF GitHub Bot commented on IGNITE-9558: GitHub user ilantukh opened a pull request: https://github.com/apache/ignite/pull/4761 IGNITE-9558 You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-9558 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4761.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 #4761 commit b1a17a82619b72c73453541ba2b85ac77a224050 Author: Ilya Lantukh Date: 2018-09-14T12:48:35Z IGNITE-9558 : Assert for externalizable methods in ATV. > Avoid changing AffinityTopologyVersion on client connect when possible > -- > > Key: IGNITE-9558 > URL: https://issues.apache.org/jira/browse/IGNITE-9558 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.0 >Reporter: Alexey Goncharuk >Assignee: Ilya Lantukh >Priority: Major > > Currently a client join event changes discovery topology version which, in > turn, changes AffinityTopologyVersion. > When a client maps transaction on new AffinityTopologyVersion, corresponding > message is not processed on remote node until remote node receives the > corresponding discovery event. If discovery event delivery is delayed for > some reason, this will result in transaction stalls on client joins. > Since the client node does not change partition affinity, we can safely map > transactions on the previous topology version and do not change the affinity > topology version at all. > Some cases need special care and probably do not qualify for this > optimization, such as when client has near cache or client hosts partition > for REPLICATED cache. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9074) ODBC: Wrong error message on handshake failure
[
https://issues.apache.org/jira/browse/IGNITE-9074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16614781#comment-16614781
]
ASF GitHub Bot commented on IGNITE-9074:
Github user asfgit closed the pull request at:
https://github.com/apache/ignite/pull/4428
> ODBC: Wrong error message on handshake failure
> --
>
> Key: IGNITE-9074
> URL: https://issues.apache.org/jira/browse/IGNITE-9074
> Project: Ignite
> Issue Type: Bug
> Components: odbc
>Affects Versions: 2.1
>Reporter: Igor Sapego
>Assignee: Igor Sapego
>Priority: Major
> Labels: odbc
> Fix For: 2.7
>
>
> Currently, on handshake failure ODBC driver prints the following message:
> {noformat}
> Unsupported version. Current node Apache Ignite version: X.X.X, driver
> protocol version introduced in version: Y.Y.Y.
> {noformat}
> It should say about node's *protocol* version, not the version of the node
> itself.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9465) Node.js client: improve complex object flags processing
[ https://issues.apache.org/jira/browse/IGNITE-9465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16614774#comment-16614774 ] Igor Sapego commented on IGNITE-9465: - [~ekaterina.vergizova], can you run Node.js tests on TC and provide link to results? > Node.js client: improve complex object flags processing > --- > > Key: IGNITE-9465 > URL: https://issues.apache.org/jira/browse/IGNITE-9465 > Project: Ignite > Issue Type: Bug > Components: thin client >Reporter: Alexey Kosenchuk >Assignee: ekaterina.vergizova >Priority: Major > Fix For: 2.7 > > > 1) fix the issue in the full schema support > 2) do not throw exception when object with HAS_RAW_DATA flag is received > 3) support OFFSET_*_BYTE flags/optimizations when writing data -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9314) MVCC TX: Datastreamer operations
[
https://issues.apache.org/jira/browse/IGNITE-9314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-9314:
Fix Version/s: (was: 2.7)
2.8
> MVCC TX: Datastreamer operations
>
>
> Key: IGNITE-9314
> URL: https://issues.apache.org/jira/browse/IGNITE-9314
> Project: Ignite
> Issue Type: Task
> Components: mvcc, sql
>Reporter: Igor Seliverstov
>Priority: Major
> Fix For: 2.8
>
>
> Need to change DataStreamer semantics (make it transactional)
> Currently clients can see DataStreamer partial writes and two subsequent
> selects, which are run in scope of one transaction at load time, may return
> different results.
> Related thread:
>
> [http://apache-ignite-developers.2346864.n4.nabble.com/MVCC-and-IgniteDataStreamer-td32340.html]
> Also there is a problem when {{DataStreamer}} with {{allowOverwrite ==
> false}} does not insert value when versions for entry exist but they all are
> aborted. Proper transactional semantics should developed for such case. After
> that attention should be put on Cache.size method behavior. Cache.size
> addressed in https://issues.apache.org/jira/browse/IGNITE-8149 could be
> decremented improperly in
> {{org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManager#mvccRemoveAll
> method (called during streamer processing) when all existing mvcc row
> versions are aborted or last committed one is _remove_ version.}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9074) ODBC: Wrong error message on handshake failure
[
https://issues.apache.org/jira/browse/IGNITE-9074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16614770#comment-16614770
]
Igor Sapego commented on IGNITE-9074:
-
[~vozerov], tests re-run, everything's good:
https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&branch_IgniteTests24Java8=pull%2F4428%2Fhead
> ODBC: Wrong error message on handshake failure
> --
>
> Key: IGNITE-9074
> URL: https://issues.apache.org/jira/browse/IGNITE-9074
> Project: Ignite
> Issue Type: Bug
> Components: odbc
>Affects Versions: 2.1
>Reporter: Igor Sapego
>Assignee: Igor Sapego
>Priority: Major
> Labels: odbc
> Fix For: 2.7
>
>
> Currently, on handshake failure ODBC driver prints the following message:
> {noformat}
> Unsupported version. Current node Apache Ignite version: X.X.X, driver
> protocol version introduced in version: Y.Y.Y.
> {noformat}
> It should say about node's *protocol* version, not the version of the node
> itself.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9442) Collocated IgniteSet#close is not working on non-affinity node.
[
https://issues.apache.org/jira/browse/IGNITE-9442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-9442:
-
Description:
Method {{close()}} in collocated {{IgniteSet}} works incorrectly if cluster
contains non-affinity nodes.
Steps to reproduce:
1. Start cluster with two nodes: server and client.
2. Create collocated {{IgniteSet}} on client node.
3. Close {{IgniteSet}} on client node.
4. Invoke {{add()}} method on closed IgniteSet.
Expected: {{add()}} throws {{IllegalStateException}}.
Actual: {{add()}} does not throw exception and put new "orphan" item in the
datastructure cache.
Alternatively to client node we can exclude server node by using cache node
filter, as shown in attached junit reproducer.
This bug is related to
[IGNITE-6346|https://issues.apache.org/jira/browse/IGNITE-6346], which also
affects usage of IgniteSet in cluster with non-affinity nodes.
was:
Method {{close()}} in collocated {{IgniteSet}} works incorrectly if cluster
includes non-affinity nodes.
Steps to reproduce:
1. Start cluster with two nodes: server and client.
2. Create collocated {{IgniteSet}} on client node.
3. Close {{IgniteSet}} on client node.
4. Invoke {{add()}} method on closed IgniteSet.
Expected: {{add()}} throws {{IllegalStateException}}.
Actual: {{add()}} does not throw exception and put new "orphan" item in the
datastructure cache.
Alternatively to client node we can exclude server node by using cache node
filter, as shown in attached junit reproducer.
This bug is related to
[IGNITE-6346|https://issues.apache.org/jira/browse/IGNITE-6346], which also
affects usage of IgniteSet in cluster with non-affinity nodes.
> Collocated IgniteSet#close is not working on non-affinity node.
> ---
>
> Key: IGNITE-9442
> URL: https://issues.apache.org/jira/browse/IGNITE-9442
> Project: Ignite
> Issue Type: Bug
> Components: data structures
>Affects Versions: 2.6
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
>Priority: Major
> Attachments: Reproducer.java
>
>
> Method {{close()}} in collocated {{IgniteSet}} works incorrectly if cluster
> contains non-affinity nodes.
> Steps to reproduce:
> 1. Start cluster with two nodes: server and client.
> 2. Create collocated {{IgniteSet}} on client node.
> 3. Close {{IgniteSet}} on client node.
> 4. Invoke {{add()}} method on closed IgniteSet.
> Expected: {{add()}} throws {{IllegalStateException}}.
> Actual: {{add()}} does not throw exception and put new "orphan" item in the
> datastructure cache.
> Alternatively to client node we can exclude server node by using cache node
> filter, as shown in attached junit reproducer.
> This bug is related to
> [IGNITE-6346|https://issues.apache.org/jira/browse/IGNITE-6346], which also
> affects usage of IgniteSet in cluster with non-affinity nodes.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-9470) MVCC TX: Mvcc transactions should throw proper exception when rolled back.
[
https://issues.apache.org/jira/browse/IGNITE-9470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov reassigned IGNITE-9470:
---
Assignee: Andrew Mashenkov (was: Ivan Pavlukhin)
> MVCC TX: Mvcc transactions should throw proper exception when rolled back.
> --
>
> Key: IGNITE-9470
> URL: https://issues.apache.org/jira/browse/IGNITE-9470
> Project: Ignite
> Issue Type: Bug
> Components: jdbc, mvcc, odbc
>Reporter: Roman Kondakov
>Assignee: Andrew Mashenkov
>Priority: Major
> Fix For: 2.7
>
>
> When MVCC transaction is rolled back due to a write conflict it throws
> {{CacheException}} with "Mvcc version mismatch" message. This behavior
> violates Ignite transactions API. Instead it should throw
> {{TransactionRollbackException}} with a clear message like a "Transaction has
> been aborted due to a write conflict (Please try again.)"
> It is also need to propogate this changes to JDBC and ODBC components and fix
> mvcc tests.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9442) Collocated IgniteSet#close is not working on non-affinity node.
[
https://issues.apache.org/jira/browse/IGNITE-9442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16614698#comment-16614698
]
Pavel Pereslegin commented on IGNITE-9442:
--
Hello [~avinogradov].
This patch includes fixing of
[IGNITE-6346|https://issues.apache.org/jira/browse/IGNITE-6346], because this
is a similar problem with non-affinity nodes in the cluster, which are not
currently covered by the API tests.
Please, review it.
> Collocated IgniteSet#close is not working on non-affinity node.
> ---
>
> Key: IGNITE-9442
> URL: https://issues.apache.org/jira/browse/IGNITE-9442
> Project: Ignite
> Issue Type: Bug
> Components: data structures
>Affects Versions: 2.6
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
>Priority: Major
> Attachments: Reproducer.java
>
>
> Method {{close()}} in collocated {{IgniteSet}} works incorrectly if cluster
> includes non-affinity nodes.
> Steps to reproduce:
> 1. Start cluster with two nodes: server and client.
> 2. Create collocated {{IgniteSet}} on client node.
> 3. Close {{IgniteSet}} on client node.
> 4. Invoke {{add()}} method on closed IgniteSet.
> Expected: {{add()}} throws {{IllegalStateException}}.
> Actual: {{add()}} does not throw exception and put new "orphan" item in the
> datastructure cache.
> Alternatively to client node we can exclude server node by using cache node
> filter, as shown in attached junit reproducer.
> This bug is related to
> [IGNITE-6346|https://issues.apache.org/jira/browse/IGNITE-6346], which also
> affects usage of IgniteSet in cluster with non-affinity nodes.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-6346) Distributed set does not work in REPLICATED mode
[
https://issues.apache.org/jira/browse/IGNITE-6346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16614681#comment-16614681
]
Pavel Pereslegin commented on IGNITE-6346:
--
[~avinogradov], [~vk].
One more similar problem was found with non-affinity nodes in IGNITE-9442 and
fixing it includes fixes for this issue.
So I would like to move complete patch in 9442 and close this issue when 9442
will be merged.
> Distributed set does not work in REPLICATED mode
>
>
> Key: IGNITE-6346
> URL: https://issues.apache.org/jira/browse/IGNITE-6346
> Project: Ignite
> Issue Type: Bug
> Components: data structures
>Affects Versions: 2.1
>Reporter: Valentin Kulichenko
>Assignee: vk
>Priority: Major
> Attachments: Reproducer.java
>
>
> When {{IgniteSet}} is created with {{REPLICATED}} cache mode, any attempt to
> read it fails with exception:
> {noformat}
> Exception in thread "main" class org.apache.ignite.IgniteException: Cluster
> group is empty.
> at
> org.apache.ignite.internal.util.lang.GridIteratorAdapter.hasNext(GridIteratorAdapter.java:48)
> at ReplicatedSet.main(ReplicatedSet.java:36)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at com.intellij.rt.execution.application.AppMain.main(AppMain.java:144)
> Caused by: class
> org.apache.ignite.internal.cluster.ClusterGroupEmptyCheckedException: Cluster
> group is empty.
> at
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryAdapter.execute0(GridCacheQueryAdapter.java:481)
> at
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryAdapter.execute(GridCacheQueryAdapter.java:442)
> at
> org.apache.ignite.internal.processors.datastructures.GridCacheSetImpl.iterator0(GridCacheSetImpl.java:420)
> at
> org.apache.ignite.internal.processors.datastructures.GridCacheSetImpl.iterator(GridCacheSetImpl.java:375)
> at
> org.apache.ignite.internal.processors.datastructures.GridCacheSetProxy.iterator(GridCacheSetProxy.java:342)
> ... 6 more
> {noformat}
> To reproduce run the following code:
> {code}
> Ignition.start(new IgniteConfiguration().setIgniteInstanceName("server-1"));
> Ignition.start(new IgniteConfiguration().setIgniteInstanceName("server-2"));
> Ignition.setClientMode(true);
> Ignite ignite = Ignition.start();
> IgniteSet set = ignite.set("my-set", new
> CollectionConfiguration().setCacheMode(CacheMode.REPLICATED));
> for (String s : set) {
> System.out.println(s);
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9601) Write rollover WAL record as the last record in current segment
[ https://issues.apache.org/jira/browse/IGNITE-9601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Kuznetsov updated IGNITE-9601: - Summary: Write rollover WAL record as the last record in current segment (was: Write rollover WAL record as the last ) > Write rollover WAL record as the last record in current segment > --- > > Key: IGNITE-9601 > URL: https://issues.apache.org/jira/browse/IGNITE-9601 > Project: Ignite > Issue Type: Task >Affects Versions: 2.6 >Reporter: Andrey Kuznetsov >Assignee: Andrey Kuznetsov >Priority: Major > Fix For: 2.8 > > > Currently, rollover WAL record gets to the next segment when being logged. > Moreover, the implementation does allows data races, and rollover record is > not necessarily the first record in the next segment. We are to add an option > to logging facility to allow writing rollover record to the end of the > current segment; subsequent records should get to the next segment then. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9601) Write rollover WAL record as the last
Andrey Kuznetsov created IGNITE-9601: Summary: Write rollover WAL record as the last Key: IGNITE-9601 URL: https://issues.apache.org/jira/browse/IGNITE-9601 Project: Ignite Issue Type: Task Affects Versions: 2.6 Reporter: Andrey Kuznetsov Assignee: Andrey Kuznetsov Fix For: 2.8 Currently, rollover WAL record gets to the next segment when being logged. Moreover, the implementation does allows data races, and rollover record is not necessarily the first record in the next segment. We are to add an option to logging facility to allow writing rollover record to the end of the current segment; subsequent records should get to the next segment then. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9465) Node.js client: improve complex object flags processing
[ https://issues.apache.org/jira/browse/IGNITE-9465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16614675#comment-16614675 ] ekaterina.vergizova commented on IGNITE-9465: - Some tests for different field offset types and empty object serialization (HAS_SCHEMA = false) are added > Node.js client: improve complex object flags processing > --- > > Key: IGNITE-9465 > URL: https://issues.apache.org/jira/browse/IGNITE-9465 > Project: Ignite > Issue Type: Bug > Components: thin client >Reporter: Alexey Kosenchuk >Assignee: ekaterina.vergizova >Priority: Major > Fix For: 2.7 > > > 1) fix the issue in the full schema support > 2) do not throw exception when object with HAS_RAW_DATA flag is received > 3) support OFFSET_*_BYTE flags/optimizations when writing data -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9593) Spark Optimization fails to optimize statements
[
https://issues.apache.org/jira/browse/IGNITE-9593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16614655#comment-16614655
]
ASF GitHub Bot commented on IGNITE-9593:
Github user asfgit closed the pull request at:
https://github.com/apache/ignite/pull/4757
> Spark Optimization fails to optimize statements
> ---
>
> Key: IGNITE-9593
> URL: https://issues.apache.org/jira/browse/IGNITE-9593
> Project: Ignite
> Issue Type: Bug
> Components: spark
>Affects Versions: 2.6
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Blocker
> Fix For: 2.7
>
> Attachments: Spark_optimization_bugs_reproducer.patch
>
>
> In some cases, {{IgniteOptimization}} fails to optimize spark query.
> Reproducer attached.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9599) Add ability to manage compression level for compressed WAL archives
[ https://issues.apache.org/jira/browse/IGNITE-9599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16614656#comment-16614656 ] ASF GitHub Bot commented on IGNITE-9599: GitHub user a-polyakov opened a pull request: https://github.com/apache/ignite/pull/4759 IGNITE-9599 Add ability to manage compression level for compressed WAL archives You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite IGNITE-9599 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4759.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 #4759 commit 73b2170fe87595be35bce4cea74c6f86729e2ad7 Author: a-polyakov Date: 2018-09-14T10:38:50Z IGNITE-9599 Add ability to manage compression level for compressed WAL archives Signed-off-by: a-polyakov > Add ability to manage compression level for compressed WAL archives > --- > > Key: IGNITE-9599 > URL: https://issues.apache.org/jira/browse/IGNITE-9599 > Project: Ignite > Issue Type: Improvement >Reporter: Andrey Kalinin >Assignee: Alexand Polyakov >Priority: Minor > > In some cases, WAL compression performance is not sufficient, i.e. new > archives accumulate faster than old ones are compressed. > We did some tests: the file size of 1GB is compressed at the default > compression level for 1 minute, the output file size is ~120MB. > After that, the compression rate was tested with compression-level=-1: 1 GB > file is compressed in 13 seconds, the output file size is ~125MB. > So we need add an option to change the default compression level in the > ignite configuration file. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-6454) Data structure suite timeout: test is not able to fail after interruption
[
https://issues.apache.org/jira/browse/IGNITE-6454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16614648#comment-16614648
]
Denis Garus commented on IGNITE-6454:
-
The cause of handing tests is a hanging transaction on the primary node for the
intrinsic key of IgniteLock data structure.
The Near node is a node that attempts to aсquire a distributed lock, but the
same time distributed has got state interruptAll == true and isBroken == true.
There are two messages for that transaction:
- GridDistributedLockRequest from near node to node with the primary partition.
- GridDistributedLockResponse from the node with the primary partition to near
node.
> Data structure suite timeout: test is not able to fail after interruption
> -
>
> Key: IGNITE-6454
> URL: https://issues.apache.org/jira/browse/IGNITE-6454
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Dmitriy Pavlov
>Assignee: Denis Garus
>Priority: Critical
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.7
>
> Attachments:
> lastStartedTest_GridCacheReplicatedDataStructuresFailoverSelfTest.testFairReentrantLockConstantMultipleTopologyChangeNonFailoverSafe.log.zip,
>
> lastStartedTest_GridCacheReplicatedDataStructuresFailoverSelfTest.testReentrantLockConstantMultipleTopologyChangeNonFailoverSafe.log.zip
>
>
> https://ci.ignite.apache.org/viewType.html?buildTypeId=Ignite20Tests_IgniteDataStrucutures&branch=%3Cdefault%3E&tab=buildTypeStatusDiv
> Most often timeout is caused by following tests:
> GridCacheReplicatedDataStructuresFailoverSelfTest
> - testReentrantLockConstantMultipleTopologyChangeNonFailoverSafe()
> - testFairReentrantLockConstantMultipleTopologyChangeNonFailoverSafe()
> And most of thread dumps contains the following
> {noformat}
> ] :[Step 4/5] Thread
> [name="test-runner-#35143%replicated.GridCacheReplicatedDataStructuresFailoverSelfTest%",
> id=38586, state=RUNNABLE, blockCnt=0, waitCnt=60]
> [20:34:26] : [Step 4/5] at
> java.lang.Throwable.fillInStackTrace(Native Method)
> [20:34:26] : [Step 4/5] at
> java.lang.Throwable.fillInStackTrace(Throwable.java:783)
> [20:34:26] : [Step 4/5] - locked o.a.i.IgniteException@754033e
> [20:34:26] : [Step 4/5] at
> java.lang.Throwable.(Throwable.java:265)
> [20:34:26] : [Step 4/5] at
> java.lang.Exception.(Exception.java:66)
> [20:34:26] : [Step 4/5] at
> java.lang.RuntimeException.(RuntimeException.java:62)
> [20:34:26] : [Step 4/5] at
> o.a.i.IgniteException.(IgniteException.java:44)
> [20:34:26] : [Step 4/5] at
> o.a.i.i.processors.datastructures.GridCacheLockImpl$Sync.validate(GridCacheLockImpl.java:275)
> [20:34:26] : [Step 4/5] at
> o.a.i.i.processors.datastructures.GridCacheLockImpl$Sync.access$1000(GridCacheLockImpl.java:122)
> [20:34:26] : [Step 4/5] at
> o.a.i.i.processors.datastructures.GridCacheLockImpl.lock(GridCacheLockImpl.java:1200)
> [20:34:26] : [Step 4/5] at
> o.a.i.i.processors.cache.datastructures.GridCacheAbstractDataStructuresFailoverSelfTest.doTestReentrantLock(GridCacheAbstractDataStructuresFailoverSelfTest.java:785)
> [20:34:26] : [Step 4/5] at
> o.a.i.i.processors.cache.datastructures.GridCacheAbstractDataStructuresFailoverSelfTest.testFairReentrantLockConstantMultipleTopologyChangeNonFailoverSafe(GridCacheAbstractDataStructuresFailoverSelfTest.java:739)
> [20:34:26] : [Step 4/5] at
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [20:34:26] : [Step 4/5] at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> [20:34:26] : [Step 4/5] at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [20:34:26] : [Step 4/5] at
> java.lang.reflect.Method.invoke(Method.java:606)
> [20:34:26] : [Step 4/5] at
> junit.framework.TestCase.runTest(TestCase.java:176)
> [20:34:26] : [Step 4/5] at
> o.a.i.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2000)
> [20:34:26] : [Step 4/5] at
> o.a.i.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:132)
> [20:34:26] : [Step 4/5] at
> o.a.i.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1915)
> [20:34:26] : [Step 4/5] at java.lang.Thread.run(Thread.java:745)
> [20:34:26] : [Step 4/5]
> {noformat}
> That can be indicator that threads are interrupted and flag
> org.apache.ignite.internal.processors.datastructures.GridCacheLockImpl#interruptAll
> is set,
> than org.apache.ignite.IgniteException is thrown, but it is ignored by test
> and test continues to execute
--
Th
[jira] [Updated] (IGNITE-9584) .NET DataStorageMetricsTest is flaky in master
[ https://issues.apache.org/jira/browse/IGNITE-9584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-9584: - Ignite Flags: (was: Docs Required) > .NET DataStorageMetricsTest is flaky in master > -- > > Key: IGNITE-9584 > URL: https://issues.apache.org/jira/browse/IGNITE-9584 > Project: Ignite > Issue Type: Test >Reporter: Alexey Goncharuk >Assignee: Alexey Goncharuk >Priority: Major > Labels: MakeTeamcityGreenAgain > Fix For: 2.7 > > > Most often it fails because the latest metric does not show a non-zero number > of pages. Looks like it happens because the checkpoint frequency is set to a > too small value. > Also, sometimes checkpoint lock wait time is non-zero because a checkpoint > may start when the test runs cache puts. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9584) .NET DataStorageMetricsTest is flaky in master
[ https://issues.apache.org/jira/browse/IGNITE-9584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-9584: - Labels: MakeTeamcityGreenAgain (was: ) > .NET DataStorageMetricsTest is flaky in master > -- > > Key: IGNITE-9584 > URL: https://issues.apache.org/jira/browse/IGNITE-9584 > Project: Ignite > Issue Type: Test >Reporter: Alexey Goncharuk >Assignee: Alexey Goncharuk >Priority: Major > Labels: MakeTeamcityGreenAgain > Fix For: 2.7 > > > Most often it fails because the latest metric does not show a non-zero number > of pages. Looks like it happens because the checkpoint frequency is set to a > too small value. > Also, sometimes checkpoint lock wait time is non-zero because a checkpoint > may start when the test runs cache puts. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9593) Spark Optimization fails to optimize statements
[
https://issues.apache.org/jira/browse/IGNITE-9593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16614628#comment-16614628
]
Nikolay Izhikov commented on IGNITE-9593:
-
Tests -
https://ci.ignite.apache.org/viewQueued.html?itemId=1866251&tab=queuedBuildOverviewTab
> Spark Optimization fails to optimize statements
> ---
>
> Key: IGNITE-9593
> URL: https://issues.apache.org/jira/browse/IGNITE-9593
> Project: Ignite
> Issue Type: Bug
> Components: spark
>Affects Versions: 2.6
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Blocker
> Fix For: 2.7
>
> Attachments: Spark_optimization_bugs_reproducer.patch
>
>
> In some cases, {{IgniteOptimization}} fails to optimize spark query.
> Reproducer attached.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9573) ZookeeperDiscoverySpiSaslFailedAuthTest fails after added to suite
[ https://issues.apache.org/jira/browse/IGNITE-9573?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Kasnacheev updated IGNITE-9573: Labels: MakeTeamcityGreenAgain (was: ) > ZookeeperDiscoverySpiSaslFailedAuthTest fails after added to suite > -- > > Key: IGNITE-9573 > URL: https://issues.apache.org/jira/browse/IGNITE-9573 > Project: Ignite > Issue Type: Bug >Reporter: Ilya Kasnacheev >Assignee: Ilya Kasnacheev >Priority: Minor > Labels: MakeTeamcityGreenAgain > > Due to proliferation of static fields in Zk and Security code it fails when a > part of suite and/or will cause other tests to fail. Needs to be fixed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9594) Regression in release build for ignite-zookeeper module
[ https://issues.apache.org/jira/browse/IGNITE-9594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16614623#comment-16614623 ] Peter Ivanov commented on IGNITE-9594: -- Looks ok. > Regression in release build for ignite-zookeeper module > --- > > Key: IGNITE-9594 > URL: https://issues.apache.org/jira/browse/IGNITE-9594 > Project: Ignite > Issue Type: Bug >Reporter: Alexey Kuznetsov >Assignee: Alexey Kuznetsov >Priority: Major > Fix For: 2.7 > > > In IGNITE-9073 from pom.xml of ignite-zookeeper jackson-core-asl & > jackson-mapper-asl > were removed and that leads to ClassNotFound errors at runtime if ignite node > uses TcpDiscoveryZookeeperIpFinder and started from binary build. > > We need to return that dependencies back, because Ignite binary build logic > ignore transient dependencies. > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9597) 'size() == 0' replaceable with 'isEmpty()' according inspections profile
[
https://issues.apache.org/jira/browse/IGNITE-9597?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16614611#comment-16614611
]
ASF GitHub Bot commented on IGNITE-9597:
GitHub user Mmuzaf opened a pull request:
https://github.com/apache/ignite/pull/4758
IGNITE-9597: replace with isEmpty
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/Mmuzaf/ignite ignite-9597
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/4758.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 #4758
commit a180e18e0f2a898afeb076d771c9a642b2c6b2bd
Author: Maxim Muzafarov
Date: 2018-09-14T09:56:47Z
IGNITE-9597: replace with isEmpty
> 'size() == 0' replaceable with 'isEmpty()' according inspections profile
>
>
> Key: IGNITE-9597
> URL: https://issues.apache.org/jira/browse/IGNITE-9597
> Project: Ignite
> Issue Type: Bug
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Minor
> Labels: inspections
>
> New `Code Inspections` profile can be found
> {{\idea\ignite_inspections.xml}}.
> We need to fix rule `size() == 0' replaceable with 'isEmpty()` in
> {{ignite-core}} module.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9600) SQL update fails if the sql updates more than one field
[
https://issues.apache.org/jira/browse/IGNITE-9600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16614603#comment-16614603
]
Mikhail Cherkasov commented on IGNITE-9600:
---
[~antkr] clarified that I used "AND" instead of ",", after fixing query it
works fine.
I think this syntax error should be handled and explained to a user by some
clear message.
> SQL update fails if the sql updates more than one field
> ---
>
> Key: IGNITE-9600
> URL: https://issues.apache.org/jira/browse/IGNITE-9600
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.6
>Reporter: Mikhail Cherkasov
>Priority: Minor
> Attachments: TwoFieldUpdate.java
>
>
> SQL update fails if the sql updates more than one field:
> {noformat}
> Exception in thread "main" javax.cache.CacheException: Failed to execute map
> query on remote node [nodeId=9c46dc49-30d2-46ca-a2ec-8b1be7f19c91,
> errMsg=Failed to execute SQL query. Data conversion error converting
> "Entity2"; SQL statement:
> SELECT
> __Z0._KEY __C0_0,
> __Z0._VAL __C0_1,
> ((?1 AND (__Z0.ENTITY_NAME2 = ?2)) AND (__Z0.CONTINENT = ?3)) __C0_2
> FROM PUBLIC.ENTITY_TABLE __Z0
> WHERE __Z0.ENTITY_ID = ?4 [22018-195]]
> at
> org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.fail(GridReduceQueryExecutor.java:288)
> at
> org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.onFail(GridReduceQueryExecutor.java:278)
> at
> org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.onMessage(GridReduceQueryExecutor.java:257)
> at
> org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor$2.onMessage(GridReduceQueryExecutor.java:202)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$ArrayListener.onMessage(GridIoManager.java:2349)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1569)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1197)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:127)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1093)
> at
> 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){noformat}
> Looks like ignite or underlying h2 engine generates query incorrectly:
> ((?1 AND (__Z0.ENTITY_NAME2 = ?2)) AND (__Z0.CONTINENT = ?3)) __C0_2
> the name for first field is missed.
>
> The reproducer is attached.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9600) SQL update fails if the sql updates more than one field
[
https://issues.apache.org/jira/browse/IGNITE-9600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Cherkasov updated IGNITE-9600:
--
Priority: Minor (was: Blocker)
> SQL update fails if the sql updates more than one field
> ---
>
> Key: IGNITE-9600
> URL: https://issues.apache.org/jira/browse/IGNITE-9600
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.6
>Reporter: Mikhail Cherkasov
>Priority: Minor
> Attachments: TwoFieldUpdate.java
>
>
> SQL update fails if the sql updates more than one field:
> {noformat}
> Exception in thread "main" javax.cache.CacheException: Failed to execute map
> query on remote node [nodeId=9c46dc49-30d2-46ca-a2ec-8b1be7f19c91,
> errMsg=Failed to execute SQL query. Data conversion error converting
> "Entity2"; SQL statement:
> SELECT
> __Z0._KEY __C0_0,
> __Z0._VAL __C0_1,
> ((?1 AND (__Z0.ENTITY_NAME2 = ?2)) AND (__Z0.CONTINENT = ?3)) __C0_2
> FROM PUBLIC.ENTITY_TABLE __Z0
> WHERE __Z0.ENTITY_ID = ?4 [22018-195]]
> at
> org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.fail(GridReduceQueryExecutor.java:288)
> at
> org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.onFail(GridReduceQueryExecutor.java:278)
> at
> org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.onMessage(GridReduceQueryExecutor.java:257)
> at
> org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor$2.onMessage(GridReduceQueryExecutor.java:202)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$ArrayListener.onMessage(GridIoManager.java:2349)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1569)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1197)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:127)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1093)
> at
> 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){noformat}
> Looks like ignite or underlying h2 engine generates query incorrectly:
> ((?1 AND (__Z0.ENTITY_NAME2 = ?2)) AND (__Z0.CONTINENT = ?3)) __C0_2
> the name for first field is missed.
>
> The reproducer is attached.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9573) ZookeeperDiscoverySpiSaslFailedAuthTest fails after added to suite
[ https://issues.apache.org/jira/browse/IGNITE-9573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16614601#comment-16614601 ] Ilya Kasnacheev commented on IGNITE-9573: - [~dpavlov] please review proposed test fix. > ZookeeperDiscoverySpiSaslFailedAuthTest fails after added to suite > -- > > Key: IGNITE-9573 > URL: https://issues.apache.org/jira/browse/IGNITE-9573 > Project: Ignite > Issue Type: Bug >Reporter: Ilya Kasnacheev >Assignee: Ilya Kasnacheev >Priority: Minor > > Due to proliferation of static fields in Zk and Security code it fails when a > part of suite and/or will cause other tests to fail. Needs to be fixed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9392) CacheAsyncOperationsFailoverTxTest hangs on TC
[
https://issues.apache.org/jira/browse/IGNITE-9392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Govorukhin updated IGNITE-9392:
---
Fix Version/s: 2.7
> CacheAsyncOperationsFailoverTxTest hangs on TC
> --
>
> Key: IGNITE-9392
> URL: https://issues.apache.org/jira/browse/IGNITE-9392
> Project: Ignite
> Issue Type: Bug
>Reporter: Ilya Lantukh
>Assignee: Ilya Lantukh
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.7
>
>
> Exchange worker hangs while waiting for partition release:
> {code}
> [13:42:50] : [Step 3/4] Thread
> [name="exchange-worker-#214881%distributed.CacheAsyncOperationsFailoverTxTest0%",
> id=245275, state=TIMED_WAITING, blockCnt=135, waitCnt=176]
> [13:42:50] : [Step 3/4] at sun.misc.Unsafe.park(Native Method)
> [13:42:50] : [Step 3/4] at
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:338)
> [13:42:50] : [Step 3/4] at
> o.a.i.i.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:217)
> [13:42:50] : [Step 3/4] at
> o.a.i.i.util.future.GridFutureAdapter.get(GridFutureAdapter.java:159)
> [13:42:50] : [Step 3/4] at
> o.a.i.i.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.waitPartitionRelease(GridDhtPartitionsExchangeFuture.java:1367)
> [13:42:50] : [Step 3/4] at
> o.a.i.i.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.distributedExchange(GridDhtPartitionsExchangeFuture.java:1211)
> [13:42:50] : [Step 3/4] at
> o.a.i.i.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:752)
> [13:42:50] : [Step 3/4] at
> o.a.i.i.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body0(GridCachePartitionExchangeManager.java:2525)
> [13:42:50] : [Step 3/4] at
> o.a.i.i.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2405)
> [13:42:50] : [Step 3/4] at
> o.a.i.i.util.worker.GridWorker.run(GridWorker.java:110)
> [13:42:50] : [Step 3/4] at java.lang.Thread.run(Thread.java:748)
> {code}
> At that moment there are lots of pending transactions and one pending TX
> finish future:
> {code}
> [13:43:14]W: [org.apache.ignite:ignite-core] [2018-08-27
> 10:43:14,632][WARN
> ][exchange-worker-#214881%distributed.CacheAsyncOperationsFailoverTxTest0%][diagnostic]
> Failed to wait for partition map exchange [topVer=AffinityTopologyVersion
> [topVer=37, minorTopVer=0], node=98909049-bca4-4cba-b659-768ccfe0].
> Dumping pending objects that might be the cause:
> [13:43:14]W: [org.apache.ignite:ignite-core] [2018-08-27
> 10:43:14,632][WARN
> ][exchange-worker-#214881%distributed.CacheAsyncOperationsFailoverTxTest0%][diagnostic]
> Ready affinity version: AffinityTopologyVersion [topVer=36, minorTopVer=0]
> [13:43:14]W: [org.apache.ignite:ignite-core] [2018-08-27
> 10:43:14,633][WARN
> ][exchange-worker-#214881%distributed.CacheAsyncOperationsFailoverTxTest0%][diagnostic]
> Last exchange future: GridDhtPartitionsExchangeFuture
> [firstDiscoEvt=DiscoveryEvent [evtNode=TcpDiscoveryNode
> [id=387bab47-9542-4d98-8dda-03e3a3f3, addrs=ArrayList [127.0.0.1],
> sockAddrs=HashSet [/127.0.0.1:47503], discPort=47503, order=4, intOrder=4,
> lastExchangeTime=1535366199108, loc=false, ver=2.7.0#20180824-sha1:b0175cf6,
> isClient=false], topVer=37, nodeId8=98909049, msg=Node left: TcpDiscoveryNode
> [id=387bab47-9542-4d98-8dda-03e3a3f3, addrs=ArrayList [127.0.0.1],
> sockAddrs=HashSet [/127.0.0.1:47503], discPort=47503, order=4, intOrder=4,
> lastExchangeTime=1535366199108, loc=false, ver=2.7.0#20180824-sha1:b0175cf6,
> isClient=false], type=NODE_LEFT, tstamp=1535366275135], crd=TcpDiscoveryNode
> [id=98909049-bca4-4cba-b659-768ccfe0, addrs=ArrayList [127.0.0.1],
> sockAddrs=HashSet [/127.0.0.1:47500], discPort=47500, order=1, intOrder=1,
> lastExchangeTime=1535366575460, loc=true, ver=2.7.0#20180824-sha1:b0175cf6,
> isClient=false], exchId=GridDhtPartitionExchangeId
> [topVer=AffinityTopologyVersion [topVer=37, minorTopVer=0],
> discoEvt=DiscoveryEvent [evtNode=TcpDiscoveryNode
> [id=387bab47-9542-4d98-8dda-03e3a3f3, addrs=ArrayList [127.0.0.1],
> sockAddrs=HashSet [/127.0.0.1:47503], discPort=47503, order=4, intOrder=4,
> lastExchangeTime=1535366199108, loc=false, ver=2.7.0#20180824-sha1:b0175cf6,
> isClient=false], topVer=37, nodeId8=98909049, msg=Node left: TcpDiscoveryNode
> [id=387bab47-9542-4d98-8dda-03e3a3f3, addrs=ArrayList [127.0.0.1],
> sockAddrs=HashSet [/127.0.0.1:47503], discPort=47503, order=4, intOrder=4,
> lastExchangeTime=1535366199108, loc=false, ver=2.7
[jira] [Commented] (IGNITE-9593) Spark Optimization fails to optimize statements
[
https://issues.apache.org/jira/browse/IGNITE-9593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16614591#comment-16614591
]
ASF GitHub Bot commented on IGNITE-9593:
GitHub user nizhikov opened a pull request:
https://github.com/apache/ignite/pull/4757
IGNITE-9593: Fix of IgniteOptimization bugs.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/nizhikov/ignite IGNITE-9593
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/4757.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 #4757
commit e1800978d36115419be777dacbc79cc0e2e7c89a
Author: Nikolay Izhikov
Date: 2018-09-14T04:06:48Z
IGNITE-9593: Two of three bugs fixed
commit 12791876fb421e2c81c1430c2e9fd5e3ec4a2185
Author: Nikolay Izhikov
Date: 2018-09-14T09:45:15Z
IGNITE-9593: Fix of IgniteOptimization bugs.
> Spark Optimization fails to optimize statements
> ---
>
> Key: IGNITE-9593
> URL: https://issues.apache.org/jira/browse/IGNITE-9593
> Project: Ignite
> Issue Type: Bug
> Components: spark
>Affects Versions: 2.6
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Blocker
> Fix For: 2.7
>
> Attachments: Spark_optimization_bugs_reproducer.patch
>
>
> In some cases, {{IgniteOptimization}} fails to optimize spark query.
> Reproducer attached.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9600) SQL update fails if the sql updates more than one field
[
https://issues.apache.org/jira/browse/IGNITE-9600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Cherkasov updated IGNITE-9600:
--
Attachment: TwoFieldUpdate.java
> SQL update fails if the sql updates more than one field
> ---
>
> Key: IGNITE-9600
> URL: https://issues.apache.org/jira/browse/IGNITE-9600
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.6
>Reporter: Mikhail Cherkasov
>Priority: Blocker
> Attachments: TwoFieldUpdate.java
>
>
> SQL update fails if the sql updates more than one field:
> {noformat}
> Exception in thread "main" javax.cache.CacheException: Failed to execute map
> query on remote node [nodeId=9c46dc49-30d2-46ca-a2ec-8b1be7f19c91,
> errMsg=Failed to execute SQL query. Data conversion error converting
> "Entity2"; SQL statement:
> SELECT
> __Z0._KEY __C0_0,
> __Z0._VAL __C0_1,
> ((?1 AND (__Z0.ENTITY_NAME2 = ?2)) AND (__Z0.CONTINENT = ?3)) __C0_2
> FROM PUBLIC.ENTITY_TABLE __Z0
> WHERE __Z0.ENTITY_ID = ?4 [22018-195]]
> at
> org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.fail(GridReduceQueryExecutor.java:288)
> at
> org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.onFail(GridReduceQueryExecutor.java:278)
> at
> org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.onMessage(GridReduceQueryExecutor.java:257)
> at
> org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor$2.onMessage(GridReduceQueryExecutor.java:202)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$ArrayListener.onMessage(GridIoManager.java:2349)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1569)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1197)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:127)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1093)
> at
> 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){noformat}
> Looks like ignite or underlying h2 engine generates query incorrectly:
> ((?1 AND (__Z0.ENTITY_NAME2 = ?2)) AND (__Z0.CONTINENT = ?3)) __C0_2
> the name for first field is missed.
>
> The reproducer is attached.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-9600) SQL update fails if the sql updates more than one field
Mikhail Cherkasov created IGNITE-9600:
-
Summary: SQL update fails if the sql updates more than one field
Key: IGNITE-9600
URL: https://issues.apache.org/jira/browse/IGNITE-9600
Project: Ignite
Issue Type: Bug
Components: sql
Affects Versions: 2.6
Reporter: Mikhail Cherkasov
SQL update fails if the sql updates more than one field:
{noformat}
Exception in thread "main" javax.cache.CacheException: Failed to execute map
query on remote node [nodeId=9c46dc49-30d2-46ca-a2ec-8b1be7f19c91,
errMsg=Failed to execute SQL query. Data conversion error converting "Entity2";
SQL statement:
SELECT
__Z0._KEY __C0_0,
__Z0._VAL __C0_1,
((?1 AND (__Z0.ENTITY_NAME2 = ?2)) AND (__Z0.CONTINENT = ?3)) __C0_2
FROM PUBLIC.ENTITY_TABLE __Z0
WHERE __Z0.ENTITY_ID = ?4 [22018-195]]
at
org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.fail(GridReduceQueryExecutor.java:288)
at
org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.onFail(GridReduceQueryExecutor.java:278)
at
org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.onMessage(GridReduceQueryExecutor.java:257)
at
org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor$2.onMessage(GridReduceQueryExecutor.java:202)
at
org.apache.ignite.internal.managers.communication.GridIoManager$ArrayListener.onMessage(GridIoManager.java:2349)
at
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1569)
at
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1197)
at
org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:127)
at
org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1093)
at
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){noformat}
Looks like ignite or underlying h2 engine generates query incorrectly:
((?1 AND (__Z0.ENTITY_NAME2 = ?2)) AND (__Z0.CONTINENT = ?3)) __C0_2
the name for first field is missed.
The reproducer is attached.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[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&focusedCommentId=16614576#comment-16614576 ] Sergey Grimstad commented on IGNITE-8552: - reviewed, re-run https://ci.ignite.apache.org/viewLog.html?buildId=1859127&buildTypeId=IgniteTests24Java8_RunAllSql&tab=buildResultsDiv > 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: Sergey Grimstad >Priority: Blocker > Fix For: 2.7 > > Attachments: IGNITE-8552_implemented.patch > > > 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] [Assigned] (IGNITE-9599) Add ability to manage compression level for compressed WAL archives
[ https://issues.apache.org/jira/browse/IGNITE-9599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexand Polyakov reassigned IGNITE-9599: Assignee: Alexand Polyakov > Add ability to manage compression level for compressed WAL archives > --- > > Key: IGNITE-9599 > URL: https://issues.apache.org/jira/browse/IGNITE-9599 > Project: Ignite > Issue Type: Improvement >Reporter: Andrey Kalinin >Assignee: Alexand Polyakov >Priority: Minor > > In some cases, WAL compression performance is not sufficient, i.e. new > archives accumulate faster than old ones are compressed. > We did some tests: the file size of 1GB is compressed at the default > compression level for 1 minute, the output file size is ~120MB. > After that, the compression rate was tested with compression-level=-1: 1 GB > file is compressed in 13 seconds, the output file size is ~125MB. > So we need add an option to change the default compression level in the > ignite configuration file. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9487) REST: getall can only output keys as scalars
[
https://issues.apache.org/jira/browse/IGNITE-9487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16614568#comment-16614568
]
ASF GitHub Bot commented on IGNITE-9487:
GitHub user alamar opened a pull request:
https://github.com/apache/ignite/pull/4756
IGNITE-9487 Introduce IGNITE_REST_GETALL_KEY_VALUE to change getall output
format.
Second take
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-9487bis
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/4756.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 #4756
commit b1b9ee2c32357f8919379e9b2d1606196eb42999
Author: Ilya Kasnacheev
Date: 2018-09-14T09:21:29Z
IGNITE-9487 Introduce IGNITE_REST_GETALL_KEY_VALUE to change getall output
format.
> REST: getall can only output keys as scalars
>
>
> Key: IGNITE-9487
> URL: https://issues.apache.org/jira/browse/IGNITE-9487
> Project: Ignite
> Issue Type: Improvement
> Components: rest
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Kasnacheev
>Priority: Major
>
> Regardless of what ConnectorMessageInterceptor does, `getall' command can
> only output key as string or number, and not as JSON object as values can.
> This is because output format is as follows:
> {code}
> {"successStatus":0,"affinityNodeId":null,"sessionToken":null,"response":{"CustomType
> [idHash=1588995554, hash=34706515, key=111]":{"val":"111"},"CustomType
> [idHash=978025370, hash=30386820, key=222]":{"val":"222"}},"error":null}
> {code}
> The desired output format may look like:
> {code}
> {"successStatus":0,"affinityNodeId":null,"sessionToken":null,"response":[{"key":{"key":111},"value":{"val":"111"}},{"key":{"key":222},"value":{"val":"222"}}],"error":null}
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9599) Add ability to manage compression level for compressed WAL archives
[ https://issues.apache.org/jira/browse/IGNITE-9599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Kalinin updated IGNITE-9599: --- Description: In some cases, WAL compression performance is not sufficient, i.e. new archives accumulate faster than old ones are compressed. We did some tests: the file size of 1GB is compressed at the default compression level for 1 minute, the output file size is ~120MB. After that, the compression rate was tested with compression-level=-1: 1 GB file is compressed in 13 seconds, the output file size is ~125MB. So we need add an option to change the default compression level in the ignite configuration file. was:In some cases, WAL compression performance is not sufficient, i.e. new archives accumulate faster than old ones are compressed. We need add an option to change the default compression level in the ignite configuration file. > Add ability to manage compression level for compressed WAL archives > --- > > Key: IGNITE-9599 > URL: https://issues.apache.org/jira/browse/IGNITE-9599 > Project: Ignite > Issue Type: Improvement >Reporter: Andrey Kalinin >Priority: Minor > > In some cases, WAL compression performance is not sufficient, i.e. new > archives accumulate faster than old ones are compressed. > We did some tests: the file size of 1GB is compressed at the default > compression level for 1 minute, the output file size is ~120MB. > After that, the compression rate was tested with compression-level=-1: 1 GB > file is compressed in 13 seconds, the output file size is ~125MB. > So we need add an option to change the default compression level in the > ignite configuration file. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9599) Add ability to manage compression level for compressed WAL archives
[ https://issues.apache.org/jira/browse/IGNITE-9599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Kalinin updated IGNITE-9599: --- Description: In some cases, WAL compression performance is not sufficient, i.e. new archives accumulate faster than old ones are compressed. We need add an option to change the default compression level. (was: In some cases, WAL compression performance is not sufficient, i.e. new archives accumulate faster than old ones are compressed. We must add an option to change the default compression level.) > Add ability to manage compression level for compressed WAL archives > --- > > Key: IGNITE-9599 > URL: https://issues.apache.org/jira/browse/IGNITE-9599 > Project: Ignite > Issue Type: Improvement >Reporter: Andrey Kalinin >Priority: Minor > > In some cases, WAL compression performance is not sufficient, i.e. new > archives accumulate faster than old ones are compressed. We need add an > option to change the default compression level. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9599) Add ability to manage compression level for compressed WAL archives
[ https://issues.apache.org/jira/browse/IGNITE-9599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Kalinin updated IGNITE-9599: --- Description: In some cases, WAL compression performance is not sufficient, i.e. new archives accumulate faster than old ones are compressed. We need add an option to change the default compression level in the ignite configuration file. (was: In some cases, WAL compression performance is not sufficient, i.e. new archives accumulate faster than old ones are compressed. We need add an option to change the default compression level.) > Add ability to manage compression level for compressed WAL archives > --- > > Key: IGNITE-9599 > URL: https://issues.apache.org/jira/browse/IGNITE-9599 > Project: Ignite > Issue Type: Improvement >Reporter: Andrey Kalinin >Priority: Minor > > In some cases, WAL compression performance is not sufficient, i.e. new > archives accumulate faster than old ones are compressed. We need add an > option to change the default compression level in the ignite configuration > file. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9599) Add ability to manage compression level for compressed WAL archives
Andrey Kalinin created IGNITE-9599: -- Summary: Add ability to manage compression level for compressed WAL archives Key: IGNITE-9599 URL: https://issues.apache.org/jira/browse/IGNITE-9599 Project: Ignite Issue Type: Improvement Reporter: Andrey Kalinin In some cases, WAL compression performance is not sufficient, i.e. new archives accumulate faster than old ones are compressed. We must add an option to change the default compression level. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9580) Fix exit code 137 in Query 1 Suite
[ https://issues.apache.org/jira/browse/IGNITE-9580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16614549#comment-16614549 ] Dmitriy Pavlov commented on IGNITE-9580: Yes, sure, thank you > Fix exit code 137 in Query 1 Suite > -- > > Key: IGNITE-9580 > URL: https://issues.apache.org/jira/browse/IGNITE-9580 > Project: Ignite > Issue Type: Bug >Reporter: Alexey Platonov >Assignee: Alexey Platonov >Priority: Major > Labels: MakeTeamcityGreenAgain > > Sometimes "Queries 1" fails with 137 exit code without stacktraces. > Potentially it's due to OOM-Killer activity and some test suite without > configuration of maxSize-parameter in data region config. > > Examples of failure > > [https://ci.ignite.apache.org/viewLog.html?buildId=1797966&tab=buildResultsDiv&buildTypeId=IgniteTests24Java8_Queries1] > [https://ci.ignite.apache.org/viewLog.html?buildId=1838170&tab=buildResultsDiv&buildTypeId=IgniteTests24Java8_Queries1] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9550) Get operation returns null for a lost partition with READ_SAFE policy
[ https://issues.apache.org/jira/browse/IGNITE-9550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Govorukhin updated IGNITE-9550: --- Fix Version/s: 2.7 > Get operation returns null for a lost partition with READ_SAFE policy > - > > Key: IGNITE-9550 > URL: https://issues.apache.org/jira/browse/IGNITE-9550 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.6 >Reporter: Pavel Vinokurov >Assignee: Ivan Bessonov >Priority: Major > Fix For: 2.7 > > Attachments: PartitionLostReproducer.java > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9442) Collocated IgniteSet#close is not working on non-affinity node.
[
https://issues.apache.org/jira/browse/IGNITE-9442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-9442:
-
Description:
Method {{close()}} in collocated {{IgniteSet}} works incorrectly if cluster
includes non-affinity nodes.
Steps to reproduce:
1. Start cluster with two nodes: server and client.
2. Create collocated {{IgniteSet}} on client node.
3. Close {{IgniteSet}} on client node.
4. Invoke {{add()}} method on closed IgniteSet.
Expected: {{add()}} throws {{IllegalStateException}}.
Actual: {{add()}} does not throw exception and put new "orphan" item in the
datastructure cache.
Alternatively to client node we can exclude server node by using cache node
filter, as shown in attached junit reproducer.
This bug is related to
[IGNITE-6346|https://issues.apache.org/jira/browse/IGNITE-6346], which also
affects usage of IgniteSet in cluster with non-affinity nodes.
was:
Method {{close()}} in collocated {{IgniteSet}} works incorrectly if cluster
includes non-affinity nodes.
Steps to reproduce:
1. Start cluster with two nodes: server and client.
2. Create collocated {{IgniteSet}} on client node.
3. Close {{IgniteSet}} on client node.
4. Invoke {{add()}} method on closed IgniteSet.
Expected: {{add()}} throws {{IllegalStateException}}.
Actual: {{add()}} does not throw exception and put new "orphan" item in the
datastructure cache.
Alternatively to client node we can exclude server node by using cache node
filter, as shown in attached junit reproducer.
This bug relates to
[IGNITE-6346|https://issues.apache.org/jira/browse/IGNITE-6346], which also
affects usage of IgniteSet in cluster with non-affinity nodes.
> Collocated IgniteSet#close is not working on non-affinity node.
> ---
>
> Key: IGNITE-9442
> URL: https://issues.apache.org/jira/browse/IGNITE-9442
> Project: Ignite
> Issue Type: Bug
> Components: data structures
>Affects Versions: 2.6
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
>Priority: Major
> Attachments: Reproducer.java
>
>
> Method {{close()}} in collocated {{IgniteSet}} works incorrectly if cluster
> includes non-affinity nodes.
> Steps to reproduce:
> 1. Start cluster with two nodes: server and client.
> 2. Create collocated {{IgniteSet}} on client node.
> 3. Close {{IgniteSet}} on client node.
> 4. Invoke {{add()}} method on closed IgniteSet.
> Expected: {{add()}} throws {{IllegalStateException}}.
> Actual: {{add()}} does not throw exception and put new "orphan" item in the
> datastructure cache.
> Alternatively to client node we can exclude server node by using cache node
> filter, as shown in attached junit reproducer.
> This bug is related to
> [IGNITE-6346|https://issues.apache.org/jira/browse/IGNITE-6346], which also
> affects usage of IgniteSet in cluster with non-affinity nodes.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9249) Tests hang when different threads try to start and stop nodes at the same time.
[
https://issues.apache.org/jira/browse/IGNITE-9249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16614539#comment-16614539
]
Alexey Goncharuk commented on IGNITE-9249:
--
[~ilantukh], I see multiple mass tests failures in your PR for tests with 0%
failure rate in master. Please take a look.
> Tests hang when different threads try to start and stop nodes at the same
> time.
> ---
>
> Key: IGNITE-9249
> URL: https://issues.apache.org/jira/browse/IGNITE-9249
> Project: Ignite
> Issue Type: Bug
>Reporter: Ilya Lantukh
>Assignee: Ilya Lantukh
>Priority: Major
> Labels: MakeTeamcityGreenAgain
>
> An example of such test is
> GridCachePartitionedNearDisabledOptimisticTxNodeRestartTest.testRestartWithPutFourNodesOneBackupsOffheapEvict().
> Hanged threads:
> {code}
> "restart-worker-1@63424" prio=5 tid=0x7f5e nid=NA waiting
> java.lang.Thread.State: WAITING
> at java.lang.Object.wait(Object.java:-1)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl.joinTopology(ServerImpl.java:949)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl.spiStart(ServerImpl.java:389)
> at
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.spiStart(TcpDiscoverySpi.java:2002)
> at
> org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:297)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.start(GridDiscoveryManager.java:916)
> at
> org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:1754)
> at
> org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1050)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2020)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1725)
> - locked <0xfc36> (a
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1153)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:651)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:920)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:858)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:846)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:812)
> at
> org.apache.ignite.internal.processors.cache.distributed.GridCacheAbstractNodeRestartSelfTest.access$1000(GridCacheAbstractNodeRestartSelfTest.java:64)
> at
> org.apache.ignite.internal.processors.cache.distributed.GridCacheAbstractNodeRestartSelfTest$2.run(GridCacheAbstractNodeRestartSelfTest.java:665)
> at java.lang.Thread.run(Thread.java:748)
> "restart-worker-0@63423" prio=5 tid=0x7f5d nid=NA waiting
> java.lang.Thread.State: WAITING
> at sun.misc.Unsafe.park(Unsafe.java:-1)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304)
> at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231)
> at
> org.apache.ignite.internal.util.IgniteUtils.awaitQuiet(IgniteUtils.java:7584)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.grid(IgnitionEx.java:1666)
> at
> org.apache.ignite.internal.IgnitionEx.allGrids(IgnitionEx.java:1284)
> at
> org.apache.ignite.internal.IgnitionEx.allGrids(IgnitionEx.java:1262)
> at org.apache.ignite.Ignition.allGrids(Ignition.java:502)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.awaitTopologyChange(GridAbstractTest.java:2258)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.stopGrid(GridAbstractTest.java:1158)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.stopGrid(GridAbstractTest.java:1133)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.stopGrid(GridAbstractTest.java:1433)
> at
> org.apache.ignite.internal.processors.cache.distributed.GridCacheAbstractNodeRestartSelfTest.access$800(GridCacheAbstractNodeRestartSelfTest.java:64)
> at
> org.apache.ignite.internal.processors.cache.distributed.GridCacheAbst
[jira] [Updated] (IGNITE-9442) Collocated IgniteSet#close is not working on non-affinity node.
[
https://issues.apache.org/jira/browse/IGNITE-9442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-9442:
-
Description:
Method {{close()}} in collocated {{IgniteSet}} works incorrectly if cluster
includes non-affinity nodes.
Steps to reproduce:
1. Start cluster with two nodes: server and client.
2. Create collocated {{IgniteSet}} on client node.
3. Close {{IgniteSet}} on client node.
4. Invoke {{add()}} method on closed IgniteSet.
Expected: {{add()}} throws {{IllegalStateException}}.
Actual: {{add()}} does not throw exception and put new "orphan" item in the
datastructure cache.
Alternatively to client node we can exclude server node by using cache node
filter, as shown in attached junit reproducer.
This bug relates to
[IGNITE-6346|https://issues.apache.org/jira/browse/IGNITE-6346], which also
affects usage of IgniteSet in cluster with non-affinity nodes.
was:
Method {{close()}} in collocated {{IgniteSet}} works incorrectly if cluster
includes non-affinity nodes.
Steps to reproduce:
1. Start cluster with two nodes: server and client.
2. Create collocated {{IgniteSet}} on client node.
3. Close {{IgniteSet}} on client node.
4. Invoke {{add()}} method on closed IgniteSet.
Expected: {{add()}} throws {{IllegalStateException}}.
Actual: {{add()}} does not throws exception and puts new "orphan" element in
datastructure cache.
Alternatively to client node we can exclude server node by using cache node
filter, as shown in attached junit reproducer.
This bug relates to
[IGNITE-6346|https://issues.apache.org/jira/browse/IGNITE-6346], which also
affects usage of IgniteSet in cluster with non-affinity nodes.
> Collocated IgniteSet#close is not working on non-affinity node.
> ---
>
> Key: IGNITE-9442
> URL: https://issues.apache.org/jira/browse/IGNITE-9442
> Project: Ignite
> Issue Type: Bug
> Components: data structures
>Affects Versions: 2.6
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
>Priority: Major
> Attachments: Reproducer.java
>
>
> Method {{close()}} in collocated {{IgniteSet}} works incorrectly if cluster
> includes non-affinity nodes.
> Steps to reproduce:
> 1. Start cluster with two nodes: server and client.
> 2. Create collocated {{IgniteSet}} on client node.
> 3. Close {{IgniteSet}} on client node.
> 4. Invoke {{add()}} method on closed IgniteSet.
> Expected: {{add()}} throws {{IllegalStateException}}.
> Actual: {{add()}} does not throw exception and put new "orphan" item in the
> datastructure cache.
> Alternatively to client node we can exclude server node by using cache node
> filter, as shown in attached junit reproducer.
> This bug relates to
> [IGNITE-6346|https://issues.apache.org/jira/browse/IGNITE-6346], which also
> affects usage of IgniteSet in cluster with non-affinity nodes.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9442) Collocated IgniteSet#close is not working on non-affinity node.
[
https://issues.apache.org/jira/browse/IGNITE-9442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-9442:
-
Attachment: Reproducer.java
> Collocated IgniteSet#close is not working on non-affinity node.
> ---
>
> Key: IGNITE-9442
> URL: https://issues.apache.org/jira/browse/IGNITE-9442
> Project: Ignite
> Issue Type: Bug
> Components: data structures
>Affects Versions: 2.6
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
>Priority: Major
> Attachments: Reproducer.java
>
>
> Method {{close()}} in collocated {{IgniteSet}} works incorrectly if cluster
> includes non-affinity nodes.
> Steps to reproduce:
> 1. Start cluster with two nodes: server and client.
> 2. Create collocated {{IgniteSet}} on client node.
> 3. Close {{IgniteSet}} on client node.
> 4. Invoke {{add()}} method on closed IgniteSet.
> Expected: {{add()}} throws {{IllegalStateException}}.
> Actual: {{add()}} does not throws exception and puts new "orphan" element in
> datastructure cache.
> Alternatively to client node we can exclude server node by using cache node
> filter, as shown in attached junit reproducer.
> This bug relates to
> [IGNITE-6346|https://issues.apache.org/jira/browse/IGNITE-6346], which also
> affects usage of IgniteSet in cluster with non-affinity nodes.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9442) Collocated IgniteSet#close is not working on non-affinity node.
[
https://issues.apache.org/jira/browse/IGNITE-9442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-9442:
-
Description:
Method {{close()}} in collocated {{IgniteSet}} works incorrectly if cluster
includes non-affinity nodes.
Steps to reproduce:
1. Start cluster with two nodes: server and client.
2. Create collocated {{IgniteSet}} on client node.
3. Close {{IgniteSet}} on client node.
4. Invoke {{add()}} method on closed IgniteSet.
Expected: {{add()}} throws {{IllegalStateException}}.
Actual: {{add()}} does not throws exception and puts new "orphan" element in
datastructure cache.
Alternatively to client node we can exclude server node by using cache node
filter, as shown in attached junit reproducer.
This bug relates to
[IGNITE-6346|https://issues.apache.org/jira/browse/IGNITE-6346], which also
affects usage of IgniteSet in cluster with non-affinity nodes.
was:
Method {{close()}} in collocated {{IgniteSet}} works incorrectly if cluster
includes non-affinity nodes.
Steps to reproduce:
1. Start cluster with two nodes: server and client.
2. Create {{IgniteSet}} on client node.
3. Close {{IgniteSet}} on client node.
4. Invoke {{add()}} method on closed IgniteSet.
Expected: {{add()}} throws {{IllegalStateException}}.
Actual: {{add()}} does not throws exception and puts new "orphan" element in
datastructure cache.
Alternatively to client node we can exclude server node by using cache node
filter, as shown in attached junit reproducer.
This bug relates to
[IGNITE-6346|https://issues.apache.org/jira/browse/IGNITE-6346], which also
affects usage of IgniteSet in cluster with non-affinity nodes.
> Collocated IgniteSet#close is not working on non-affinity node.
> ---
>
> Key: IGNITE-9442
> URL: https://issues.apache.org/jira/browse/IGNITE-9442
> Project: Ignite
> Issue Type: Bug
> Components: data structures
>Affects Versions: 2.6
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
>Priority: Major
>
> Method {{close()}} in collocated {{IgniteSet}} works incorrectly if cluster
> includes non-affinity nodes.
> Steps to reproduce:
> 1. Start cluster with two nodes: server and client.
> 2. Create collocated {{IgniteSet}} on client node.
> 3. Close {{IgniteSet}} on client node.
> 4. Invoke {{add()}} method on closed IgniteSet.
> Expected: {{add()}} throws {{IllegalStateException}}.
> Actual: {{add()}} does not throws exception and puts new "orphan" element in
> datastructure cache.
> Alternatively to client node we can exclude server node by using cache node
> filter, as shown in attached junit reproducer.
> This bug relates to
> [IGNITE-6346|https://issues.apache.org/jira/browse/IGNITE-6346], which also
> affects usage of IgniteSet in cluster with non-affinity nodes.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9442) Collocated IgniteSet#close is not working on non-affinity node.
[
https://issues.apache.org/jira/browse/IGNITE-9442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-9442:
-
Description:
Method {{close()}} in collocated {{IgniteSet}} works incorrectly if cluster
includes non-affinity nodes.
Steps to reproduce:
1. Start cluster with two nodes: server and client.
2. Create {{IgniteSet}} on client node.
3. Close {{IgniteSet}} on client node.
4. Invoke {{add()}} method on closed IgniteSet.
Expected: {{add()}} throws {{IllegalStateException}}.
Actual: {{add()}} does not throws exception and puts new "orphan" element in
datastructure cache.
Alternatively to client node we can exclude server node by using cache node
filter, as shown in attached junit reproducer.
This bug relates to
[IGNITE-6346|https://issues.apache.org/jira/browse/IGNITE-6346], which also
affects usage of IgniteSet in cluster with non-affinity nodes.
was:
Simple reproducer:
{code:java}
public void testSetBlockOnCloseFromNonAffinityNode() throws Exception {
Ignite node = startGridsMultiThreaded(2);
ClusterNode locNode = node.cluster().localNode();
IgniteSet set = node.set("test",
new CollectionConfiguration().setCollocated(true).setNodeFilter(n
-> !locNode.equals(n)));
set.close();
GridTestUtils.assertThrows(log, new Callable() {
@Override public Void call() throws Exception {
set.add(1);
return null;
}
}, IllegalStateException.class, null);
}
{code}
IgniteSet should be blocked on all nodes before cleanup data.
> Collocated IgniteSet#close is not working on non-affinity node.
> ---
>
> Key: IGNITE-9442
> URL: https://issues.apache.org/jira/browse/IGNITE-9442
> Project: Ignite
> Issue Type: Bug
> Components: data structures
>Affects Versions: 2.6
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
>Priority: Major
>
> Method {{close()}} in collocated {{IgniteSet}} works incorrectly if cluster
> includes non-affinity nodes.
> Steps to reproduce:
> 1. Start cluster with two nodes: server and client.
> 2. Create {{IgniteSet}} on client node.
> 3. Close {{IgniteSet}} on client node.
> 4. Invoke {{add()}} method on closed IgniteSet.
> Expected: {{add()}} throws {{IllegalStateException}}.
> Actual: {{add()}} does not throws exception and puts new "orphan" element in
> datastructure cache.
> Alternatively to client node we can exclude server node by using cache node
> filter, as shown in attached junit reproducer.
> This bug relates to
> [IGNITE-6346|https://issues.apache.org/jira/browse/IGNITE-6346], which also
> affects usage of IgniteSet in cluster with non-affinity nodes.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-9555) Web Console can stop due to an unexpected message via web sockets
[
https://issues.apache.org/jira/browse/IGNITE-9555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Kuznetsov reassigned IGNITE-9555:
Assignee: Alexey Kuznetsov
> Web Console can stop due to an unexpected message via web sockets
> -
>
> Key: IGNITE-9555
> URL: https://issues.apache.org/jira/browse/IGNITE-9555
> Project: Ignite
> Issue Type: Bug
> Components: wizards
>Reporter: Roman Guseinov
>Assignee: Alexey Kuznetsov
>Priority: Major
> Attachments: webconsole.log
>
>
> Web Console shows error only if debug messages are enabled `DEBUG=mongodb-*
> ./gridgain-web-console-linux`. Otherwise, it just stops.
> Here is the error message:
> {code:java}
> /snapshot/backend/node_modules/ignite-web-console/app/browsersHandler.js:211
> return cb('Invalid format of message: "node:rest"');
> ^
> TypeError: cb is not a function
> at Socket.module.exports.factory.nodeListeners.sock.on
> (/snapshot/backend/node_modules/ignite-web-console/app/browsersHandler.js:211:32)
> at emitThree (events.js:136:13)
> at Socket.emit (events.js:217:7)
> at
> /snapshot/backend/node_modules/ignite-web-console/node_modules/socket.io/lib/socket.js:503:12
> at _combinedTickCallback (internal/process/next_tick.js:131:7)
> at process._tickCallback (internal/process/next_tick.js:180:9)
> {code}
> The full log is attached: [^webconsole.log].
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9555) Web Console can stop due to an unexpected message via web sockets
[
https://issues.apache.org/jira/browse/IGNITE-9555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Kuznetsov updated IGNITE-9555:
-
Fix Version/s: 2.7
> Web Console can stop due to an unexpected message via web sockets
> -
>
> Key: IGNITE-9555
> URL: https://issues.apache.org/jira/browse/IGNITE-9555
> Project: Ignite
> Issue Type: Bug
> Components: wizards
>Reporter: Roman Guseinov
>Assignee: Alexey Kuznetsov
>Priority: Major
> Fix For: 2.7
>
> Attachments: webconsole.log
>
>
> Web Console shows error only if debug messages are enabled `DEBUG=mongodb-*
> ./gridgain-web-console-linux`. Otherwise, it just stops.
> Here is the error message:
> {code:java}
> /snapshot/backend/node_modules/ignite-web-console/app/browsersHandler.js:211
> return cb('Invalid format of message: "node:rest"');
> ^
> TypeError: cb is not a function
> at Socket.module.exports.factory.nodeListeners.sock.on
> (/snapshot/backend/node_modules/ignite-web-console/app/browsersHandler.js:211:32)
> at emitThree (events.js:136:13)
> at Socket.emit (events.js:217:7)
> at
> /snapshot/backend/node_modules/ignite-web-console/node_modules/socket.io/lib/socket.js:503:12
> at _combinedTickCallback (internal/process/next_tick.js:131:7)
> at process._tickCallback (internal/process/next_tick.js:180:9)
> {code}
> The full log is attached: [^webconsole.log].
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9573) ZookeeperDiscoverySpiSaslFailedAuthTest fails after added to suite
[ https://issues.apache.org/jira/browse/IGNITE-9573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16614531#comment-16614531 ] ASF GitHub Bot commented on IGNITE-9573: GitHub user alamar opened a pull request: https://github.com/apache/ignite/pull/4755 IGNITE-9573 Fix ZooKeeper SASL authentication tests. You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-9573 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4755.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 #4755 commit bd146cb9bb0459021a3f46fb3f1f5961118c32e8 Author: Ilya Kasnacheev Date: 2018-09-13T12:16:26Z IGNITE-9573 Fix ZooKeeper SASL authentication tests. > ZookeeperDiscoverySpiSaslFailedAuthTest fails after added to suite > -- > > Key: IGNITE-9573 > URL: https://issues.apache.org/jira/browse/IGNITE-9573 > Project: Ignite > Issue Type: Bug >Reporter: Ilya Kasnacheev >Assignee: Ilya Kasnacheev >Priority: Minor > > Due to proliferation of static fields in Zk and Security code it fails when a > part of suite and/or will cause other tests to fail. Needs to be fixed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9592) MVCC: Use linked lists to store multiple versions.
[
https://issues.apache.org/jira/browse/IGNITE-9592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roman Kondakov updated IGNITE-9592:
---
Description:
Currently we store all versions of each row in primary index. It is not very
efficient for several reasons:
* We have to insert and remove tree item each time a new version is created or
an old version deleted. This leads to a considerable tree operations number
increasing as well as extra tree splits and merges operations.
* Also this leads to a contention on leaf page write lock - each update
operation has to obtain exclusive access to insert a new version or remove old
version of row. During this update no body on that leaf can not be able to
update or even read data of neighbour keys.
* Primary key tree consumes more space if it stores each version.
* Other vendors do not store each version in primary indexes (as far as I
know).
Possible solution - store only key and link to the newest version in the
primary index. Instead of this {{CacheDataTree}} item
{{| key part | | |}}
{{|-| lockVer | link |}}
{{| cache_id | hash | mvccVer | | |}}
we'll have:
{{| key part | | link to the |}}
{{|-| lockVer | newest |}}
{{| cache_id | hash | |version |}}
Note, we do not have mvccVer in tree item. Link to the newer version leads to
the most recent inserted data item. To find older versions, each DatRow is
provided with "prevLink" - the link to previous version of row. DataRow layout
can be changed from
|header|xid_max|xid_min |KV bytes|
to the next one:
|header|xid_max|xid_min|*PREV_LINK*|KV bytes|
Where *PREV_LINK* field points to the previous version of the row. Doing
traverse overt this prevRow links we can iterate over all available versions
without using and affecting the primary key tree.
When the new version is created we just insert the new row in datastore, then
do CAS on the link to the newest version in primary key tree in order it points
to the new row. PrevLink in the new row should point on the previous one. That
is all. We've just inserted a new version just with a long field CAS in the
CacheDataTree. Without obtaining write lock and other headache.
Secondary indexes are handled in the same manner as before.
was:
Currently we store all versions of each row in primary index. It is not very
efficient for several reasons:
* We have to insert and remove tree item each time a new version is created or
an old version deleted. This leads to a considerable tree operations number
increasing as well as extra tree splits and merges operations.
* Also this leads to a contention on leaf page write lock - each update
operation has to obtain exclusive access to insert a new version or remove old
version of row. During this update no body on that leaf can not be able to
update or even read data of neighbour keys.
* Primary key tree consumes more space if it stores each version.
* Other vendors do not store each version in primary indexes (as far as I
know).
Possible solution - store only key and link to the newest version in the
primary index. Instead of this {{CacheDataTree}} item
{{| key part | | |}}
{{|-| lockVer | link |}}
{{| cache_id | hash | mvccVer | | |}}
we'll have:
{{| key part | | link to the |}}
{{|-| lockVer | newest |}}
{{| cache_id | hash | |version |}}
Note, we do not have mvccVer in tree item. Link to the newer version leads to
the most recent inserted data item. To find older versions, each DatRow is
provided with "prevLink" - the link to previous version of row. DataRow layout
can be changed from
|header|xid_max|xid_min |KV bytes|
to the next one:
|header|xid_max|xid_min|*PREV_LINK*|KV bytes|
Where *PREV_LINK* field points to the previous version of the row. Traversing
this prevRow links we can iterate over all available versions without affecting
primary key tree.
When the new version is created we just insert the new row in datastore, then
do CAS on the link to the newest version in primary key tree in order it points
to the new row. PrevLink in the new row should point on the previous one. That
is all. We've just inserted a new version just with a long field CAS in the
CacheDataTree. Without obtaining write lock and other headache.
Secondary indexes are handled in the same manner as before.
> MVCC: Use linked lists to store multiple versions.
> --
>
> Key: IGNITE-9592
> URL: https://issues.apache.org/jira/browse/IGNITE-9592
> Project: Ignite
> Issue Type: Improvement
> Components: mvcc
>
[jira] [Updated] (IGNITE-9592) MVCC: Use linked lists to store multiple versions.
[
https://issues.apache.org/jira/browse/IGNITE-9592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roman Kondakov updated IGNITE-9592:
---
Description:
Currently we store all versions of each row in primary index. It is not very
efficient for several reasons:
* We have to insert and remove tree item each time a new version is created or
an old version deleted. This leads to a considerable tree operations number
increasing as well as extra tree splits and merges operations.
* Also this leads to a contention on leaf page write lock - each update
operation has to obtain exclusive access to insert a new version or remove old
version of row. During this update no body on that leaf can not be able to
update or even read data of neighbour keys.
* Primary key tree consumes more space if it stores each version.
* Other vendors do not store each version in primary indexes (as far as I
know).
Possible solution - store only key and link to the newest version in the
primary index. Instead of this {{CacheDataTree}} item
{{| key part | | |}}
{{|-| lockVer | link |}}
{{| cache_id | hash | mvccVer | | |}}
we'll have:
{{| key part | | link to the |}}
{{|-| lockVer | newest |}}
{{| cache_id | hash | |version |}}
Note, we do not have mvccVer in tree item. Link to the newer version leads to
the most recent inserted data item. To find older versions, each DatRow is
provided with "prevLink" - the link to previous version of row. DataRow layout
can be changed from
|header|xid_max|xid_min |KV bytes|
to the next one:
|header|xid_max|xid_min|*PREV_LINK*|KV bytes|
Where *PREV_LINK* field points to the previous version of the row. Traversing
this prevRow links we can iterate over all available versions without affecting
primary key tree.
When the new version is created we just insert the new row in datastore, then
do CAS on the link to the newest version in primary key tree in order it points
to the new row. PrevLink in the new row should point on the previous one. That
is all. We've just inserted a new version just with a long field CAS in the
CacheDataTree. Without obtaining write lock and other headache.
Secondary indexes are handled in the same manner as before.
was:
Currently we store all versions of each row in primary index. It is not very
efficient for several reasons:
* We have to insert and remove tree item each time a new version is created or
an old version deleted. This leads to a considerable tree operations number
increasing as well as tree splits and merges operations.
* Also this leads to a contention on leaf page write lock - each update
operation has to obtain exclusive access to insert a new version of row. During
this update no body on that leaf can not be able to update or even read data of
neighbour keys.
* Primary key tree consumes more space if it stores each version.
* Other vendors do not store each version in primary indexes (as far as I
know).
Possible solution - store only key and link to the newest version in the
primary index. Instead of this {{CacheDataTree}} item
{{| key part | | |}}
{{|-| lockVer | link |}}
{{| cache_id | hash | mvccVer | | |}}
we'll have:
{{| key part | | link to the |}}
{{|-| lockVer | newest |}}
{{| cache_id | hash | |version |}}
Note, we do not have mvccVer in tree item. Link to the newer version leads to
the most recent inserted data item. To find older versions, each DatRow is
provided with "prevLink" - the link to previous version of row. DataRow layout
can be changed from
| header | xid_max | xid_min | KV bytes |
to the next one:
| header | xid_max | xid_min | *PREV_LINK* | KV bytes |
Where *PREV_LINK* field points to the previous version of the row. Traversing
this prevRow links we can iterate over all available versions without affecting
primary key tree.
When the new version is created we just insert the new row in datastore, then
do CAS on the link to the newest version in primary key tree in order it points
to the new row. PrevLink in the new row should point on the previous one. That
is all. We've just inserted a new version just with a long field CAS in the
CacheDataTree. Without obtaining write lock and other headache.
Secondary indexes are handled in the same manner as before.
> MVCC: Use linked lists to store multiple versions.
> --
>
> Key: IGNITE-9592
> URL: https://issues.apache.org/jira/browse/IGNITE-9592
> Project: Ignite
> Issue Type: Improvement
> Components: mvcc
>Reporter: Roman Kondakov
>
[jira] [Assigned] (IGNITE-9598) Error in console if user goes away from queries
[
https://issues.apache.org/jira/browse/IGNITE-9598?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Kalinin reassigned IGNITE-9598:
-
Assignee: Alexey Kuznetsov (was: Alexander Kalinin)
Fixed error. Please review.
> Error in console if user goes away from queries
> ---
>
> Key: IGNITE-9598
> URL: https://issues.apache.org/jira/browse/IGNITE-9598
> Project: Ignite
> Issue Type: Bug
> Components: wizards
>Reporter: Alexander Kalinin
>Assignee: Alexey Kuznetsov
>Priority: Major
>
> If startWatch cluster function operates too long and user goes aways from
> queries the following error is raised in console:
> {code:java}
> Cannot read property 'unsubscribe' of undefined
> at NotebookCtrl.$onDestroy (controller.js:1972)
> at callOnDestroyHook (angular.js:10068)
> at Scope.$broadcast (angular.js:19165)
> at Scope.$destroy (angular.js:18779)
> at cleanupLastView (ui-router-angularjs.js:1799)
> at ui-router-angularjs.js:1849
> at publicLinkFn (angular.js:9234)
> at lazyCompilation (angular.js:9626)
> at updateView (ui-router-angularjs.js:1838)
> at Object.configUpdatedCallback [as configUpdated]
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-9598) Error in console if user goes away from queries
Alexander Kalinin created IGNITE-9598:
-
Summary: Error in console if user goes away from queries
Key: IGNITE-9598
URL: https://issues.apache.org/jira/browse/IGNITE-9598
Project: Ignite
Issue Type: Bug
Components: wizards
Reporter: Alexander Kalinin
Assignee: Alexander Kalinin
If startWatch cluster function operates too long and user goes aways from
queries the following error is raised in console:
{code:java}
Cannot read property 'unsubscribe' of undefined
at NotebookCtrl.$onDestroy (controller.js:1972)
at callOnDestroyHook (angular.js:10068)
at Scope.$broadcast (angular.js:19165)
at Scope.$destroy (angular.js:18779)
at cleanupLastView (ui-router-angularjs.js:1799)
at ui-router-angularjs.js:1849
at publicLinkFn (angular.js:9234)
at lazyCompilation (angular.js:9626)
at updateView (ui-router-angularjs.js:1838)
at Object.configUpdatedCallback [as configUpdated]
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8770) OutOfMemory in Queries1 suite in master branch on TC
[ https://issues.apache.org/jira/browse/IGNITE-8770?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16614517#comment-16614517 ] Alexey Platonov commented on IGNITE-8770: - try to reproduce OOM with 20 runs of tests [https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_Queries]1&branch_IgniteTests24Java8=pull%2F4750%2Fhead&tab=buildTypeStatusDiv > OutOfMemory in Queries1 suite in master branch on TC > > > Key: IGNITE-8770 > URL: https://issues.apache.org/jira/browse/IGNITE-8770 > Project: Ignite > Issue Type: Bug >Reporter: Sergey Chugunov >Assignee: Alexey Platonov >Priority: Blocker > Labels: MakeTeamcityGreenAgain > Fix For: 2.8 > > > OutOfMemory happened for the first time in a while for this suite: [TC > link|https://ci.ignite.apache.org/viewLog.html?buildId=1372426&tab=buildResultsDiv&buildTypeId=IgniteTests24Java8_Queries1] > No execution timeouts or OOM errors in recent history: [TC > link|https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_Queries1&branch_IgniteTests24Java8=%3Cdefault%3E&tab=buildTypeStatusDiv] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9511) Update styling for modal windows
[ https://issues.apache.org/jira/browse/IGNITE-9511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16614514#comment-16614514 ] Alexander Kalinin commented on IGNITE-9511: --- [~pkonstantinov] Please test correct height of confirm modals, explain and show queries modals, and "execute on selected node" modal in queries. > Update styling for modal windows > > > Key: IGNITE-9511 > URL: https://issues.apache.org/jira/browse/IGNITE-9511 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Alexander Kalinin >Assignee: Alexander Kalinin >Priority: Major > > Currently we have two way of styles - modern (confirmation, etc) and old > styled (getting started, messages ect). > The modals have to be consistent. Let's update them with new style. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-9511) Update styling for modal windows
[ https://issues.apache.org/jira/browse/IGNITE-9511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Kalinin reassigned IGNITE-9511: - Assignee: Pavel Konstantinov (was: Alexander Kalinin) > Update styling for modal windows > > > Key: IGNITE-9511 > URL: https://issues.apache.org/jira/browse/IGNITE-9511 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Alexander Kalinin >Assignee: Pavel Konstantinov >Priority: Major > > Currently we have two way of styles - modern (confirmation, etc) and old > styled (getting started, messages ect). > The modals have to be consistent. Let's update them with new style. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9580) Fix exit code 137 in Query 1 Suite
[ https://issues.apache.org/jira/browse/IGNITE-9580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16614509#comment-16614509 ] Alexey Platonov commented on IGNITE-9580: - [~dpavlov], is this description valid? > Fix exit code 137 in Query 1 Suite > -- > > Key: IGNITE-9580 > URL: https://issues.apache.org/jira/browse/IGNITE-9580 > Project: Ignite > Issue Type: Bug >Reporter: Alexey Platonov >Assignee: Alexey Platonov >Priority: Major > Labels: MakeTeamcityGreenAgain > > Sometimes "Queries 1" fails with 137 exit code without stacktraces. > Potentially it's due to OOM-Killer activity and some test suite without > configuration of maxSize-parameter in data region config. > > Examples of failure > > [https://ci.ignite.apache.org/viewLog.html?buildId=1797966&tab=buildResultsDiv&buildTypeId=IgniteTests24Java8_Queries1] > [https://ci.ignite.apache.org/viewLog.html?buildId=1838170&tab=buildResultsDiv&buildTypeId=IgniteTests24Java8_Queries1] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9580) Fix exit code 137 in Query 1 Suite
[ https://issues.apache.org/jira/browse/IGNITE-9580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16614507#comment-16614507 ] Alexey Platonov commented on IGNITE-9580: - I've found more examples with such behavior: [https://ci.ignite.apache.org/viewLog.html?buildId=1782941&buildTypeId=IgniteTests24Java8_Queries1&tab=buildResultsDiv] [https://ci.ignite.apache.org/viewLog.html?buildId=1774499&buildTypeId=IgniteTests24Java8_Queries1&tab=buildResultsDiv] In all of these cases CacheQueryEvictDataLostTest was falling. Indeed, CacheQueryEvictDataLostTest is using own cache configuration without setting data region parameters unlike other tests. > Fix exit code 137 in Query 1 Suite > -- > > Key: IGNITE-9580 > URL: https://issues.apache.org/jira/browse/IGNITE-9580 > Project: Ignite > Issue Type: Bug >Reporter: Alexey Platonov >Assignee: Alexey Platonov >Priority: Major > Labels: MakeTeamcityGreenAgain > > Sometimes "Queries 1" fails with 137 exit code without stacktraces. > Potentially it's due to OOM-Killer activity and some test suite without > configuration of maxSize-parameter in data region config. > > Examples of failure > > [https://ci.ignite.apache.org/viewLog.html?buildId=1797966&tab=buildResultsDiv&buildTypeId=IgniteTests24Java8_Queries1] > [https://ci.ignite.apache.org/viewLog.html?buildId=1838170&tab=buildResultsDiv&buildTypeId=IgniteTests24Java8_Queries1] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9580) Fix exit code 137 in Query 1 Suite
[ https://issues.apache.org/jira/browse/IGNITE-9580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Platonov updated IGNITE-9580: Description: Sometimes "Queries 1" fails with 137 exit code without stacktraces. Potentially it's due to OOM-Killer activity and some test suite without configuration of maxSize-parameter in data region config. Examples of failure [https://ci.ignite.apache.org/viewLog.html?buildId=1797966&tab=buildResultsDiv&buildTypeId=IgniteTests24Java8_Queries1] [https://ci.ignite.apache.org/viewLog.html?buildId=1838170&tab=buildResultsDiv&buildTypeId=IgniteTests24Java8_Queries1] was: Sometimes "Queries 1" fails with 137 exit code without stacktraces. Potentially it's due to OOM-Killer activity and some test suite without Examples of failure [https://ci.ignite.apache.org/viewLog.html?buildId=1797966&tab=buildResultsDiv&buildTypeId=IgniteTests24Java8_Queries1] https://ci.ignite.apache.org/viewLog.html?buildId=1838170&tab=buildResultsDiv&buildTypeId=IgniteTests24Java8_Queries1 > Fix exit code 137 in Query 1 Suite > -- > > Key: IGNITE-9580 > URL: https://issues.apache.org/jira/browse/IGNITE-9580 > Project: Ignite > Issue Type: Bug >Reporter: Alexey Platonov >Assignee: Alexey Platonov >Priority: Major > Labels: MakeTeamcityGreenAgain > > Sometimes "Queries 1" fails with 137 exit code without stacktraces. > Potentially it's due to OOM-Killer activity and some test suite without > configuration of maxSize-parameter in data region config. > > Examples of failure > > [https://ci.ignite.apache.org/viewLog.html?buildId=1797966&tab=buildResultsDiv&buildTypeId=IgniteTests24Java8_Queries1] > [https://ci.ignite.apache.org/viewLog.html?buildId=1838170&tab=buildResultsDiv&buildTypeId=IgniteTests24Java8_Queries1] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9580) Fix exit code 137 in Query 1 Suite
[ https://issues.apache.org/jira/browse/IGNITE-9580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Platonov updated IGNITE-9580: Description: Sometimes "Queries 1" fails with 137 exit code without stacktraces. Potentially it's due to OOM-Killer activity and some test suite without Examples of failure [https://ci.ignite.apache.org/viewLog.html?buildId=1797966&tab=buildResultsDiv&buildTypeId=IgniteTests24Java8_Queries1] https://ci.ignite.apache.org/viewLog.html?buildId=1838170&tab=buildResultsDiv&buildTypeId=IgniteTests24Java8_Queries1 was: Example of failure https://ci.ignite.apache.org/viewLog.html?buildId=1797966&tab=buildResultsDiv&buildTypeId=IgniteTests24Java8_Queries1 > Fix exit code 137 in Query 1 Suite > -- > > Key: IGNITE-9580 > URL: https://issues.apache.org/jira/browse/IGNITE-9580 > Project: Ignite > Issue Type: Bug >Reporter: Alexey Platonov >Assignee: Alexey Platonov >Priority: Major > Labels: MakeTeamcityGreenAgain > > Sometimes "Queries 1" fails with 137 exit code without stacktraces. > Potentially it's due to OOM-Killer activity and some test suite without > > Examples of failure > > [https://ci.ignite.apache.org/viewLog.html?buildId=1797966&tab=buildResultsDiv&buildTypeId=IgniteTests24Java8_Queries1] > https://ci.ignite.apache.org/viewLog.html?buildId=1838170&tab=buildResultsDiv&buildTypeId=IgniteTests24Java8_Queries1 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-9550) Get operation returns null for a lost partition with READ_SAFE policy
[ https://issues.apache.org/jira/browse/IGNITE-9550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Bessonov reassigned IGNITE-9550: - Assignee: Ivan Bessonov (was: Pavel Vinokurov) > Get operation returns null for a lost partition with READ_SAFE policy > - > > Key: IGNITE-9550 > URL: https://issues.apache.org/jira/browse/IGNITE-9550 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.6 >Reporter: Pavel Vinokurov >Assignee: Ivan Bessonov >Priority: Major > Attachments: PartitionLostReproducer.java > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9593) Spark Optimization fails to optimize statements
[
https://issues.apache.org/jira/browse/IGNITE-9593?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Goncharuk updated IGNITE-9593:
-
Summary: Spark Optimization fails to optimize statements (was: Spart
Optimization fails to optimize statements)
> Spark Optimization fails to optimize statements
> ---
>
> Key: IGNITE-9593
> URL: https://issues.apache.org/jira/browse/IGNITE-9593
> Project: Ignite
> Issue Type: Bug
> Components: spark
>Affects Versions: 2.6
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Blocker
> Fix For: 2.7
>
> Attachments: Spark_optimization_bugs_reproducer.patch
>
>
> In some cases, {{IgniteOptimization}} fails to optimize spark query.
> Reproducer attached.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-6960) ContinuousQuery failed if set deploymentMode to Private
[ https://issues.apache.org/jira/browse/IGNITE-6960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-6960: Fix Version/s: (was: 2.7) 2.8 > ContinuousQuery failed if set deploymentMode to Private > --- > > Key: IGNITE-6960 > URL: https://issues.apache.org/jira/browse/IGNITE-6960 > Project: Ignite > Issue Type: Bug > Components: cache, general >Affects Versions: 2.3 >Reporter: Mikhail Cherkasov >Assignee: Maxim Muzafarov >Priority: Critical > Fix For: 2.8 > > > user list: > http://apache-ignite-users.70518.x6.nabble.com/Scan-query-failed-if-set-deploymentMode-to-Private-tt18244.html -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9597) 'size() == 0' replaceable with 'isEmpty()' according inspections profile
Maxim Muzafarov created IGNITE-9597:
---
Summary: 'size() == 0' replaceable with 'isEmpty()' according
inspections profile
Key: IGNITE-9597
URL: https://issues.apache.org/jira/browse/IGNITE-9597
Project: Ignite
Issue Type: Bug
Reporter: Maxim Muzafarov
Assignee: Maxim Muzafarov
New `Code Inspections` profile can be found
{{\idea\ignite_inspections.xml}}.
We need to fix rule `size() == 0' replaceable with 'isEmpty()` in
{{ignite-core}} module.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9311) Add missing @Override annotation
[
https://issues.apache.org/jira/browse/IGNITE-9311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated IGNITE-9311:
Labels: inspections (was: )
> Add missing @Override annotation
>
>
> Key: IGNITE-9311
> URL: https://issues.apache.org/jira/browse/IGNITE-9311
> Project: Ignite
> Issue Type: Bug
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Minor
> Labels: inspections
> Fix For: 2.7
>
>
> New `Code Inspections` profile can be found
> {{\idea\ignite_inspections.xml}}.
> We will need to fix all methods with missed {{@Override}} annotation
> regarding this inscpetion profile.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9312) Remove unnecessary @SuppressWarnings annotation
[
https://issues.apache.org/jira/browse/IGNITE-9312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated IGNITE-9312:
Labels: inspections (was: )
> Remove unnecessary @SuppressWarnings annotation
> ---
>
> Key: IGNITE-9312
> URL: https://issues.apache.org/jira/browse/IGNITE-9312
> Project: Ignite
> Issue Type: Bug
>Reporter: Maxim Muzafarov
>Assignee: PetrovMikhail
>Priority: Minor
> Labels: inspections
>
> New `Code Inspections` profile can be found
> \idea\ignite_inspections.xml.
> We will need to fix all methods with unnecessary {{@SuppressWarnings}}
> annotation regarding this inscpetion profile.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
