[jira] [Created] (IGNITE-13361) SQL Select query hangs during cursor iteration.
Mikhail Petrov created IGNITE-13361:
---
Summary: SQL Select query hangs during cursor iteration.
Key: IGNITE-13361
URL: https://issues.apache.org/jira/browse/IGNITE-13361
Project: Ignite
Issue Type: Bug
Reporter: Mikhail Petrov
The following test hangs intermittently (once for 4-5 runs) on my laptop
(Ubuntu 20.04, i7-8565u, 16gb RAM). 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}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13358) Improvements for partition clearing related parts
[ https://issues.apache.org/jira/browse/IGNITE-13358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Scherbakov updated IGNITE-13358: --- Description: We have several issues related to a partition clearing worth fixing. 1. PartitionsEvictManager doent's provide obvious guarantees for a correctness when a node or a cache group is stopped while partitions are concurrently clearing. 2. GridDhtLocalPartition#awaitDestroy is called while holding topology write lock, which is deadlock prone, because we currently require write lock to destroy a partition. 3. GridDhtLocalPartition contains a lot of messy code related to partition clearing, most notably ClearFuture, but the clearing is done by PartitionsEvictManager. We should get rid of a clearing code in GridDhtLocalPartition. This should also bring better code readility and help understand what happening during a clearing. 4. Currently moving partitions are cleared before rebalancing in the order different to rebalanceOrder, breaking the contract. 5. The clearing logic for for moving partitions (before rebalancing) seems incorrect: it's possible to lost updates received during clearing. 6. To clear partitions before full rebalancing we utilize same threads as for a partition eviction. This can slow rebalancing even if we have resources. Better to clear partitions in the rebalance pool (explicitely dedicated by user). 7. It's possible to reserve a renting partition, which have absolutely no meaning. All operations with a renting partitions (except clearing) are a waste of resources. 8. Partition eviction causes system pool starvation if a number of thread in system pool is < 8. This can break crucial functionality. was: We have several issues related to a partition clearing worth fixing. 1. PartitionsEvictManager doent's provide obvious guarantees for a correctness when a node or a cache group is stopped while partitions are concurrently clearing. 2. GridDhtLocalPartition#awaitDestroy is called while holding topology write lock, which is deadlock prone, because we currently require write lock to destroy a partition. 3. GridDhtLocalPartition contains a lot of messy code related to partition clearing, most notably ClearFuture, but the clearing is done by PartitionsEvictManager. We should get rid of a clearing code in GridDhtLocalPartition. This should also bring better code readility and help understand what happening during a clearing. 4. Currently moving partitions are cleared before rebalancing in the order different to rebalanceOrder, breaking the contract. 5. The clearing logic for for moving partitions (before rebalancing) seems incorrect: it's possible to lost updates received during clearing. 6. To clear partitions before full rebalancing we utilize same threads as for a partition eviction. This can slow rebalancing even if we have resources. Better to clear partitions in the rebalance pool (explicitely dedicated by user). 7. It's possible to reserve a renting partition, which have absolutely no meaning. All operations with a renting partitions (except clearing) are a waste of resources. > Improvements for partition clearing related parts > - > > Key: IGNITE-13358 > URL: https://issues.apache.org/jira/browse/IGNITE-13358 > Project: Ignite > Issue Type: Improvement >Reporter: Alexey Scherbakov >Assignee: Alexey Scherbakov >Priority: Major > > We have several issues related to a partition clearing worth fixing. > 1. PartitionsEvictManager doent's provide obvious guarantees for a > correctness when a node or a cache group is stopped while partitions are > concurrently clearing. > 2. GridDhtLocalPartition#awaitDestroy is called while holding topology write > lock, which is deadlock prone, because we currently require write lock to > destroy a partition. > 3. GridDhtLocalPartition contains a lot of messy code related to partition > clearing, most notably ClearFuture, but the clearing is done by > PartitionsEvictManager. We should get rid of a clearing code in > GridDhtLocalPartition. This should also bring better code readility and help > understand what happening during a clearing. > 4. Currently moving partitions are cleared before rebalancing in the order > different to rebalanceOrder, breaking the contract. > 5. The clearing logic for for moving partitions (before rebalancing) seems > incorrect: it's possible to lost updates received during clearing. > 6. To clear partitions before full rebalancing we utilize same threads as for > a partition eviction. This can slow rebalancing even if we have resources. > Better to clear partitions in the rebalance pool (explicitely dedicated by > user). > 7. It's possible to reserve a renting partition, which have absolutely no > meaning. All operati
[jira] [Updated] (IGNITE-13358) Improvements for partition clearing related parts
[ https://issues.apache.org/jira/browse/IGNITE-13358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Scherbakov updated IGNITE-13358: --- Description: We have several issues related to a partition clearing worth fixing. 1. PartitionsEvictManager doent's provide obvious guarantees for a correctness when a node or a cache group is stopped while partitions are concurrently clearing. 2. GridDhtLocalPartition#awaitDestroy is called while holding topology write lock, which is deadlock prone, because we currently require write lock to destroy a partition. 3. GridDhtLocalPartition contains a lot of messy code related to partition clearing, most notably ClearFuture, but the clearing is done by PartitionsEvictManager. We should get rid of a clearing code in GridDhtLocalPartition. This should also bring better code readility and help understand what happening during a clearing. 4. Currently moving partitions are cleared before rebalancing in the order different to rebalanceOrder, breaking the contract. 5. The clearing logic for for moving partitions (before rebalancing) seems incorrect: it's possible to lost updates received during clearing. 6. To clear partitions before full rebalancing we utilize same threads as for a partition eviction. This can slow rebalancing even if we have resources. Better to clear partitions in the rebalance pool (explicitely dedicated by user). 7. It's possible to reserve a renting partition, which have absolutely no meaning. All operations with a renting partitions (except clearing) are a waste of resources. 8. Partition eviction causes system pool starvation if a number of thread in system pool=1. This can break crucial functionality. was: We have several issues related to a partition clearing worth fixing. 1. PartitionsEvictManager doent's provide obvious guarantees for a correctness when a node or a cache group is stopped while partitions are concurrently clearing. 2. GridDhtLocalPartition#awaitDestroy is called while holding topology write lock, which is deadlock prone, because we currently require write lock to destroy a partition. 3. GridDhtLocalPartition contains a lot of messy code related to partition clearing, most notably ClearFuture, but the clearing is done by PartitionsEvictManager. We should get rid of a clearing code in GridDhtLocalPartition. This should also bring better code readility and help understand what happening during a clearing. 4. Currently moving partitions are cleared before rebalancing in the order different to rebalanceOrder, breaking the contract. 5. The clearing logic for for moving partitions (before rebalancing) seems incorrect: it's possible to lost updates received during clearing. 6. To clear partitions before full rebalancing we utilize same threads as for a partition eviction. This can slow rebalancing even if we have resources. Better to clear partitions in the rebalance pool (explicitely dedicated by user). 7. It's possible to reserve a renting partition, which have absolutely no meaning. All operations with a renting partitions (except clearing) are a waste of resources. 8. Partition eviction causes system pool starvation if a number of thread in system pool is < 8. This can break crucial functionality. > Improvements for partition clearing related parts > - > > Key: IGNITE-13358 > URL: https://issues.apache.org/jira/browse/IGNITE-13358 > Project: Ignite > Issue Type: Improvement >Reporter: Alexey Scherbakov >Assignee: Alexey Scherbakov >Priority: Major > > We have several issues related to a partition clearing worth fixing. > 1. PartitionsEvictManager doent's provide obvious guarantees for a > correctness when a node or a cache group is stopped while partitions are > concurrently clearing. > 2. GridDhtLocalPartition#awaitDestroy is called while holding topology write > lock, which is deadlock prone, because we currently require write lock to > destroy a partition. > 3. GridDhtLocalPartition contains a lot of messy code related to partition > clearing, most notably ClearFuture, but the clearing is done by > PartitionsEvictManager. We should get rid of a clearing code in > GridDhtLocalPartition. This should also bring better code readility and help > understand what happening during a clearing. > 4. Currently moving partitions are cleared before rebalancing in the order > different to rebalanceOrder, breaking the contract. > 5. The clearing logic for for moving partitions (before rebalancing) seems > incorrect: it's possible to lost updates received during clearing. > 6. To clear partitions before full rebalancing we utilize same threads as for > a partition eviction. This can slow rebalancing even if we have resources. > Better to clear partitions in the rebalance pool (ex
[jira] [Updated] (IGNITE-13358) Improvements for partition clearing related parts
[ https://issues.apache.org/jira/browse/IGNITE-13358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Scherbakov updated IGNITE-13358: --- Description: We have several issues related to a partition clearing worth fixing. 1. PartitionsEvictManager doent's provide obvious guarantees for a correctness when a node or a cache group is stopped while partitions are concurrently clearing. 2. GridDhtLocalPartition#awaitDestroy is called while holding topology write lock, which is deadlock prone, because we currently require write lock to destroy a partition. 3. GridDhtLocalPartition contains a lot of messy code related to partition clearing, most notably ClearFuture, but the clearing is done by PartitionsEvictManager. We should get rid of a clearing code in GridDhtLocalPartition. This should also bring better code readility and help understand what happening during a clearing. 4. Currently moving partitions are cleared before rebalancing in the order different to rebalanceOrder, breaking the contract. 5. The clearing logic for for moving partitions (before rebalancing) seems incorrect: it's possible to lost updates received during clearing. 6. To clear partitions before full rebalancing we utilize same threads as for a partition eviction. This can slow rebalancing even if we have resources. Better to clear partitions in the rebalance pool (explicitely dedicated by user). 7. It's possible to reserve a renting partition, which have absolutely no meaning. All operations with a renting partitions (except clearing) are a waste of resources. 8. Partition eviction causes system pool starvation if a number of threads in system pool=1. This can break crucial functionality. was: We have several issues related to a partition clearing worth fixing. 1. PartitionsEvictManager doent's provide obvious guarantees for a correctness when a node or a cache group is stopped while partitions are concurrently clearing. 2. GridDhtLocalPartition#awaitDestroy is called while holding topology write lock, which is deadlock prone, because we currently require write lock to destroy a partition. 3. GridDhtLocalPartition contains a lot of messy code related to partition clearing, most notably ClearFuture, but the clearing is done by PartitionsEvictManager. We should get rid of a clearing code in GridDhtLocalPartition. This should also bring better code readility and help understand what happening during a clearing. 4. Currently moving partitions are cleared before rebalancing in the order different to rebalanceOrder, breaking the contract. 5. The clearing logic for for moving partitions (before rebalancing) seems incorrect: it's possible to lost updates received during clearing. 6. To clear partitions before full rebalancing we utilize same threads as for a partition eviction. This can slow rebalancing even if we have resources. Better to clear partitions in the rebalance pool (explicitely dedicated by user). 7. It's possible to reserve a renting partition, which have absolutely no meaning. All operations with a renting partitions (except clearing) are a waste of resources. 8. Partition eviction causes system pool starvation if a number of thread in system pool=1. This can break crucial functionality. > Improvements for partition clearing related parts > - > > Key: IGNITE-13358 > URL: https://issues.apache.org/jira/browse/IGNITE-13358 > Project: Ignite > Issue Type: Improvement >Reporter: Alexey Scherbakov >Assignee: Alexey Scherbakov >Priority: Major > > We have several issues related to a partition clearing worth fixing. > 1. PartitionsEvictManager doent's provide obvious guarantees for a > correctness when a node or a cache group is stopped while partitions are > concurrently clearing. > 2. GridDhtLocalPartition#awaitDestroy is called while holding topology write > lock, which is deadlock prone, because we currently require write lock to > destroy a partition. > 3. GridDhtLocalPartition contains a lot of messy code related to partition > clearing, most notably ClearFuture, but the clearing is done by > PartitionsEvictManager. We should get rid of a clearing code in > GridDhtLocalPartition. This should also bring better code readility and help > understand what happening during a clearing. > 4. Currently moving partitions are cleared before rebalancing in the order > different to rebalanceOrder, breaking the contract. > 5. The clearing logic for for moving partitions (before rebalancing) seems > incorrect: it's possible to lost updates received during clearing. > 6. To clear partitions before full rebalancing we utilize same threads as for > a partition eviction. This can slow rebalancing even if we have resources. > Better to clear partitions in the rebalance pool (explic
[jira] [Updated] (IGNITE-13358) Improvements for partition clearing related parts
[ https://issues.apache.org/jira/browse/IGNITE-13358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Scherbakov updated IGNITE-13358: --- Description: We have several issues related to a partition clearing worth fixing. 1. PartitionsEvictManager doent's provide obvious guarantees for a correctness when a node or a cache group is stopped while partitions are concurrently clearing. 2. GridDhtLocalPartition#awaitDestroy is called while holding topology write lock, which is deadlock prone, because we currently require write lock to destroy a partition. 3. GridDhtLocalPartition contains a lot of messy code related to partition clearing, most notably ClearFuture, but the clearing is done by PartitionsEvictManager. We should get rid of a clearing code in GridDhtLocalPartition. This should also bring better code readility and help understand what happening during a clearing. 4. Currently moving partitions are cleared before rebalancing in the order different to rebalanceOrder, breaking the contract. 5. The clearing logic for for moving partitions (before rebalancing) seems incorrect: it's possible to lost updates received during clearing. 6. To clear partitions before full rebalancing we utilize same threads as for a partition eviction. This can slow rebalancing even if we have resources. Better to clear partitions in the rebalance pool (explicitely dedicated by user). 7. It's possible to reserve a renting partition, which have absolutely no meaning. All operations with a renting partitions (except clearing) are a waste of resources. 8. Partition eviction causes system pool tasks starvation if a number of threads in system pool=1. This can break crucial functionality. was: We have several issues related to a partition clearing worth fixing. 1. PartitionsEvictManager doent's provide obvious guarantees for a correctness when a node or a cache group is stopped while partitions are concurrently clearing. 2. GridDhtLocalPartition#awaitDestroy is called while holding topology write lock, which is deadlock prone, because we currently require write lock to destroy a partition. 3. GridDhtLocalPartition contains a lot of messy code related to partition clearing, most notably ClearFuture, but the clearing is done by PartitionsEvictManager. We should get rid of a clearing code in GridDhtLocalPartition. This should also bring better code readility and help understand what happening during a clearing. 4. Currently moving partitions are cleared before rebalancing in the order different to rebalanceOrder, breaking the contract. 5. The clearing logic for for moving partitions (before rebalancing) seems incorrect: it's possible to lost updates received during clearing. 6. To clear partitions before full rebalancing we utilize same threads as for a partition eviction. This can slow rebalancing even if we have resources. Better to clear partitions in the rebalance pool (explicitely dedicated by user). 7. It's possible to reserve a renting partition, which have absolutely no meaning. All operations with a renting partitions (except clearing) are a waste of resources. 8. Partition eviction causes system pool starvation if a number of threads in system pool=1. This can break crucial functionality. > Improvements for partition clearing related parts > - > > Key: IGNITE-13358 > URL: https://issues.apache.org/jira/browse/IGNITE-13358 > Project: Ignite > Issue Type: Improvement >Reporter: Alexey Scherbakov >Assignee: Alexey Scherbakov >Priority: Major > > We have several issues related to a partition clearing worth fixing. > 1. PartitionsEvictManager doent's provide obvious guarantees for a > correctness when a node or a cache group is stopped while partitions are > concurrently clearing. > 2. GridDhtLocalPartition#awaitDestroy is called while holding topology write > lock, which is deadlock prone, because we currently require write lock to > destroy a partition. > 3. GridDhtLocalPartition contains a lot of messy code related to partition > clearing, most notably ClearFuture, but the clearing is done by > PartitionsEvictManager. We should get rid of a clearing code in > GridDhtLocalPartition. This should also bring better code readility and help > understand what happening during a clearing. > 4. Currently moving partitions are cleared before rebalancing in the order > different to rebalanceOrder, breaking the contract. > 5. The clearing logic for for moving partitions (before rebalancing) seems > incorrect: it's possible to lost updates received during clearing. > 6. To clear partitions before full rebalancing we utilize same threads as for > a partition eviction. This can slow rebalancing even if we have resources. > Better to clear partitions in the rebalance pool
[jira] [Commented] (IGNITE-13354) Add ClusterMetrics to the new framework
[ https://issues.apache.org/jira/browse/IGNITE-13354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17177585#comment-17177585 ] Amelchev Nikita commented on IGNITE-13354: -- [~nizhikov], Hi. Could you take a look, please? > Add ClusterMetrics to the new framework > --- > > Key: IGNITE-13354 > URL: https://issues.apache.org/jira/browse/IGNITE-13354 > Project: Ignite > Issue Type: Improvement >Reporter: Nikolay Izhikov >Assignee: Amelchev Nikita >Priority: Major > Labels: IEP-35 > Time Spent: 10m > Remaining Estimate: 0h > > We need to provide to the user information about cluster topology such as: > * TopologyVersion > * TotalNodes > * TotalBaselineNodes > * TotalServerNodes > * TotalClientNodes > * ActiveBaselineNodes -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13345) Warming up strategy
[
https://issues.apache.org/jira/browse/IGNITE-13345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17177594#comment-17177594
]
Ignite TC Bot commented on IGNITE-13345:
{panel:title=Branch: [pull/8148/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/8148/head] Base: [master] : New Tests
(20)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}MVCC PDS 4{color} [[tests
6|https://ci.ignite.apache.org/viewLog.html?buildId=5537064]]
* {color:#013220}IgnitePdsMvccTestSuite4:
WarmUpSelfTest.testNonPersistentDataRegionWarmUpConfiguration - PASSED{color}
* {color:#013220}IgnitePdsMvccTestSuite4:
WarmUpSelfTest.testUnknownDataRegionWarmUpConfiguration - PASSED{color}
* {color:#013220}IgnitePdsMvccTestSuite4:
WarmUpSelfTest.testUnknownDefaultWarmUpConfiguration - PASSED{color}
* {color:#013220}IgnitePdsMvccTestSuite4:
WarmUpSelfTest.testExecutionStrategies - PASSED{color}
* {color:#013220}IgnitePdsMvccTestSuite4:
WarmUpSelfTest.testAvailableWarmUpStrategies - PASSED{color}
* {color:#013220}IgnitePdsMvccTestSuite4: WarmUpSelfTest.testStopWarmUp -
PASSED{color}
{color:#8b}PDS 4{color} [[tests
6|https://ci.ignite.apache.org/viewLog.html?buildId=5536612]]
* {color:#013220}IgnitePdsTestSuite4:
WarmUpSelfTest.testNonPersistentDataRegionWarmUpConfiguration - PASSED{color}
* {color:#013220}IgnitePdsTestSuite4:
WarmUpSelfTest.testUnknownDataRegionWarmUpConfiguration - PASSED{color}
* {color:#013220}IgnitePdsTestSuite4:
WarmUpSelfTest.testUnknownDefaultWarmUpConfiguration - PASSED{color}
* {color:#013220}IgnitePdsTestSuite4: WarmUpSelfTest.testExecutionStrategies -
PASSED{color}
* {color:#013220}IgnitePdsTestSuite4:
WarmUpSelfTest.testAvailableWarmUpStrategies - PASSED{color}
* {color:#013220}IgnitePdsTestSuite4: WarmUpSelfTest.testStopWarmUp -
PASSED{color}
{color:#8b}Service Grid (legacy mode){color} [[tests
4|https://ci.ignite.apache.org/viewLog.html?buildId=5536626]]
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=7ff330b2-71e1-4f12-9b7b-ae68b587c1e5, topVer=0,
msgTemplate=null, span=null, nodeId8=bd98aadb, msg=, type=NODE_JOINED,
tstamp=1597321299268], val2=AffinityTopologyVersion
[topVer=2881683751248964234, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=7ff330b2-71e1-4f12-9b7b-ae68b587c1e5, topVer=0,
msgTemplate=null, span=null, nodeId8=bd98aadb, msg=, type=NODE_JOINED,
tstamp=1597321299268], val2=AffinityTopologyVersion
[topVer=2881683751248964234, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest
[id=a371fc7e371-238e0c65-2924-43d2-9cdf-3afd5d0d3adf, reqs=SingletonList
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent
[evtNode=5d88c5a4-1c7b-42a1-b4d0-8bdc061d426e, topVer=0, msgTemplate=null,
span=null, nodeId8=5d88c5a4, msg=null, type=DISCOVERY_CUSTOM_EVT,
tstamp=1597321299268]], val2=AffinityTopologyVersion
[topVer=-2466747293893613496, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest
[id=a371fc7e371-238e0c65-2924-43d2-9cdf-3afd5d0d3adf, reqs=SingletonList
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent
[evtNode=5d88c5a4-1c7b-42a1-b4d0-8bdc061d426e, topVer=0, msgTemplate=null,
span=null, nodeId8=5d88c5a4, msg=null, type=DISCOVERY_CUSTOM_EVT,
tstamp=1597321299268]], val2=AffinityTopologyVersion
[topVer=-2466747293893613496, minorTopVer=0]]] - PASSED{color}
{color:#8b}Service Grid{color} [[tests
4|https://ci.ignite.apache.org/viewLog.html?buildId=5536625]]
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=6f0834a3-b94c-48c7-9965-30d94bf26fd0, topVer=0,
msgTemplate=null, span=null, nodeId8=db1fd5be, msg=, type=NODE_JOINED,
tstamp=1597321227594], val2=AffinityTopologyVersion
[topVer=-8178158958501439281, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=6f0834a3-b94c-48c7-9965-30d94bf26fd0, topVer=0,
msgTemplate=null, span=null, nodeId8=db1fd5be, msg=, type=NODE_JOINED,
tstamp=1597321227594], val2=AffinityTopologyVersion
[topVer=-8178158958501439281, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDe
[jira] [Commented] (IGNITE-13345) Warming up strategy
[
https://issues.apache.org/jira/browse/IGNITE-13345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17177609#comment-17177609
]
Kirill Tkalenko commented on IGNITE-13345:
--
At the moment, stop warm-up via "control.sh" is not possible due to fact that
processing messages from "control.sh" occurs after "discovery" and warm-up goes
before it. So MXBean has been added for now. And for "control.sh" will be done
via a separate ticket.
> Warming up strategy
> ---
>
> Key: IGNITE-13345
> URL: https://issues.apache.org/jira/browse/IGNITE-13345
> Project: Ignite
> Issue Type: New Feature
>Reporter: Kirill Tkalenko
>Assignee: Kirill Tkalenko
>Priority: Major
> Labels: IEP-40
> Fix For: 2.10
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Summary of
> [Dev-list|http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSSION-Cache-warmup-td48582.html]
> # Adding a marker interface
> *org.apache.ignite.configuration.WarmUpConfiguration*;
> # Adding a configuration to
> ##
> *org.apache.ignite.configuration.DataRegionConfiguration#setWarmUpConfiguration*
> ##
> *org.apache.ignite.configuration.DataStorageConfiguration#setDefaultWarmUpConfiguration*
> # Add an internal warm-up interface that will start in [1] after [2] (after
> recovery);
> {code:java}
> package org.apache.ignite.internal.processors.cache.warmup;
> import org.apache.ignite.IgniteCheckedException;
> import org.apache.ignite.configuration.WarmUpConfiguration;
> import org.apache.ignite.internal.GridKernalContext;
> import org.apache.ignite.internal.processors.cache.persistence.DataRegion;
> /**
> * Interface for warming up.
> */
> public interface WarmUpStrategy {
> /**
> * Returns configuration class for mapping to strategy.
> *
> * @return Configuration class.
> */
> Class configClass();
> /**
> * Warm up.
> *
> * @param kernalCtx Kernal context.
> * @param cfg Warm-up configuration.
> * @param regionData region.
> * @throws IgniteCheckedException if faild.
> */
> void warmUp(GridKernalContext kernalCtx, T cfg, DataRegion region) throws
> IgniteCheckedException;
> /**
> * Closing warm up.
> *
> * @throws IgniteCheckedException if faild.
> */
> void close() throws IgniteCheckedException;
> }
> {code}
> # Adding an internal plugin extension for add own strategies;
> {code:java}
> package org.apache.ignite.internal.processors.cache.warmup;
>
> import java.util.Collection;
> import org.apache.ignite.plugin.Extension;
>
> /**
> * Interface for getting warm-up strategies from plugins.
> */
> public interface WarmUpStrategySupplier extends Extension {
> /**
> * Getting warm-up strategies.
> *
> * @return Warm-up strategies.
> */
> Collection strategies();
> }
> {code}
> # Adding strategies:
> ## Without implementation, for the possibility of disabling the warm-up: NoOP
> ## Loading everything while there is RAM with priority to indexes: LoadAll
> # Add a command to "control.sh", to stop current warm-up and cancel all
> others: --warm-up stop
> [1] -
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.CacheRecoveryLifecycle#afterLogicalUpdatesApplied
> [2] -
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.CacheRecoveryLifecycle#restorePartitionStates
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13358) Improvements for partition clearing related parts
[ https://issues.apache.org/jira/browse/IGNITE-13358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Scherbakov updated IGNITE-13358: --- Description: We have several issues related to a partition clearing worth fixing. 1. PartitionsEvictManager doent's provide obvious guarantees for a correctness when a node or a cache group is stopped while partitions are concurrently clearing. 2. GridDhtLocalPartition#awaitDestroy is called while holding topology write lock, which is deadlock prone, because we currently require write lock to destroy a partition. 3. GridDhtLocalPartition contains a lot of messy code related to partition clearing, most notably ClearFuture, but the clearing is done by PartitionsEvictManager. We should get rid of a clearing code in GridDhtLocalPartition. This should also bring better code readility and help understand what happening during a clearing. 4. Currently moving partitions are cleared before rebalancing in the order different to rebalanceOrder, breaking the contract. Better to submit such partitions to clearing in the rebalancing pool before each group start to rebalance. This will allow faster rebalancing (accoring to configured rebalance pool size) and will provide rebalanceOrder guarantees. 5. The clearing logic for for moving partitions (before rebalancing) seems incorrect: it's possible to lost updates received during clearing. 6. To clear partitions before full rebalancing we utilize same threads as for a partition eviction. This can slow rebalancing even if we have resources. Better to clear partitions in the rebalance pool (explicitely dedicated by user). 7. It's possible to reserve a renting partition, which have absolutely no meaning. All operations with a renting partitions (except clearing) are a waste of resources. 8. Partition eviction causes system pool tasks starvation if a number of threads in system pool=1. This can break crucial functionality. was: We have several issues related to a partition clearing worth fixing. 1. PartitionsEvictManager doent's provide obvious guarantees for a correctness when a node or a cache group is stopped while partitions are concurrently clearing. 2. GridDhtLocalPartition#awaitDestroy is called while holding topology write lock, which is deadlock prone, because we currently require write lock to destroy a partition. 3. GridDhtLocalPartition contains a lot of messy code related to partition clearing, most notably ClearFuture, but the clearing is done by PartitionsEvictManager. We should get rid of a clearing code in GridDhtLocalPartition. This should also bring better code readility and help understand what happening during a clearing. 4. Currently moving partitions are cleared before rebalancing in the order different to rebalanceOrder, breaking the contract. 5. The clearing logic for for moving partitions (before rebalancing) seems incorrect: it's possible to lost updates received during clearing. 6. To clear partitions before full rebalancing we utilize same threads as for a partition eviction. This can slow rebalancing even if we have resources. Better to clear partitions in the rebalance pool (explicitely dedicated by user). 7. It's possible to reserve a renting partition, which have absolutely no meaning. All operations with a renting partitions (except clearing) are a waste of resources. 8. Partition eviction causes system pool tasks starvation if a number of threads in system pool=1. This can break crucial functionality. > Improvements for partition clearing related parts > - > > Key: IGNITE-13358 > URL: https://issues.apache.org/jira/browse/IGNITE-13358 > Project: Ignite > Issue Type: Improvement >Reporter: Alexey Scherbakov >Assignee: Alexey Scherbakov >Priority: Major > > We have several issues related to a partition clearing worth fixing. > 1. PartitionsEvictManager doent's provide obvious guarantees for a > correctness when a node or a cache group is stopped while partitions are > concurrently clearing. > 2. GridDhtLocalPartition#awaitDestroy is called while holding topology write > lock, which is deadlock prone, because we currently require write lock to > destroy a partition. > 3. GridDhtLocalPartition contains a lot of messy code related to partition > clearing, most notably ClearFuture, but the clearing is done by > PartitionsEvictManager. We should get rid of a clearing code in > GridDhtLocalPartition. This should also bring better code readility and help > understand what happening during a clearing. > 4. Currently moving partitions are cleared before rebalancing in the order > different to rebalanceOrder, breaking the contract. Better to submit such > partitions to clearing in the rebalancing pool before each group start to > rebalance. This
[jira] [Created] (IGNITE-13362) Stop warm-up via control.sh
Kirill Tkalenko created IGNITE-13362: Summary: Stop warm-up via control.sh Key: IGNITE-13362 URL: https://issues.apache.org/jira/browse/IGNITE-13362 Project: Ignite Issue Type: New Feature Reporter: Kirill Tkalenko Fix For: 2.10 At the moment, stop warm-up via "control.sh" is not possible due to fact that processing messages from "control.sh" occurs after "discovery" and warm-up goes before it. It is necessary to do processing of messages from "control.sh" before warming up and implement command for "control.sh". -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13362) Stop warm-up via control.sh
[ https://issues.apache.org/jira/browse/IGNITE-13362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Tkalenko updated IGNITE-13362: - Labels: IEP-40 (was: ) > Stop warm-up via control.sh > --- > > Key: IGNITE-13362 > URL: https://issues.apache.org/jira/browse/IGNITE-13362 > Project: Ignite > Issue Type: New Feature >Reporter: Kirill Tkalenko >Priority: Major > Labels: IEP-40 > Fix For: 2.10 > > > At the moment, stop warm-up via "control.sh" is not possible due to fact that > processing messages from "control.sh" occurs after "discovery" and warm-up > goes before it. > It is necessary to do processing of messages from "control.sh" before warming > up and implement command for "control.sh". -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-13345) Warming up strategy
[
https://issues.apache.org/jira/browse/IGNITE-13345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17177609#comment-17177609
]
Kirill Tkalenko edited comment on IGNITE-13345 at 8/14/20, 8:41 AM:
At the moment, stop warm-up via "control.sh" is not possible due to fact that
processing messages from "control.sh" occurs after "discovery" and warm-up goes
before it. So MXBean has been added for now. And for "control.sh" will be done
via a separate ticket IGNITE-13362.
was (Author: ktkale...@gridgain.com):
At the moment, stop warm-up via "control.sh" is not possible due to fact that
processing messages from "control.sh" occurs after "discovery" and warm-up goes
before it. So MXBean has been added for now. And for "control.sh" will be done
via a separate ticket.
> Warming up strategy
> ---
>
> Key: IGNITE-13345
> URL: https://issues.apache.org/jira/browse/IGNITE-13345
> Project: Ignite
> Issue Type: New Feature
>Reporter: Kirill Tkalenko
>Assignee: Kirill Tkalenko
>Priority: Major
> Labels: IEP-40
> Fix For: 2.10
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Summary of
> [Dev-list|http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSSION-Cache-warmup-td48582.html]
> # Adding a marker interface
> *org.apache.ignite.configuration.WarmUpConfiguration*;
> # Adding a configuration to
> ##
> *org.apache.ignite.configuration.DataRegionConfiguration#setWarmUpConfiguration*
> ##
> *org.apache.ignite.configuration.DataStorageConfiguration#setDefaultWarmUpConfiguration*
> # Add an internal warm-up interface that will start in [1] after [2] (after
> recovery);
> {code:java}
> package org.apache.ignite.internal.processors.cache.warmup;
> import org.apache.ignite.IgniteCheckedException;
> import org.apache.ignite.configuration.WarmUpConfiguration;
> import org.apache.ignite.internal.GridKernalContext;
> import org.apache.ignite.internal.processors.cache.persistence.DataRegion;
> /**
> * Interface for warming up.
> */
> public interface WarmUpStrategy {
> /**
> * Returns configuration class for mapping to strategy.
> *
> * @return Configuration class.
> */
> Class configClass();
> /**
> * Warm up.
> *
> * @param kernalCtx Kernal context.
> * @param cfg Warm-up configuration.
> * @param regionData region.
> * @throws IgniteCheckedException if faild.
> */
> void warmUp(GridKernalContext kernalCtx, T cfg, DataRegion region) throws
> IgniteCheckedException;
> /**
> * Closing warm up.
> *
> * @throws IgniteCheckedException if faild.
> */
> void close() throws IgniteCheckedException;
> }
> {code}
> # Adding an internal plugin extension for add own strategies;
> {code:java}
> package org.apache.ignite.internal.processors.cache.warmup;
>
> import java.util.Collection;
> import org.apache.ignite.plugin.Extension;
>
> /**
> * Interface for getting warm-up strategies from plugins.
> */
> public interface WarmUpStrategySupplier extends Extension {
> /**
> * Getting warm-up strategies.
> *
> * @return Warm-up strategies.
> */
> Collection strategies();
> }
> {code}
> # Adding strategies:
> ## Without implementation, for the possibility of disabling the warm-up: NoOP
> ## Loading everything while there is RAM with priority to indexes: LoadAll
> # Add a command to "control.sh", to stop current warm-up and cancel all
> others: --warm-up stop
> [1] -
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.CacheRecoveryLifecycle#afterLogicalUpdatesApplied
> [2] -
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.CacheRecoveryLifecycle#restorePartitionStates
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-13363) GridDhtCacheEntry::toString locks
Stepachev Maksim created IGNITE-13363:
-
Summary: GridDhtCacheEntry::toString locks
Key: IGNITE-13363
URL: https://issues.apache.org/jira/browse/IGNITE-13363
Project: Ignite
Issue Type: Bug
Components: networking
Affects Versions: 2.8.1
Reporter: Stepachev Maksim
Assignee: Stepachev Maksim
Fix For: 3.0
`GridDhtCacheEntry::toString` locks the entry which may lead to dead locks and,
I assume, even performance issues.
We, naturally, call `toString` on everything all the time and it needs to be
the safest and the lightest possible operation.
Example of a hang with locking toString:
{{Thread [name="grid-timeout-worker-#71%GRIDC1%", id=98, state=WAITING,
blockCnt=2, waitCnt=14196]
Lock [object=java.util.concurrent.locks.ReentrantLock$NonfairSync@20c96143,
ownerName=exchange-worker-#188%GRIDC1%, ownerId=265]
at java.base@11.0.2/jdk.internal.misc.Unsafe.park(Native Method)
at
java.base@11.0.2/java.util.concurrent.locks.LockSupport.park(LockSupport.java:194)
at
java.base@11.0.2/java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:885)
at
java.base@11.0.2/java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:917)
at
java.base@11.0.2/java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1240)
at
java.base@11.0.2/java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:267)
at
app//o.a.i.i.processors.cache.GridCacheMapEntry.lockEntry(GridCacheMapEntry.java:5051)
at
app//o.a.i.i.processors.cache.distributed.dht.GridDhtCacheEntry.toString(GridDhtCacheEntry.java:819)
at java.base@11.0.2/java.lang.String.valueOf(String.java:2951)
at app//o.a.i.i.util.GridStringBuilder.a(GridStringBuilder.java:101)
at app//o.a.i.i.util.tostring.SBLimitedLength.a(SBLimitedLength.java:88)
at
app//o.a.i.i.util.tostring.GridToStringBuilder.toString(GridToStringBuilder.java:939)
at
app//o.a.i.i.util.tostring.GridToStringBuilder.toStringImpl(GridToStringBuilder.java:1005)
at
app//o.a.i.i.util.tostring.GridToStringBuilder.toString(GridToStringBuilder.java:826)
at
app//o.a.i.i.util.tostring.GridToStringBuilder.toString(GridToStringBuilder.java:783)
at
app//o.a.i.i.processors.cache.transactions.IgniteTxEntry.toString(IgniteTxEntry.java:1273)
at java.base@11.0.2/java.lang.String.valueOf(String.java:2951)
at
java.base@11.0.2/java.lang.StringBuilder.append(StringBuilder.java:168)
at
java.base@11.0.2/java.util.AbstractCollection.toString(AbstractCollection.java:473)
at java.base@11.0.2/java.lang.String.valueOf(String.java:2951)
at app//o.a.i.i.util.GridStringBuilder.a(GridStringBuilder.java:101)
at app//o.a.i.i.util.tostring.SBLimitedLength.a(SBLimitedLength.java:88)
at
app//o.a.i.i.util.tostring.GridToStringBuilder.toString(GridToStringBuilder.java:939)
at
app//o.a.i.i.util.tostring.GridToStringBuilder.toStringImpl(GridToStringBuilder.java:1005)
at
app//o.a.i.i.util.tostring.GridToStringBuilder.toString(GridToStringBuilder.java:826)
at
app//o.a.i.i.util.tostring.GridToStringBuilder.toString(GridToStringBuilder.java:783)
at
app//o.a.i.i.processors.cache.distributed.GridDistributedTxMapping.toString(GridDistributedTxMapping.java:319)
at java.base@11.0.2/java.lang.String.valueOf(String.java:2951)
at app//o.a.i.i.util.GridStringBuilder.a(GridStringBuilder.java:101)
at app//o.a.i.i.util.tostring.SBLimitedLength.a(SBLimitedLength.java:88)
at
app//o.a.i.i.util.tostring.GridToStringBuilder.toString(GridToStringBuilder.java:939)
at
app//o.a.i.i.util.tostring.GridToStringBuilder.toStringImpl(GridToStringBuilder.java:1005)
at
app//o.a.i.i.util.tostring.GridToStringBuilder.toString(GridToStringBuilder.java:864)
at
app//o.a.i.i.processors.cache.distributed.near.IgniteTxMappingsSingleImpl.toString(IgniteTxMappingsSingleImpl.java:99)
at java.base@11.0.2/java.lang.String.valueOf(String.java:2951)
at app//o.a.i.i.util.GridStringBuilder.a(GridStringBuilder.java:101)
at app//o.a.i.i.util.tostring.SBLimitedLength.a(SBLimitedLength.java:88)
at
app//o.a.i.i.util.tostring.GridToStringBuilder.toString(GridToStringBuilder.java:939)
at
app//o.a.i.i.util.tostring.GridToStringBuilder.toStringImpl(GridToStringBuilder.java:1005)
at
app//o.a.i.i.util.tostring.GridToStringBuilder.toString(GridToStringBuilder.java:685)
at
app//o.a.i.i.util.tostring.GridToStringBuilder.toString(GridToStringBuilder.java:621)
at
app//o.a.i.i.processors.cache.distributed.near.GridNearTxLocal.toString(GridNearTxLocal.java:48
[jira] [Updated] (IGNITE-13358) Improvements for partition clearing related parts
[ https://issues.apache.org/jira/browse/IGNITE-13358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Scherbakov updated IGNITE-13358: --- Description: We have several issues related to a partition clearing worth fixing. 1. PartitionsEvictManager doent's provide obvious guarantees for a correctness when a node or a cache group is stopped while partitions are concurrently clearing. 2. GridDhtLocalPartition#awaitDestroy is called while holding topology write lock, which is deadlock prone, because we currently require write lock to destroy a partition. 3. GridDhtLocalPartition contains a lot of messy code related to partition clearing, most notably ClearFuture, but the clearing is done by PartitionsEvictManager. We should get rid of a clearing code in GridDhtLocalPartition. This should also bring better code readility and help understand what happening during a clearing. 4. Currently moving partitions are cleared before rebalancing in the order different to rebalanceOrder, breaking the contract. Better to submit such partitions for clearing to the rebalancing pool before each group starts to rebalance. This will allow faster rebalancing (accoring to configured rebalance pool size) and will provide rebalanceOrder guarantees. 5. The clearing logic for for moving partitions (before rebalancing) seems incorrect: it's possible to lost updates received during clearing. 6. To clear partitions before full rebalancing we utilize same threads as for a partition eviction. This can slow rebalancing even if we have resources. Better to clear partitions in the rebalance pool (explicitely dedicated by user). 7. It's possible to reserve a renting partition, which have absolutely no meaning. All operations with a renting partitions (except clearing) are a waste of resources. 8. Partition eviction causes system pool tasks starvation if a number of threads in system pool=1. This can break crucial functionality. was: We have several issues related to a partition clearing worth fixing. 1. PartitionsEvictManager doent's provide obvious guarantees for a correctness when a node or a cache group is stopped while partitions are concurrently clearing. 2. GridDhtLocalPartition#awaitDestroy is called while holding topology write lock, which is deadlock prone, because we currently require write lock to destroy a partition. 3. GridDhtLocalPartition contains a lot of messy code related to partition clearing, most notably ClearFuture, but the clearing is done by PartitionsEvictManager. We should get rid of a clearing code in GridDhtLocalPartition. This should also bring better code readility and help understand what happening during a clearing. 4. Currently moving partitions are cleared before rebalancing in the order different to rebalanceOrder, breaking the contract. Better to submit such partitions to clearing in the rebalancing pool before each group start to rebalance. This will allow faster rebalancing (accoring to configured rebalance pool size) and will provide rebalanceOrder guarantees. 5. The clearing logic for for moving partitions (before rebalancing) seems incorrect: it's possible to lost updates received during clearing. 6. To clear partitions before full rebalancing we utilize same threads as for a partition eviction. This can slow rebalancing even if we have resources. Better to clear partitions in the rebalance pool (explicitely dedicated by user). 7. It's possible to reserve a renting partition, which have absolutely no meaning. All operations with a renting partitions (except clearing) are a waste of resources. 8. Partition eviction causes system pool tasks starvation if a number of threads in system pool=1. This can break crucial functionality. > Improvements for partition clearing related parts > - > > Key: IGNITE-13358 > URL: https://issues.apache.org/jira/browse/IGNITE-13358 > Project: Ignite > Issue Type: Improvement >Reporter: Alexey Scherbakov >Assignee: Alexey Scherbakov >Priority: Major > > We have several issues related to a partition clearing worth fixing. > 1. PartitionsEvictManager doent's provide obvious guarantees for a > correctness when a node or a cache group is stopped while partitions are > concurrently clearing. > 2. GridDhtLocalPartition#awaitDestroy is called while holding topology write > lock, which is deadlock prone, because we currently require write lock to > destroy a partition. > 3. GridDhtLocalPartition contains a lot of messy code related to partition > clearing, most notably ClearFuture, but the clearing is done by > PartitionsEvictManager. We should get rid of a clearing code in > GridDhtLocalPartition. This should also bring better code readility and help > understand what happening during a clearing. > 4. Currentl
[jira] [Commented] (IGNITE-5038) BinaryMarshaller might need to use context class loader for deserialization
[ https://issues.apache.org/jira/browse/IGNITE-5038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17177646#comment-17177646 ] Vladislav Pyatkov commented on IGNITE-5038: --- [~ivan.glukos] I left a couple of comments in PR. Both of them carry of optional character. > BinaryMarshaller might need to use context class loader for deserialization > --- > > Key: IGNITE-5038 > URL: https://issues.apache.org/jira/browse/IGNITE-5038 > Project: Ignite > Issue Type: Improvement > Components: binary >Affects Versions: 2.0 >Reporter: Dmitry Karachentsev >Assignee: Ivan Rakov >Priority: Major > Labels: features > Attachments: results-compound-20170802.zip, > results-compound-20170808.zip > > Time Spent: 1h 40m > Remaining Estimate: 0h > > There is a special use case discussed on the dev list: > http://apache-ignite-developers.2346864.n4.nabble.com/Re-BinaryObjectImpl-deserializeValue-with-specific-ClassLoader-td17126.html#a17224 > According to the use case, BinaryMarshaller might need to try to deserialize > an object using a context class loader if it failed to do so with a custom > classloader (`IgniteConfiguration.getClassLoader()`) or the system one. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-12350) MVCC activated and causing memory leak (OOM) despite no mvccEnabled caches
[ https://issues.apache.org/jira/browse/IGNITE-12350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladislav Pyatkov reassigned IGNITE-12350: -- Assignee: Vladislav Pyatkov > MVCC activated and causing memory leak (OOM) despite no mvccEnabled caches > -- > > Key: IGNITE-12350 > URL: https://issues.apache.org/jira/browse/IGNITE-12350 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.7.5 >Reporter: Ming Vuong >Assignee: Vladislav Pyatkov >Priority: Major > Attachments: MATheap.jpg, proxy-memory-leak.png, proxy-oom-2.png > > > We have a critical memory leak where mvccCoordinator is still selected and > mvcc is still 'activated' despite having no mvccEnabled caches, this is > causing constant OOM crashes and issues on both server and client nodes. > All client CacheAtomicityModes are of type ATOMIC, and for server config > persistence is false, TCPDiscoverySpi used and PeerClassLoadingEnabled=true. > There are two server JVM instances on two separate nodes. One of the servers > consistently get an OOM error, as well as all clients, due to the same > recoveryBallotBoxes HashMap constantly increasing in size and unable to be > Garbage Collected. > Attached is Eclipse Memory Analyzer Tool screenshot on the heap dump close to > one of the server JVM OOM crashes. The same heap analysis result is apparent > for all clients as well. > !MATheap.jpg! -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-5038) BinaryMarshaller might need to use context class loader for deserialization
[ https://issues.apache.org/jira/browse/IGNITE-5038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17177674#comment-17177674 ] Igor Seliverstov commented on IGNITE-5038: -- [~ivan.glukos]I went across the PR, generally I'm OK with changes. > BinaryMarshaller might need to use context class loader for deserialization > --- > > Key: IGNITE-5038 > URL: https://issues.apache.org/jira/browse/IGNITE-5038 > Project: Ignite > Issue Type: Improvement > Components: binary >Affects Versions: 2.0 >Reporter: Dmitry Karachentsev >Assignee: Ivan Rakov >Priority: Major > Labels: features > Attachments: results-compound-20170802.zip, > results-compound-20170808.zip > > Time Spent: 1h 40m > Remaining Estimate: 0h > > There is a special use case discussed on the dev list: > http://apache-ignite-developers.2346864.n4.nabble.com/Re-BinaryObjectImpl-deserializeValue-with-specific-ClassLoader-td17126.html#a17224 > According to the use case, BinaryMarshaller might need to try to deserialize > an object using a context class loader if it failed to do so with a custom > classloader (`IgniteConfiguration.getClassLoader()`) or the system one. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12754) .NET: Thin Client: Service invocation
[
https://issues.apache.org/jira/browse/IGNITE-12754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17177689#comment-17177689
]
Ignite TC Bot commented on IGNITE-12754:
{panel:title=Branch: [pull/8151/head] Base: [master] : Possible Blockers
(7)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Cache (Restarts) 1{color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=5538395]]
{color:#d04437}MVCC Cache 7{color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=5538439]]
{color:#d04437}Platform .NET (Long Running){color} [[tests 0 Exit Code ,
Compilation Error |https://ci.ignite.apache.org/viewLog.html?buildId=5538423]]
{color:#d04437}Platform .NET{color} [[tests 0 Exit Code , Compilation Error
|https://ci.ignite.apache.org/viewLog.html?buildId=5538419]]
{color:#d04437}Basic 1{color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=5538378]]
{color:#d04437}Platform .NET (Inspections)*{color} [[tests 0 Exit Code ,
Compilation Error |https://ci.ignite.apache.org/viewLog.html?buildId=5538421]]
{color:#d04437}Platform .NET (Integrations){color} [[tests 0 Exit Code ,
Compilation Error |https://ci.ignite.apache.org/viewLog.html?buildId=5538422]]
{panel}
{panel:title=Branch: [pull/8151/head] Base: [master] : New Tests
(18)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Platform .NET (Core Linux){color} [[tests
18|https://ci.ignite.apache.org/viewLog.html?buildId=5538420]]
* {color:#013220}dll: ServicesClientTest.TestJavaServiceCall - PASSED{color}
* {color:#013220}dll:
ServicesClientTest.TestExceptionInServiceIsPropagatedToClient - PASSED{color}
* {color:#013220}dll: ServicesClientTest.TestEmptyClusterGroupThrowsError -
PASSED{color}
* {color:#013220}dll:
ServicesClientTest.TestClusterGroupWithoutMatchingServiceNodesThrowsError -
PASSED{color}
* {color:#013220}dll:
ServicesClientTest.TestClientKeepBinaryReturnsServiceInvocationResultInBinaryMode
- PASSED{color}
* {color:#013220}dll: ServicesClientTest.TestBasicServiceCall - PASSED{color}
* {color:#013220}dll:
ServicesClientTest.TestServerKeepBinaryPassesServerSideArgumentsInBinaryMode -
PASSED{color}
* {color:#013220}dll:
ServicesClientTest.TestServerAndClientKeepBinaryPassesBinaryObjectsOnServerAndClient
- PASSED{color}
* {color:#013220}dll: ServicesClientTest.TestPropertyCalls - PASSED{color}
* {color:#013220}dll: ServicesClientTest.TestOverloadResolution - PASSED{color}
* {color:#013220}dll: ServicesClientTest.TestObjectMethodCall - PASSED{color}
... and 7 new tests
{panel}
[TeamCity *--> Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5538454&buildTypeId=IgniteTests24Java8_RunAll]
> .NET: Thin Client: Service invocation
> -
>
> Key: IGNITE-12754
> URL: https://issues.apache.org/jira/browse/IGNITE-12754
> Project: Ignite
> Issue Type: New Feature
> Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: .NET, iep-46
> Fix For: 2.10
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Provide an API to invoke Ignite Services from Thin Clients.
> .NET API:
> {code}
> IIgniteClient.GetServices().GetServiceProxy("name").Bar();
> {code}
> See
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-46%3A+Thin+Client+Service+Invocation
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13345) Warming up strategy
[
https://issues.apache.org/jira/browse/IGNITE-13345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirill Tkalenko updated IGNITE-13345:
-
Description:
Summary of
[Dev-list|http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSSION-Cache-warmup-td48582.html]
# Adding a marker interface
*org.apache.ignite.configuration.WarmUpConfiguration*;
# Adding a configuration to
##
*org.apache.ignite.configuration.DataRegionConfiguration#setWarmUpConfiguration*
##
*org.apache.ignite.configuration.DataStorageConfiguration#setDefaultWarmUpConfiguration*
# Add an internal warm-up interface that will start in [1] after [2] (after
recovery);
{code:java}
package org.apache.ignite.internal.processors.cache.warmup;
import org.apache.ignite.IgniteCheckedException;
import org.apache.ignite.configuration.WarmUpConfiguration;
import org.apache.ignite.internal.GridKernalContext;
import org.apache.ignite.internal.processors.cache.persistence.DataRegion;
/**
* Interface for warming up.
*/
public interface WarmUpStrategy {
/**
* Returns configuration class for mapping to strategy.
*
* @return Configuration class.
*/
Class configClass();
/**
* Warm up.
*
* @param kernalCtx Kernal context.
* @param cfg Warm-up configuration.
* @param regionData region.
* @throws IgniteCheckedException if faild.
*/
void warmUp(GridKernalContext kernalCtx, T cfg, DataRegion region) throws
IgniteCheckedException;
/**
* Closing warm up.
*
* @throws IgniteCheckedException if faild.
*/
void close() throws IgniteCheckedException;
}
{code}
# Adding an internal plugin extension for add own strategies;
{code:java}
package org.apache.ignite.internal.processors.cache.warmup;
import java.util.Collection;
import org.apache.ignite.plugin.Extension;
/**
* Interface for getting warm-up strategies from plugins.
*/
public interface WarmUpStrategySupplier extends Extension {
/**
* Getting warm-up strategies.
*
* @return Warm-up strategies.
*/
Collection strategies();
}
{code}
# Adding strategies:
## Without implementation, for the possibility of disabling the warm-up: NoOP
## Loading everything while there is RAM with priority to indexes: LoadAll
# Add a command to "control.sh", to stop current warm-up and cancel all others:
--warm-up stop in IGNITE-13362
[1] -
org.apache.ignite.internal.processors.cache.GridCacheProcessor.CacheRecoveryLifecycle#afterLogicalUpdatesApplied
[2] -
org.apache.ignite.internal.processors.cache.GridCacheProcessor.CacheRecoveryLifecycle#restorePartitionStates
was:
Summary of
[Dev-list|http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSSION-Cache-warmup-td48582.html]
# Adding a marker interface
*org.apache.ignite.configuration.WarmUpConfiguration*;
# Adding a configuration to
##
*org.apache.ignite.configuration.DataRegionConfiguration#setWarmUpConfiguration*
##
*org.apache.ignite.configuration.DataStorageConfiguration#setDefaultWarmUpConfiguration*
# Add an internal warm-up interface that will start in [1] after [2] (after
recovery);
{code:java}
package org.apache.ignite.internal.processors.cache.warmup;
import org.apache.ignite.IgniteCheckedException;
import org.apache.ignite.configuration.WarmUpConfiguration;
import org.apache.ignite.internal.GridKernalContext;
import org.apache.ignite.internal.processors.cache.persistence.DataRegion;
/**
* Interface for warming up.
*/
public interface WarmUpStrategy {
/**
* Returns configuration class for mapping to strategy.
*
* @return Configuration class.
*/
Class configClass();
/**
* Warm up.
*
* @param kernalCtx Kernal context.
* @param cfg Warm-up configuration.
* @param regionData region.
* @throws IgniteCheckedException if faild.
*/
void warmUp(GridKernalContext kernalCtx, T cfg, DataRegion region) throws
IgniteCheckedException;
/**
* Closing warm up.
*
* @throws IgniteCheckedException if faild.
*/
void close() throws IgniteCheckedException;
}
{code}
# Adding an internal plugin extension for add own strategies;
{code:java}
package org.apache.ignite.internal.processors.cache.warmup;
import java.util.Collection;
import org.apache.ignite.plugin.Extension;
/**
* Interface for getting warm-up strategies from plugins.
*/
public interface WarmUpStrategySupplier extends Extension {
/**
* Getting warm-up strategies.
*
* @return Warm-up strategies.
*/
Collection strategies();
}
{code}
# Adding strategies:
## Without implementation, for the possibility of disabling the warm-up: NoOP
## Loading everything while there is RAM with priority to indexes: LoadAll
# Add a command to "control.sh", to stop current warm-up and cancel all others:
--warm-up stop
[1] -
org.apache.ignite.internal.processors.cache.GridCacheProc
[jira] [Commented] (IGNITE-12806) Incorret usage of Class.isAssignableFrom in SystemViewLocal and SystemViewMBean classes
[
https://issues.apache.org/jira/browse/IGNITE-12806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17177716#comment-17177716
]
Nikolay Izhikov commented on IGNITE-12806:
--
LGTM
> Incorret usage of Class.isAssignableFrom in SystemViewLocal and
> SystemViewMBean classes
> ---
>
> Key: IGNITE-12806
> URL: https://issues.apache.org/jira/browse/IGNITE-12806
> Project: Ignite
> Issue Type: Bug
>Reporter: Andrey N. Gura
>Assignee: Yaroslav Molochkov
>Priority: Minor
> Labels: IEP-35
> Fix For: 2.10
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Classes {{SystemViewLocal}} and {{SystemViewMBean}} uses method
> {{Class.isAssignableFrom}} in incorrect manner. I given cases relation is
> inverted and doesn't have any sense. In most cases usages of
> {{Class.isAssignableFrom}} could be avoided.
> See creation of {{AttributeVisitor}} and {{AttributeWithValueVisitor}}
> instance in mentioned classes.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (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 reassigned IGNITE-13361:
---
Assignee: Mikhail Petrov
> SQL Select query hangs during cursor iteration.
> ---
>
> 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). 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}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[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). 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 dc3ddf08 commit is responsible for the behavior described
above.
was:
The following test hangs intermittently (once for 4-5 runs) on my laptop
(Ubuntu 20.04, i7-8565u, 16gb RAM). 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}
> SQL Select query hangs during cursor iteration.
> ---
>
> Key: IGNITE-13361
> URL: https://issues.apache.org/jira/browse/IGNITE-13361
>
[jira] [Assigned] (IGNITE-12946) Add description to MBeans
[ https://issues.apache.org/jira/browse/IGNITE-12946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov reassigned IGNITE-12946: Assignee: Nikolay Izhikov > Add description to MBeans > - > > Key: IGNITE-12946 > URL: https://issues.apache.org/jira/browse/IGNITE-12946 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.8 >Reporter: Denis A. Magda >Assignee: Nikolay Izhikov >Priority: Major > Labels: IEP-35 > > Presently, application developers will see hundreds of metrics once connect > through JMX and it will be hard for them to sort out the valuable ones. > The documentation can do a great job outlining the right ones but we can also > add descriptions to MXBeans explaining what each metric reports. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[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). 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 dc3ddf08 commit is responsible for the behavior described
above. Cursor iteration hangs due to GridQueryNextPageRequest is not sent
correctly from the client node.
was:
The following test hangs intermittently (once for 4-5 runs) on my laptop
(Ubuntu 20.04, i7-8565u, 16gb RAM). 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 dc3ddf08 commit is responsible for the behavior described
above.
> SQL Select query hangs during c
[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). 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 dc3ddf08 commit is responsible for the behavior described
above. Cursor iteration hangs due to GridQueryNextPageRequest may not be sent
correctly from the client node.
was:
The following test hangs intermittently (once for 4-5 runs) on my laptop
(Ubuntu 20.04, i7-8565u, 16gb RAM). 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 dc3ddf08 commit is responsible for the behavior described
above. Cursor iteration hangs due to Gr
[jira] [Commented] (IGNITE-13013) Thick client must not open server sockets when used by serverless functions
[
https://issues.apache.org/jira/browse/IGNITE-13013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17177744#comment-17177744
]
Ignite TC Bot commented on IGNITE-13013:
{panel:title=Branch: [pull/8074/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/8074/head] Base: [master] : New Tests
(2)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}SPI{color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=5538710]]
* {color:#013220}IgniteSpiTestSuite:
GridTotallyUnreachableClientTest.testTotallyUnreachableClient - PASSED{color}
* {color:#013220}IgniteSpiTestSuite:
GridSandboxedClientWithoutNetworkTest.testNodeWithoutNetwork - PASSED{color}
{panel}
[TeamCity *--> Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5536924&buildTypeId=IgniteTests24Java8_RunAll]
> Thick client must not open server sockets when used by serverless functions
> ---
>
> Key: IGNITE-13013
> URL: https://issues.apache.org/jira/browse/IGNITE-13013
> Project: Ignite
> Issue Type: Improvement
> Components: networking
>Affects Versions: 2.8
>Reporter: Denis A. Magda
>Assignee: Ivan Bessonov
>Priority: Critical
> Fix For: 2.10
>
> Attachments: image-2020-07-30-18-42-01-266.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> A thick client fails to start if being used inside of a serverless function
> such as AWS Lamda or Azure Functions. Cloud providers prohibit opening
> network ports to accept connections on the function's end. In short, the
> function can only connect to a remote address.
> To reproduce, you can follow this tutorial and swap the thin client (used in
> the tutorial) with the thick one:
> https://www.gridgain.com/docs/tutorials/serverless/azure_functions_tutorial
> The thick client needs to support a mode when the communication SPI doesn't
> create a server socket if the client is used for serverless computing. This
> improvement looks like an extra task of this initiative:
> https://issues.apache.org/jira/browse/IGNITE-12438
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13345) Warming up strategy
[
https://issues.apache.org/jira/browse/IGNITE-13345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17177747#comment-17177747
]
Ignite TC Bot commented on IGNITE-13345:
{panel:title=Branch: [pull/8148/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/8148/head] Base: [master] : New Tests
(14)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}MVCC PDS 4{color} [[tests
7|https://ci.ignite.apache.org/viewLog.html?buildId=5538566]]
* {color:#013220}IgnitePdsMvccTestSuite4: WarmUpSelfTest.testStopWarmUpByMXBean
- PASSED{color}
* {color:#013220}IgnitePdsMvccTestSuite4:
WarmUpSelfTest.testNonPersistentDataRegionWarmUpConfiguration - PASSED{color}
* {color:#013220}IgnitePdsMvccTestSuite4:
WarmUpSelfTest.testUnknownDataRegionWarmUpConfiguration - PASSED{color}
* {color:#013220}IgnitePdsMvccTestSuite4:
WarmUpSelfTest.testUnknownDefaultWarmUpConfiguration - PASSED{color}
* {color:#013220}IgnitePdsMvccTestSuite4:
WarmUpSelfTest.testExecutionStrategies - PASSED{color}
* {color:#013220}IgnitePdsMvccTestSuite4:
WarmUpSelfTest.testAvailableWarmUpStrategies - PASSED{color}
* {color:#013220}IgnitePdsMvccTestSuite4: WarmUpSelfTest.testStopWarmUp -
PASSED{color}
{color:#8b}PDS 4{color} [[tests
7|https://ci.ignite.apache.org/viewLog.html?buildId=5538539]]
* {color:#013220}IgnitePdsTestSuite4:
WarmUpSelfTest.testNonPersistentDataRegionWarmUpConfiguration - PASSED{color}
* {color:#013220}IgnitePdsTestSuite4:
WarmUpSelfTest.testUnknownDataRegionWarmUpConfiguration - PASSED{color}
* {color:#013220}IgnitePdsTestSuite4:
WarmUpSelfTest.testUnknownDefaultWarmUpConfiguration - PASSED{color}
* {color:#013220}IgnitePdsTestSuite4: WarmUpSelfTest.testExecutionStrategies -
PASSED{color}
* {color:#013220}IgnitePdsTestSuite4:
WarmUpSelfTest.testAvailableWarmUpStrategies - PASSED{color}
* {color:#013220}IgnitePdsTestSuite4: WarmUpSelfTest.testStopWarmUp -
PASSED{color}
* {color:#013220}IgnitePdsTestSuite4: WarmUpSelfTest.testStopWarmUpByMXBean -
PASSED{color}
{panel}
[TeamCity *--> Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5538575&buildTypeId=IgniteTests24Java8_RunAll]
> Warming up strategy
> ---
>
> Key: IGNITE-13345
> URL: https://issues.apache.org/jira/browse/IGNITE-13345
> Project: Ignite
> Issue Type: New Feature
>Reporter: Kirill Tkalenko
>Assignee: Kirill Tkalenko
>Priority: Major
> Labels: IEP-40
> Fix For: 2.10
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Summary of
> [Dev-list|http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSSION-Cache-warmup-td48582.html]
> # Adding a marker interface
> *org.apache.ignite.configuration.WarmUpConfiguration*;
> # Adding a configuration to
> ##
> *org.apache.ignite.configuration.DataRegionConfiguration#setWarmUpConfiguration*
> ##
> *org.apache.ignite.configuration.DataStorageConfiguration#setDefaultWarmUpConfiguration*
> # Add an internal warm-up interface that will start in [1] after [2] (after
> recovery);
> {code:java}
> package org.apache.ignite.internal.processors.cache.warmup;
> import org.apache.ignite.IgniteCheckedException;
> import org.apache.ignite.configuration.WarmUpConfiguration;
> import org.apache.ignite.internal.GridKernalContext;
> import org.apache.ignite.internal.processors.cache.persistence.DataRegion;
> /**
> * Interface for warming up.
> */
> public interface WarmUpStrategy {
> /**
> * Returns configuration class for mapping to strategy.
> *
> * @return Configuration class.
> */
> Class configClass();
> /**
> * Warm up.
> *
> * @param kernalCtx Kernal context.
> * @param cfg Warm-up configuration.
> * @param regionData region.
> * @throws IgniteCheckedException if faild.
> */
> void warmUp(GridKernalContext kernalCtx, T cfg, DataRegion region) throws
> IgniteCheckedException;
> /**
> * Closing warm up.
> *
> * @throws IgniteCheckedException if faild.
> */
> void close() throws IgniteCheckedException;
> }
> {code}
> # Adding an internal plugin extension for add own strategies;
> {code:java}
> package org.apache.ignite.internal.processors.cache.warmup;
>
> import java.util.Collection;
> import org.apache.ignite.plugin.Extension;
>
> /**
> * Interface for getting warm-up strategies from plugins.
> */
> public interface WarmUpStrategySupplier extends Extension {
> /**
> * Getting warm-up strategies.
> *
> * @return Warm-up strategies.
> */
> Collection strategies();
> }
> {code}
> # Adding strategies:
> ## Without implementation, for the possibility of disabling the warm-up: NoOP
> ## Loading everything while there is RAM with priorit
[jira] [Updated] (IGNITE-13363) GridDhtCacheEntry::toString locks
[
https://issues.apache.org/jira/browse/IGNITE-13363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stepachev Maksim updated IGNITE-13363:
--
Fix Version/s: (was: 3.0)
2.10
> GridDhtCacheEntry::toString locks
> -
>
> Key: IGNITE-13363
> URL: https://issues.apache.org/jira/browse/IGNITE-13363
> Project: Ignite
> Issue Type: Bug
> Components: networking
>Affects Versions: 2.8.1
>Reporter: Stepachev Maksim
>Assignee: Stepachev Maksim
>Priority: Major
> Fix For: 2.10
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> `GridDhtCacheEntry::toString` locks the entry which may lead to dead locks
> and, I assume, even performance issues.
> We, naturally, call `toString` on everything all the time and it needs to be
> the safest and the lightest possible operation.
> Example of a hang with locking toString:
>
> {{Thread [name="grid-timeout-worker-#71%GRIDC1%", id=98, state=WAITING,
> blockCnt=2, waitCnt=14196]
> Lock
> [object=java.util.concurrent.locks.ReentrantLock$NonfairSync@20c96143,
> ownerName=exchange-worker-#188%GRIDC1%, ownerId=265]
> at java.base@11.0.2/jdk.internal.misc.Unsafe.park(Native Method)
> at
> java.base@11.0.2/java.util.concurrent.locks.LockSupport.park(LockSupport.java:194)
> at
> java.base@11.0.2/java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:885)
> at
> java.base@11.0.2/java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:917)
> at
> java.base@11.0.2/java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1240)
> at
> java.base@11.0.2/java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:267)
> at
> app//o.a.i.i.processors.cache.GridCacheMapEntry.lockEntry(GridCacheMapEntry.java:5051)
> at
> app//o.a.i.i.processors.cache.distributed.dht.GridDhtCacheEntry.toString(GridDhtCacheEntry.java:819)
> at java.base@11.0.2/java.lang.String.valueOf(String.java:2951)
> at app//o.a.i.i.util.GridStringBuilder.a(GridStringBuilder.java:101)
> at
> app//o.a.i.i.util.tostring.SBLimitedLength.a(SBLimitedLength.java:88)
> at
> app//o.a.i.i.util.tostring.GridToStringBuilder.toString(GridToStringBuilder.java:939)
> at
> app//o.a.i.i.util.tostring.GridToStringBuilder.toStringImpl(GridToStringBuilder.java:1005)
> at
> app//o.a.i.i.util.tostring.GridToStringBuilder.toString(GridToStringBuilder.java:826)
> at
> app//o.a.i.i.util.tostring.GridToStringBuilder.toString(GridToStringBuilder.java:783)
> at
> app//o.a.i.i.processors.cache.transactions.IgniteTxEntry.toString(IgniteTxEntry.java:1273)
> at java.base@11.0.2/java.lang.String.valueOf(String.java:2951)
> at
> java.base@11.0.2/java.lang.StringBuilder.append(StringBuilder.java:168)
> at
> java.base@11.0.2/java.util.AbstractCollection.toString(AbstractCollection.java:473)
> at java.base@11.0.2/java.lang.String.valueOf(String.java:2951)
> at app//o.a.i.i.util.GridStringBuilder.a(GridStringBuilder.java:101)
> at
> app//o.a.i.i.util.tostring.SBLimitedLength.a(SBLimitedLength.java:88)
> at
> app//o.a.i.i.util.tostring.GridToStringBuilder.toString(GridToStringBuilder.java:939)
> at
> app//o.a.i.i.util.tostring.GridToStringBuilder.toStringImpl(GridToStringBuilder.java:1005)
> at
> app//o.a.i.i.util.tostring.GridToStringBuilder.toString(GridToStringBuilder.java:826)
> at
> app//o.a.i.i.util.tostring.GridToStringBuilder.toString(GridToStringBuilder.java:783)
> at
> app//o.a.i.i.processors.cache.distributed.GridDistributedTxMapping.toString(GridDistributedTxMapping.java:319)
> at java.base@11.0.2/java.lang.String.valueOf(String.java:2951)
> at app//o.a.i.i.util.GridStringBuilder.a(GridStringBuilder.java:101)
> at
> app//o.a.i.i.util.tostring.SBLimitedLength.a(SBLimitedLength.java:88)
> at
> app//o.a.i.i.util.tostring.GridToStringBuilder.toString(GridToStringBuilder.java:939)
> at
> app//o.a.i.i.util.tostring.GridToStringBuilder.toStringImpl(GridToStringBuilder.java:1005)
> at
> app//o.a.i.i.util.tostring.GridToStringBuilder.toString(GridToStringBuilder.java:864)
> at
> app//o.a.i.i.processors.cache.distributed.near.IgniteTxMappingsSingleImpl.toString(IgniteTxMappingsSingleImpl.java:99)
> at java.base@11.0.2/java.lang.String.valueOf(String.java:2951)
> at app//o.a.i.i.util.GridStringBuilder.a(GridStringBuilder.java:101)
> at
> app//o.a.i.i.util.tostring.SBLimitedLength.a(SBLimitedLength.java:88)
> at
> app//o.a.i.i.util.tostring.GridToStri
[jira] [Assigned] (IGNITE-12946) Add description to MBeans
[ https://issues.apache.org/jira/browse/IGNITE-12946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov reassigned IGNITE-12946: Assignee: (was: Nikolay Izhikov) > Add description to MBeans > - > > Key: IGNITE-12946 > URL: https://issues.apache.org/jira/browse/IGNITE-12946 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.8 >Reporter: Denis A. Magda >Priority: Major > Labels: IEP-35 > > Presently, application developers will see hundreds of metrics once connect > through JMX and it will be hard for them to sort out the valuable ones. > The documentation can do a great job outlining the right ones but we can also > add descriptions to MXBeans explaining what each metric reports. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13013) Thick client must not open server sockets when used by serverless functions
[ https://issues.apache.org/jira/browse/IGNITE-13013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17177759#comment-17177759 ] Sergey Chugunov commented on IGNITE-13013: -- [~ibessonov], I reviewed and merged your patch to master branch in commit *79031e59002b40d2a8dc0cad43475ce4b982adcb*. Thank you for contribution! > Thick client must not open server sockets when used by serverless functions > --- > > Key: IGNITE-13013 > URL: https://issues.apache.org/jira/browse/IGNITE-13013 > Project: Ignite > Issue Type: Improvement > Components: networking >Affects Versions: 2.8 >Reporter: Denis A. Magda >Assignee: Ivan Bessonov >Priority: Critical > Fix For: 2.10 > > Attachments: image-2020-07-30-18-42-01-266.png > > Time Spent: 20m > Remaining Estimate: 0h > > A thick client fails to start if being used inside of a serverless function > such as AWS Lamda or Azure Functions. Cloud providers prohibit opening > network ports to accept connections on the function's end. In short, the > function can only connect to a remote address. > To reproduce, you can follow this tutorial and swap the thin client (used in > the tutorial) with the thick one: > https://www.gridgain.com/docs/tutorials/serverless/azure_functions_tutorial > The thick client needs to support a mode when the communication SPI doesn't > create a server socket if the client is used for serverless computing. This > improvement looks like an extra task of this initiative: > https://issues.apache.org/jira/browse/IGNITE-12438 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13151) Checkpointer code refactoring: extracting classes from GridCacheDatabaseSharedManager
[ https://issues.apache.org/jira/browse/IGNITE-13151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17177799#comment-17177799 ] Sergey Chugunov commented on IGNITE-13151: -- [~akalashnikov], I merged your patch to master branch in commit *8d6a636b795a860974a7e86d3e2f54e9295616b6*. Thank you for contribution! > Checkpointer code refactoring: extracting classes from > GridCacheDatabaseSharedManager > - > > Key: IGNITE-13151 > URL: https://issues.apache.org/jira/browse/IGNITE-13151 > Project: Ignite > Issue Type: Sub-task > Components: persistence >Reporter: Sergey Chugunov >Assignee: Anton Kalashnikov >Priority: Major > Labels: IEP-47 > Time Spent: 20m > Remaining Estimate: 0h > > Checkpointer is at the center of Ignite persistence subsystem and more people > from the community understand it the better means it is more stable and more > efficient. > However for now checkpointer code sits inside of > GridCacheDatabaseSharedManager class and is entangled with this higher-level > and more general component. > To take a step forward to more modular checkpointer we need to do two things: > # Move checkpointer code outside database manager to a separate class. > (That's what this ticket is about.) > # Create a well-defined API of checkpointer that will allow us to create new > implementations of checkpointer in the future. An example of this is new > checkpointer implementation needed for defragmentation feature purposes. > (Should be done in a separate ticket) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13151) Checkpointer code refactoring: extracting classes from GridCacheDatabaseSharedManager
[ https://issues.apache.org/jira/browse/IGNITE-13151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Chugunov updated IGNITE-13151: - Fix Version/s: 2.10 > Checkpointer code refactoring: extracting classes from > GridCacheDatabaseSharedManager > - > > Key: IGNITE-13151 > URL: https://issues.apache.org/jira/browse/IGNITE-13151 > Project: Ignite > Issue Type: Sub-task > Components: persistence >Reporter: Sergey Chugunov >Assignee: Anton Kalashnikov >Priority: Major > Labels: IEP-47 > Fix For: 2.10 > > Time Spent: 20m > Remaining Estimate: 0h > > Checkpointer is at the center of Ignite persistence subsystem and more people > from the community understand it the better means it is more stable and more > efficient. > However for now checkpointer code sits inside of > GridCacheDatabaseSharedManager class and is entangled with this higher-level > and more general component. > To take a step forward to more modular checkpointer we need to do two things: > # Move checkpointer code outside database manager to a separate class. > (That's what this ticket is about.) > # Create a well-defined API of checkpointer that will allow us to create new > implementations of checkpointer in the future. An example of this is new > checkpointer implementation needed for defragmentation feature purposes. > (Should be done in a separate ticket) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-13198) Calcite integration. Rework error / cancel logic at execution
[ https://issues.apache.org/jira/browse/IGNITE-13198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Taras Ledkov reassigned IGNITE-13198: - Assignee: Igor Seliverstov (was: Taras Ledkov) > Calcite integration. Rework error / cancel logic at execution > - > > Key: IGNITE-13198 > URL: https://issues.apache.org/jira/browse/IGNITE-13198 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Taras Ledkov >Assignee: Igor Seliverstov >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > Change error & cancel logic on query execution. > *Error* > - propagated from source to downstream nodes. > - Always propagated to the RootNode; > - RootNode receive an error and cancel all execution tree. > *Cancel* > - propagated from downstream to source; > - any node may cancel its execution sub-tree; > - (technical details) to prevent race on Inbox creation Outbox resend Cancel > message to Inbox. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12350) MVCC activated and causing memory leak (OOM) despite no mvccEnabled caches
[
https://issues.apache.org/jira/browse/IGNITE-12350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17177816#comment-17177816
]
Ignite TC Bot commented on IGNITE-12350:
{panel:title=Branch: [pull/8152/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/8152/head] Base: [master] : New Tests
(2)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}MVCC Cache{color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=5538631]]
* {color:#013220}IgniteCacheMvccTestSuite:
MvccStructuresOverheadTest.testWithoutMvcc - PASSED{color}
* {color:#013220}IgniteCacheMvccTestSuite:
MvccStructuresOverheadTest.testWithMvcc - PASSED{color}
{panel}
[TeamCity *--> Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5538704&buildTypeId=IgniteTests24Java8_RunAll]
> MVCC activated and causing memory leak (OOM) despite no mvccEnabled caches
> --
>
> Key: IGNITE-12350
> URL: https://issues.apache.org/jira/browse/IGNITE-12350
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.7.5
>Reporter: Ming Vuong
>Assignee: Vladislav Pyatkov
>Priority: Major
> Attachments: MATheap.jpg, proxy-memory-leak.png, proxy-oom-2.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We have a critical memory leak where mvccCoordinator is still selected and
> mvcc is still 'activated' despite having no mvccEnabled caches, this is
> causing constant OOM crashes and issues on both server and client nodes.
> All client CacheAtomicityModes are of type ATOMIC, and for server config
> persistence is false, TCPDiscoverySpi used and PeerClassLoadingEnabled=true.
> There are two server JVM instances on two separate nodes. One of the servers
> consistently get an OOM error, as well as all clients, due to the same
> recoveryBallotBoxes HashMap constantly increasing in size and unable to be
> Garbage Collected.
> Attached is Eclipse Memory Analyzer Tool screenshot on the heap dump close to
> one of the server JVM OOM crashes. The same heap analysis result is apparent
> for all clients as well.
> !MATheap.jpg!
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12350) MVCC activated and causing memory leak (OOM) despite no mvccEnabled caches
[ https://issues.apache.org/jira/browse/IGNITE-12350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladislav Pyatkov updated IGNITE-12350: --- Reviewer: Igor Seliverstov > MVCC activated and causing memory leak (OOM) despite no mvccEnabled caches > -- > > Key: IGNITE-12350 > URL: https://issues.apache.org/jira/browse/IGNITE-12350 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.7.5 >Reporter: Ming Vuong >Assignee: Vladislav Pyatkov >Priority: Major > Attachments: MATheap.jpg, proxy-memory-leak.png, proxy-oom-2.png > > Time Spent: 10m > Remaining Estimate: 0h > > We have a critical memory leak where mvccCoordinator is still selected and > mvcc is still 'activated' despite having no mvccEnabled caches, this is > causing constant OOM crashes and issues on both server and client nodes. > All client CacheAtomicityModes are of type ATOMIC, and for server config > persistence is false, TCPDiscoverySpi used and PeerClassLoadingEnabled=true. > There are two server JVM instances on two separate nodes. One of the servers > consistently get an OOM error, as well as all clients, due to the same > recoveryBallotBoxes HashMap constantly increasing in size and unable to be > Garbage Collected. > Attached is Eclipse Memory Analyzer Tool screenshot on the heap dump close to > one of the server JVM OOM crashes. The same heap analysis result is apparent > for all clients as well. > !MATheap.jpg! -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12350) MVCC activated and causing memory leak (OOM) despite no mvccEnabled caches
[ https://issues.apache.org/jira/browse/IGNITE-12350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17177855#comment-17177855 ] Vladislav Pyatkov commented on IGNITE-12350: [~gvvinblade] Please, do a review? > MVCC activated and causing memory leak (OOM) despite no mvccEnabled caches > -- > > Key: IGNITE-12350 > URL: https://issues.apache.org/jira/browse/IGNITE-12350 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.7.5 >Reporter: Ming Vuong >Assignee: Vladislav Pyatkov >Priority: Major > Attachments: MATheap.jpg, proxy-memory-leak.png, proxy-oom-2.png > > Time Spent: 10m > Remaining Estimate: 0h > > We have a critical memory leak where mvccCoordinator is still selected and > mvcc is still 'activated' despite having no mvccEnabled caches, this is > causing constant OOM crashes and issues on both server and client nodes. > All client CacheAtomicityModes are of type ATOMIC, and for server config > persistence is false, TCPDiscoverySpi used and PeerClassLoadingEnabled=true. > There are two server JVM instances on two separate nodes. One of the servers > consistently get an OOM error, as well as all clients, due to the same > recoveryBallotBoxes HashMap constantly increasing in size and unable to be > Garbage Collected. > Attached is Eclipse Memory Analyzer Tool screenshot on the heap dump close to > one of the server JVM OOM crashes. The same heap analysis result is apparent > for all clients as well. > !MATheap.jpg! -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-12350) MVCC activated and causing memory leak (OOM) despite no mvccEnabled caches
[ https://issues.apache.org/jira/browse/IGNITE-12350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17177855#comment-17177855 ] Vladislav Pyatkov edited comment on IGNITE-12350 at 8/14/20, 4:15 PM: -- [~gvvinblade] Please, do a review. was (Author: v.pyatkov): [~gvvinblade] Please, do a review? > MVCC activated and causing memory leak (OOM) despite no mvccEnabled caches > -- > > Key: IGNITE-12350 > URL: https://issues.apache.org/jira/browse/IGNITE-12350 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.7.5 >Reporter: Ming Vuong >Assignee: Vladislav Pyatkov >Priority: Major > Attachments: MATheap.jpg, proxy-memory-leak.png, proxy-oom-2.png > > Time Spent: 10m > Remaining Estimate: 0h > > We have a critical memory leak where mvccCoordinator is still selected and > mvcc is still 'activated' despite having no mvccEnabled caches, this is > causing constant OOM crashes and issues on both server and client nodes. > All client CacheAtomicityModes are of type ATOMIC, and for server config > persistence is false, TCPDiscoverySpi used and PeerClassLoadingEnabled=true. > There are two server JVM instances on two separate nodes. One of the servers > consistently get an OOM error, as well as all clients, due to the same > recoveryBallotBoxes HashMap constantly increasing in size and unable to be > Garbage Collected. > Attached is Eclipse Memory Analyzer Tool screenshot on the heap dump close to > one of the server JVM OOM crashes. The same heap analysis result is apparent > for all clients as well. > !MATheap.jpg! -- This message was sent by Atlassian Jira (v8.3.4#803005)
[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). 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 may not be sent
correctly from the client node.
was:
The following test hangs intermittently (once for 4-5 runs) on my laptop
(Ubuntu 20.04, i7-8565u, 16gb RAM). 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 seem
[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). 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.
was:
The following test hangs intermittently (once for 4-5 runs) on my laptop
(Ubuntu 20.04, i7-8565u, 16gb RAM). 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}
[jira] [Resolved] (IGNITE-6785) Affinity field name forced to be upper-case
[
https://issues.apache.org/jira/browse/IGNITE-6785?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis A. Magda resolved IGNITE-6785.
Release Note: The issue will be solved automatically in Ignite 3.0 that
introduces a new storage format that is decoupled from the serialization logic.
Resolution: Won't Fix (was: Not A Problem)
> Affinity field name forced to be upper-case
> ---
>
> Key: IGNITE-6785
> URL: https://issues.apache.org/jira/browse/IGNITE-6785
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.1, 2.8
>Reporter: Denis A. Magda
>Priority: Major
> Labels: newbie, usability
> Fix For: 2.10
>
> Attachments: SqlAffinityKeyTest.java, sql_bug.zip
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> If an SQL schema and cache is created with CREATE TABLE command and a user
> wants to use key-value APIs creating its own custom key class, then (at
> least) the key class's affinity field forced to be written in upper-case.
> Steps to reproduce using the project attached:
> * start a node with {{./ignite.sh ../examples/config/example-ignite.xml}}.
> * create {{City}} table using {{ignite_world.sql}}. SQLline is one of the
> quickest ways: https://apacheignite-sql.readme.io/docs/sqlline
> * Run {{KeyValueDataProcessing}} to catch the exception below
> {noformat}
> Exception in thread "main" class
> org.apache.ignite.binary.BinaryObjectException: Binary type has different
> affinity key fields [typeName=demo.model.CityKey,
> affKeyFieldName1=COUNTRYCODE, affKeyFieldName2=countryCode]
> at
> org.apache.ignite.internal.binary.BinaryUtils.mergeMetadata(BinaryUtils.java:987)
> {noformat}
> If fact {{CityKey}} names the affinity field in the same way as in CREATE
> TABLE - {{countryCode}}.
> Next, run {{KeyValueBinaryDataProcessing}} to spot another weird thing:
> * BinaryObject key accepts `countryCode` as the affinity field name.
> * If to print our a binary object value then all the fields are in the
> upper-case (they were not defined this way in CREATE TABLE):
> {noformat}
> demo.model.City [idHash=1613627715, hash=-1386587499, DISTRICT=Noord-Holland,
> POPULATION=711200, NAME=Amsterdam]
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (IGNITE-6785) Affinity field name forced to be upper-case
[
https://issues.apache.org/jira/browse/IGNITE-6785?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis A. Magda closed IGNITE-6785.
--
> Affinity field name forced to be upper-case
> ---
>
> Key: IGNITE-6785
> URL: https://issues.apache.org/jira/browse/IGNITE-6785
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.1, 2.8
>Reporter: Denis A. Magda
>Priority: Major
> Labels: newbie, usability
> Fix For: 2.10
>
> Attachments: SqlAffinityKeyTest.java, sql_bug.zip
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> If an SQL schema and cache is created with CREATE TABLE command and a user
> wants to use key-value APIs creating its own custom key class, then (at
> least) the key class's affinity field forced to be written in upper-case.
> Steps to reproduce using the project attached:
> * start a node with {{./ignite.sh ../examples/config/example-ignite.xml}}.
> * create {{City}} table using {{ignite_world.sql}}. SQLline is one of the
> quickest ways: https://apacheignite-sql.readme.io/docs/sqlline
> * Run {{KeyValueDataProcessing}} to catch the exception below
> {noformat}
> Exception in thread "main" class
> org.apache.ignite.binary.BinaryObjectException: Binary type has different
> affinity key fields [typeName=demo.model.CityKey,
> affKeyFieldName1=COUNTRYCODE, affKeyFieldName2=countryCode]
> at
> org.apache.ignite.internal.binary.BinaryUtils.mergeMetadata(BinaryUtils.java:987)
> {noformat}
> If fact {{CityKey}} names the affinity field in the same way as in CREATE
> TABLE - {{countryCode}}.
> Next, run {{KeyValueBinaryDataProcessing}} to spot another weird thing:
> * BinaryObject key accepts `countryCode` as the affinity field name.
> * If to print our a binary object value then all the fields are in the
> upper-case (they were not defined this way in CREATE TABLE):
> {noformat}
> demo.model.City [idHash=1613627715, hash=-1386587499, DISTRICT=Noord-Holland,
> POPULATION=711200, NAME=Amsterdam]
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12754) .NET: Thin Client: Service invocation
[
https://issues.apache.org/jira/browse/IGNITE-12754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17178091#comment-17178091
]
Ignite TC Bot commented on IGNITE-12754:
{panel:title=Branch: [pull/8151/head] Base: [master] : Possible Blockers
(6)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Cache 2{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=5539970]]
* IgniteCacheTestSuite2:
GridCachePartitionedTxSingleThreadedSelfTest.testOptimisticRepeatableReadRollback
- Test has low fail rate in base branch 0,0% and is not flaky
{color:#d04437}Cache (Restarts) 1{color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=5539966]]
{color:#d04437}MVCC Cache 7{color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=5540010]]
{color:#d04437}MVCC Queries{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=5539954]]
* IgniteCacheMvccSqlTestSuite:
CacheMvccPartitionedSqlTxQueriesWithReducerTest.testQueryReducerDeadlockInsertWithTxTimeout
- Test has low fail rate in base branch 0,0% and is not flaky
{color:#d04437}Platform .NET (Core Linux){color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=5539991]]
{color:#d04437}Cache 1{color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=5539969]]
{panel}
{panel:title=Branch: [pull/8151/head] Base: [master] : New Tests
(17)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Platform .NET{color} [[tests
17|https://ci.ignite.apache.org/viewLog.html?buildId=5539990]]
* {color:#013220}exe:
ServicesClientTest.TestServicesWithCustomClusterGroupInvokeOnSpecifiedNodes -
PASSED{color}
* {color:#013220}exe:
ServicesClientTest.TestServerKeepBinaryPassesServerSideArgumentsInBinaryMode -
PASSED{color}
* {color:#013220}exe:
ServicesClientTest.TestServerAndClientKeepBinaryPassesBinaryObjectsOnServerAndClient
- PASSED{color}
* {color:#013220}exe: ServicesClientTest.TestPropertyCalls - PASSED{color}
* {color:#013220}exe: ServicesClientTest.TestOverloadResolution - PASSED{color}
* {color:#013220}exe: ServicesClientTest.TestObjectMethodCall - PASSED{color}
* {color:#013220}exe: ServicesClientTest.TestObjectArrayBinary - PASSED{color}
* {color:#013220}exe: ServicesClientTest.TestVoidMethodCall - PASSED{color}
* {color:#013220}exe:
ServicesClientTest.TestClientKeepBinaryReturnsServiceInvocationResultInBinaryMode
- PASSED{color}
* {color:#013220}exe: ServicesClientTest.TestBasicServiceCall - PASSED{color}
* {color:#013220}exe: ServicesClientTest.TestAllArgumentTypes - PASSED{color}
... and 6 new tests
{panel}
[TeamCity *--> Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5540025&buildTypeId=IgniteTests24Java8_RunAll]
> .NET: Thin Client: Service invocation
> -
>
> Key: IGNITE-12754
> URL: https://issues.apache.org/jira/browse/IGNITE-12754
> Project: Ignite
> Issue Type: New Feature
> Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: .NET, iep-46
> Fix For: 2.10
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Provide an API to invoke Ignite Services from Thin Clients.
> .NET API:
> {code}
> IIgniteClient.GetServices().GetServiceProxy("name").Bar();
> {code}
> See
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-46%3A+Thin+Client+Service+Invocation
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
