[jira] [Commented] (IGNITE-13373) WAL segmentns do not released on releaseHistoryForPreloading()
[
https://issues.apache.org/jira/browse/IGNITE-13373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17180874#comment-17180874
]
Ignite TC Bot commented on IGNITE-13373:
{panel:title=Branch: [pull/8165/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/8165/head] Base: [master] : New Tests
(2)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}MVCC PDS 2{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=5553335]]
* {color:#013220}IgnitePdsMvccTestSuite2: WALPreloadingWithCompactionTest.test
- PASSED{color}
{color:#8b}PDS 2{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=5553308]]
* {color:#013220}IgnitePdsTestSuite2: WALPreloadingWithCompactionTest.test -
PASSED{color}
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5553346buildTypeId=IgniteTests24Java8_RunAll]
> WAL segmentns do not released on releaseHistoryForPreloading()
> --
>
> Key: IGNITE-13373
> URL: https://issues.apache.org/jira/browse/IGNITE-13373
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexander Lapin
>Assignee: Alexander Lapin
>Priority: Major
> Fix For: 2.10
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> * Reserve/releaseHistoryForPreloading() was reworked, now we store oldest
> WALPointer that was reserved during reserveHistoryForPreloading in
> reservedForPreloading field. As a result it's possible to release wall
> reservation on releaseHIstoryForPreloading().
> * searchAndReserveCheckpoints() was slightly refactored: now it returns not
> only an earliestValidCheckpoints but also an oldest reservedCheckpoint, so
> that there’s no need to recalculate it within reserveHistoryForExchange().
> *
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13369) .NET: Local node info is not updated on client reconnect
[
https://issues.apache.org/jira/browse/IGNITE-13369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-13369:
Ignite Flags: (was: Release Notes Required)
Release Note: .NET: Fix stale local node info after client reconnect
> .NET: Local node info is not updated on client reconnect
>
>
> Key: IGNITE-13369
> URL: https://issues.apache.org/jira/browse/IGNITE-13369
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 2.8.1
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: .NET
> Fix For: 2.10
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {{Ignite._locNode}} field caches local node information, and this cache info
> is not updated on client reconnect. We should remove cached info on every
> disconnect.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13369) .NET: Local node info is not updated on client reconnect
[
https://issues.apache.org/jira/browse/IGNITE-13369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17180779#comment-17180779
]
Pavel Tupitsyn commented on IGNITE-13369:
-
Merged to master: 3cb71994e4fc22c34337658c3b5c24cb9ac0d7a3
> .NET: Local node info is not updated on client reconnect
>
>
> Key: IGNITE-13369
> URL: https://issues.apache.org/jira/browse/IGNITE-13369
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 2.8.1
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: .NET
> Fix For: 2.10
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {{Ignite._locNode}} field caches local node information, and this cache info
> is not updated on client reconnect. We should remove cached info on every
> disconnect.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13369) .NET: Local node info is not updated on client reconnect
[
https://issues.apache.org/jira/browse/IGNITE-13369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17180626#comment-17180626
]
Ignite TC Bot commented on IGNITE-13369:
{panel:title=Branch: [pull/8166/head] Base: [master] : Possible Blockers
(9)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Cache 5{color} [[tests 0 TIMEOUT , Exit Code , [Artifacts
publishing failed] |https://ci.ignite.apache.org/viewLog.html?buildId=5552937]]
{color:#d04437}MVCC Cache 9{color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=5552976]]
{color:#d04437}Cache 6{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=5552938]]
* IgniteCacheTestSuite6:
TxRollbackOnMapOnInvalidTopologyTest.testRollbackOnMapToInvalidTopology_4 -
Test has low fail rate in base branch 0,0% and is not flaky
{color:#d04437}Cache 1{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=5552933]]
* IgniteBinaryCacheTestSuite: IgniteCommunicationBalanceTest.testRandomBalance
- Test has low fail rate in base branch 0,0% and is not flaky
{color:#d04437}Queries 1{color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=5552960]]
* IgniteBinaryCacheQueryTestSuite:
DynamicIndexServerCoordinatorBasicSelfTest.testCreateIndexWithParallelismPartitionedTransactional
- Test has low fail rate in base branch 1,5% and is not flaky
* IgniteBinaryCacheQueryTestSuite:
IgniteSqlSplitterSelfTest.testReplicatedTablesUsingPartitionedCacheSegmentedClientRO
- Test has low fail rate in base branch 0,0% and is not flaky
{color:#d04437}Data Structures{color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=5552945]]
* IgniteCacheDataStructuresSelfTestSuite:
GridCachePartitionedQueueFailoverDataConsistencySelfTest.testAddFailoverCollocated
- Test has low fail rate in base branch 0,0% and is not flaky
* IgniteCacheDataStructuresSelfTestSuite:
GridCachePartitionedQueueMultiNodeSelfTest.testAddMultinode - Test has low fail
rate in base branch 0,0% and is not flaky
{color:#d04437}Start Nodes{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=5552901]]
* IgniteStartStopRestartTestSuite:
IgniteProjectionStartStopRestartSelfTest.testCustomScript - Test has low fail
rate in base branch 0,0% and is not flaky
{panel}
{panel:title=Branch: [pull/8166/head] Base: [master] : No new tests
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5552989buildTypeId=IgniteTests24Java8_RunAll]
> .NET: Local node info is not updated on client reconnect
>
>
> Key: IGNITE-13369
> URL: https://issues.apache.org/jira/browse/IGNITE-13369
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 2.8.1
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: .NET
> Fix For: 2.10
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {{Ignite._locNode}} field caches local node information, and this cache info
> is not updated on client reconnect. We should remove cached info on every
> disconnect.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13204) Java Thin client Kubernetes discovery
[ https://issues.apache.org/jira/browse/IGNITE-13204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17180607#comment-17180607 ] Maksim Timonin commented on IGNITE-13204: - Hi [~Vladimir Pligin] ! Current status: # Discussed on dev list that the issue can be resolved with just configuring k8s cluster with StatefulSet (as DNS names of nodes aren't changed). But agreed that Ignite should provide opportunity to configure ThinClient within k8s env with the single setting. # I've implementing this setting. Common idea is rather simple but there are some corner cases in the org.apache.ignite.internal.client.thin.ReliableChannel class that should be carefully tested. I'm working on this now and on next week will provide a PR for review. > Java Thin client Kubernetes discovery > - > > Key: IGNITE-13204 > URL: https://issues.apache.org/jira/browse/IGNITE-13204 > Project: Ignite > Issue Type: New Feature > Components: platforms >Reporter: Alexandr >Assignee: Maksim Timonin >Priority: Major > Labels: java > > Thin clients should be able to discover servers from within Kubernetes pod > through k8s API, without specifying any IP addresses. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13376) Primary index can be created with fields sequence differ from declared.
Stanilovsky Evgeny created IGNITE-13376:
---
Summary: Primary index can be created with fields sequence differ
from declared.
Key: IGNITE-13376
URL: https://issues.apache.org/jira/browse/IGNITE-13376
Project: Ignite
Issue Type: Improvement
Components: sql
Affects Versions: 2.8.1, 2.7.6
Reporter: Stanilovsky Evgeny
Assignee: Stanilovsky Evgeny
Steps to reproduce:
Execute the following DDL (create table + create index):
{noformat}
CREATE TABLE IF NOT EXISTS Workspace (
id UUID NOT NULL,
accountId UUID NOT NULL,
jsonModel VARCHAR,
PRIMARY KEY (accountId, id)
) WITH
"template=partitioned,atomicity=transactional,key_type=org.gridgain.gmc.dto.workspace.WorkspaceKey,value_type=workspace.Workspace,cache_name=WorkspaceCache";
CREATE INDEX IF NOT EXISTS workspace_id_account_id_idx ON Workspace (id,
accountId);
{noformat}
On node start got the following warning:
{noformat}
Index with the given set or subset of columns already exists (consider dropping
either new or existing index) [cacheName=WorkspaceCache, schemaName=PUBLIC,
tableName=WORKSPACE, newIndexName=WORKSPACE_ID_ACCOUNT_ID_IDX,
existingIndexName=_key_PK, existingIndexColumns=[ID, ACCOUNTID]]
{noformat}
But PK and index have different order!
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13280) Improper index usage, fields enumeration not used with pk index creation.
[
https://issues.apache.org/jira/browse/IGNITE-13280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17180538#comment-17180538
]
Stanilovsky Evgeny commented on IGNITE-13280:
-
[~tledkov-gridgain] got it ! thanks, now i understand what proxy index is used
for :) TC in progress.
> Improper index usage, fields enumeration not used with pk index creation.
> -
>
> Key: IGNITE-13280
> URL: https://issues.apache.org/jira/browse/IGNITE-13280
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.8.1
>Reporter: Stanilovsky Evgeny
>Assignee: Stanilovsky Evgeny
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> For example:
> {code:java}
> CREATE TABLE PUBLIC.TEST_TABLE (FIRST_NAME VARCHAR, LAST_NAME VARCHAR,
> ADDRESS VARCHAR, LANG VARCHAR, CONSTRAINT PK_PERSON PRIMARY KEY (FIRST_NAME,
> LAST_NAME));
> CREATE INDEX "idx2" ON PUBLIC.TEST_TABLE (LANG, ADDRESS);
> {code}
> and further explain:
> {code:java}
> SELECT
> "__Z0"."FIRST_NAME" AS "__C0_0",
> "__Z0"."LAST_NAME" AS "__C0_1",
> "__Z0"."ADDRESS" AS "__C0_2",
> "__Z0"."LANG" AS "__C0_3"
> FROM "PUBLIC"."TEST_TABLE" "__Z0"
> /* PUBLIC.IDX2: ADDRESS > 0 */
> WHERE "__Z0"."ADDRESS" > 0
> {code}
> this is erroneous to use "idx2" here, because first index field LANG not
> equals to predicate ADDRESS.
> Looks like this bug brings this ticket [1]
> [1] https://issues.apache.org/jira/browse/IGNITE-10217
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-10789) CacheInterceptor on server node get BinaryObject if put was invoked by ClientCache.
[
https://issues.apache.org/jira/browse/IGNITE-10789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17180499#comment-17180499
]
Stanilovsky Evgeny commented on IGNITE-10789:
-
[~ptupitsyn] seems this request\functional need to be correctly documented and
all errors: inner - from grid server side and outer - which would be thrown on
client side. I prepare fix, plz take a look ? TC in progress.
> CacheInterceptor on server node get BinaryObject if put was invoked by
> ClientCache.
> ---
>
> Key: IGNITE-10789
> URL: https://issues.apache.org/jira/browse/IGNITE-10789
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.7
>Reporter: Sergey Antonov
>Assignee: Stanilovsky Evgeny
>Priority: Major
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Cache interceptor on server node expects deserialized object, but gets
> BinaryObject in case of put was from thin client.
> The exception is following:
> {noformat}
> [2018-12-21
> 17:25:08,213][ERROR][client-connector-#53%cache.Test20%][ClientListenerNioListener]
> Failed to process client request
> [req=o.a.i.i.processors.platform.client.cache.ClientCachePutRequest@72009659]
> org.apache.ignite.cache.CachePartialUpdateException: Failed to update keys
> (retry update if possible).: [key]
> at
> org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1313)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.cacheException(IgniteCacheProxyImpl.java:1754)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.put(IgniteCacheProxyImpl.java:1107)
> at
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.put(GatewayProtectedCacheProxy.java:820)
> at
> org.apache.ignite.internal.processors.platform.client.cache.ClientCachePutRequest.process(ClientCachePutRequest.java:40)
> at
> org.apache.ignite.internal.processors.platform.client.ClientRequestHandler.handle(ClientRequestHandler.java:52)
> at
> org.apache.ignite.internal.processors.odbc.ClientListenerNioListener.onMessage(ClientListenerNioListener.java:174)
> at
> org.apache.ignite.internal.processors.odbc.ClientListenerNioListener.onMessage(ClientListenerNioListener.java:48)
> at
> org.apache.ignite.internal.util.nio.GridNioFilterChain$TailFilter.onMessageReceived(GridNioFilterChain.java:279)
> at
> org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedMessageReceived(GridNioFilterAdapter.java:109)
> at
> org.apache.ignite.internal.util.nio.GridNioAsyncNotifyFilter$3.body(GridNioAsyncNotifyFilter.java:97)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> at
> org.apache.ignite.internal.util.worker.GridWorkerPool$1.run(GridWorkerPool.java:70)
> 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)
> Caused by: class
> org.apache.ignite.internal.processors.cache.CachePartialUpdateCheckedException:
> Failed to update keys (retry update if possible).: [key]
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.onPrimaryError(GridNearAtomicAbstractUpdateFuture.java:397)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.onPrimaryResponse(GridNearAtomicSingleUpdateFuture.java:252)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture$1.apply(GridNearAtomicAbstractUpdateFuture.java:304)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture$1.apply(GridNearAtomicAbstractUpdateFuture.java:301)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicAbstractUpdateFuture.map(GridDhtAtomicAbstractUpdateFuture.java:394)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1942)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1671)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.sendSingleRequest(GridNearAtomicAbstractUpdateFuture.java:300)
> at
>
[jira] [Comment Edited] (IGNITE-10789) CacheInterceptor on server node get BinaryObject if put was invoked by ClientCache.
[
https://issues.apache.org/jira/browse/IGNITE-10789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17180499#comment-17180499
]
Stanilovsky Evgeny edited comment on IGNITE-10789 at 8/19/20, 12:17 PM:
[~ptupitsyn] seems this request\functional need to be correctly documented and
all errors: inner - from grid server side and outer - which would be thrown on
client side need to be informative. I prepare fix, plz take a look ? TC in
progress.
was (Author: zstan):
[~ptupitsyn] seems this request\functional need to be correctly documented and
all errors: inner - from grid server side and outer - which would be thrown on
client side. I prepare fix, plz take a look ? TC in progress.
> CacheInterceptor on server node get BinaryObject if put was invoked by
> ClientCache.
> ---
>
> Key: IGNITE-10789
> URL: https://issues.apache.org/jira/browse/IGNITE-10789
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.7
>Reporter: Sergey Antonov
>Assignee: Stanilovsky Evgeny
>Priority: Major
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Cache interceptor on server node expects deserialized object, but gets
> BinaryObject in case of put was from thin client.
> The exception is following:
> {noformat}
> [2018-12-21
> 17:25:08,213][ERROR][client-connector-#53%cache.Test20%][ClientListenerNioListener]
> Failed to process client request
> [req=o.a.i.i.processors.platform.client.cache.ClientCachePutRequest@72009659]
> org.apache.ignite.cache.CachePartialUpdateException: Failed to update keys
> (retry update if possible).: [key]
> at
> org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1313)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.cacheException(IgniteCacheProxyImpl.java:1754)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.put(IgniteCacheProxyImpl.java:1107)
> at
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.put(GatewayProtectedCacheProxy.java:820)
> at
> org.apache.ignite.internal.processors.platform.client.cache.ClientCachePutRequest.process(ClientCachePutRequest.java:40)
> at
> org.apache.ignite.internal.processors.platform.client.ClientRequestHandler.handle(ClientRequestHandler.java:52)
> at
> org.apache.ignite.internal.processors.odbc.ClientListenerNioListener.onMessage(ClientListenerNioListener.java:174)
> at
> org.apache.ignite.internal.processors.odbc.ClientListenerNioListener.onMessage(ClientListenerNioListener.java:48)
> at
> org.apache.ignite.internal.util.nio.GridNioFilterChain$TailFilter.onMessageReceived(GridNioFilterChain.java:279)
> at
> org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedMessageReceived(GridNioFilterAdapter.java:109)
> at
> org.apache.ignite.internal.util.nio.GridNioAsyncNotifyFilter$3.body(GridNioAsyncNotifyFilter.java:97)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> at
> org.apache.ignite.internal.util.worker.GridWorkerPool$1.run(GridWorkerPool.java:70)
> 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)
> Caused by: class
> org.apache.ignite.internal.processors.cache.CachePartialUpdateCheckedException:
> Failed to update keys (retry update if possible).: [key]
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.onPrimaryError(GridNearAtomicAbstractUpdateFuture.java:397)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.onPrimaryResponse(GridNearAtomicSingleUpdateFuture.java:252)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture$1.apply(GridNearAtomicAbstractUpdateFuture.java:304)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture$1.apply(GridNearAtomicAbstractUpdateFuture.java:301)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicAbstractUpdateFuture.map(GridDhtAtomicAbstractUpdateFuture.java:394)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1942)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1671)
> at
[jira] [Created] (IGNITE-13375) Operations started on client nodes are not traced.
Alexander Lapin created IGNITE-13375: Summary: Operations started on client nodes are not traced. Key: IGNITE-13375 URL: https://issues.apache.org/jira/browse/IGNITE-13375 Project: Ignite Issue Type: Bug Reporter: Alexander Lapin Assignee: Alexander Lapin Fix For: 2.10 Root spans should be created on client node like it’s done on server node. I suppose that to already existent node join span creation we should add: * addMessage * node stop * custom event -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Issue Comment Deleted] (IGNITE-13369) .NET: Local node info is not updated on client reconnect
[
https://issues.apache.org/jira/browse/IGNITE-13369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-13369:
Comment: was deleted
(was: {panel:title=Branch: [pull/8166/head] Base: [master] : Possible Blockers
(116)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}MVCC Cache 7{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5552694]]
{color:#d04437}Cache (Restarts) 1{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5552650]]
{color:#d04437}Platform .NET (Long Running){color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5552678]]
{color:#d04437}SPI{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5552622]]
{color:#d04437}Cache 2{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5552654]]
{color:#d04437}Cache 7{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5552659]]
{color:#d04437}Cache 5{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5552657]]
{color:#d04437}Queries 2{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5552617]]
{color:#d04437}Cache (Failover) 2{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5552646]]
{color:#d04437}Continuous Query 4{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5552664]]
{color:#d04437}Control Utility (Zookeeper){color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5552708]]
{color:#d04437}MVCC Cache 9{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5552696]]
{color:#d04437}PDS 3{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5552672]]
{color:#d04437}ZooKeeper (Discovery) 1{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5552629]]
{color:#d04437}Cache (Expiry Policy){color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5552643]]
{color:#d04437}JCache TCK 1.1{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5552635]]
{color:#d04437}ZooKeeper (Discovery) 4{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5552683]]
{color:#d04437}Cache 6{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5552658]]
{color:#d04437}Platform .NET (Core Linux){color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5552675]]
{color:#d04437}MVCC Queries{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5552638]]
{color:#d04437}Cache 1{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5552653]]
{color:#d04437}PDS 1{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5552670]]
{color:#d04437}JDBC Driver{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5552614]]
{color:#d04437}Queries 1{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5552680]]
{color:#d04437}Control Utility{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5552707]]
{color:#d04437}Streamers{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5552620]]
{color:#d04437}MVCC PDS 4{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5552700]]
{color:#d04437}Compute (Grid){color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5552600]]
{color:#d04437}~Build Apache Ignite~{color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=5552591]]
{color:#d04437}Examples{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5552603]]
{color:#d04437}MVCC PDS 2{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5552698]]
{color:#d04437}MVCC Cache 1{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5552688]]
{color:#d04437}Cache 9{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5552661]]
{color:#d04437}ZooKeeper (Discovery) 3{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5552682]]
{color:#d04437}Basic 1{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5552633]]
{color:#d04437}Cache 8{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5552660]]
{color:#d04437}Continuous Query 3{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5552663]]
{color:#d04437}PDS 4{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5552673]]
{color:#d04437}Scala (Examples){color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5552627]]
[jira] [Commented] (IGNITE-13367) meta --remove command usage improvements
[
https://issues.apache.org/jira/browse/IGNITE-13367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17180492#comment-17180492
]
Ignite TC Bot commented on IGNITE-13367:
{panel:title=Branch: [pull/8162/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/8162/head] Base: [master] : New Tests
(2)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Control Utility{color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=5550045]]
* {color:#013220}IgniteControlUtilityTestSuite:
GridCommandHandlerMetadataTest.testMetadataRemoveWrongType - PASSED{color}
* {color:#013220}IgniteControlUtilityTestSuite:
GridCommandHandlerMetadataTest.testMetadataForInternalClassesIsNotRegistered -
PASSED{color}
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5550047buildTypeId=IgniteTests24Java8_RunAll]
> meta --remove command usage improvements
>
>
> Key: IGNITE-13367
> URL: https://issues.apache.org/jira/browse/IGNITE-13367
> Project: Ignite
> Issue Type: Improvement
>Reporter: Sergey Chugunov
>Assignee: Sergey Chugunov
>Priority: Major
> Fix For: 2.10
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Command for removing metadata has the following issues:
> # In 'Type not found' scenario it prints long stack traces to console instead
> of short information about requested type.
> # When used it registers some internal classes which are not supposed to go
> through binary metadata registration protocol.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13328) Control.sh bash script swallow return code of CommandHandler and always return 0
[
https://issues.apache.org/jira/browse/IGNITE-13328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17180493#comment-17180493
]
Ivan Daschinskiy commented on IGNITE-13328:
---
[~vveider] [~agura] I strongly believe that we should revert changes also for
ignitevisorcmd and sqline. While I understand the initial concerns about
ignite.sh, but as for these utils, I simply do not. Can you explain why
swallowing potential problems costs less than hypothetical problems with almost
zero probability.
> Control.sh bash script swallow return code of CommandHandler and always
> return 0
>
>
> Key: IGNITE-13328
> URL: https://issues.apache.org/jira/browse/IGNITE-13328
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.8, 2.8.1
>Reporter: Ivan Daschinskiy
>Assignee: Ivan Daschinskiy
>Priority: Blocker
> Fix For: 2.9
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> After merging
> [IGNITE-12367|https://issues.apache.org/jira/browse/IGNITE-12367],
> control.sh always return 0, despite the fact that CommandHandler returns
> correct code.
> For example:
> Ignite 2.8.1
> {code}
> Failed to execute baseline command='collect'
> Latest topology update failed.
> Connection to cluster failed. Latest topology update failed.
> Command [BASELINE] finished with code: 2
> Control utility has completed execution at: 2020-08-05T15:01:34.123
> Execution time: 26627 ms
> >>> echo $?
> 0
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-13368) Speed base throttling unexpectedly degraded to zero
[ https://issues.apache.org/jira/browse/IGNITE-13368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17180457#comment-17180457 ] Sergey Chugunov edited comment on IGNITE-13368 at 8/19/20, 11:13 AM: - [~zstan], it is exactly what Anton fixed, thanks for bringing it in. [~akalashnikov], I merged the fix, looks like we spotted serious bug, thank you for your attentiveness! Merged to master in commit *3ee23000b581e00bab5da3582780c9204a6b238d*. was (Author: sergeychugunov): [~zstan], it is exactly what Anton fixed, thanks for bringing it in. [~akalashnikov], I merged the fix, looks like we spotted serious bug, thank you for your attention! Merged to master in commit *3ee23000b581e00bab5da3582780c9204a6b238d*. > Speed base throttling unexpectedly degraded to zero > --- > > Key: IGNITE-13368 > URL: https://issues.apache.org/jira/browse/IGNITE-13368 > Project: Ignite > Issue Type: Bug >Reporter: Anton Kalashnikov >Assignee: Anton Kalashnikov >Priority: Major > Fix For: 2.10 > > Time Spent: 20m > Remaining Estimate: 0h > > New test failure in master PagesWriteThrottleSmokeTest.testThrottle > https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=2808794487465215609=%3Cdefault%3E=testDetails > Throttling degraded to zero. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13368) Speed base throttling unexpectedly degraded to zero
[ https://issues.apache.org/jira/browse/IGNITE-13368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17180457#comment-17180457 ] Sergey Chugunov commented on IGNITE-13368: -- [~zstan], it is exactly what Anton fixed, thanks for bringing it in. [~akalashnikov], I merged the fix, looks like we spotted serious bug, thank you for your attention! Merged to master in commit *3ee23000b581e00bab5da3582780c9204a6b238d*. > Speed base throttling unexpectedly degraded to zero > --- > > Key: IGNITE-13368 > URL: https://issues.apache.org/jira/browse/IGNITE-13368 > Project: Ignite > Issue Type: Bug >Reporter: Anton Kalashnikov >Assignee: Anton Kalashnikov >Priority: Major > Fix For: 2.10 > > Time Spent: 20m > Remaining Estimate: 0h > > New test failure in master PagesWriteThrottleSmokeTest.testThrottle > https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=2808794487465215609=%3Cdefault%3E=testDetails > Throttling degraded to zero. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13368) Speed base throttling unexpectedly degraded to zero
[ https://issues.apache.org/jira/browse/IGNITE-13368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Chugunov updated IGNITE-13368: - Ignite Flags: (was: Docs Required,Release Notes Required) > Speed base throttling unexpectedly degraded to zero > --- > > Key: IGNITE-13368 > URL: https://issues.apache.org/jira/browse/IGNITE-13368 > Project: Ignite > Issue Type: Bug >Reporter: Anton Kalashnikov >Assignee: Anton Kalashnikov >Priority: Major > Fix For: 2.10 > > Time Spent: 10m > Remaining Estimate: 0h > > New test failure in master PagesWriteThrottleSmokeTest.testThrottle > https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=2808794487465215609=%3Cdefault%3E=testDetails > Throttling degraded to zero. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13368) Speed base throttling unexpectedly degraded to zero
[ https://issues.apache.org/jira/browse/IGNITE-13368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17180451#comment-17180451 ] Stanilovsky Evgeny commented on IGNITE-13368: - may be something like it ? https://github.com/apache/ignite/commit/3f54fe046385ac771dd949d819daae0f792b1370 > Speed base throttling unexpectedly degraded to zero > --- > > Key: IGNITE-13368 > URL: https://issues.apache.org/jira/browse/IGNITE-13368 > Project: Ignite > Issue Type: Bug >Reporter: Anton Kalashnikov >Assignee: Anton Kalashnikov >Priority: Major > Fix For: 2.10 > > Time Spent: 10m > Remaining Estimate: 0h > > New test failure in master PagesWriteThrottleSmokeTest.testThrottle > https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=2808794487465215609=%3Cdefault%3E=testDetails > Throttling degraded to zero. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13368) Speed base throttling unexpectedly degraded to zero
[ https://issues.apache.org/jira/browse/IGNITE-13368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Chugunov updated IGNITE-13368: - Fix Version/s: 2.10 > Speed base throttling unexpectedly degraded to zero > --- > > Key: IGNITE-13368 > URL: https://issues.apache.org/jira/browse/IGNITE-13368 > Project: Ignite > Issue Type: Bug >Reporter: Anton Kalashnikov >Assignee: Anton Kalashnikov >Priority: Major > Fix For: 2.10 > > Time Spent: 10m > Remaining Estimate: 0h > > New test failure in master PagesWriteThrottleSmokeTest.testThrottle > https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=2808794487465215609=%3Cdefault%3E=testDetails > Throttling degraded to zero. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13370) Missed README.txt in ignite-control-utility module
[ https://issues.apache.org/jira/browse/IGNITE-13370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17180441#comment-17180441 ] Sergey Chugunov commented on IGNITE-13370: -- [~ktkale...@gridgain.com], I merged the patch to master under commit *6ca1944d2cb6c2b670a10a06b12a83c470061a91*. Thank you for this contribution to our documentation! > Missed README.txt in ignite-control-utility module > -- > > Key: IGNITE-13370 > URL: https://issues.apache.org/jira/browse/IGNITE-13370 > Project: Ignite > Issue Type: Improvement > Components: control.sh >Reporter: Kirill Tkalenko >Assignee: Kirill Tkalenko >Priority: Major > Fix For: 2.10 > > Time Spent: 20m > Remaining Estimate: 0h > > Missed README.txt in ignite-control-utility module -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (IGNITE-10331) Document Disk page compression
[ https://issues.apache.org/jira/browse/IGNITE-10331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Artem Budnikov resolved IGNITE-10331. - Resolution: Fixed > Document Disk page compression > -- > > Key: IGNITE-10331 > URL: https://issues.apache.org/jira/browse/IGNITE-10331 > Project: Ignite > Issue Type: New Feature > Components: documentation >Reporter: Sergei Vladykin >Priority: Blocker > Fix For: 2.9 > > > There is an email thread titled "Disk page compression for Ignite persistent > store" -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-10331) Document Disk page compression
[ https://issues.apache.org/jira/browse/IGNITE-10331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17180439#comment-17180439 ] Artem Budnikov commented on IGNITE-10331: - This was fixed in 2.8. https://apacheignite.readme.io/docs/disk-page-compression > Document Disk page compression > -- > > Key: IGNITE-10331 > URL: https://issues.apache.org/jira/browse/IGNITE-10331 > Project: Ignite > Issue Type: New Feature > Components: documentation >Reporter: Sergei Vladykin >Priority: Blocker > Fix For: 2.9 > > > There is an email thread titled "Disk page compression for Ignite persistent > store" -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13369) .NET: Local node info is not updated on client reconnect
[
https://issues.apache.org/jira/browse/IGNITE-13369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17180437#comment-17180437
]
Alexandr Shapkin commented on IGNITE-13369:
---
[~ptupitsyn] LGTM
> .NET: Local node info is not updated on client reconnect
>
>
> Key: IGNITE-13369
> URL: https://issues.apache.org/jira/browse/IGNITE-13369
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 2.8.1
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: .NET
> Fix For: 2.10
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {{Ignite._locNode}} field caches local node information, and this cache info
> is not updated on client reconnect. We should remove cached info on every
> disconnect.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13369) .NET: Local node info is not updated on client reconnect
[
https://issues.apache.org/jira/browse/IGNITE-13369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17180428#comment-17180428
]
Ignite TC Bot commented on IGNITE-13369:
{panel:title=Branch: [pull/8166/head] Base: [master] : Possible Blockers
(116)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}MVCC Cache 7{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5552694]]
{color:#d04437}Cache (Restarts) 1{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5552650]]
{color:#d04437}Platform .NET (Long Running){color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5552678]]
{color:#d04437}SPI{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5552622]]
{color:#d04437}Cache 2{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5552654]]
{color:#d04437}Cache 7{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5552659]]
{color:#d04437}Cache 5{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5552657]]
{color:#d04437}Queries 2{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5552617]]
{color:#d04437}Cache (Failover) 2{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5552646]]
{color:#d04437}Continuous Query 4{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5552664]]
{color:#d04437}Control Utility (Zookeeper){color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5552708]]
{color:#d04437}MVCC Cache 9{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5552696]]
{color:#d04437}PDS 3{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5552672]]
{color:#d04437}ZooKeeper (Discovery) 1{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5552629]]
{color:#d04437}Cache (Expiry Policy){color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5552643]]
{color:#d04437}JCache TCK 1.1{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5552635]]
{color:#d04437}ZooKeeper (Discovery) 4{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5552683]]
{color:#d04437}Cache 6{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5552658]]
{color:#d04437}Platform .NET (Core Linux){color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5552675]]
{color:#d04437}MVCC Queries{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5552638]]
{color:#d04437}Cache 1{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5552653]]
{color:#d04437}PDS 1{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5552670]]
{color:#d04437}JDBC Driver{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5552614]]
{color:#d04437}Queries 1{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5552680]]
{color:#d04437}Control Utility{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5552707]]
{color:#d04437}Streamers{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5552620]]
{color:#d04437}MVCC PDS 4{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5552700]]
{color:#d04437}Compute (Grid){color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5552600]]
{color:#d04437}~Build Apache Ignite~{color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=5552591]]
{color:#d04437}Examples{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5552603]]
{color:#d04437}MVCC PDS 2{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5552698]]
{color:#d04437}MVCC Cache 1{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5552688]]
{color:#d04437}Cache 9{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5552661]]
{color:#d04437}ZooKeeper (Discovery) 3{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5552682]]
{color:#d04437}Basic 1{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5552633]]
{color:#d04437}Cache 8{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5552660]]
{color:#d04437}Continuous Query 3{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5552663]]
{color:#d04437}PDS 4{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5552673]]
{color:#d04437}Scala (Examples){color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5552627]]
[jira] [Updated] (IGNITE-13361) Sending of communication messages can hang infinitely.
[
https://issues.apache.org/jira/browse/IGNITE-13361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Petrov updated IGNITE-13361:
Summary: Sending of communication messages can hang infinitely. (was:
Sending of the communication messages can hang infinitely.)
> Sending of communication messages can hang infinitely.
> --
>
> Key: IGNITE-13361
> URL: https://issues.apache.org/jira/browse/IGNITE-13361
> Project: Ignite
> Issue Type: Bug
>Reporter: Mikhail Petrov
>Assignee: Mikhail Petrov
>Priority: Major
>
> The following test hangs intermittently (once for 4-5 runs) on my laptop
> (Ubuntu 20.04, i7-8565u, 16gb RAM, JDK 1.8.0_251). The cursor iteration
> randomly hangs on the stage of waiting for the next page from the remote node.
> {code:java}
> /** */
> public static final int NODES_CNT = 2;
> /** */
> public static final int TABLE_POPULATION = 2000;
> /** */
> public static final int SELECT_RANGE = 1000;
> /** */
> public static final int QRY_PAGE_SIZE = 5;
> /** */
> @Test
> public void test() throws Exception {
> for (int i = 0; i < NODES_CNT; i++)
> startGrid(i, false);
> IgniteEx cli = startGrid(NODES_CNT, true);
> GridQueryProcessor qryProc = cli.context().query();
> qryProc.querySqlFields(
> new SqlFieldsQuery("CREATE TABLE test_table (id LONG PRIMARY KEY,
> val LONG)"), false);
> qryProc.querySqlFields(new SqlFieldsQuery("CREATE INDEX val_idx ON
> test_table (val)"), false);
> for (long l = 0; l < TABLE_POPULATION; ++l) {
> qryProc.querySqlFields(
> new SqlFieldsQuery("INSERT INTO test_table (id, val) VALUES
> (?, ?)").setArgs(l, l),
> true
> );
> }
> for (int i = 0; i < 1 ; i++) {
> long lowId =
> ThreadLocalRandom.current().nextLong(TABLE_POPULATION - SELECT_RANGE);
> long highId = lowId + SELECT_RANGE;
> try (
> FieldsQueryCursor> cursor = cli
> .context().query().querySqlFields(
> new SqlFieldsQuery("SELECT id, val FROM test_table
> WHERE id BETWEEN ? and ?")
> .setArgs(lowId, highId)
> .setPageSize(QRY_PAGE_SIZE),
> false
> )
> ) {
> cursor.iterator().forEachRemaining(val -> {});
> }
> }
> }
> /** */
> private IgniteEx startGrid(int idx, boolean clientMode) throws Exception {
> return (IgniteEx) Ignition.start(new IgniteConfiguration()
> .setIgniteInstanceName("node-" + idx)
> .setGridLogger(new
> Log4JLogger("modules/core/src/test/config/log4j-test.xml"))
> .setClientMode(clientMode));
> }
> {code}
> UPD It seems that IGNITE-12845 is responsible for the behavior described
> above. Commit which is related to this ticket is the first since which the
> code mentioned above started to hang.
> Cursor iteration hangs due to GridQueryNextPageRequest in some cases are not
> sent correctly from the client node.
> UPD Simplified reproducer of the problem described above:
> {code:java}
> @Test
> public void test() throws Exception {
> IgniteEx srv = startGrid(0);
> IgniteEx cli = startClientGrid(1);
> GridQueryNextPageRequest msg = new GridQueryNextPageRequest(0, 0, 0,
> 0, (byte)0);
> CyclicBarrier barrier = new CyclicBarrier(2);
> srv.context().io().addMessageListener(GridTopic.TOPIC_QUERY, new
> GridMessageListener() {
> @Override public void onMessage(UUID nodeId, Object msg, byte
> plc) {
> try {
> if (msg instanceof GridQueryNextPageRequest)
> barrier.await();
> }
> catch (InterruptedException | BrokenBarrierException e) {
> throw new RuntimeException(e);
> }
> }
> });
> for (int i = 0; i < 1000; i++) {
> barrier.reset();
>
> cli.context().io().sendToGridTopic(srv.context().discovery().localNode(),
> GridTopic.TOPIC_QUERY, msg, GridIoPolicy.QUERY_POOL);
> try {
> barrier.await(1, TimeUnit.SECONDS);
> }
> catch (InterruptedException | BrokenBarrierException |
> TimeoutException e) {
> fail();
> }
> }
> }
> {code}
> The root cause of the hanging is lack of synchronization between
> org.apache.ignite.internal.util.nio.GridNioServer#stopPollingForWrite and
> org.apache.ignite.internal.util.nio.GridNioServer#send0 methods. The
> following situation is
[jira] [Updated] (IGNITE-13361) Sending of the communication messages can hang infinitely.
[
https://issues.apache.org/jira/browse/IGNITE-13361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Petrov updated IGNITE-13361:
Summary: Sending of the communication messages can hang infinitely. (was:
SQL Select query hangs during cursor iteration.)
> Sending of the communication messages can hang infinitely.
> --
>
> Key: IGNITE-13361
> URL: https://issues.apache.org/jira/browse/IGNITE-13361
> Project: Ignite
> Issue Type: Bug
>Reporter: Mikhail Petrov
>Assignee: Mikhail Petrov
>Priority: Major
>
> The following test hangs intermittently (once for 4-5 runs) on my laptop
> (Ubuntu 20.04, i7-8565u, 16gb RAM, JDK 1.8.0_251). The cursor iteration
> randomly hangs on the stage of waiting for the next page from the remote node.
> {code:java}
> /** */
> public static final int NODES_CNT = 2;
> /** */
> public static final int TABLE_POPULATION = 2000;
> /** */
> public static final int SELECT_RANGE = 1000;
> /** */
> public static final int QRY_PAGE_SIZE = 5;
> /** */
> @Test
> public void test() throws Exception {
> for (int i = 0; i < NODES_CNT; i++)
> startGrid(i, false);
> IgniteEx cli = startGrid(NODES_CNT, true);
> GridQueryProcessor qryProc = cli.context().query();
> qryProc.querySqlFields(
> new SqlFieldsQuery("CREATE TABLE test_table (id LONG PRIMARY KEY,
> val LONG)"), false);
> qryProc.querySqlFields(new SqlFieldsQuery("CREATE INDEX val_idx ON
> test_table (val)"), false);
> for (long l = 0; l < TABLE_POPULATION; ++l) {
> qryProc.querySqlFields(
> new SqlFieldsQuery("INSERT INTO test_table (id, val) VALUES
> (?, ?)").setArgs(l, l),
> true
> );
> }
> for (int i = 0; i < 1 ; i++) {
> long lowId =
> ThreadLocalRandom.current().nextLong(TABLE_POPULATION - SELECT_RANGE);
> long highId = lowId + SELECT_RANGE;
> try (
> FieldsQueryCursor> cursor = cli
> .context().query().querySqlFields(
> new SqlFieldsQuery("SELECT id, val FROM test_table
> WHERE id BETWEEN ? and ?")
> .setArgs(lowId, highId)
> .setPageSize(QRY_PAGE_SIZE),
> false
> )
> ) {
> cursor.iterator().forEachRemaining(val -> {});
> }
> }
> }
> /** */
> private IgniteEx startGrid(int idx, boolean clientMode) throws Exception {
> return (IgniteEx) Ignition.start(new IgniteConfiguration()
> .setIgniteInstanceName("node-" + idx)
> .setGridLogger(new
> Log4JLogger("modules/core/src/test/config/log4j-test.xml"))
> .setClientMode(clientMode));
> }
> {code}
> UPD It seems that IGNITE-12845 is responsible for the behavior described
> above. Commit which is related to this ticket is the first since which the
> code mentioned above started to hang.
> Cursor iteration hangs due to GridQueryNextPageRequest in some cases are not
> sent correctly from the client node.
> UPD Simplified reproducer of the problem described above:
> {code:java}
> @Test
> public void test() throws Exception {
> IgniteEx srv = startGrid(0);
> IgniteEx cli = startClientGrid(1);
> GridQueryNextPageRequest msg = new GridQueryNextPageRequest(0, 0, 0,
> 0, (byte)0);
> CyclicBarrier barrier = new CyclicBarrier(2);
> srv.context().io().addMessageListener(GridTopic.TOPIC_QUERY, new
> GridMessageListener() {
> @Override public void onMessage(UUID nodeId, Object msg, byte
> plc) {
> try {
> if (msg instanceof GridQueryNextPageRequest)
> barrier.await();
> }
> catch (InterruptedException | BrokenBarrierException e) {
> throw new RuntimeException(e);
> }
> }
> });
> for (int i = 0; i < 1000; i++) {
> barrier.reset();
>
> cli.context().io().sendToGridTopic(srv.context().discovery().localNode(),
> GridTopic.TOPIC_QUERY, msg, GridIoPolicy.QUERY_POOL);
> try {
> barrier.await(1, TimeUnit.SECONDS);
> }
> catch (InterruptedException | BrokenBarrierException |
> TimeoutException e) {
> fail();
> }
> }
> }
> {code}
> The root cause of the hanging is lack of synchronization between
> org.apache.ignite.internal.util.nio.GridNioServer#stopPollingForWrite and
> org.apache.ignite.internal.util.nio.GridNioServer#send0 methods. The
> following situation is
[jira] [Updated] (IGNITE-13361) SQL Select query hangs during cursor iteration.
[
https://issues.apache.org/jira/browse/IGNITE-13361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Petrov updated IGNITE-13361:
Description:
The following test hangs intermittently (once for 4-5 runs) on my laptop
(Ubuntu 20.04, i7-8565u, 16gb RAM, JDK 1.8.0_251). The cursor iteration
randomly hangs on the stage of waiting for the next page from the remote node.
{code:java}
/** */
public static final int NODES_CNT = 2;
/** */
public static final int TABLE_POPULATION = 2000;
/** */
public static final int SELECT_RANGE = 1000;
/** */
public static final int QRY_PAGE_SIZE = 5;
/** */
@Test
public void test() throws Exception {
for (int i = 0; i < NODES_CNT; i++)
startGrid(i, false);
IgniteEx cli = startGrid(NODES_CNT, true);
GridQueryProcessor qryProc = cli.context().query();
qryProc.querySqlFields(
new SqlFieldsQuery("CREATE TABLE test_table (id LONG PRIMARY KEY,
val LONG)"), false);
qryProc.querySqlFields(new SqlFieldsQuery("CREATE INDEX val_idx ON
test_table (val)"), false);
for (long l = 0; l < TABLE_POPULATION; ++l) {
qryProc.querySqlFields(
new SqlFieldsQuery("INSERT INTO test_table (id, val) VALUES (?,
?)").setArgs(l, l),
true
);
}
for (int i = 0; i < 1 ; i++) {
long lowId = ThreadLocalRandom.current().nextLong(TABLE_POPULATION
- SELECT_RANGE);
long highId = lowId + SELECT_RANGE;
try (
FieldsQueryCursor> cursor = cli
.context().query().querySqlFields(
new SqlFieldsQuery("SELECT id, val FROM test_table
WHERE id BETWEEN ? and ?")
.setArgs(lowId, highId)
.setPageSize(QRY_PAGE_SIZE),
false
)
) {
cursor.iterator().forEachRemaining(val -> {});
}
}
}
/** */
private IgniteEx startGrid(int idx, boolean clientMode) throws Exception {
return (IgniteEx) Ignition.start(new IgniteConfiguration()
.setIgniteInstanceName("node-" + idx)
.setGridLogger(new
Log4JLogger("modules/core/src/test/config/log4j-test.xml"))
.setClientMode(clientMode));
}
{code}
UPD It seems that IGNITE-12845 is responsible for the behavior described above.
Commit which is related to this ticket is the first since which the code
mentioned above started to hang.
Cursor iteration hangs due to GridQueryNextPageRequest in some cases are not
sent correctly from the client node.
UPD Simplified reproducer of the problem described above:
{code:java}
@Test
public void test() throws Exception {
IgniteEx srv = startGrid(0);
IgniteEx cli = startClientGrid(1);
GridQueryNextPageRequest msg = new GridQueryNextPageRequest(0, 0, 0, 0,
(byte)0);
CyclicBarrier barrier = new CyclicBarrier(2);
srv.context().io().addMessageListener(GridTopic.TOPIC_QUERY, new
GridMessageListener() {
@Override public void onMessage(UUID nodeId, Object msg, byte plc) {
try {
if (msg instanceof GridQueryNextPageRequest)
barrier.await();
}
catch (InterruptedException | BrokenBarrierException e) {
throw new RuntimeException(e);
}
}
});
for (int i = 0; i < 1000; i++) {
barrier.reset();
cli.context().io().sendToGridTopic(srv.context().discovery().localNode(),
GridTopic.TOPIC_QUERY, msg, GridIoPolicy.QUERY_POOL);
try {
barrier.await(1, TimeUnit.SECONDS);
}
catch (InterruptedException | BrokenBarrierException |
TimeoutException e) {
fail();
}
}
}
{code}
The root cause of the hanging is lack of synchronization between
org.apache.ignite.internal.util.nio.GridNioServer#stopPollingForWrite and
org.apache.ignite.internal.util.nio.GridNioServer#send0 methods. The following
situation is possible:
1. In stopPollingForWrite method we check the the queue is empty:
{code:java}
if (ses.writeQueue().isEmpty()) {
{code}
from worker thread. And this condition appears true.
2. Message sender thread calls send0 method and it returns.
org.apache.ignite.internal.util.nio.GridSelectorNioSessionImpl#procWrite was
not set to false yet, so sending message isn't added to worker queue due to:
{code:java}
else if (!ses.procWrite.get() && ses.procWrite.compareAndSet(false, true)) {
{code}
3. Worker thread continues stopPollingForWrite execution and sets procWrite
flag to false, which means that socket write events are no longer listened.
So the message remains unsent.
[jira] [Updated] (IGNITE-13361) SQL Select query hangs during cursor iteration.
[
https://issues.apache.org/jira/browse/IGNITE-13361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Petrov updated IGNITE-13361:
Description:
The following test hangs intermittently (once for 4-5 runs) on my laptop
(Ubuntu 20.04, i7-8565u, 16gb RAM, JDK 1.8.0_251). The cursor iteration
randomly hangs on the stage of waiting for the next page from the remote node.
{code:java}
/** */
public static final int NODES_CNT = 2;
/** */
public static final int TABLE_POPULATION = 2000;
/** */
public static final int SELECT_RANGE = 1000;
/** */
public static final int QRY_PAGE_SIZE = 5;
/** */
@Test
public void test() throws Exception {
for (int i = 0; i < NODES_CNT; i++)
startGrid(i, false);
IgniteEx cli = startGrid(NODES_CNT, true);
GridQueryProcessor qryProc = cli.context().query();
qryProc.querySqlFields(
new SqlFieldsQuery("CREATE TABLE test_table (id LONG PRIMARY KEY,
val LONG)"), false);
qryProc.querySqlFields(new SqlFieldsQuery("CREATE INDEX val_idx ON
test_table (val)"), false);
for (long l = 0; l < TABLE_POPULATION; ++l) {
qryProc.querySqlFields(
new SqlFieldsQuery("INSERT INTO test_table (id, val) VALUES (?,
?)").setArgs(l, l),
true
);
}
for (int i = 0; i < 1 ; i++) {
long lowId = ThreadLocalRandom.current().nextLong(TABLE_POPULATION
- SELECT_RANGE);
long highId = lowId + SELECT_RANGE;
try (
FieldsQueryCursor> cursor = cli
.context().query().querySqlFields(
new SqlFieldsQuery("SELECT id, val FROM test_table
WHERE id BETWEEN ? and ?")
.setArgs(lowId, highId)
.setPageSize(QRY_PAGE_SIZE),
false
)
) {
cursor.iterator().forEachRemaining(val -> {});
}
}
}
/** */
private IgniteEx startGrid(int idx, boolean clientMode) throws Exception {
return (IgniteEx) Ignition.start(new IgniteConfiguration()
.setIgniteInstanceName("node-" + idx)
.setGridLogger(new
Log4JLogger("modules/core/src/test/config/log4j-test.xml"))
.setClientMode(clientMode));
}
{code}
UPD It seems that IGNITE-12845 is responsible for the behavior described above.
Commit which is related to this ticket is the first since which the code
mentioned above started to hang.
Cursor iteration hangs due to GridQueryNextPageRequest in some cases are not
sent correctly from the client node.
UPD Simplified reproducer of the problem described above:
{code:java}
@Test
public void test() throws Exception {
IgniteEx srv = startGrid(0);
IgniteEx cli = startClientGrid(1);
GridQueryNextPageRequest msg = new GridQueryNextPageRequest(0, 0, 0, 0,
(byte)0);
CyclicBarrier barrier = new CyclicBarrier(2);
srv.context().io().addMessageListener(GridTopic.TOPIC_QUERY, new
GridMessageListener() {
@Override public void onMessage(UUID nodeId, Object msg, byte plc) {
try {
if (msg instanceof GridQueryNextPageRequest)
barrier.await();
}
catch (InterruptedException | BrokenBarrierException e) {
e.printStackTrace();
}
}
});
for (int i = 0; i < 1000; i++) {
barrier.reset();
cli.context().io().sendToGridTopic(srv.context().discovery().localNode(),
GridTopic.TOPIC_QUERY, msg, GridIoPolicy.QUERY_POOL);
try {
barrier.await(1, TimeUnit.SECONDS);
}
catch (InterruptedException | BrokenBarrierException |
TimeoutException e) {
fail();
}
}
}
{code}
The root cause of the hanging is lack of synchronization between
org.apache.ignite.internal.util.nio.GridNioServer#stopPollingForWrite and
org.apache.ignite.internal.util.nio.GridNioServer#send0 methods. The following
situation is possible:
1. In stopPollingForWrite method we check the the queue is empty:
{code:java}
if (ses.writeQueue().isEmpty()) {
{code}
from worker thread. And this condition appears true.
2. Message sender thread calls send0 method and it returns.
org.apache.ignite.internal.util.nio.GridSelectorNioSessionImpl#procWrite was
not set to false yet, so sending message isn't added to worker queue due to:
{code:java}
else if (!ses.procWrite.get() && ses.procWrite.compareAndSet(false, true)) {
{code}
3. Worker thread continues stopPollingForWrite execution and sets procWrite
flag to false, which means that socket write events are no longer listened.
So the message remains unsent.
was:
The
[jira] [Updated] (IGNITE-13361) SQL Select query hangs during cursor iteration.
[
https://issues.apache.org/jira/browse/IGNITE-13361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Petrov updated IGNITE-13361:
Description:
The following test hangs intermittently (once for 4-5 runs) on my laptop
(Ubuntu 20.04, i7-8565u, 16gb RAM, JDK 1.8.0_251). The cursor iteration
randomly hangs on the stage of waiting for the next page from the remote node.
{code:java}
/** */
public static final int NODES_CNT = 2;
/** */
public static final int TABLE_POPULATION = 2000;
/** */
public static final int SELECT_RANGE = 1000;
/** */
public static final int QRY_PAGE_SIZE = 5;
/** */
@Test
public void test() throws Exception {
for (int i = 0; i < NODES_CNT; i++)
startGrid(i, false);
IgniteEx cli = startGrid(NODES_CNT, true);
GridQueryProcessor qryProc = cli.context().query();
qryProc.querySqlFields(
new SqlFieldsQuery("CREATE TABLE test_table (id LONG PRIMARY KEY,
val LONG)"), false);
qryProc.querySqlFields(new SqlFieldsQuery("CREATE INDEX val_idx ON
test_table (val)"), false);
for (long l = 0; l < TABLE_POPULATION; ++l) {
qryProc.querySqlFields(
new SqlFieldsQuery("INSERT INTO test_table (id, val) VALUES (?,
?)").setArgs(l, l),
true
);
}
for (int i = 0; i < 1 ; i++) {
long lowId = ThreadLocalRandom.current().nextLong(TABLE_POPULATION
- SELECT_RANGE);
long highId = lowId + SELECT_RANGE;
try (
FieldsQueryCursor> cursor = cli
.context().query().querySqlFields(
new SqlFieldsQuery("SELECT id, val FROM test_table
WHERE id BETWEEN ? and ?")
.setArgs(lowId, highId)
.setPageSize(QRY_PAGE_SIZE),
false
)
) {
cursor.iterator().forEachRemaining(val -> {});
}
}
}
/** */
private IgniteEx startGrid(int idx, boolean clientMode) throws Exception {
return (IgniteEx) Ignition.start(new IgniteConfiguration()
.setIgniteInstanceName("node-" + idx)
.setGridLogger(new
Log4JLogger("modules/core/src/test/config/log4j-test.xml"))
.setClientMode(clientMode));
}
{code}
UPD It seems that IGNITE-12845 is responsible for the behavior described above.
Commit which is related to this ticket is the first since which the code
mentioned above started to hang.
Cursor iteration hangs due to GridQueryNextPageRequest in some cases are not
sent correctly from the client node.
UPD Simplified reproducer of the problem described above:
{code:java}
@Test
public void test() throws Exception {
IgniteEx srv = startGrid(0);
IgniteEx cli = startClientGrid(1);
GridQueryNextPageRequest msg = new GridQueryNextPageRequest(0, 0, 0, 0,
(byte)0);
CyclicBarrier barrier = new CyclicBarrier(2);
srv.context().io().addMessageListener(GridTopic.TOPIC_QUERY, new
GridMessageListener() {
@Override public void onMessage(UUID nodeId, Object msg, byte plc) {
try {
if (msg instanceof GridQueryNextPageRequest)
barrier.await();
}
catch (InterruptedException | BrokenBarrierException e) {
e.printStackTrace();
}
}
});
for (int i = 0; i < 1000; i++) {
barrier.reset();
cli.context().io().sendToGridTopic(srv.context().discovery().localNode(),
GridTopic.TOPIC_QUERY, msg, GridIoPolicy.QUERY_POOL);
try {
barrier.await(1, TimeUnit.SECONDS);
}
catch (InterruptedException | BrokenBarrierException |
TimeoutException e) {
fail();
}
}
}
{code}
The root cause of the hanging is lack of synchronization between
org.apache.ignite.internal.util.nio.GridNioServer#stopPollingForWrite and
org.apache.ignite.internal.util.nio.GridNioServer#send0 methods. The following
situation is possible:
1. In stopPollingForWrite method we check the the queue is empty:
{code:java}
if (ses.writeQueue().isEmpty()) {
{code}
from worker thread. And this condition appears true.
2. Message sender thread calls send0 method and it returns.
org.apache.ignite.internal.util.nio.GridSelectorNioSessionImpl#procWrite was
not set to false yet, so sending message isn't added to worker queue due to:
{code:java}
else if (!ses.procWrite.get() && ses.procWrite.compareAndSet(false, true)) {
{code}
3. Worker thread continues stopPollingForWrite execution and sets procWrite
flag to false, which means that socket write events are no longer listened.
was:
The following test hangs intermittently
[jira] [Commented] (IGNITE-13368) Speed base throttling unexpectedly degraded to zero
[ https://issues.apache.org/jira/browse/IGNITE-13368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17180371#comment-17180371 ] Anton Kalashnikov commented on IGNITE-13368: [~sergey-chugunov] can you take a look at it? > Speed base throttling unexpectedly degraded to zero > --- > > Key: IGNITE-13368 > URL: https://issues.apache.org/jira/browse/IGNITE-13368 > Project: Ignite > Issue Type: Bug >Reporter: Anton Kalashnikov >Assignee: Anton Kalashnikov >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > New test failure in master PagesWriteThrottleSmokeTest.testThrottle > https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=2808794487465215609=%3Cdefault%3E=testDetails > Throttling degraded to zero. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13368) Speed base throttling unexpectedly degraded to zero
[
https://issues.apache.org/jira/browse/IGNITE-13368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17180370#comment-17180370
]
Ignite TC Bot commented on IGNITE-13368:
{panel:title=Branch: [pull/8163/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/8163/head] Base: [master] : No new tests
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5550430buildTypeId=IgniteTests24Java8_RunAll]
> Speed base throttling unexpectedly degraded to zero
> ---
>
> Key: IGNITE-13368
> URL: https://issues.apache.org/jira/browse/IGNITE-13368
> Project: Ignite
> Issue Type: Bug
>Reporter: Anton Kalashnikov
>Assignee: Anton Kalashnikov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> New test failure in master PagesWriteThrottleSmokeTest.testThrottle
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=2808794487465215609=%3Cdefault%3E=testDetails
> Throttling degraded to zero.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-13374) Initial PME hangs because of multiple blinking nodes
Alexander Lapin created IGNITE-13374: Summary: Initial PME hangs because of multiple blinking nodes Key: IGNITE-13374 URL: https://issues.apache.org/jira/browse/IGNITE-13374 Project: Ignite Issue Type: Bug Reporter: Alexander Lapin Assignee: Alexander Lapin Fix For: 2.10 *Root cause* of the issue is a race inside GridDhtPartitionsExchangeFuture on client side between two processes: # When old coordinator fails and the new one takes over it sends GridDhtPartitionsSingleRequest messages to all nodes including clients to restore exchange results. Processing this message on client includes updating current coordinator reference (crd field). # When future receives discovery notification about old coordinator failure it should detect change of coordinator and send GridDhtPartitionsSingleMessage to new coordinator to obtain affinity. But updated crd field prevents client from detecting coordinator failure and sending SingleMessage to new coordinator which in turn leads to hanging client. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13373) WAL segmentns do not released on releaseHistoryForPreloading()
[ https://issues.apache.org/jira/browse/IGNITE-13373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin updated IGNITE-13373: - Fix Version/s: 2.10 > WAL segmentns do not released on releaseHistoryForPreloading() > -- > > Key: IGNITE-13373 > URL: https://issues.apache.org/jira/browse/IGNITE-13373 > Project: Ignite > Issue Type: Bug >Reporter: Alexander Lapin >Assignee: Alexander Lapin >Priority: Major > Fix For: 2.10 > > > * Reserve/releaseHistoryForPreloading() was reworked, now we store oldest > WALPointer that was reserved during reserveHistoryForPreloading in > reservedForPreloading field. As a result it's possible to release wall > reservation on releaseHIstoryForPreloading(). > * searchAndReserveCheckpoints() was slightly refactored: now it returns not > only an earliestValidCheckpoints but also an oldest reservedCheckpoint, so > that there’s no need to recalculate it within reserveHistoryForExchange(). > * -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13373) WAL segmentns do not released on releaseHistoryForPreloading()
[ https://issues.apache.org/jira/browse/IGNITE-13373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin updated IGNITE-13373: - Fix Version/s: (was: 2.10) > WAL segmentns do not released on releaseHistoryForPreloading() > -- > > Key: IGNITE-13373 > URL: https://issues.apache.org/jira/browse/IGNITE-13373 > Project: Ignite > Issue Type: Bug >Reporter: Alexander Lapin >Assignee: Alexander Lapin >Priority: Major > > * Reserve/releaseHistoryForPreloading() was reworked, now we store oldest > WALPointer that was reserved during reserveHistoryForPreloading in > reservedForPreloading field. As a result it's possible to release wall > reservation on releaseHIstoryForPreloading(). > * searchAndReserveCheckpoints() was slightly refactored: now it returns not > only an earliestValidCheckpoints but also an oldest reservedCheckpoint, so > that there’s no need to recalculate it within reserveHistoryForExchange(). > * -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13373) WAL segmentns do not released on releaseHistoryForPreloading()
[ https://issues.apache.org/jira/browse/IGNITE-13373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin updated IGNITE-13373: - Fix Version/s: 2.10 > WAL segmentns do not released on releaseHistoryForPreloading() > -- > > Key: IGNITE-13373 > URL: https://issues.apache.org/jira/browse/IGNITE-13373 > Project: Ignite > Issue Type: Bug >Reporter: Alexander Lapin >Assignee: Alexander Lapin >Priority: Major > Fix For: 2.10 > > > * Reserve/releaseHistoryForPreloading() was reworked, now we store oldest > WALPointer that was reserved during reserveHistoryForPreloading in > reservedForPreloading field. As a result it's possible to release wall > reservation on releaseHIstoryForPreloading(). > * searchAndReserveCheckpoints() was slightly refactored: now it returns not > only an earliestValidCheckpoints but also an oldest reservedCheckpoint, so > that there’s no need to recalculate it within reserveHistoryForExchange(). > * -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13373) WAL segmentns do not released on releaseHistoryForPreloading()
Alexander Lapin created IGNITE-13373: Summary: WAL segmentns do not released on releaseHistoryForPreloading() Key: IGNITE-13373 URL: https://issues.apache.org/jira/browse/IGNITE-13373 Project: Ignite Issue Type: Bug Reporter: Alexander Lapin Assignee: Alexander Lapin * Reserve/releaseHistoryForPreloading() was reworked, now we store oldest WALPointer that was reserved during reserveHistoryForPreloading in reservedForPreloading field. As a result it's possible to release wall reservation on releaseHIstoryForPreloading(). * searchAndReserveCheckpoints() was slightly refactored: now it returns not only an earliestValidCheckpoints but also an oldest reservedCheckpoint, so that there’s no need to recalculate it within reserveHistoryForExchange(). * -- This message was sent by Atlassian Jira (v8.3.4#803005)
