[jira] [Assigned] (IGNITE-8911) While cache is restarting it's possible to start new cache with this name
[ https://issues.apache.org/jira/browse/IGNITE-8911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eduard Shangareev reassigned IGNITE-8911: - Assignee: Eduard Shangareev > While cache is restarting it's possible to start new cache with this name > - > > Key: IGNITE-8911 > URL: https://issues.apache.org/jira/browse/IGNITE-8911 > Project: Ignite > Issue Type: Bug >Reporter: Eduard Shangareev >Assignee: Eduard Shangareev >Priority: Major > > We have the state "restarting" for caches when we certainly now that these > caches would start at some moment in future. But we could start new cache > with the same name. > Plus, NPE is throwing when we try to get proxy for such caches (in > "restarting" state). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8911) While cache is restarting it's possible to start new cache with this name
Eduard Shangareev created IGNITE-8911: - Summary: While cache is restarting it's possible to start new cache with this name Key: IGNITE-8911 URL: https://issues.apache.org/jira/browse/IGNITE-8911 Project: Ignite Issue Type: Bug Reporter: Eduard Shangareev We have the state "restarting" for caches when we certainly now that these caches would start at some moment in future. But we could start new cache with the same name. Plus, NPE is throwing when we try to get proxy for such caches (in "restarting" state). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8908) NPE on discovery message processing
[ https://issues.apache.org/jira/browse/IGNITE-8908?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Gerus updated IGNITE-8908: Priority: Critical (was: Major) > NPE on discovery message processing > --- > > Key: IGNITE-8908 > URL: https://issues.apache.org/jira/browse/IGNITE-8908 > Project: Ignite > Issue Type: Bug > Components: general >Reporter: Mikhail Cherkasov >Priority: Critical > Attachments: ContinuousQueryTask.txt, RegisterTask.txt, > ServiceTask.txt > > > To reproduce the problem we do the the following steps: > 1) start 4 server nodes > 2) start client nodes: ServiceTask, RegisterTask, ContinuousQueryTask > 3) restart 3 of 4 server nodes. > The following exception is observed in logs: > [2018-07-02 10:15:48,199][ERROR]tcp-disco-msg-worker-#2 Failed to notify > direct custom event listener: MetadataUpdateAcceptedMessage > [id=cae4cd95461-6f8d75e0-424e-4a8f-8f20-c34a9d55e44f, typeId=-372239526, > acceptedVer=1, duplicated=false] > java.lang.NullPointerException: null > at > org.apache.ignite.internal.processors.cache.binary.BinaryMetadataTransport$MetadataUpdateAcceptedListener.onCustomEvent(BinaryMetadataTransport.java:451) > ~[ignite-core-2.x.x.jar:2.x.x] > at > org.apache.ignite.internal.processors.cache.binary.BinaryMetadataTransport$MetadataUpdateAcceptedListener.onCustomEvent(BinaryMetadataTransport.java:418) > ~[ignite-core-2.x.x.jar:2.x.x] > at > org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery0(GridDiscoveryManager.java:695) > [ignite-core-2.x.x.jar:2.x.x] > at > org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery(GridDiscoveryManager.java:577) > [ignite-core-2.x.x.jar:2.x.x] > at > org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.notifyDiscoveryListener(ServerImpl.java:5453) > [ignite-core-2.x.x.jar:2.x.x] > at > org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processCustomMessage(ServerImpl.java:5279) > [ignite-core-2.x.x.jar:2.x.x] > at > org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processCustomMessage(ServerImpl.java:5313) > [ignite-core-2.x.x.jar:2.x.x] > at > org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2739) > [ignite-core-2.x.x.jar:2.x.x] > at > org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2531) > [ignite-core-2.x.x.jar:2.x.x] > at > org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorkerAdapter.body(ServerImpl.java:6730) > [ignite-core-2.x.x.jar:2.x.x] > at > org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.body(ServerImpl.java:2614) > [ignite-core-2.x.x.jar:2.x.x] > at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62) > [ignite-core-2.x.x.jar:2.x.x] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7967) DataRegionMetrics#totalAllocatedPages is invalid if metrics were enabled at runtime
[
https://issues.apache.org/jira/browse/IGNITE-7967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16530129#comment-16530129
]
Dmitriy Sorokin commented on IGNITE-7967:
-
[~agoncharuk], done.
> DataRegionMetrics#totalAllocatedPages is invalid if metrics were enabled at
> runtime
> ---
>
> Key: IGNITE-7967
> URL: https://issues.apache.org/jira/browse/IGNITE-7967
> Project: Ignite
> Issue Type: Bug
> Components: persistence
>Affects Versions: 2.3
>Reporter: Alexey Goncharuk
>Assignee: Dmitriy Sorokin
>Priority: Major
> Labels: iep-6
> Fix For: 2.7
>
>
> {{totalAllocatedPages}} is updated during runtime via callback. When metrics
> are enabled at runtime, some pages may be already allocated, thus the metric
> shows invalid value.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-8910) PagesList.takeEmptyPage may fail with AssertionError: type = 1
[
https://issues.apache.org/jira/browse/IGNITE-8910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Rakov updated IGNITE-8910:
---
Priority: Critical (was: Major)
> PagesList.takeEmptyPage may fail with AssertionError: type = 1
> --
>
> Key: IGNITE-8910
> URL: https://issues.apache.org/jira/browse/IGNITE-8910
> Project: Ignite
> Issue Type: Bug
>Reporter: Ivan Rakov
>Assignee: Dmitriy Sorokin
>Priority: Critical
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.7
>
>
> Even after IGNITE-8769 fix, we sometimes get an AssertionError from free list
> during update operation. Page with type PageIO#T_DATA appears in free list
> for some reason.
> Example hang on TC:
> https://ci.ignite.apache.org/viewLog.html?buildId=1442664=IgniteTests24Java8_PdsIndexingWalRecovery
> Example stacktrace:
> {noformat}
> [15:59:26]W: [org.apache.ignite:ignite-indexing]
> java.lang.AssertionError: Assertion error on search row:
> org.apache.ignite.internal.processors.cache.tree.SearchRow@1e76dfc5
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.invoke(BPlusTree.java:1643)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.invoke(IgniteCacheOffheapManagerImpl.java:1272)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.invoke(GridCacheOffheapManager.java:1603)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.invoke(IgniteCacheOffheapManagerImpl.java:370)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.innerUpdate(GridCacheMapEntry.java:1755)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateSingle(GridDhtAtomicCache.java:2436)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.update(GridDhtAtomicCache.java:1898)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1740)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1630)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.sendSingleRequest(GridNearAtomicAbstractUpdateFuture.java:299)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.map(GridNearAtomicSingleUpdateFuture.java:483)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.mapOnTopology(GridNearAtomicSingleUpdateFuture.java:443)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.map(GridNearAtomicAbstractUpdateFuture.java:248)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.update0(GridDhtAtomicCache.java:1119)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.put0(GridDhtAtomicCache.java:609)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2428)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2405)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.put(IgniteCacheProxyImpl.java:1084)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.put(GatewayProtectedCacheProxy.java:812)
> [15:59:26]W:
[jira] [Updated] (IGNITE-8910) PagesList.takeEmptyPage may fail with AssertionError: type = 1
[
https://issues.apache.org/jira/browse/IGNITE-8910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Rakov updated IGNITE-8910:
---
Fix Version/s: 2.7
> PagesList.takeEmptyPage may fail with AssertionError: type = 1
> --
>
> Key: IGNITE-8910
> URL: https://issues.apache.org/jira/browse/IGNITE-8910
> Project: Ignite
> Issue Type: Bug
>Reporter: Ivan Rakov
>Assignee: Dmitriy Sorokin
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.7
>
>
> Even after IGNITE-8769 fix, we sometimes get an AssertionError from free list
> during update operation. Page with type PageIO#T_DATA appears in free list
> for some reason.
> Example hang on TC:
> https://ci.ignite.apache.org/viewLog.html?buildId=1442664=IgniteTests24Java8_PdsIndexingWalRecovery
> Example stacktrace:
> {noformat}
> [15:59:26]W: [org.apache.ignite:ignite-indexing]
> java.lang.AssertionError: Assertion error on search row:
> org.apache.ignite.internal.processors.cache.tree.SearchRow@1e76dfc5
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.invoke(BPlusTree.java:1643)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.invoke(IgniteCacheOffheapManagerImpl.java:1272)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.invoke(GridCacheOffheapManager.java:1603)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.invoke(IgniteCacheOffheapManagerImpl.java:370)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.innerUpdate(GridCacheMapEntry.java:1755)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateSingle(GridDhtAtomicCache.java:2436)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.update(GridDhtAtomicCache.java:1898)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1740)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1630)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.sendSingleRequest(GridNearAtomicAbstractUpdateFuture.java:299)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.map(GridNearAtomicSingleUpdateFuture.java:483)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.mapOnTopology(GridNearAtomicSingleUpdateFuture.java:443)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.map(GridNearAtomicAbstractUpdateFuture.java:248)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.update0(GridDhtAtomicCache.java:1119)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.put0(GridDhtAtomicCache.java:609)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2428)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2405)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.put(IgniteCacheProxyImpl.java:1084)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.put(GatewayProtectedCacheProxy.java:812)
> [15:59:26]W:
[jira] [Created] (IGNITE-8910) PagesList.takeEmptyPage may fail with AssertionError: type = 1
Ivan Rakov created IGNITE-8910:
--
Summary: PagesList.takeEmptyPage may fail with AssertionError:
type = 1
Key: IGNITE-8910
URL: https://issues.apache.org/jira/browse/IGNITE-8910
Project: Ignite
Issue Type: Bug
Reporter: Ivan Rakov
Assignee: Dmitriy Sorokin
Even after IGNITE-8769 fix, we sometimes get an AssertionError from free list
during update operation. Page with type PageIO#T_DATA appears in free list for
some reason.
Example hang on TC:
https://ci.ignite.apache.org/viewLog.html?buildId=1442664=IgniteTests24Java8_PdsIndexingWalRecovery
Example stacktrace:
{noformat}
[15:59:26]W: [org.apache.ignite:ignite-indexing]
java.lang.AssertionError: Assertion error on search row:
org.apache.ignite.internal.processors.cache.tree.SearchRow@1e76dfc5
[15:59:26]W: [org.apache.ignite:ignite-indexing]at
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.invoke(BPlusTree.java:1643)
[15:59:26]W: [org.apache.ignite:ignite-indexing]at
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.invoke(IgniteCacheOffheapManagerImpl.java:1272)
[15:59:26]W: [org.apache.ignite:ignite-indexing]at
org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.invoke(GridCacheOffheapManager.java:1603)
[15:59:26]W: [org.apache.ignite:ignite-indexing]at
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.invoke(IgniteCacheOffheapManagerImpl.java:370)
[15:59:26]W: [org.apache.ignite:ignite-indexing]at
org.apache.ignite.internal.processors.cache.GridCacheMapEntry.innerUpdate(GridCacheMapEntry.java:1755)
[15:59:26]W: [org.apache.ignite:ignite-indexing]at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateSingle(GridDhtAtomicCache.java:2436)
[15:59:26]W: [org.apache.ignite:ignite-indexing]at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.update(GridDhtAtomicCache.java:1898)
[15:59:26]W: [org.apache.ignite:ignite-indexing]at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1740)
[15:59:26]W: [org.apache.ignite:ignite-indexing]at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1630)
[15:59:26]W: [org.apache.ignite:ignite-indexing]at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.sendSingleRequest(GridNearAtomicAbstractUpdateFuture.java:299)
[15:59:26]W: [org.apache.ignite:ignite-indexing]at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.map(GridNearAtomicSingleUpdateFuture.java:483)
[15:59:26]W: [org.apache.ignite:ignite-indexing]at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.mapOnTopology(GridNearAtomicSingleUpdateFuture.java:443)
[15:59:26]W: [org.apache.ignite:ignite-indexing]at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.map(GridNearAtomicAbstractUpdateFuture.java:248)
[15:59:26]W: [org.apache.ignite:ignite-indexing]at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.update0(GridDhtAtomicCache.java:1119)
[15:59:26]W: [org.apache.ignite:ignite-indexing]at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.put0(GridDhtAtomicCache.java:609)
[15:59:26]W: [org.apache.ignite:ignite-indexing]at
org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2428)
[15:59:26]W: [org.apache.ignite:ignite-indexing]at
org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2405)
[15:59:26]W: [org.apache.ignite:ignite-indexing]at
org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.put(IgniteCacheProxyImpl.java:1084)
[15:59:26]W: [org.apache.ignite:ignite-indexing]at
org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.put(GatewayProtectedCacheProxy.java:812)
[15:59:26]W: [org.apache.ignite:ignite-indexing]at
org.apache.ignite.internal.processors.cache.persistence.db.wal.IgniteWalRecoveryTest$2.call(IgniteWalRecoveryTest.java:551)
[15:59:26]W: [org.apache.ignite:ignite-indexing]at
org.apache.ignite.internal.processors.cache.persistence.db.wal.IgniteWalRecoveryTest$2.call(IgniteWalRecoveryTest.java:546)
[15:59:26]W:
[jira] [Updated] (IGNITE-8910) PagesList.takeEmptyPage may fail with AssertionError: type = 1
[
https://issues.apache.org/jira/browse/IGNITE-8910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Rakov updated IGNITE-8910:
---
Labels: MakeTeamcityGreenAgain (was: )
> PagesList.takeEmptyPage may fail with AssertionError: type = 1
> --
>
> Key: IGNITE-8910
> URL: https://issues.apache.org/jira/browse/IGNITE-8910
> Project: Ignite
> Issue Type: Bug
>Reporter: Ivan Rakov
>Assignee: Dmitriy Sorokin
>Priority: Major
> Labels: MakeTeamcityGreenAgain
>
> Even after IGNITE-8769 fix, we sometimes get an AssertionError from free list
> during update operation. Page with type PageIO#T_DATA appears in free list
> for some reason.
> Example hang on TC:
> https://ci.ignite.apache.org/viewLog.html?buildId=1442664=IgniteTests24Java8_PdsIndexingWalRecovery
> Example stacktrace:
> {noformat}
> [15:59:26]W: [org.apache.ignite:ignite-indexing]
> java.lang.AssertionError: Assertion error on search row:
> org.apache.ignite.internal.processors.cache.tree.SearchRow@1e76dfc5
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.invoke(BPlusTree.java:1643)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.invoke(IgniteCacheOffheapManagerImpl.java:1272)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.invoke(GridCacheOffheapManager.java:1603)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.invoke(IgniteCacheOffheapManagerImpl.java:370)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.innerUpdate(GridCacheMapEntry.java:1755)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateSingle(GridDhtAtomicCache.java:2436)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.update(GridDhtAtomicCache.java:1898)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1740)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1630)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.sendSingleRequest(GridNearAtomicAbstractUpdateFuture.java:299)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.map(GridNearAtomicSingleUpdateFuture.java:483)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.mapOnTopology(GridNearAtomicSingleUpdateFuture.java:443)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.map(GridNearAtomicAbstractUpdateFuture.java:248)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.update0(GridDhtAtomicCache.java:1119)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.put0(GridDhtAtomicCache.java:609)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2428)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2405)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.put(IgniteCacheProxyImpl.java:1084)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.put(GatewayProtectedCacheProxy.java:812)
> [15:59:26]W:
[jira] [Commented] (IGNITE-8746) EVT_CACHE_REBALANCE_PART_DATA_LOST event received twice on the coordinator node
[ https://issues.apache.org/jira/browse/IGNITE-8746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16530094#comment-16530094 ] ASF GitHub Bot commented on IGNITE-8746: Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/4242 > EVT_CACHE_REBALANCE_PART_DATA_LOST event received twice on the coordinator > node > --- > > Key: IGNITE-8746 > URL: https://issues.apache.org/jira/browse/IGNITE-8746 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.4 >Reporter: Pavel Vinokurov >Assignee: Pavel Vinokurov >Priority: Major > Fix For: 2.7 > > Attachments: EvtDataLostTwiceOnCoordinatorReprocuder.java > > > After a node left the cluster the coordinator recieves the partition lost > event twice. > The reproducer is attached. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7967) DataRegionMetrics#totalAllocatedPages is invalid if metrics were enabled at runtime
[
https://issues.apache.org/jira/browse/IGNITE-7967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16530092#comment-16530092
]
Alexey Goncharuk commented on IGNITE-7967:
--
[~cyberdemon], can you please pull up master and re-run TC, I have merge
conflicts.
> DataRegionMetrics#totalAllocatedPages is invalid if metrics were enabled at
> runtime
> ---
>
> Key: IGNITE-7967
> URL: https://issues.apache.org/jira/browse/IGNITE-7967
> Project: Ignite
> Issue Type: Bug
> Components: persistence
>Affects Versions: 2.3
>Reporter: Alexey Goncharuk
>Assignee: Dmitriy Sorokin
>Priority: Major
> Labels: iep-6
> Fix For: 2.7
>
>
> {{totalAllocatedPages}} is updated during runtime via callback. When metrics
> are enabled at runtime, some pages may be already allocated, thus the metric
> shows invalid value.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8821) Huge logs on BPlusTreeSelfTest put/remove family tests
[ https://issues.apache.org/jira/browse/IGNITE-8821?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16530049#comment-16530049 ] ASF GitHub Bot commented on IGNITE-8821: Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/4218 > Huge logs on BPlusTreeSelfTest put/remove family tests > -- > > Key: IGNITE-8821 > URL: https://issues.apache.org/jira/browse/IGNITE-8821 > Project: Ignite > Issue Type: Test > Components: general >Reporter: Dmitriy Sorokin >Assignee: Dmitriy Sorokin >Priority: Minor > Labels: test > Fix For: 2.7 > > > A printLocks method generates huge count of ## XX log lines without any > more info assigned to. Avoiding the output of unnecessary non-informative > lines is suggested. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-1903) Cache configuration is serialized to nodes whether they require it or not
[
https://issues.apache.org/jira/browse/IGNITE-1903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16530031#comment-16530031
]
Ilya Kasnacheev commented on IGNITE-1903:
-
It doesn't always have to be a class, sometimes it's a Spring bean which is
present on server nodes but not client nodes.
> Cache configuration is serialized to nodes whether they require it or not
> -
>
> Key: IGNITE-1903
> URL: https://issues.apache.org/jira/browse/IGNITE-1903
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 1.5.0.final
>Reporter: Michael Griggs
>Priority: Major
> Labels: community, usability
> Fix For: 2.7
>
>
> See User discussion thread:
> http://apache-ignite-users.70518.x6.nabble.com/CacheStore-being-serialized-to-client-td1931.html
> Brief summary: When a grid client joins the grid (clientMode=true) it
> receives a message from the server node(s) on the grid that contains the
> serialized CacheStore implementation object. If the client does not have
> this class on its CLASSPATH (and there is no reason it should, as it is a
> client) then the de-serialization of this message will fail, causing this
> exception:
> {code}SEVERE: Failed to unmarshal discovery data for component: 1
> class org.apache.ignite.IgniteCheckedException: Failed to find class with
> given class loader for unmarshalling (make sure same versions of all classes
> are available on all nodes or enable peer-class-loading):
> sun.misc.Launcher$AppClassLoader@14dad5dc
> at
> org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal(JdkMarshaller.java:104)
>
> at
> org.apache.ignite.marshaller.AbstractMarshaller.unmarshal(AbstractMarshaller.java:67)
>
> at
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.onExchange(TcpDiscoverySpi.java:1529)
>
> at
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.processNodeAddFinishedMessage(ClientImpl.java:1317)
>
> at
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.processDiscoveryMessage(ClientImpl.java:1229)
>
> at
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.body(ClientImpl.java:1199)
>
> at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
> Caused by: java.lang.ClassNotFoundException:
> c.g.r.cachewrapper.ignite.CacheMissHandlerIgnite
> {code}
> where {{c.g.r.cachewrapper.ignite.CacheMissHandlerIgnite}} is the CacheStore
> implementation.
> The ostensible reason for the CacheStore serialization is so that clients of
> a TRANSACTIONAL cache can begin the transaction on the underlying store.
> The only current solution to this is to add the grid node's CacheStore
> implementation class definition to the CLASSPATH of the client. This creates
> an *undesirable coupling* between server and client.
> ---
> *UPDATE (copy-paste from comment below)*
> This is actually more generic issue. When a new node joins (client or
> server), all existing cache configurations (which include cache stores) are
> sent to this node. It then deserializes it during startup which can cause
> exceptions on clients or servers where cache is not supposed to be deployed
> as defined by node filter.
> As a solution we can do the following:
> * During discovery, send node filter and cache store factory in binary format
> along with the cache configuration, not as its parts.
> * On server, check node filter first and deserialize cache configuration and
> cache store only if it returns true. In case of error, STOP join process (now
> we just print exception in log and go on, which is very error-prone).
> * On client, do not deserialize cache configuration and cache store until
> user's code tries to actually use the cache (calls Ignite.cache. If cache is
> ATOMIC, never deserialize the cache store.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8746) EVT_CACHE_REBALANCE_PART_DATA_LOST event received twice on the coordinator node
[ https://issues.apache.org/jira/browse/IGNITE-8746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16530023#comment-16530023 ] Pavel Kovalenko commented on IGNITE-8746: - [~pvinokurov] Looks good. Ready to merge. > EVT_CACHE_REBALANCE_PART_DATA_LOST event received twice on the coordinator > node > --- > > Key: IGNITE-8746 > URL: https://issues.apache.org/jira/browse/IGNITE-8746 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.4 >Reporter: Pavel Vinokurov >Assignee: Pavel Vinokurov >Priority: Major > Fix For: 2.7 > > Attachments: EvtDataLostTwiceOnCoordinatorReprocuder.java > > > After a node left the cluster the coordinator recieves the partition lost > event twice. > The reproducer is attached. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8203) Interrupting task can cause node fail with PersistenceStorageIOException.
[ https://issues.apache.org/jira/browse/IGNITE-8203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16529937#comment-16529937 ] ASF GitHub Bot commented on IGNITE-8203: Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/4211 > Interrupting task can cause node fail with PersistenceStorageIOException. > -- > > Key: IGNITE-8203 > URL: https://issues.apache.org/jira/browse/IGNITE-8203 > Project: Ignite > Issue Type: Bug > Components: persistence >Affects Versions: 2.4 >Reporter: Ivan Daschinskiy >Assignee: Aleksey Plekhanov >Priority: Major > Fix For: 2.7 > > Attachments: GridFailNodesOnCanceledTaskTest.java > > > Interrupting task with simple cache operations (i.e. get, put) can cause > PersistenceStorageIOException. Main cause of this failure is lack of proper > handling InterruptedException in FilePageStore.init() etc. This cause a throw > of ClosedByInterruptException by FileChannel.write() and so on. > PersistenceStorageIOException is a critical failure and typically makes a > node to stop. As a workaround, I would suggest to enable AsyncFileIO by > default until the fix was available. > A reproducer is attached. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8756) SQL: CREATE/ALTER USER documentation should contain information about case sensitivity of username
[
https://issues.apache.org/jira/browse/IGNITE-8756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16529831#comment-16529831
]
Andrey Aleksandrov commented on IGNITE-8756:
[~Artem Budnikov] Thank you but I think that next part of the documentation
isn't fully correct:
-If it's planned to access Ignite from Java, .Net or other programming
languages APIs then the username has to be passed in the *upper-case letters*
from those interfaces.
-You have to use TEST as the username from Ignite's native *SQL APIs designed
for Java*, .NET and other programming languages.
As for me, it meant that in SQL APIs designed for Java you can use only upper
case. But you can also *create* (CREATE USER) and *use* (ALTER USER) values in
camel case like in JDBC/ODBC using quotations.
So I think that "When Case-Sensitive Names are Preferred?" should be updated.
> SQL: CREATE/ALTER USER documentation should contain information about case
> sensitivity of username
> --
>
> Key: IGNITE-8756
> URL: https://issues.apache.org/jira/browse/IGNITE-8756
> Project: Ignite
> Issue Type: Improvement
> Components: documentation, sql
>Affects Versions: 2.5
>Reporter: Andrey Aleksandrov
>Assignee: Artem Budnikov
>Priority: Major
> Labels: doc
> Fix For: 2.7
>
>
> Now documentation contains next:
> https://apacheignite-sql.readme.io/docs/create-user#section-description
> For instance, if {{test}} was set as a username then:
> * You can use {{Test}}, {{TEst}}, {{TEST}} and other combinations from JDBC
> and ODBC.
> * You have to use {{TEST}} as the username from Ignite's native SQL APIs
> designed for Java, .NET and other programming languages.
> But next behavior exists:
> When you create the user in quotes ("test") using SQL as next:
> CREATE USER "test" WITH PASSWORD 'test'
> It will be created as it was set (in this case it will be test)
> If you create the user without quotes (test) using SQL as next:
> CREATE USER test WITH PASSWORD 'test'
> then username will be stored in uppercase (TEST).
> The same situation with ALTER USER.
> The documentation should be updated to clear that SQL supports case sensitive
> data too (using quotas).
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-8909) Visor shows unimplemented off-heap memory cache metric
Denis Mekhanikov created IGNITE-8909: Summary: Visor shows unimplemented off-heap memory cache metric Key: IGNITE-8909 URL: https://issues.apache.org/jira/browse/IGNITE-8909 Project: Ignite Issue Type: Task Components: visor Affects Versions: 2.5 Reporter: Denis Mekhanikov "Off-Heap Memory" metric in result of *cache -a* command is always 0. Cache memory metrics were replaced with the ones for data regions, so this metric is unlikely to be implemented. Off-Heap Memory metric should be removed from Visor. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-6531) Need to add a 'required' field to the SpringResource annotation.
[
https://issues.apache.org/jira/browse/IGNITE-6531?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16514783#comment-16514783
]
joungdal.nam edited comment on IGNITE-6531 at 7/2/18 12:39 PM:
---
please read outlink
[mail
thread|https://lists.apache.org/thread.html/%3ccafhuo56mb8ppk3+6xgpkgkz_jg-kbdapj7cjlyeytc+qbzx...@mail.gmail.com%3E]
was (Author: skylark-nam):
please read outlink
[mail
thread|https://lists.apache.org/list.html?d...@ignite.apache.org:lte=1M:joungdal.nam]
> Need to add a 'required' field to the SpringResource annotation.
>
>
> Key: IGNITE-6531
> URL: https://issues.apache.org/jira/browse/IGNITE-6531
> Project: Ignite
> Issue Type: Improvement
> Components: spring
>Affects Versions: 2.3
>Reporter: joungdal.nam
>Assignee: joungdal.nam
>Priority: Minor
> Labels: easyfix, newbie
>
> In my test environment, only the client is used(setForceServerMode(true)).
> Operating environments use clients and servers.
> Sometimes Injection is not required in the test environment.
> NoSuchBeanDefinitionException is not generated by specifying a value of false.
> public @interface SpringResource {
>
> /**
>* Declares whether the annotated dependency is required.
>* Defaults to {@code true}.
>*/
> boolean required() default true;
> ..
> if (!StringUtils.isEmpty(beanName)) {
> try {
> bean = springCtx.getBean(beanName);
> } catch(NoSuchBeanDefinitionException ne) {
> if(annotation.required()) {
> throw ne;
> }
> }
> }
> else {
> try {
> bean = springCtx.getBean(beanCls);
> } catch(NoSuchBeanDefinitionException ne) {
> if(annotation.required()) {
> throw ne;
> }
> }
> }
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8756) SQL: CREATE/ALTER USER documentation should contain information about case sensitivity of username
[
https://issues.apache.org/jira/browse/IGNITE-8756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16529809#comment-16529809
]
Artem Budnikov commented on IGNITE-8756:
[~aealeksandrov],
The page mentions that "To create a _case-sensitive_ username, use the
quotation (") SQL identifier."
Please verify if that is what you wanted to achieve by creating this issue.
> SQL: CREATE/ALTER USER documentation should contain information about case
> sensitivity of username
> --
>
> Key: IGNITE-8756
> URL: https://issues.apache.org/jira/browse/IGNITE-8756
> Project: Ignite
> Issue Type: Improvement
> Components: documentation, sql
>Affects Versions: 2.5
>Reporter: Andrey Aleksandrov
>Assignee: Artem Budnikov
>Priority: Major
> Labels: doc
> Fix For: 2.7
>
>
> Now documentation contains next:
> https://apacheignite-sql.readme.io/docs/create-user#section-description
> For instance, if {{test}} was set as a username then:
> * You can use {{Test}}, {{TEst}}, {{TEST}} and other combinations from JDBC
> and ODBC.
> * You have to use {{TEST}} as the username from Ignite's native SQL APIs
> designed for Java, .NET and other programming languages.
> But next behavior exists:
> When you create the user in quotes ("test") using SQL as next:
> CREATE USER "test" WITH PASSWORD 'test'
> It will be created as it was set (in this case it will be test)
> If you create the user without quotes (test) using SQL as next:
> CREATE USER test WITH PASSWORD 'test'
> then username will be stored in uppercase (TEST).
> The same situation with ALTER USER.
> The documentation should be updated to clear that SQL supports case sensitive
> data too (using quotas).
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8899) IgniteJdbcDriver directly create JavaLogger in static context
[ https://issues.apache.org/jira/browse/IGNITE-8899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16529782#comment-16529782 ] Evgenii Zhuravlev commented on IGNITE-8899: --- Checked TC: https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_RunAll_IgniteTests24Java8=pull%2F4284%2Fhead=buildTypeStatusDiv It looks good and doesn't have any new test failures. > IgniteJdbcDriver directly create JavaLogger in static context > - > > Key: IGNITE-8899 > URL: https://issues.apache.org/jira/browse/IGNITE-8899 > Project: Ignite > Issue Type: Bug >Reporter: Evgenii Zhuravlev >Assignee: Evgenii Zhuravlev >Priority: Major > > It means, that it always prints error in logs, if Jul logging file doesn't > exist. I suggest to use the same approach as in thin driver: > replace > new JavaLogger() > with > Logger.getLogger(IgniteJdbcDriver.class.getName()) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8908) NPE on discovery message processing
[ https://issues.apache.org/jira/browse/IGNITE-8908?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Cherkasov updated IGNITE-8908: -- Summary: NPE on discovery message processing (was: NPE in BinaryMetadataTransport) > NPE on discovery message processing > --- > > Key: IGNITE-8908 > URL: https://issues.apache.org/jira/browse/IGNITE-8908 > Project: Ignite > Issue Type: Bug > Components: general >Reporter: Mikhail Cherkasov >Priority: Major > Attachments: ContinuousQueryTask.txt, RegisterTask.txt, > ServiceTask.txt > > > To reproduce the problem we do the the following steps: > 1) start 4 server nodes > 2) start client nodes: ServiceTask, RegisterTask, ContinuousQueryTask > 3) restart 3 of 4 server nodes. > The following exception is observed in logs: > [2018-07-02 10:15:48,199][ERROR]tcp-disco-msg-worker-#2 Failed to notify > direct custom event listener: MetadataUpdateAcceptedMessage > [id=cae4cd95461-6f8d75e0-424e-4a8f-8f20-c34a9d55e44f, typeId=-372239526, > acceptedVer=1, duplicated=false] > java.lang.NullPointerException: null > at > org.apache.ignite.internal.processors.cache.binary.BinaryMetadataTransport$MetadataUpdateAcceptedListener.onCustomEvent(BinaryMetadataTransport.java:451) > ~[ignite-core-2.x.x.jar:2.x.x] > at > org.apache.ignite.internal.processors.cache.binary.BinaryMetadataTransport$MetadataUpdateAcceptedListener.onCustomEvent(BinaryMetadataTransport.java:418) > ~[ignite-core-2.x.x.jar:2.x.x] > at > org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery0(GridDiscoveryManager.java:695) > [ignite-core-2.x.x.jar:2.x.x] > at > org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery(GridDiscoveryManager.java:577) > [ignite-core-2.x.x.jar:2.x.x] > at > org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.notifyDiscoveryListener(ServerImpl.java:5453) > [ignite-core-2.x.x.jar:2.x.x] > at > org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processCustomMessage(ServerImpl.java:5279) > [ignite-core-2.x.x.jar:2.x.x] > at > org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processCustomMessage(ServerImpl.java:5313) > [ignite-core-2.x.x.jar:2.x.x] > at > org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2739) > [ignite-core-2.x.x.jar:2.x.x] > at > org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2531) > [ignite-core-2.x.x.jar:2.x.x] > at > org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorkerAdapter.body(ServerImpl.java:6730) > [ignite-core-2.x.x.jar:2.x.x] > at > org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.body(ServerImpl.java:2614) > [ignite-core-2.x.x.jar:2.x.x] > at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62) > [ignite-core-2.x.x.jar:2.x.x] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8908) NPE in BinaryMetadataTransport
[ https://issues.apache.org/jira/browse/IGNITE-8908?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Cherkasov updated IGNITE-8908: -- Attachment: ServiceTask.txt RegisterTask.txt ContinuousQueryTask.txt > NPE in BinaryMetadataTransport > -- > > Key: IGNITE-8908 > URL: https://issues.apache.org/jira/browse/IGNITE-8908 > Project: Ignite > Issue Type: Bug > Components: general >Reporter: Mikhail Cherkasov >Priority: Major > Attachments: ContinuousQueryTask.txt, RegisterTask.txt, > ServiceTask.txt > > > To reproduce the problem we do the the following steps: > 1) start 4 server nodes > 2) start client nodes: ServiceTask, RegisterTask, ContinuousQueryTask > 3) restart 3 of 4 server nodes. > The following exception is observed in logs: > [2018-07-02 10:15:48,199][ERROR]tcp-disco-msg-worker-#2 Failed to notify > direct custom event listener: MetadataUpdateAcceptedMessage > [id=cae4cd95461-6f8d75e0-424e-4a8f-8f20-c34a9d55e44f, typeId=-372239526, > acceptedVer=1, duplicated=false] > java.lang.NullPointerException: null > at > org.apache.ignite.internal.processors.cache.binary.BinaryMetadataTransport$MetadataUpdateAcceptedListener.onCustomEvent(BinaryMetadataTransport.java:451) > ~[ignite-core-2.x.x.jar:2.x.x] > at > org.apache.ignite.internal.processors.cache.binary.BinaryMetadataTransport$MetadataUpdateAcceptedListener.onCustomEvent(BinaryMetadataTransport.java:418) > ~[ignite-core-2.x.x.jar:2.x.x] > at > org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery0(GridDiscoveryManager.java:695) > [ignite-core-2.x.x.jar:2.x.x] > at > org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery(GridDiscoveryManager.java:577) > [ignite-core-2.x.x.jar:2.x.x] > at > org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.notifyDiscoveryListener(ServerImpl.java:5453) > [ignite-core-2.x.x.jar:2.x.x] > at > org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processCustomMessage(ServerImpl.java:5279) > [ignite-core-2.x.x.jar:2.x.x] > at > org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processCustomMessage(ServerImpl.java:5313) > [ignite-core-2.x.x.jar:2.x.x] > at > org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2739) > [ignite-core-2.x.x.jar:2.x.x] > at > org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2531) > [ignite-core-2.x.x.jar:2.x.x] > at > org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorkerAdapter.body(ServerImpl.java:6730) > [ignite-core-2.x.x.jar:2.x.x] > at > org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.body(ServerImpl.java:2614) > [ignite-core-2.x.x.jar:2.x.x] > at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62) > [ignite-core-2.x.x.jar:2.x.x] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8908) NPE in BinaryMetadataTransport
[ https://issues.apache.org/jira/browse/IGNITE-8908?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Cherkasov updated IGNITE-8908: -- Description: To reproduce the problem we do the the following steps: 1) start 4 server nodes 2) start client nodes: ServiceTask, RegisterTask, ContinuousQueryTask 3) restart 3 of 4 server nodes. The following exception is observed in logs: [2018-07-02 10:15:48,199][ERROR]tcp-disco-msg-worker-#2 Failed to notify direct custom event listener: MetadataUpdateAcceptedMessage [id=cae4cd95461-6f8d75e0-424e-4a8f-8f20-c34a9d55e44f, typeId=-372239526, acceptedVer=1, duplicated=false] java.lang.NullPointerException: null at org.apache.ignite.internal.processors.cache.binary.BinaryMetadataTransport$MetadataUpdateAcceptedListener.onCustomEvent(BinaryMetadataTransport.java:451) ~[ignite-core-2.x.x.jar:2.x.x] at org.apache.ignite.internal.processors.cache.binary.BinaryMetadataTransport$MetadataUpdateAcceptedListener.onCustomEvent(BinaryMetadataTransport.java:418) ~[ignite-core-2.x.x.jar:2.x.x] at org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery0(GridDiscoveryManager.java:695) [ignite-core-2.x.x.jar:2.x.x] at org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery(GridDiscoveryManager.java:577) [ignite-core-2.x.x.jar:2.x.x] at org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.notifyDiscoveryListener(ServerImpl.java:5453) [ignite-core-2.x.x.jar:2.x.x] at org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processCustomMessage(ServerImpl.java:5279) [ignite-core-2.x.x.jar:2.x.x] at org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processCustomMessage(ServerImpl.java:5313) [ignite-core-2.x.x.jar:2.x.x] at org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2739) [ignite-core-2.x.x.jar:2.x.x] at org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2531) [ignite-core-2.x.x.jar:2.x.x] at org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorkerAdapter.body(ServerImpl.java:6730) [ignite-core-2.x.x.jar:2.x.x] at org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.body(ServerImpl.java:2614) [ignite-core-2.x.x.jar:2.x.x] at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62) [ignite-core-2.x.x.jar:2.x.x] was: To reproduce the problem we run the following scenary: [2018-07-02 10:15:48,199][ERROR][tcp-disco-msg-worker-#2] Failed to notify direct custom event listener: MetadataUpdateAcceptedMessage [id=cae4cd95461-6f8d75e0-424e-4a8f-8f20-c34a9d55e44f, typeId=-372239526, acceptedVer=1, duplicated=false] java.lang.NullPointerException: null at org.apache.ignite.internal.processors.cache.binary.BinaryMetadataTransport$MetadataUpdateAcceptedListener.onCustomEvent(BinaryMetadataTransport.java:451) ~[ignite-core-2.4.7.jar:2.4.7] at org.apache.ignite.internal.processors.cache.binary.BinaryMetadataTransport$MetadataUpdateAcceptedListener.onCustomEvent(BinaryMetadataTransport.java:418) ~[ignite-core-2.4.7.jar:2.4.7] at org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery0(GridDiscoveryManager.java:695) [ignite-core-2.4.7.jar:2.4.7] at org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery(GridDiscoveryManager.java:577) [ignite-core-2.4.7.jar:2.4.7] at org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.notifyDiscoveryListener(ServerImpl.java:5453) [ignite-core-2.4.7.jar:2.4.7] at org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processCustomMessage(ServerImpl.java:5279) [ignite-core-2.4.7.jar:2.4.7] at org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processCustomMessage(ServerImpl.java:5313) [ignite-core-2.4.7.jar:2.4.7] at org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2739) [ignite-core-2.4.7.jar:2.4.7] at org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2531) [ignite-core-2.4.7.jar:2.4.7] at org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorkerAdapter.body(ServerImpl.java:6730) [ignite-core-2.4.7.jar:2.4.7] at org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.body(ServerImpl.java:2614) [ignite-core-2.4.7.jar:2.4.7] at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62) [ignite-core-2.4.7.jar:2.4.7] > NPE in BinaryMetadataTransport > -- > > Key: IGNITE-8908 > URL: https://issues.apache.org/jira/browse/IGNITE-8908 > Project: Ignite > Issue Type: Bug > Components: general >Reporter: Mikhail Cherkasov >Priority: Major > > To reproduce the problem we do the the following steps: > 1) start 4 server nodes
[jira] [Commented] (IGNITE-8905) Incorrect assertion in GridDhtPartitionsExchangeFuture
[ https://issues.apache.org/jira/browse/IGNITE-8905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16529709#comment-16529709 ] ASF GitHub Bot commented on IGNITE-8905: GitHub user sergey-chugunov-1985 opened a pull request: https://github.com/apache/ignite/pull/4288 IGNITE-8905 incorrect assertion was replaced with if-check You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-8905 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4288.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 #4288 commit f2194169e9eda7232bc642bf3b1b5a1ad4967af0 Author: Sergey Chugunov Date: 2018-07-02T10:54:55Z IGNITE-8905 incorrect assertion was replaced with if-check > Incorrect assertion in GridDhtPartitionsExchangeFuture > -- > > Key: IGNITE-8905 > URL: https://issues.apache.org/jira/browse/IGNITE-8905 > Project: Ignite > Issue Type: Bug >Reporter: Sergey Chugunov >Assignee: Sergey Chugunov >Priority: Major > Fix For: 2.7 > > Original Estimate: 2h > Remaining Estimate: 2h > > Assertion was added as part IGNITE-8657 into GridDhtPartitionsExchangeFuture > which is correct only in situation when client has to reconnect due to too > short EXCHANGE_HISTORY. > Exceptions from other situations like not being able to acquire file lock are > also passed to client node in FullMessage. > This assertion should be removed and check should be introduced instead: if > this exception is intended to be thrown on current client node, we should do > this, otherwise old program flow should be executed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8908) NPE in BinaryMetadataTransport
Mikhail Cherkasov created IGNITE-8908: - Summary: NPE in BinaryMetadataTransport Key: IGNITE-8908 URL: https://issues.apache.org/jira/browse/IGNITE-8908 Project: Ignite Issue Type: Bug Components: general Reporter: Mikhail Cherkasov -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8908) NPE in BinaryMetadataTransport
[ https://issues.apache.org/jira/browse/IGNITE-8908?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Cherkasov updated IGNITE-8908: -- Description: To reproduce the problem we run the following scenary: [2018-07-02 10:15:48,199][ERROR][tcp-disco-msg-worker-#2] Failed to notify direct custom event listener: MetadataUpdateAcceptedMessage [id=cae4cd95461-6f8d75e0-424e-4a8f-8f20-c34a9d55e44f, typeId=-372239526, acceptedVer=1, duplicated=false] java.lang.NullPointerException: null at org.apache.ignite.internal.processors.cache.binary.BinaryMetadataTransport$MetadataUpdateAcceptedListener.onCustomEvent(BinaryMetadataTransport.java:451) ~[ignite-core-2.4.7.jar:2.4.7] at org.apache.ignite.internal.processors.cache.binary.BinaryMetadataTransport$MetadataUpdateAcceptedListener.onCustomEvent(BinaryMetadataTransport.java:418) ~[ignite-core-2.4.7.jar:2.4.7] at org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery0(GridDiscoveryManager.java:695) [ignite-core-2.4.7.jar:2.4.7] at org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery(GridDiscoveryManager.java:577) [ignite-core-2.4.7.jar:2.4.7] at org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.notifyDiscoveryListener(ServerImpl.java:5453) [ignite-core-2.4.7.jar:2.4.7] at org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processCustomMessage(ServerImpl.java:5279) [ignite-core-2.4.7.jar:2.4.7] at org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processCustomMessage(ServerImpl.java:5313) [ignite-core-2.4.7.jar:2.4.7] at org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2739) [ignite-core-2.4.7.jar:2.4.7] at org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2531) [ignite-core-2.4.7.jar:2.4.7] at org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorkerAdapter.body(ServerImpl.java:6730) [ignite-core-2.4.7.jar:2.4.7] at org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.body(ServerImpl.java:2614) [ignite-core-2.4.7.jar:2.4.7] at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62) [ignite-core-2.4.7.jar:2.4.7] > NPE in BinaryMetadataTransport > -- > > Key: IGNITE-8908 > URL: https://issues.apache.org/jira/browse/IGNITE-8908 > Project: Ignite > Issue Type: Bug > Components: general >Reporter: Mikhail Cherkasov >Priority: Major > > To reproduce the problem we run the following scenary: > > [2018-07-02 10:15:48,199][ERROR][tcp-disco-msg-worker-#2] Failed to notify > direct custom event listener: MetadataUpdateAcceptedMessage > [id=cae4cd95461-6f8d75e0-424e-4a8f-8f20-c34a9d55e44f, typeId=-372239526, > acceptedVer=1, duplicated=false] > java.lang.NullPointerException: null > at > org.apache.ignite.internal.processors.cache.binary.BinaryMetadataTransport$MetadataUpdateAcceptedListener.onCustomEvent(BinaryMetadataTransport.java:451) > ~[ignite-core-2.4.7.jar:2.4.7] > at > org.apache.ignite.internal.processors.cache.binary.BinaryMetadataTransport$MetadataUpdateAcceptedListener.onCustomEvent(BinaryMetadataTransport.java:418) > ~[ignite-core-2.4.7.jar:2.4.7] > at > org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery0(GridDiscoveryManager.java:695) > [ignite-core-2.4.7.jar:2.4.7] > at > org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery(GridDiscoveryManager.java:577) > [ignite-core-2.4.7.jar:2.4.7] > at > org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.notifyDiscoveryListener(ServerImpl.java:5453) > [ignite-core-2.4.7.jar:2.4.7] > at > org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processCustomMessage(ServerImpl.java:5279) > [ignite-core-2.4.7.jar:2.4.7] > at > org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processCustomMessage(ServerImpl.java:5313) > [ignite-core-2.4.7.jar:2.4.7] > at > org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2739) > [ignite-core-2.4.7.jar:2.4.7] > at > org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2531) > [ignite-core-2.4.7.jar:2.4.7] > at > org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorkerAdapter.body(ServerImpl.java:6730) > [ignite-core-2.4.7.jar:2.4.7] > at > org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.body(ServerImpl.java:2614) > [ignite-core-2.4.7.jar:2.4.7] > at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62) > [ignite-core-2.4.7.jar:2.4.7] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8662) Umbrella: ML data preprocessing for 2.7 release
[ https://issues.apache.org/jira/browse/IGNITE-8662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Babak updated IGNITE-8662: --- Summary: Umbrella: ML data preprocessing for 2.7 release (was: Umbrella: ML data preprocessing for 2.6 release) > Umbrella: ML data preprocessing for 2.7 release > --- > > Key: IGNITE-8662 > URL: https://issues.apache.org/jira/browse/IGNITE-8662 > Project: Ignite > Issue Type: New Feature > Components: ml >Reporter: Yury Babak >Assignee: Yury Babak >Priority: Major > Fix For: 2.7 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8907) [ML] Using vectors in featureExtractor
Yury Babak created IGNITE-8907: -- Summary: [ML] Using vectors in featureExtractor Key: IGNITE-8907 URL: https://issues.apache.org/jira/browse/IGNITE-8907 Project: Ignite Issue Type: Improvement Components: ml Reporter: Yury Babak Assignee: Alexey Platonov Fix For: 2.7 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8780) File I/O operations must be retried if buffer hasn't read/written completely
[
https://issues.apache.org/jira/browse/IGNITE-8780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16529688#comment-16529688
]
Alexey Stelmak commented on IGNITE-8780:
https://ci.ignite.apache.org/viewLog.html?buildId=1437898;
> File I/O operations must be retried if buffer hasn't read/written completely
>
>
> Key: IGNITE-8780
> URL: https://issues.apache.org/jira/browse/IGNITE-8780
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.5
>Reporter: Pavel Kovalenko
>Assignee: Alexey Stelmak
>Priority: Critical
> Labels: important
> Fix For: 2.6
>
>
> Currently we don't actually ensure that we write or read some buffer
> completely:
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager#writeCheckpointEntry
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager#nodeStart
> As result we may not write to the disk actual data and after node restart we
> can get BufferUnderflowException, like this:
> {noformat}
> java.nio.BufferUnderflowException
> at java.nio.Buffer.nextGetIndex(Buffer.java:506)
> at java.nio.HeapByteBuffer.getLong(HeapByteBuffer.java:412)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.readPointer(GridCacheDatabaseSharedManager.java:1915)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.readCheckpointStatus(GridCacheDatabaseSharedManager.java:1892)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.readMetastore(GridCacheDatabaseSharedManager.java:565)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.start0(GridCacheDatabaseSharedManager.java:525)
> at
> org.apache.ignite.internal.processors.cache.GridCacheSharedManagerAdapter.start(GridCacheSharedManagerAdapter.java:61)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.start(GridCacheProcessor.java:700)
> at
> org.apache.ignite.internal.IgniteKernal.startProcessor(IgniteKernal.java:1738)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:985)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2014)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1723)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1151)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:671)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:596)
> at org.apache.ignite.Ignition.start(Ignition.java:327)
> at org.apache.ignite.ci.db.TcHelperDb.start(TcHelperDb.java:67)
> at
> org.apache.ignite.ci.web.CtxListener.contextInitialized(CtxListener.java:37)
> at
> org.eclipse.jetty.server.handler.ContextHandler.callContextInitialized(ContextHandler.java:890)
> at
> org.eclipse.jetty.servlet.ServletContextHandler.callContextInitialized(ServletContextHandler.java:532)
> at
> org.eclipse.jetty.server.handler.ContextHandler.startContext(ContextHandler.java:853)
> at
> org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:344)
> at
> org.eclipse.jetty.webapp.WebAppContext.startWebapp(WebAppContext.java:1501)
> at
> org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1463)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:785)
> at
> org.eclipse.jetty.servlet.ServletContextHandler.doStart(ServletContextHandler.java:261)
> at org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:545)
> at
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
> at
> org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:131)
> at org.eclipse.jetty.server.Server.start(Server.java:452)
> at
> org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:105)
> at
> org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:113)
> at org.eclipse.jetty.server.Server.doStart(Server.java:419)
> at
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
> at org.apache.ignite.ci.web.Launcher.runServer(Launcher.java:68)
> at
> org.apache.ignite.ci.TcHelperJettyLauncher.main(TcHelperJettyLauncher.java:10)
> {noformat}
> and node become into unrecoverable state.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-8906) SQL TX: Immediate rollback for Near transactions during topology changing.
Roman Kondakov created IGNITE-8906: -- Summary: SQL TX: Immediate rollback for Near transactions during topology changing. Key: IGNITE-8906 URL: https://issues.apache.org/jira/browse/IGNITE-8906 Project: Ignite Issue Type: Improvement Components: sql Reporter: Roman Kondakov At the moment all near transaction that was active during PME, but hadn't locked topology (i.e. read transactions), are marked as rollback only in GridDhtPartitionsExchangeFuture#onDone. But it is better to stop transaction execution immediately to prevent useless updates. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8684) Partition state exchange during rebalance continues to keep sending state messages (single,full) in loop even if no changes in partition states
[ https://issues.apache.org/jira/browse/IGNITE-8684?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16529638#comment-16529638 ] ASF GitHub Bot commented on IGNITE-8684: GitHub user DmitriyGovorukhin opened a pull request: https://github.com/apache/ignite/pull/4287 IGNITE-8684 fix partition state exchange during rebalance Partition state exchange during rebalance continues to keep sending state messages (single, full) in the loop even if no changes in partition states. You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-8684-2 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4287.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 #4287 commit ecca120b70d211ad6586eed11e9309cd18cf9226 Author: Dmitriy Govorukhin Date: 2018-07-02T09:53:59Z IGNITE-8684 fix partition state exchange during rebalance continues to keep sending state messages (single,full) in loop even if no changes in partition states. > Partition state exchange during rebalance continues to keep sending state > messages (single,full) in loop even if no changes in partition states > --- > > Key: IGNITE-8684 > URL: https://issues.apache.org/jira/browse/IGNITE-8684 > Project: Ignite > Issue Type: Bug >Reporter: Alexei Scherbakov >Assignee: Dmitriy Govorukhin >Priority: Major > Fix For: 2.7 > > > This is due to invalid "changed" state computation in > org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl#update(org.apache.ignite.internal.processors.affinity.AffinityTopologyVersion, > > org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionFullMap, > > org.apache.ignite.internal.processors.cache.distributed.dht.preloader.CachePartitionFullCountersMap, > java.util.Set, > org.apache.ignite.internal.processors.affinity.AffinityTopologyVersion) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8905) Incorrect assertion in GridDhtPartitionsExchangeFuture
[ https://issues.apache.org/jira/browse/IGNITE-8905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Chugunov updated IGNITE-8905: Remaining Estimate: 2h (was: 4h) Original Estimate: 2h (was: 4h) > Incorrect assertion in GridDhtPartitionsExchangeFuture > -- > > Key: IGNITE-8905 > URL: https://issues.apache.org/jira/browse/IGNITE-8905 > Project: Ignite > Issue Type: Bug >Reporter: Sergey Chugunov >Assignee: Sergey Chugunov >Priority: Major > Fix For: 2.7 > > Original Estimate: 2h > Remaining Estimate: 2h > > Assertion was added as part IGNITE-8657 into GridDhtPartitionsExchangeFuture > which is correct only in situation when client has to reconnect due to too > short EXCHANGE_HISTORY. > Exceptions from other situations like not being able to acquire file lock are > also passed to client node in FullMessage. > This assertion should be removed and check should be introduced instead: if > this exception is intended to be thrown on current client node, we should do > this, otherwise old program flow should be executed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8905) Incorrect assertion in GridDhtPartitionsExchangeFuture
[ https://issues.apache.org/jira/browse/IGNITE-8905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Chugunov updated IGNITE-8905: Remaining Estimate: 4h Original Estimate: 4h > Incorrect assertion in GridDhtPartitionsExchangeFuture > -- > > Key: IGNITE-8905 > URL: https://issues.apache.org/jira/browse/IGNITE-8905 > Project: Ignite > Issue Type: Bug >Reporter: Sergey Chugunov >Assignee: Sergey Chugunov >Priority: Major > Fix For: 2.7 > > Original Estimate: 4h > Remaining Estimate: 4h > > Assertion was added as part IGNITE-8657 into GridDhtPartitionsExchangeFuture > which is correct only in situation when client has to reconnect due to too > short EXCHANGE_HISTORY. > Exceptions from other situations like not being able to acquire file lock are > also passed to client node in FullMessage. > This assertion should be removed and check should be introduced instead: if > this exception is intended to be thrown on current client node, we should do > this, otherwise old program flow should be executed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8905) Incorrect assertion in GridDhtPartitionsExchangeFuture
[ https://issues.apache.org/jira/browse/IGNITE-8905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Chugunov updated IGNITE-8905: Fix Version/s: 2.7 > Incorrect assertion in GridDhtPartitionsExchangeFuture > -- > > Key: IGNITE-8905 > URL: https://issues.apache.org/jira/browse/IGNITE-8905 > Project: Ignite > Issue Type: Bug >Reporter: Sergey Chugunov >Assignee: Sergey Chugunov >Priority: Major > Fix For: 2.7 > > Original Estimate: 4h > Remaining Estimate: 4h > > Assertion was added as part IGNITE-8657 into GridDhtPartitionsExchangeFuture > which is correct only in situation when client has to reconnect due to too > short EXCHANGE_HISTORY. > Exceptions from other situations like not being able to acquire file lock are > also passed to client node in FullMessage. > This assertion should be removed and check should be introduced instead: if > this exception is intended to be thrown on current client node, we should do > this, otherwise old program flow should be executed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8905) Incorrect assertion in GridDhtPartitionsExchangeFuture
Sergey Chugunov created IGNITE-8905: --- Summary: Incorrect assertion in GridDhtPartitionsExchangeFuture Key: IGNITE-8905 URL: https://issues.apache.org/jira/browse/IGNITE-8905 Project: Ignite Issue Type: Bug Reporter: Sergey Chugunov Assignee: Sergey Chugunov Assertion was added as part IGNITE-8657 into GridDhtPartitionsExchangeFuture which is correct only in situation when client has to reconnect due to too short EXCHANGE_HISTORY. Exceptions from other situations like not being able to acquire file lock are also passed to client node in FullMessage. This assertion should be removed and check should be introduced instead: if this exception is intended to be thrown on current client node, we should do this, otherwise old program flow should be executed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-8684) Partition state exchange during rebalance continues to keep sending state messages (single,full) in loop even if no changes in partition states
[ https://issues.apache.org/jira/browse/IGNITE-8684?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Govorukhin reassigned IGNITE-8684: -- Assignee: Dmitriy Govorukhin > Partition state exchange during rebalance continues to keep sending state > messages (single,full) in loop even if no changes in partition states > --- > > Key: IGNITE-8684 > URL: https://issues.apache.org/jira/browse/IGNITE-8684 > Project: Ignite > Issue Type: Bug >Reporter: Alexei Scherbakov >Assignee: Dmitriy Govorukhin >Priority: Major > Fix For: 2.7 > > > This is due to invalid "changed" state computation in > org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl#update(org.apache.ignite.internal.processors.affinity.AffinityTopologyVersion, > > org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionFullMap, > > org.apache.ignite.internal.processors.cache.distributed.dht.preloader.CachePartitionFullCountersMap, > java.util.Set, > org.apache.ignite.internal.processors.affinity.AffinityTopologyVersion) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-8766) TcpDiscoverySpi: discovery threads naming
[ https://issues.apache.org/jira/browse/IGNITE-8766?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry Karachentsev reassigned IGNITE-8766: --- Assignee: Dmitry Karachentsev > TcpDiscoverySpi: discovery threads naming > - > > Key: IGNITE-8766 > URL: https://issues.apache.org/jira/browse/IGNITE-8766 > Project: Ignite > Issue Type: Improvement > Components: general >Reporter: Sergey Chugunov >Assignee: Dmitry Karachentsev >Priority: Major > Labels: discovery > > Including information about next/prev nodes into names of discovery-related > threads could be very helpful when investigating situations of network > glitches. > tcp-disco-sock-reader and tcp-disco-msg-worker threads must include such > information in their names. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8904) Add rebalanceThreadPoolSize to nodes configuration consistency check
Pavel Kovalenko created IGNITE-8904: --- Summary: Add rebalanceThreadPoolSize to nodes configuration consistency check Key: IGNITE-8904 URL: https://issues.apache.org/jira/browse/IGNITE-8904 Project: Ignite Issue Type: Bug Components: cache Affects Versions: 2.5, 2.4 Reporter: Pavel Kovalenko Assignee: Pavel Kovalenko Fix For: 2.7 If supplier node has less thread-pool size than demander node, rebalance process between them will hang indefinitely. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-8754) Node outside of baseline does not start when service configured
[
https://issues.apache.org/jira/browse/IGNITE-8754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladislav Pyatkov reassigned IGNITE-8754:
-
Assignee: Vladislav Pyatkov
> Node outside of baseline does not start when service configured
> ---
>
> Key: IGNITE-8754
> URL: https://issues.apache.org/jira/browse/IGNITE-8754
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Assignee: Vladislav Pyatkov
>Priority: Major
> Attachments: ServiceOnNodeOutOfBaselineTest.java
>
>
> Enough to configure service in {{ServiceConfiguration}} and the node does not
> started if the node outside of baseline.
> {noformat}
> "async-runnable-runner-1" #287 prio=5 os_prio=0 tid=0x24e0c800
> nid=0x4e6c waiting on condition [0xe87fe000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:177)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:140)
> at
> org.apache.ignite.internal.processors.service.GridServiceProcessor.onKernalStart0(GridServiceProcessor.java:287)
> at
> org.apache.ignite.internal.processors.service.GridServiceProcessor.onKernalStart(GridServiceProcessor.java:228)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1105)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2014)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1723)
> - locked <0x00076c142400> (a
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1151)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:649)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:882)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:845)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:833)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:799)
> at
> org.gridgain.internal.ServiceOnNodeOutOfBaselineTest.lambda$test$0(ServiceOnNodeOutOfBaselineTest.java:107)
> at
> org.gridgain.internal.ServiceOnNodeOutOfBaselineTest$$Lambda$22/781127963.run(Unknown
> Source)
> at
> org.apache.ignite.testframework.GridTestUtils.lambda$runAsync$1(GridTestUtils.java:898)
> at
> org.apache.ignite.testframework.GridTestUtils$$Lambda$23/1655470614.call(Unknown
> Source)
> at
> org.apache.ignite.testframework.GridTestUtils.lambda$runAsync$2(GridTestUtils.java:956)
> at
> org.apache.ignite.testframework.GridTestUtils$$Lambda$24/1782331932.run(Unknown
> Source)
> at
> org.apache.ignite.testframework.GridTestUtils$6.call(GridTestUtils.java:1254)
> at
> org.apache.ignite.testframework.GridTestThread.run(GridTestThread.java:86)
> {noformat}
> Test [^ServiceOnNodeOutOfBaselineTest.java] hangs with assertion because
> node can not started or stopped.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8376) Add cluster (de)activation events
[
https://issues.apache.org/jira/browse/IGNITE-8376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16529524#comment-16529524
]
kcheng.mvp commented on IGNITE-8376:
[~agoncharuk]
After go through the code and found the active/deactive action will finally
router to
{code:java}
org.apache.ignite.internal.cluster.IgniteClusterImpl#active(boolean)
/** {@inheritDoc} */
@Override public void active(boolean active) {
guard();
try {
ctx.state().changeGlobalState(active, baselineNodes(), false).get();
}
catch (IgniteCheckedException e) {
throw U.convertException(e);
}
finally {
unguard();
}
}
{code}
ideally it's the best place to trigger the event, but if we trigger the event
here, seems we can not get by which means this event is triggered(api, rest,
mbean visitorcommand or auto).
is my understanding correct? Thank you very much!
> Add cluster (de)activation events
> -
>
> Key: IGNITE-8376
> URL: https://issues.apache.org/jira/browse/IGNITE-8376
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexey Goncharuk
>Assignee: kcheng.mvp
>Priority: Major
> Labels: newbie
> Fix For: 2.7
>
>
> Currently, we do not have any way to detect that a cluster got activated,
> which results in busy-loops polling {{cluster().active()}}.
> I suggest to add new events, {{EVT_CLUSTER_ACTIVATED}},
> {{EVT_CLUSTER_DEACTIVATED}}, {{EVT_CLUSTER_ACTIVATION_FAILED}} which will be
> fired when corresponding steps are completed. The event should contain, if
> possible, information about the activation source (public API or
> auto-activation), topology version on which activation was performed. The
> fail event should contain information about the cause of the failure. If
> needed, a new class for this event should be introduced.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8746) EVT_CACHE_REBALANCE_PART_DATA_LOST event received twice on the coordinator node
[ https://issues.apache.org/jira/browse/IGNITE-8746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16529523#comment-16529523 ] Pavel Vinokurov commented on IGNITE-8746: - [~EdShangGG] I attached TC link. There are test results for new test methods (last four) - https://ci.ignite.apache.org/viewLog.html?buildId=1441528=IgniteTests24Java8_Cache5=testsInfo > EVT_CACHE_REBALANCE_PART_DATA_LOST event received twice on the coordinator > node > --- > > Key: IGNITE-8746 > URL: https://issues.apache.org/jira/browse/IGNITE-8746 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.4 >Reporter: Pavel Vinokurov >Assignee: Pavel Vinokurov >Priority: Major > Fix For: 2.7 > > Attachments: EvtDataLostTwiceOnCoordinatorReprocuder.java > > > After a node left the cluster the coordinator recieves the partition lost > event twice. > The reproducer is attached. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8898) rename command argument '--force' to '--yes' for control.sh
[ https://issues.apache.org/jira/browse/IGNITE-8898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16529516#comment-16529516 ] ASF GitHub Bot commented on IGNITE-8898: GitHub user vldpyatkov opened a pull request: https://github.com/apache/ignite/pull/4286 IGNITE-8898 rename command argument '--force' to '--yes' for control.sh You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-8898 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4286.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 #4286 commit d6c3de9e0e18a61286500614f8a8f9414a9ce2a1 Author: vd-pyatkov Date: 2018-06-29T14:50:02Z IGNITE-8898 rename command argument '--force' to '--yes' for control.sh > rename command argument '--force' to '--yes' for control.sh > --- > > Key: IGNITE-8898 > URL: https://issues.apache.org/jira/browse/IGNITE-8898 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.5 >Reporter: Max Shonichev >Assignee: Vladislav Pyatkov >Priority: Major > > control.sh requires admin to provide `--force` to auto-confirm actions > requiring manual confirmation as deactivation of the grid or setting new > baseline. Semantically, this is not 'forcing', but 'auto-confirmation', so > please, rename `--force` argument of control.sh to `--yes`. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8897) Node with longer BaselineHistory joining the cluster causes cluster stopping
[
https://issues.apache.org/jira/browse/IGNITE-8897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Chugunov updated IGNITE-8897:
Remaining Estimate: 72h
Original Estimate: 72h
> Node with longer BaselineHistory joining the cluster causes cluster stopping
>
>
> Key: IGNITE-8897
> URL: https://issues.apache.org/jira/browse/IGNITE-8897
> Project: Ignite
> Issue Type: Bug
> Components: persistence
>Affects Versions: 2.5
>Reporter: Sergey Chugunov
>Assignee: Sergey Chugunov
>Priority: Critical
> Fix For: 2.7
>
> Original Estimate: 72h
> Remaining Estimate: 72h
>
> There is no array index boundary check in code verifying BaselineHistory on
> new node join so it may end up with ArrayIndexOutOfBoundsException, exception
> stack trace looks like this (failure handler is configured):
> {noformat}
> [org.apache.ignite.Ignite] Critical system error detected. Will be handled
> accordingly to configured handler [hnd=class
> o.a.i.failure.StopNodeOrHaltFailureHandler, failureCtx=FailureContext
> [type=SYSTEM_WORKER_TERMINATION, err=java.lang.IndexOutOfBoundsException:
> Index: 17, Size: 17]]
> java.lang.IndexOutOfBoundsException: Index: 17, Size: 17
> at java.util.ArrayList.rangeCheck(ArrayList.java:653)
> at java.util.ArrayList.get(ArrayList.java:429)
> at
> org.apache.ignite.internal.processors.cluster.BaselineTopologyHistory.isCompatibleWith(BaselineTopologyHistory.java:97)
> at
> org.apache.ignite.internal.processors.cluster.GridClusterStateProcessor.validateNode(GridClusterStateProcessor.java:981)
> at
> org.apache.ignite.internal.managers.GridManagerAdapter$1.validateNode(GridManagerAdapter.java:566)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processJoinRequestMessage(ServerImpl.java:3629)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2736)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2536)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorkerAdapter.body(ServerImpl.java:6775)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.body(ServerImpl.java:2621)
> at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
> {noformat}
> We need to check bltHistory size and if node joins with incorrect bltHistory
> we should refuse the join.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8746) EVT_CACHE_REBALANCE_PART_DATA_LOST event received twice on the coordinator node
[ https://issues.apache.org/jira/browse/IGNITE-8746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16529498#comment-16529498 ] Eduard Shangareev commented on IGNITE-8746: --- [~pvinokurov] Thank you! I have several boring points. Please, change the status the ticket to appropriate state. Did you updated your TC Run All link? And where could we see your test in which TC configuration? > EVT_CACHE_REBALANCE_PART_DATA_LOST event received twice on the coordinator > node > --- > > Key: IGNITE-8746 > URL: https://issues.apache.org/jira/browse/IGNITE-8746 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.4 >Reporter: Pavel Vinokurov >Assignee: Pavel Vinokurov >Priority: Major > Fix For: 2.7 > > Attachments: EvtDataLostTwiceOnCoordinatorReprocuder.java > > > After a node left the cluster the coordinator recieves the partition lost > event twice. > The reproducer is attached. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-8898) rename command argument '--force' to '--yes' for control.sh
[ https://issues.apache.org/jira/browse/IGNITE-8898?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladislav Pyatkov reassigned IGNITE-8898: - Assignee: Vladislav Pyatkov > rename command argument '--force' to '--yes' for control.sh > --- > > Key: IGNITE-8898 > URL: https://issues.apache.org/jira/browse/IGNITE-8898 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.5 >Reporter: Max Shonichev >Assignee: Vladislav Pyatkov >Priority: Major > > control.sh requires admin to provide `--force` to auto-confirm actions > requiring manual confirmation as deactivation of the grid or setting new > baseline. Semantically, this is not 'forcing', but 'auto-confirmation', so > please, rename `--force` argument of control.sh to `--yes`. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8746) EVT_CACHE_REBALANCE_PART_DATA_LOST event received twice on the coordinator node
[ https://issues.apache.org/jira/browse/IGNITE-8746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16529453#comment-16529453 ] Pavel Vinokurov commented on IGNITE-8746: - [~amashenkov][~Jokser][~EdShangGG] I have added a few tests including case of killing two nodes, killing a coordinator and cache with backup partitions. Please review > EVT_CACHE_REBALANCE_PART_DATA_LOST event received twice on the coordinator > node > --- > > Key: IGNITE-8746 > URL: https://issues.apache.org/jira/browse/IGNITE-8746 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.4 >Reporter: Pavel Vinokurov >Assignee: Pavel Vinokurov >Priority: Major > Fix For: 2.7 > > Attachments: EvtDataLostTwiceOnCoordinatorReprocuder.java > > > After a node left the cluster the coordinator recieves the partition lost > event twice. > The reproducer is attached. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
