[jira] [Updated] (IGNITE-14303) H2Cursor doesn't match to contract of the GridCursor.
[ https://issues.apache.org/jira/browse/IGNITE-14303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Timonin updated IGNITE-14303: Description: Queries like "select max(col) from table" relies on behavior of H2Cursor that differs to GridCursor: # It is not "first before". So H2 invoke cursor.get() first, without cursor.next(). So SingleCursor handles both cases "before first" and "on first". # Empty cursor it doesn't expect exception for get. It checks the return value for NULL. Currently we can't do smth with that as this logic is implemented within H2. But Calcite should handle that. was: Queries like "select max(col) from table" relies on behavior of H2Cursor that differs to GridCursor: # It is not "first before". So H2 invoke cursor.get() first, without cursor.next(). # Then for empty cursor it doesn't expect exception for get. It checks the return value for NULL. Currently we can't do smth with that as this logic is implemented within H2. But Calcite should handle that. > H2Cursor doesn't match to contract of the GridCursor. > - > > Key: IGNITE-14303 > URL: https://issues.apache.org/jira/browse/IGNITE-14303 > Project: Ignite > Issue Type: Bug >Reporter: Maksim Timonin >Assignee: Maksim Timonin >Priority: Major > > Queries like "select max(col) from table" relies on behavior of H2Cursor that > differs to GridCursor: > # It is not "first before". So H2 invoke cursor.get() first, without > cursor.next(). So SingleCursor handles both cases "before first" and "on > first". > # Empty cursor it doesn't expect exception for get. It checks the return > value for NULL. > Currently we can't do smth with that as this logic is implemented within H2. > But Calcite should handle that. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14303) H2Cursor doesn't match to contract of the GridCursor.
Maksim Timonin created IGNITE-14303: --- Summary: H2Cursor doesn't match to contract of the GridCursor. Key: IGNITE-14303 URL: https://issues.apache.org/jira/browse/IGNITE-14303 Project: Ignite Issue Type: Bug Reporter: Maksim Timonin Assignee: Maksim Timonin Queries like "select max(col) from table" relies on behavior of H2Cursor that differs to GridCursor: # It is not "first before". So H2 invoke cursor.get() first, without cursor.next(). # Then for empty cursor it doesn't expect exception for get. It checks the return value for NULL. Currently we can't do smth with that as this logic is implemented within H2. But Calcite should handle that. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14198) Define interface for meta storage client
[ https://issues.apache.org/jira/browse/IGNITE-14198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17299374#comment-17299374 ] Alexander Belyak commented on IGNITE-14198: --- 1) How watch method shold look like? I mean - I need to track some key and what should I do for it? I wan't to just call: msClient.watch(key, myLsnr) and get actual value as initial event to avoid writing additional code like: processKey(msClient.get(key)); msClient.watch(key, (someHandlerHere like: event -> processKey(event.newKey()); because it lead to gap between reading and subscribing to key changes so I can lost update. And if I swap lines in example above - I can get the same update twice. 2) What about security? Can I configure some access control rules? Or even audit log? 3) Will metastore be encrypted or compressed somehow? (if yes - should API be aware of it?) > Define interface for meta storage client > > > Key: IGNITE-14198 > URL: https://issues.apache.org/jira/browse/IGNITE-14198 > Project: Ignite > Issue Type: New Feature >Reporter: Andrey N. Gura >Assignee: Andrey N. Gura >Priority: Major > Labels: iep-61, ignite-3 > Fix For: 3.0.0-alpha2 > > Time Spent: 20m > Remaining Estimate: 0h > > Interface for meta storage client should be defined in order to unblock > development and unit-testing. > Interface implementation is not needed on this stage. > We need to crystallize the metastorage interface prototype from the IEP to > understand how it will be integrated with other system components. > Need to cover: > * Asynchrony aspects > * Possible error codes (connection failure -> unknown result vs Raft failure > -> known result, etc) > * Complex multi-updates (aka transactions) > * Watchers. Each node can watch all updates and filter locally or adjust the > watched ranges dynamically (consistency is important here) > These interfaces are considered "client" interfaces as they will be available > on all nodes in the cluster -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14302) Generated configuration classes break PMD suite in REST module
Ivan Bessonov created IGNITE-14302: -- Summary: Generated configuration classes break PMD suite in REST module Key: IGNITE-14302 URL: https://issues.apache.org/jira/browse/IGNITE-14302 Project: Ignite Issue Type: Sub-task Reporter: Ivan Bessonov Assignee: Ivan Bessonov https://ci.ignite.apache.org/buildConfiguration/ignite3_Tests_SanityChecks_Pmd?branch=pull%2F65=overview=builds#all-projects -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14293) .NET: AffinityKey does not work
[
https://issues.apache.org/jira/browse/IGNITE-14293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17299118#comment-17299118
]
Pavel Tupitsyn commented on IGNITE-14293:
-
Cherry-picked to ignite-2.10: 9ee9a8f0537a26d06853f06cfdaf9e0ab5a2818e
> .NET: AffinityKey does not work
> ---
>
> Key: IGNITE-14293
> URL: https://issues.apache.org/jira/browse/IGNITE-14293
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 2.10
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Blocker
> Labels: .NET
> Fix For: 2.10
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> {{AffinityKey}} does not work as expected - {{Affinity}} property is not used
> for affinity calculation.
> This is caused by IGNITE-13160: {{AffinityKey}} system type is overwritten by
> {{UnmanagedCallbacks.BinaryTypeGet}} call. As a result, this type becomes a
> regular, user type, and does not map to a corresponding type on the Java side.
> * Add test that combines QueryEntity with AffinityKey
> * Check that other system types (IgniteUuid, etc) don't have this problem,
> add tests
> * Make sure we never overwrite system types during registration
> * Improve examples tests: Thick Sql example provides inconsistent output due
> to this bug
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14226) Ducktape tests of rebalance
[
https://issues.apache.org/jira/browse/IGNITE-14226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Sorokin updated IGNITE-14226:
-
Description:
There should be tests of rebalance for both in-memory caches and persistent
caches.
In case of persistent caches, the tests also should check both modes of
rebalance: full and historical (asserts is needed that the proper mode of
rebalance was worked).
Basic scenario:
Testing of rebalance triggered by two event types: node join and node left the
topology (baseline change in persistent mode).
Extended scenario:
Node join or left during rebalance process.
Test parameters:
# Initial node count (derived from test context);
# Cache count - the count of caches to create and data preload;
# Cache entry count - the count of entries per cache to preload;
# Cache entry size - the size of each cache entry in bytes;
# Rebalance thread pool size - the value for
{{IgniteConfiguration#rebalanceThreadPoolSize}} property (see [configuring
rebalance thread pool
title|https://ignite.apache.org/docs/latest/data-rebalancing#configuring-rebalance-thread-pool]),
expected that greater value makes rebalance faster.
# Rebalance batch size - the value for
{{IgniteConfiguration#rebalanceBatchSize}} property (see [other rebalance
properties|https://ignite.apache.org/docs/latest/data-rebalancing#other-properties]),
expected that greater value makes rebalance faster on large data or
[throttling|https://ignite.apache.org/docs/latest/data-rebalancing#throttling]
enabled (rebalanceThrottling > 0).
# Rebalance throttle - the value for {{IgniteConfiguration#rebalanceThrottle}}
property (see [rebalance message
throttling|https://ignite.apache.org/docs/latest/data-rebalancing#throttling],
[other rebalance
properties|https://ignite.apache.org/docs/latest/data-rebalancing#other-properties]),
0 - throttling disabled, greater value makes rebalance slower.
Test result: time taken to rebalance process.
was:
There should be tests of rebalance for both in-memory caches and persistent
caches.
In case of persistent caches, the tests also should check both modes of
rebalance: full and historical (asserts is needed that the proper mode of
rebalance was worked).
Basic scenario:
Testing of rebalance triggered by two event types: node join and node left the
topology (baseline change in persistent mode).
Extended scenario:
Node join or left during rebalance process.
Test parameters:
# Initial node count (derived from test context);
# Cache count - the count of caches to create and data preload;
# Cache entry count - the count of entries per cache to preload;
# Cache entry size - the size of each cache entry in bytes;
# Rebalance thread pool size - the value for
IgniteConfiguration.rebalanceThreadPoolSize property (see [configuring
rebalance thread pool
title|https://ignite.apache.org/docs/latest/data-rebalancing#configuring-rebalance-thread-pool]),
expected that greater value makes rebalance faster.
# Rebalance batch size - the value for IgniteConfiguration.rebalanceBatchSize
property (see [other rebalance
properties|https://ignite.apache.org/docs/latest/data-rebalancing#other-properties]),
expected that greater value makes rebalance faster on large data or
[throttling|https://ignite.apache.org/docs/latest/data-rebalancing#throttling]
enabled (rebalanceThrottling > 0).
# Rebalance throttle - the value for IgniteConfiguration.rebalanceThrottle
property (see [rebalance message
throttling|https://ignite.apache.org/docs/latest/data-rebalancing#throttling],
[other rebalance
properties|https://ignite.apache.org/docs/latest/data-rebalancing#other-properties]),
0 - throttling disabled, greater value makes rebalance slower.
Test result: time taken to rebalance process.
> Ducktape tests of rebalance
> ---
>
> Key: IGNITE-14226
> URL: https://issues.apache.org/jira/browse/IGNITE-14226
> Project: Ignite
> Issue Type: Test
>Reporter: Dmitriy Sorokin
>Assignee: Dmitriy Sorokin
>Priority: Major
>
> There should be tests of rebalance for both in-memory caches and persistent
> caches.
> In case of persistent caches, the tests also should check both modes of
> rebalance: full and historical (asserts is needed that the proper mode of
> rebalance was worked).
> Basic scenario:
> Testing of rebalance triggered by two event types: node join and node left
> the topology (baseline change in persistent mode).
> Extended scenario:
> Node join or left during rebalance process.
> Test parameters:
> # Initial node count (derived from test context);
> # Cache count - the count of caches to create and data preload;
> # Cache entry count - the count of entries per cache to preload;
> # Cache entry size - the size of each cache entry in bytes;
> # Rebalance thread pool size - the
[jira] [Updated] (IGNITE-14228) Ducktape test of rebalance for in-memory mode
[
https://issues.apache.org/jira/browse/IGNITE-14228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Sorokin updated IGNITE-14228:
-
Description:
This test should check the rebalance on in-memory caches in basic scenario:
rebalance triggered by two event types: node join and node left the topology.
The test should be able to run on large amounts of data enough to ensure
rebalancing time about of several minutes.
Test parameters:
# Initial node count (derived from test context);
# Cache count - the count of caches to create and data preload;
# Cache entry count - the count of entries per cache to preload;
# Cache entry size - the size of each cache entry in bytes;
# Rebalance thread pool size - the value for
{{IgniteConfiguration#rebalanceThreadPoolSize}} property (see [configuring
rebalance thread pool
title|https://ignite.apache.org/docs/latest/data-rebalancing#configuring-rebalance-thread-pool]),
expected that greater value makes rebalance faster.
# Rebalance batch size - the value for
{{IgniteConfiguration#rebalanceBatchSize}} property (see [other rebalance
properties|https://ignite.apache.org/docs/latest/data-rebalancing#other-properties]),
expected that greater value makes rebalance faster on large data or
[throttling|https://ignite.apache.org/docs/latest/data-rebalancing#throttling]
enabled (rebalanceThrottling > 0).
# Rebalance throttle - the value for {{IgniteConfiguration#rebalanceThrottle}}
property (see [rebalance message
throttling|https://ignite.apache.org/docs/latest/data-rebalancing#throttling],
[other rebalance
properties|https://ignite.apache.org/docs/latest/data-rebalancing#other-properties]),
0 - throttling disabled, greater value makes rebalance slower.
Test result: time taken to rebalance process.
was:
This test should check the rebalance on in-memory caches in basic scenario:
rebalance triggered by two event types: node join and node left the topology.
The test should be able to run on large amounts of data enough to ensure
rebalancing time about of several minutes.
Test parameters:
# Initial node count (derived from test context);
# Cache count - the count of caches to create and data preload;
# Cache entry count - the count of entries per cache to preload;
# Cache entry size - the size of each cache entry in bytes;
# Rebalance thread pool size - the value for
{{IgniteConfiguration#rebalanceThreadPoolSize}} property (see [configuring
rebalance thread pool
title|https://ignite.apache.org/docs/latest/data-rebalancing#configuring-rebalance-thread-pool]),
expected that greater value makes rebalance faster.
# Rebalance batch size - the value for
{{IgniteConfiguration#rebalanceBatchSize}} property (see [other rebalance
properties|https://ignite.apache.org/docs/latest/data-rebalancing#other-properties]),
expected that greater value makes rebalance faster on large data or
[throttling|https://ignite.apache.org/docs/latest/data-rebalancing#throttling]
enabled (rebalanceThrottling > 0).
# Rebalance throttle - the value for {{IgniteConfiguration.rebalanceThrottle}}
property (see [rebalance message
throttling|https://ignite.apache.org/docs/latest/data-rebalancing#throttling],
[other rebalance
properties|https://ignite.apache.org/docs/latest/data-rebalancing#other-properties]),
0 - throttling disabled, greater value makes rebalance slower.
Test result: time taken to rebalance process.
> Ducktape test of rebalance for in-memory mode
> -
>
> Key: IGNITE-14228
> URL: https://issues.apache.org/jira/browse/IGNITE-14228
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Dmitriy Sorokin
>Assignee: Dmitriy Sorokin
>Priority: Major
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> This test should check the rebalance on in-memory caches in basic scenario:
> rebalance triggered by two event types: node join and node left the topology.
> The test should be able to run on large amounts of data enough to ensure
> rebalancing time about of several minutes.
> Test parameters:
> # Initial node count (derived from test context);
> # Cache count - the count of caches to create and data preload;
> # Cache entry count - the count of entries per cache to preload;
> # Cache entry size - the size of each cache entry in bytes;
> # Rebalance thread pool size - the value for
> {{IgniteConfiguration#rebalanceThreadPoolSize}} property (see [configuring
> rebalance thread pool
> title|https://ignite.apache.org/docs/latest/data-rebalancing#configuring-rebalance-thread-pool]),
> expected that greater value makes rebalance faster.
> # Rebalance batch size - the value for
> {{IgniteConfiguration#rebalanceBatchSize}} property (see [other rebalance
> properties|https://ignite.apache.org/docs/latest/data-rebalancing#other-properties]),
>
[jira] [Created] (IGNITE-14301) Authentication processor can hang all user management operation after server node reconnect
Mikhail Petrov created IGNITE-14301: --- Summary: Authentication processor can hang all user management operation after server node reconnect Key: IGNITE-14301 URL: https://issues.apache.org/jira/browse/IGNITE-14301 Project: Ignite Issue Type: Bug Reporter: Mikhail Petrov First for all look at the test - AuthenticationProcessorNodeRestartTest#testConcurrentAddUpdateRemoveNodeRestartServer - [TC history|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-8873434544416175780=testDetails] The first problem with this test is that user management operations(add/update/remove) create too many discovery messages. So discovery custom message history size is not enough to properly skip duplicated custom messages that can be sent across the ring during server node reconnect. It leads to test failures due to duplication of user management operations (see GridDiscoveryManager#discoCacheHist, IGNITE_DISCOVERY_HISTORY_SIZE system property, and ServerImpl.RingMessageWorker#sendMessageAcrossRing). If the discovery history size will be increased significantly, the test stops failing and starts hanging. The steps that lead to this: 1. Client node sent UserProposedMessage across the ring while one node is offline due to reconnect. 2. Alive server nodes update their local user lists and finish the operation. 3. Reconnected node joins the ring and receives an updated user list from the coordinator. 4. Reconnected node receives duplicated UserProposedMessage that has been already handled by all nodes, handles it, and sents UserManagementOperationFinishedMessage to the coordinator and start to wait for the UserAcceptedMessage from it. But the coordinator has already finished this operation. So the thread that responsible for user management operation on the reconnected node becomes blocked (see IgniteAuthenticationProcessor.UserOperationWorker#body). 5. Client node starts the next operation that needs all alive nodes to respond with UserManagementOperationFinishedMessage. But reconnected node authentication thread is blocked. So this operation can't be completed at all. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14224) Extend logging of client failure handling.
[
https://issues.apache.org/jira/browse/IGNITE-14224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17299020#comment-17299020
]
Ignite TC Bot commented on IGNITE-14224:
{panel:title=Branch: [pull/8824/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/8824/head] Base: [master] : New Tests
(1)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Java Client{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=5908337]]
* {color:#013220}IgniteClientTestSuite:
IgniteClientFailuresTest.testExchangeWorkerIsNotTreatedAsBlockedWhenClientNodeFails
- PASSED{color}
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5908420buildTypeId=IgniteTests24Java8_RunAll]
> Extend logging of client failure handling.
> --
>
> Key: IGNITE-14224
> URL: https://issues.apache.org/jira/browse/IGNITE-14224
> Project: Ignite
> Issue Type: Improvement
> Components: clients
>Affects Versions: 2.9.1
>Reporter: Stanilovsky Evgeny
>Assignee: Stanilovsky Evgeny
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> # "Finished serving remote node connection " but this message doesn't contain
> node id, it should be added (check
> org.apache.ignite.spi.discovery.tcp.ServerImpl.SocketReader#body).
> # When client worker is removed from clientMsgWorkers,
> org.apache.ignite.internal.util.IgniteUtils#closeQuiet(java.lang.AutoCloseable)
> is used to close the socket, we don't see any exception if it has happened,
> closeQuiet should be replaced with
> org.apache.ignite.internal.util.IgniteUtils#close(java.lang.AutoCloseable,
> org.apache.ignite.IgniteLogger) which works in the same way but prints
> exception.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-14300) Rebalance speed as part of test result data
Dmitriy Sorokin created IGNITE-14300: Summary: Rebalance speed as part of test result data Key: IGNITE-14300 URL: https://issues.apache.org/jira/browse/IGNITE-14300 Project: Ignite Issue Type: Sub-task Reporter: Dmitriy Sorokin Assignee: Dmitriy Sorokin Need to add properly calculated rebalance speed value to the test result data. To do that, need to get the total rebalanced data size using jmx metrics or control.sh utility. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13348) Creating IgniteAtomicLong from the client node may hang.
[
https://issues.apache.org/jira/browse/IGNITE-13348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-13348:
-
Reviewer: Vyacheslav Koptilin (was: Slava Koptilin)
> Creating IgniteAtomicLong from the client node may hang.
>
>
> Key: IGNITE-13348
> URL: https://issues.apache.org/jira/browse/IGNITE-13348
> Project: Ignite
> Issue Type: Bug
>Reporter: Vyacheslav Koptilin
>Assignee: Vyacheslav Koptilin
>Priority: Major
> Fix For: 2.11
>
> Attachments: DataStructuresInitializationTest.java
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> It looks like, the data structure processor does not properly initialize when
> a client node connects to a cluster that changes its own state (state
> transition from the inactive state to active).
> reproducer attached.
> *UPDATE*
> It seems to me, the root cause of the issue is that {{joinFut}} is always
> completed with {{false}}.
> {code:java|title=GridClusterStateProcessor.java}
> /** {@inheritDoc} */
> @Override public void onStateFinishMessage(ChangeGlobalStateFinishMessage
> msg) {
> DiscoveryDataClusterState discoClusterState = globalState;
> if (msg.requestId().equals(discoClusterState.transitionRequestId())) {
> ...
> TransitionOnJoinWaitFuture joinFut = this.joinFut;
> if (joinFut != null)
> joinFut.onDone(false);
> ...
> }
> else
> U.warn(log, "Received state finish message with unexpected ID: "
> + msg);
> }
> {code}
> On the other hand, this value is used to determine the state of the cluster
> when a new node joins the cluster
> {code:java|title=IgniteKernal.java}
> public void start(
> DiscoveryLocalJoinData joinData = ctx.discovery().localJoin();
> IgniteInternalFuture transitionWaitFut =
> joinData.transitionWaitFuture();
> ...
> boolean active;
> if (transitionWaitFut != null) {
> if (log.isInfoEnabled()) {
> log.info("Join cluster while cluster state transition is
> in progress, waiting when transition finish.");
> }
> active = transitionWaitFut.get();
> }
> else
> active = joinData.active();
> startTimer.finishGlobalStage("Await transition");
> ...
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13348) Creating IgniteAtomicLong from the client node may hang.
[
https://issues.apache.org/jira/browse/IGNITE-13348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-13348:
-
Reviewer: Slava Koptilin (was: Vyacheslav Koptilin)
> Creating IgniteAtomicLong from the client node may hang.
>
>
> Key: IGNITE-13348
> URL: https://issues.apache.org/jira/browse/IGNITE-13348
> Project: Ignite
> Issue Type: Bug
>Reporter: Vyacheslav Koptilin
>Assignee: Vyacheslav Koptilin
>Priority: Major
> Fix For: 2.11
>
> Attachments: DataStructuresInitializationTest.java
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> It looks like, the data structure processor does not properly initialize when
> a client node connects to a cluster that changes its own state (state
> transition from the inactive state to active).
> reproducer attached.
> *UPDATE*
> It seems to me, the root cause of the issue is that {{joinFut}} is always
> completed with {{false}}.
> {code:java|title=GridClusterStateProcessor.java}
> /** {@inheritDoc} */
> @Override public void onStateFinishMessage(ChangeGlobalStateFinishMessage
> msg) {
> DiscoveryDataClusterState discoClusterState = globalState;
> if (msg.requestId().equals(discoClusterState.transitionRequestId())) {
> ...
> TransitionOnJoinWaitFuture joinFut = this.joinFut;
> if (joinFut != null)
> joinFut.onDone(false);
> ...
> }
> else
> U.warn(log, "Received state finish message with unexpected ID: "
> + msg);
> }
> {code}
> On the other hand, this value is used to determine the state of the cluster
> when a new node joins the cluster
> {code:java|title=IgniteKernal.java}
> public void start(
> DiscoveryLocalJoinData joinData = ctx.discovery().localJoin();
> IgniteInternalFuture transitionWaitFut =
> joinData.transitionWaitFuture();
> ...
> boolean active;
> if (transitionWaitFut != null) {
> if (log.isInfoEnabled()) {
> log.info("Join cluster while cluster state transition is
> in progress, waiting when transition finish.");
> }
> active = transitionWaitFut.get();
> }
> else
> active = joinData.active();
> startTimer.finishGlobalStage("Await transition");
> ...
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13348) Creating IgniteAtomicLong from the client node may hang.
[
https://issues.apache.org/jira/browse/IGNITE-13348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-13348:
-
Reviewer: Vyacheslav Koptilin
> Creating IgniteAtomicLong from the client node may hang.
>
>
> Key: IGNITE-13348
> URL: https://issues.apache.org/jira/browse/IGNITE-13348
> Project: Ignite
> Issue Type: Bug
>Reporter: Vyacheslav Koptilin
>Assignee: Vyacheslav Koptilin
>Priority: Major
> Fix For: 2.11
>
> Attachments: DataStructuresInitializationTest.java
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> It looks like, the data structure processor does not properly initialize when
> a client node connects to a cluster that changes its own state (state
> transition from the inactive state to active).
> reproducer attached.
> *UPDATE*
> It seems to me, the root cause of the issue is that {{joinFut}} is always
> completed with {{false}}.
> {code:java|title=GridClusterStateProcessor.java}
> /** {@inheritDoc} */
> @Override public void onStateFinishMessage(ChangeGlobalStateFinishMessage
> msg) {
> DiscoveryDataClusterState discoClusterState = globalState;
> if (msg.requestId().equals(discoClusterState.transitionRequestId())) {
> ...
> TransitionOnJoinWaitFuture joinFut = this.joinFut;
> if (joinFut != null)
> joinFut.onDone(false);
> ...
> }
> else
> U.warn(log, "Received state finish message with unexpected ID: "
> + msg);
> }
> {code}
> On the other hand, this value is used to determine the state of the cluster
> when a new node joins the cluster
> {code:java|title=IgniteKernal.java}
> public void start(
> DiscoveryLocalJoinData joinData = ctx.discovery().localJoin();
> IgniteInternalFuture transitionWaitFut =
> joinData.transitionWaitFuture();
> ...
> boolean active;
> if (transitionWaitFut != null) {
> if (log.isInfoEnabled()) {
> log.info("Join cluster while cluster state transition is
> in progress, waiting when transition finish.");
> }
> active = transitionWaitFut.get();
> }
> else
> active = joinData.active();
> startTimer.finishGlobalStage("Await transition");
> ...
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14299) .NET: Service loses array type information in case .Net <-> .Net call
[
https://issues.apache.org/jira/browse/IGNITE-14299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-14299:
Issue Type: Bug (was: Improvement)
> .NET: Service loses array type information in case .Net <-> .Net call
> -
>
> Key: IGNITE-14299
> URL: https://issues.apache.org/jira/browse/IGNITE-14299
> Project: Ignite
> Issue Type: Bug
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In case .Net -> .Net service call Ignite loses array type information.
> {code:java}
> using Apache.Ignite.Core;
> using Apache.Ignite.Core.Discovery.Tcp;
> using Apache.Ignite.Core.Discovery.Tcp.Static;
> using Apache.Ignite.Core.Services;
> using Castle.DynamicProxy;
> using System;
> using System.Linq;
> using Xunit;
> namespace Ignite.ServiceReturnsArray
> {
> public class Test : IDisposable
> {
> private readonly IIgnite igniteSrv;
> private readonly IIgnite ignite;
> public Test()
> {
> IgniteConfiguration IgniteConfig(bool clientMode) => new
> IgniteConfiguration()
> {
> ClientMode = clientMode,
> IgniteInstanceName = Guid.NewGuid().ToString(),
> DiscoverySpi = new TcpDiscoverySpi
> {
> IpFinder = new TcpDiscoveryStaticIpFinder { Endpoints =
> new[] { "127.0.0.1:47500" } }
> }
> };
> igniteSrv = Ignition.Start(IgniteConfig(false));
> ignite = Ignition.Start(IgniteConfig(true));
>
> ignite.GetServices().DeployClusterSingleton(nameof(ArrayFactoryService), new
> ArrayFactoryService());
> }
> public void Dispose()
> {
> ignite.Dispose();
> igniteSrv.Dispose();
> }
> [Fact]
> public void ServiceReturnsArray()
> {
> var arr =
> ignite.GetServices().GetServiceProxy(nameof(ArrayFactoryService),
> false)
> .CreateArray(2, 1);
> Assert.IsType(arr);
> Assert.Equal(1, arr?[1]?.Value);
> }
> [Fact]
> public void ServiceReturnsArrayWithReflection()
> {
> var arr =
> typeof(IArrayFactory).GetMethod(nameof(IArrayFactory.CreateArray)).Invoke(
>
> ignite.GetServices().GetServiceProxy(nameof(ArrayFactoryService)),
> new object[] { 2, 1 });
> Assert.IsType(arr);
> Assert.Equal(1, ((Result[])arr)?[1]?.Value);
> }
> [Fact]
> public void ServiceReturnsArrayWithCastleProxy()
> {
> var interceptor = new ServiceInterceptor(ignite,
> nameof(ArrayFactoryService));
>
> var arr = new
> ProxyGenerator().CreateInterfaceProxyWithoutTarget(interceptor)
> .CreateArray(2, 1);
> Assert.IsType(arr);
> Assert.Equal(1, arr?[1]?.Value);
> }
> public sealed class Result
> {
> public int Value { get; set; }
> }
> public interface IArrayFactory
> {
> Result[] CreateArray(int size, int dlftVal);
> }
> public sealed class ArrayFactoryService : IArrayFactory, IService
> {
> public Result[] CreateArray(int size, int dfltVal)
> {
> return Enumerable.Repeat(new Result { Value = dfltVal },
> size).ToArray();
> }
> public void Cancel(IServiceContext context)
> {
> }
> public void Execute(IServiceContext context)
> {
> }
> public void Init(IServiceContext context)
> {
> }
> }
> private sealed class ServiceInterceptor : IInterceptor where T:
> class
> {
> private readonly IIgnite ignite;
> private readonly string name;
> public ServiceInterceptor(IIgnite ignite, string name)
> {
> this.ignite = ignite;
> this.name = name;
> }
> public void Intercept(IInvocation invocation)
> {
> var svc = ignite.GetServices().GetServiceProxy(name,
> false);
> invocation.ReturnValue = invocation.Method.Invoke(svc,
> invocation.Arguments);
> }
> }
> }
> }
> {code}
>
> Above test fail on type check.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14299) .NET: Service loses array type information in case .Net <-> .Net call
[
https://issues.apache.org/jira/browse/IGNITE-14299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov updated IGNITE-14299:
-
Summary: .NET: Service loses array type information in case .Net <-> .Net
call (was: .Net Service loses array type information in case .Net <-> .Net
call)
> .NET: Service loses array type information in case .Net <-> .Net call
> -
>
> Key: IGNITE-14299
> URL: https://issues.apache.org/jira/browse/IGNITE-14299
> Project: Ignite
> Issue Type: Improvement
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Major
>
> In case .Net -> .Net service call Ignite loses arra type information.
> {code:java}
> using Apache.Ignite.Core;
> using Apache.Ignite.Core.Discovery.Tcp;
> using Apache.Ignite.Core.Discovery.Tcp.Static;
> using Apache.Ignite.Core.Services;
> using Castle.DynamicProxy;
> using System;
> using System.Linq;
> using Xunit;
> namespace Ignite.ServiceReturnsArray
> {
> public class Test : IDisposable
> {
> private readonly IIgnite igniteSrv;
> private readonly IIgnite ignite;
> public Test()
> {
> IgniteConfiguration IgniteConfig(bool clientMode) => new
> IgniteConfiguration()
> {
> ClientMode = clientMode,
> IgniteInstanceName = Guid.NewGuid().ToString(),
> DiscoverySpi = new TcpDiscoverySpi
> {
> IpFinder = new TcpDiscoveryStaticIpFinder { Endpoints =
> new[] { "127.0.0.1:47500" } }
> }
> };
> igniteSrv = Ignition.Start(IgniteConfig(false));
> ignite = Ignition.Start(IgniteConfig(true));
>
> ignite.GetServices().DeployClusterSingleton(nameof(ArrayFactoryService), new
> ArrayFactoryService());
> }
> public void Dispose()
> {
> ignite.Dispose();
> igniteSrv.Dispose();
> }
> [Fact]
> public void ServiceReturnsArray()
> {
> var arr =
> ignite.GetServices().GetServiceProxy(nameof(ArrayFactoryService),
> false)
> .CreateArray(2, 1);
> Assert.IsType(arr);
> Assert.Equal(1, arr?[1]?.Value);
> }
> [Fact]
> public void ServiceReturnsArrayWithReflection()
> {
> var arr =
> typeof(IArrayFactory).GetMethod(nameof(IArrayFactory.CreateArray)).Invoke(
>
> ignite.GetServices().GetServiceProxy(nameof(ArrayFactoryService)),
> new object[] { 2, 1 });
> Assert.IsType(arr);
> Assert.Equal(1, ((Result[])arr)?[1]?.Value);
> }
> [Fact]
> public void ServiceReturnsArrayWithCastleProxy()
> {
> var interceptor = new ServiceInterceptor(ignite,
> nameof(ArrayFactoryService));
>
> var arr = new
> ProxyGenerator().CreateInterfaceProxyWithoutTarget(interceptor)
> .CreateArray(2, 1);
> Assert.IsType(arr);
> Assert.Equal(1, arr?[1]?.Value);
> }
> public sealed class Result
> {
> public int Value { get; set; }
> }
> public interface IArrayFactory
> {
> Result[] CreateArray(int size, int dlftVal);
> }
> public sealed class ArrayFactoryService : IArrayFactory, IService
> {
> public Result[] CreateArray(int size, int dfltVal)
> {
> return Enumerable.Repeat(new Result { Value = dfltVal },
> size).ToArray();
> }
> public void Cancel(IServiceContext context)
> {
> }
> public void Execute(IServiceContext context)
> {
> }
> public void Init(IServiceContext context)
> {
> }
> }
> private sealed class ServiceInterceptor : IInterceptor where T:
> class
> {
> private readonly IIgnite ignite;
> private readonly string name;
> public ServiceInterceptor(IIgnite ignite, string name)
> {
> this.ignite = ignite;
> this.name = name;
> }
> public void Intercept(IInvocation invocation)
> {
> var svc = ignite.GetServices().GetServiceProxy(name,
> false);
> invocation.ReturnValue = invocation.Method.Invoke(svc,
> invocation.Arguments);
> }
> }
> }
> }
> {code}
>
> Above test fail on type check.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14299) .NET: Service loses array type information in case .Net <-> .Net call
[
https://issues.apache.org/jira/browse/IGNITE-14299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov updated IGNITE-14299:
-
Description:
In case .Net -> .Net service call Ignite loses array type information.
{code:java}
using Apache.Ignite.Core;
using Apache.Ignite.Core.Discovery.Tcp;
using Apache.Ignite.Core.Discovery.Tcp.Static;
using Apache.Ignite.Core.Services;
using Castle.DynamicProxy;
using System;
using System.Linq;
using Xunit;
namespace Ignite.ServiceReturnsArray
{
public class Test : IDisposable
{
private readonly IIgnite igniteSrv;
private readonly IIgnite ignite;
public Test()
{
IgniteConfiguration IgniteConfig(bool clientMode) => new
IgniteConfiguration()
{
ClientMode = clientMode,
IgniteInstanceName = Guid.NewGuid().ToString(),
DiscoverySpi = new TcpDiscoverySpi
{
IpFinder = new TcpDiscoveryStaticIpFinder { Endpoints =
new[] { "127.0.0.1:47500" } }
}
};
igniteSrv = Ignition.Start(IgniteConfig(false));
ignite = Ignition.Start(IgniteConfig(true));
ignite.GetServices().DeployClusterSingleton(nameof(ArrayFactoryService), new
ArrayFactoryService());
}
public void Dispose()
{
ignite.Dispose();
igniteSrv.Dispose();
}
[Fact]
public void ServiceReturnsArray()
{
var arr =
ignite.GetServices().GetServiceProxy(nameof(ArrayFactoryService),
false)
.CreateArray(2, 1);
Assert.IsType(arr);
Assert.Equal(1, arr?[1]?.Value);
}
[Fact]
public void ServiceReturnsArrayWithReflection()
{
var arr =
typeof(IArrayFactory).GetMethod(nameof(IArrayFactory.CreateArray)).Invoke(
ignite.GetServices().GetServiceProxy(nameof(ArrayFactoryService)),
new object[] { 2, 1 });
Assert.IsType(arr);
Assert.Equal(1, ((Result[])arr)?[1]?.Value);
}
[Fact]
public void ServiceReturnsArrayWithCastleProxy()
{
var interceptor = new ServiceInterceptor(ignite,
nameof(ArrayFactoryService));
var arr = new
ProxyGenerator().CreateInterfaceProxyWithoutTarget(interceptor)
.CreateArray(2, 1);
Assert.IsType(arr);
Assert.Equal(1, arr?[1]?.Value);
}
public sealed class Result
{
public int Value { get; set; }
}
public interface IArrayFactory
{
Result[] CreateArray(int size, int dlftVal);
}
public sealed class ArrayFactoryService : IArrayFactory, IService
{
public Result[] CreateArray(int size, int dfltVal)
{
return Enumerable.Repeat(new Result { Value = dfltVal },
size).ToArray();
}
public void Cancel(IServiceContext context)
{
}
public void Execute(IServiceContext context)
{
}
public void Init(IServiceContext context)
{
}
}
private sealed class ServiceInterceptor : IInterceptor where T: class
{
private readonly IIgnite ignite;
private readonly string name;
public ServiceInterceptor(IIgnite ignite, string name)
{
this.ignite = ignite;
this.name = name;
}
public void Intercept(IInvocation invocation)
{
var svc = ignite.GetServices().GetServiceProxy(name, false);
invocation.ReturnValue = invocation.Method.Invoke(svc,
invocation.Arguments);
}
}
}
}
{code}
Above test fail on type check.
was:
In case .Net -> .Net service call Ignite loses arra type information.
{code:java}
using Apache.Ignite.Core;
using Apache.Ignite.Core.Discovery.Tcp;
using Apache.Ignite.Core.Discovery.Tcp.Static;
using Apache.Ignite.Core.Services;
using Castle.DynamicProxy;
using System;
using System.Linq;
using Xunit;
namespace Ignite.ServiceReturnsArray
{
public class Test : IDisposable
{
private readonly IIgnite igniteSrv;
private readonly IIgnite ignite;
public Test()
{
IgniteConfiguration IgniteConfig(bool clientMode) => new
IgniteConfiguration()
{
ClientMode = clientMode,
IgniteInstanceName = Guid.NewGuid().ToString(),
DiscoverySpi = new TcpDiscoverySpi
{
IpFinder = new TcpDiscoveryStaticIpFinder { Endpoints =
new[] { "127.0.0.1:47500" } }
}
};
igniteSrv =
[jira] [Created] (IGNITE-14299) .Net Service loses array type information in case .Net <-> .Net call
Nikolay Izhikov created IGNITE-14299:
Summary: .Net Service loses array type information in case .Net
<-> .Net call
Key: IGNITE-14299
URL: https://issues.apache.org/jira/browse/IGNITE-14299
Project: Ignite
Issue Type: Improvement
Reporter: Nikolay Izhikov
Assignee: Nikolay Izhikov
In case .Net -> .Net service call Ignite loses arra type information.
{code:java}
using Apache.Ignite.Core;
using Apache.Ignite.Core.Discovery.Tcp;
using Apache.Ignite.Core.Discovery.Tcp.Static;
using Apache.Ignite.Core.Services;
using Castle.DynamicProxy;
using System;
using System.Linq;
using Xunit;
namespace Ignite.ServiceReturnsArray
{
public class Test : IDisposable
{
private readonly IIgnite igniteSrv;
private readonly IIgnite ignite;
public Test()
{
IgniteConfiguration IgniteConfig(bool clientMode) => new
IgniteConfiguration()
{
ClientMode = clientMode,
IgniteInstanceName = Guid.NewGuid().ToString(),
DiscoverySpi = new TcpDiscoverySpi
{
IpFinder = new TcpDiscoveryStaticIpFinder { Endpoints =
new[] { "127.0.0.1:47500" } }
}
};
igniteSrv = Ignition.Start(IgniteConfig(false));
ignite = Ignition.Start(IgniteConfig(true));
ignite.GetServices().DeployClusterSingleton(nameof(ArrayFactoryService), new
ArrayFactoryService());
}
public void Dispose()
{
ignite.Dispose();
igniteSrv.Dispose();
}
[Fact]
public void ServiceReturnsArray()
{
var arr =
ignite.GetServices().GetServiceProxy(nameof(ArrayFactoryService),
false)
.CreateArray(2, 1);
Assert.IsType(arr);
Assert.Equal(1, arr?[1]?.Value);
}
[Fact]
public void ServiceReturnsArrayWithReflection()
{
var arr =
typeof(IArrayFactory).GetMethod(nameof(IArrayFactory.CreateArray)).Invoke(
ignite.GetServices().GetServiceProxy(nameof(ArrayFactoryService)),
new object[] { 2, 1 });
Assert.IsType(arr);
Assert.Equal(1, ((Result[])arr)?[1]?.Value);
}
[Fact]
public void ServiceReturnsArrayWithCastleProxy()
{
var interceptor = new ServiceInterceptor(ignite,
nameof(ArrayFactoryService));
var arr = new
ProxyGenerator().CreateInterfaceProxyWithoutTarget(interceptor)
.CreateArray(2, 1);
Assert.IsType(arr);
Assert.Equal(1, arr?[1]?.Value);
}
public sealed class Result
{
public int Value { get; set; }
}
public interface IArrayFactory
{
Result[] CreateArray(int size, int dlftVal);
}
public sealed class ArrayFactoryService : IArrayFactory, IService
{
public Result[] CreateArray(int size, int dfltVal)
{
return Enumerable.Repeat(new Result { Value = dfltVal },
size).ToArray();
}
public void Cancel(IServiceContext context)
{
}
public void Execute(IServiceContext context)
{
}
public void Init(IServiceContext context)
{
}
}
private sealed class ServiceInterceptor : IInterceptor where T: class
{
private readonly IIgnite ignite;
private readonly string name;
public ServiceInterceptor(IIgnite ignite, string name)
{
this.ignite = ignite;
this.name = name;
}
public void Intercept(IInvocation invocation)
{
var svc = ignite.GetServices().GetServiceProxy(name, false);
invocation.ReturnValue = invocation.Method.Invoke(svc,
invocation.Arguments);
}
}
}
}
{code}
Above test fail on type check.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14293) .NET: AffinityKey does not work
[
https://issues.apache.org/jira/browse/IGNITE-14293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17298915#comment-17298915
]
Pavel Tupitsyn commented on IGNITE-14293:
-
[~isapego] comments addressed, thanks!
Merged to master: 8cc19b1041b64d7dd3bb368ce4b9cadee07a3718
> .NET: AffinityKey does not work
> ---
>
> Key: IGNITE-14293
> URL: https://issues.apache.org/jira/browse/IGNITE-14293
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 2.10
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Blocker
> Labels: .NET
> Fix For: 2.10
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> {{AffinityKey}} does not work as expected - {{Affinity}} property is not used
> for affinity calculation.
> This is caused by IGNITE-13160: {{AffinityKey}} system type is overwritten by
> {{UnmanagedCallbacks.BinaryTypeGet}} call. As a result, this type becomes a
> regular, user type, and does not map to a corresponding type on the Java side.
> * Add test that combines QueryEntity with AffinityKey
> * Check that other system types (IgniteUuid, etc) don't have this problem,
> add tests
> * Make sure we never overwrite system types during registration
> * Improve examples tests: Thick Sql example provides inconsistent output due
> to this bug
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14293) .NET: AffinityKey does not work
[
https://issues.apache.org/jira/browse/IGNITE-14293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17298912#comment-17298912
]
Ignite TC Bot commented on IGNITE-14293:
{panel:title=Branch: [pull/8866/head] Base: [master] : Possible Blockers
(1)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Queries 1{color} [[tests 0 CANCELLED, Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=5908158]]
{panel}
{panel:title=Branch: [pull/8866/head] Base: [master] : New Tests
(2)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Platform .NET (Core Linux){color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=5908225]]
* {color:#013220}dll: AffinityTest.TestAffinityKeyWithQueryEntity -
PASSED{color}
{color:#8b}Platform .NET{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=5908221]]
* {color:#013220}exe: AffinityTest.TestAffinityKeyWithQueryEntity -
PASSED{color}
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5908179buildTypeId=IgniteTests24Java8_RunAll]
> .NET: AffinityKey does not work
> ---
>
> Key: IGNITE-14293
> URL: https://issues.apache.org/jira/browse/IGNITE-14293
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 2.10
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Blocker
> Labels: .NET
> Fix For: 2.10
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> {{AffinityKey}} does not work as expected - {{Affinity}} property is not used
> for affinity calculation.
> This is caused by IGNITE-13160: {{AffinityKey}} system type is overwritten by
> {{UnmanagedCallbacks.BinaryTypeGet}} call. As a result, this type becomes a
> regular, user type, and does not map to a corresponding type on the Java side.
> * Add test that combines QueryEntity with AffinityKey
> * Check that other system types (IgniteUuid, etc) don't have this problem,
> add tests
> * Make sure we never overwrite system types during registration
> * Improve examples tests: Thick Sql example provides inconsistent output due
> to this bug
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14272) Merge modules/DEVNOTES.txt and DEVNOTES.txt
[ https://issues.apache.org/jira/browse/IGNITE-14272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-14272: -- Ignite Flags: (was: Docs Required,Release Notes Required) > Merge modules/DEVNOTES.txt and DEVNOTES.txt > --- > > Key: IGNITE-14272 > URL: https://issues.apache.org/jira/browse/IGNITE-14272 > Project: Ignite > Issue Type: Improvement > Components: documentation >Reporter: Alexey Goncharuk >Assignee: Alexey Goncharuk >Priority: Trivial > Fix For: 3.0.0-alpha2 > > > The modules/DEVNOTES.txt was mistakenly introduced, the contents should be > moved to the root DEVNOTES.txt > Also, we may add some structure to modules README.md files and link them to > DEVNOTES.txt -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14068) Infinite node persistance in the ring while outgoing connections are lost
[ https://issues.apache.org/jira/browse/IGNITE-14068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-14068: -- Description: If node looses outgoing connections, it can decide it is alone in the cluster and won't fail. Happens on small clusters where failed node attempts to connect to every other node before connRecoveryTimeout expires. Consider: - The cluster n1 -> n2 -> n3 -> n4 -> n1 - n4 looses all outgoing connections. - n3 keeps successful ping to n4. - n4 attempts to connect to n1, n2, n3. Fails with each due to outgoing network failure. - spi.connrecoveryTimeout is not reached. n4 decides it is alone and continues working. - n3 still sends messages to n4. n4 does not lack incoming connections. - ring is actually broken because of n4. n3 cannot determine failure of n4. Solution: node could watch its incoming traffic which notyfies of the incoming network. If all the outgoing connections are lost but messages are received, node must left the grid to prevent ring break. was: If node looses outgoing connections, it can decide it is alone in the cluster and won't fail. Happens on small clusters where failed node attempts to connect to every other node before connRecoveryTimeout expires. Consider: - The cluster n1 -> n2 -> n3 -> n4 -> n1 - n4 looses all outgoing connections. - n3 keeps successful ping to n4. - n4 attempts to connect to n1, n2, n3. Fails with each due to outgoing network failure. - spi.connrecoveryTimeout is not reached. n4 decides it is alone and continues working. - n3 still sends messages to n4. n4 does not lack incoming connections. - ring is actually broken because of n4. n3 cannot determine failure of n4. Solution: node can watch incoming ping what means there is incoming connection. If all outgoing connections was lost, being pinged node must left the grid not to stop the message traffic. > Infinite node persistance in the ring while outgoing connections are lost > - > > Key: IGNITE-14068 > URL: https://issues.apache.org/jira/browse/IGNITE-14068 > Project: Ignite > Issue Type: Bug >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > If node looses outgoing connections, it can decide it is alone in the cluster > and won't fail. Happens on small clusters where failed node attempts to > connect to every other node before connRecoveryTimeout expires. > Consider: > - The cluster n1 -> n2 -> n3 -> n4 -> n1 > - n4 looses all outgoing connections. > - n3 keeps successful ping to n4. > - n4 attempts to connect to n1, n2, n3. Fails with each due to outgoing > network failure. > - spi.connrecoveryTimeout is not reached. n4 decides it is alone and > continues working. > - n3 still sends messages to n4. n4 does not lack incoming connections. > - ring is actually broken because of n4. n3 cannot determine failure of n4. > Solution: node could watch its incoming traffic which notyfies of the > incoming network. If all the outgoing connections are lost but messages are > received, node must left the grid to prevent ring break. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14068) Infinite node persistance in the ring while outgoing connections are lost
[ https://issues.apache.org/jira/browse/IGNITE-14068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-14068: -- Description: If node looses outgoing connections, it can decide it is alone in the cluster and won't fail. Happens on small clusters where failed node attempts to connect to every other node before connRecoveryTimeout expires. Consider: - The cluster n1 -> n2 -> n3 -> n4 -> n1 - n4 looses all outgoing connections. - n3 keeps successful ping to n4. - n4 attempts to connect to n1, n2, n3. Fails with each due to outgoing network failure. - spi.connrecoveryTimeout is not reached. n4 decides it is alone and continues working. - n3 still sends messages to n4. n4 does not lack incoming connections. - ring is actually broken because of n4. n3 cannot determine failure of n4. Solution: node can watch incoming ping what means there is incoming connection. If all outgoing connections was lost, being pinged node must left the grid not to stop the message traffic. was: If node looses outgoing connections, it can decide it is alone in the cluster and won't fail. Happens on small clusters where failed node is able to unsuccessfully try to connect to all other nodes before connRecoveryTimeout expires. Consider: - The cluster n1 -> n2 -> n3 -> n4 -> n1 - n4 looses all outgoing connections. - n3 keeps successful ping to n4. - n4 attempts to connect to n1, n2, n3. Fails with each due to outgoing network failure. - spi.connrecoveryTimeout is not reached. n4 decides it is alone and continues working. - n3 still sends messages to n4. n4 does not lack incoming connections. - ring is actually broken because of n4. n3 cannot determine failure of n4. Solution: node can watch incoming ping what means there is incoming connection. If all outgoing connections was lost, being pinged node must left the grid not to stop the message traffic. > Infinite node persistance in the ring while outgoing connections are lost > - > > Key: IGNITE-14068 > URL: https://issues.apache.org/jira/browse/IGNITE-14068 > Project: Ignite > Issue Type: Bug >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > If node looses outgoing connections, it can decide it is alone in the cluster > and won't fail. Happens on small clusters where failed node attempts to > connect to every other node before connRecoveryTimeout expires. > Consider: > - The cluster n1 -> n2 -> n3 -> n4 -> n1 > - n4 looses all outgoing connections. > - n3 keeps successful ping to n4. > - n4 attempts to connect to n1, n2, n3. Fails with each due to outgoing > network failure. > - spi.connrecoveryTimeout is not reached. n4 decides it is alone and > continues working. > - n3 still sends messages to n4. n4 does not lack incoming connections. > - ring is actually broken because of n4. n3 cannot determine failure of n4. > Solution: node can watch incoming ping what means there is incoming > connection. If all outgoing connections was lost, being pinged node must left > the grid not to stop the message traffic. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14068) Infinite node persistance in the ring while outgoing connections are lost
[ https://issues.apache.org/jira/browse/IGNITE-14068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-14068: -- Description: If node looses outgoing connections, it can decide it is alone in the cluster and won't fail. Happens on small clusters where failed node is able to unsuccessfully try to connect to all other nodes before connRecoveryTimeout expires. Consider: - The cluster n1 -> n2 -> n3 -> n4 -> n1 - n4 looses all outgoing connections. - n3 keeps successful ping to n4. - n4 attempts to connect to n1, n2, n3. Fails with each due to outgoing network failure. - spi.connrecoveryTimeout is not reached. n4 decides it is alone and continues working. - n3 still sends messages to n4. n4 does not lack incoming connections. - ring is actually broken because of n4. n3 cannot determine failure of n4. Solution: node can watch incoming ping what means there is incoming connection. If all outgoing connections was lost, being pinged node must left the grid not to stop the message traffic. was: If node loses outgoing connections, it can decide it is alone in the cluster and won't fail. Happens on small clusters where failed node is able to unsuccessfully try to connect to all other nodes before connRecoveryTimeout expires. Consider: - The cluster n1 -> n2 -> n3 -> n4 -> n1 - n4 looses all outgoing connections. - n3 keeps successful ping to n4. - n4 attempts to connect to n1, n2, n3. Fails with each due to outgoing network failure. - spi.connrecoveryTimeout is not reached. n4 decides it is alone and continues working. - n3 still sends messages to n4. n4 does not lack incoming connections. - ring is actually broken because of n4. n3 cannot determine failure of n4. Solution: node can watch incoming ping what means there is incoming connection. If all outgoing connections was lost, being pinged node must left the grid not to stop the message traffic. > Infinite node persistance in the ring while outgoing connections are lost > - > > Key: IGNITE-14068 > URL: https://issues.apache.org/jira/browse/IGNITE-14068 > Project: Ignite > Issue Type: Bug >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > If node looses outgoing connections, it can decide it is alone in the cluster > and won't fail. Happens on small clusters where failed node is able to > unsuccessfully try to connect to all other nodes before connRecoveryTimeout > expires. > Consider: > - The cluster n1 -> n2 -> n3 -> n4 -> n1 > - n4 looses all outgoing connections. > - n3 keeps successful ping to n4. > - n4 attempts to connect to n1, n2, n3. Fails with each due to outgoing > network failure. > - spi.connrecoveryTimeout is not reached. n4 decides it is alone and > continues working. > - n3 still sends messages to n4. n4 does not lack incoming connections. > - ring is actually broken because of n4. n3 cannot determine failure of n4. > Solution: node can watch incoming ping what means there is incoming > connection. If all outgoing connections was lost, being pinged node must left > the grid not to stop the message traffic. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14138) Historical rebalance kills cluster
[
https://issues.apache.org/jira/browse/IGNITE-14138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17298876#comment-17298876
]
Maxim Muzafarov commented on IGNITE-14138:
--
Cherry-picked to 2.10
> Historical rebalance kills cluster
> --
>
> Key: IGNITE-14138
> URL: https://issues.apache.org/jira/browse/IGNITE-14138
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Assignee: Vladislav Pyatkov
>Priority: Major
> Fix For: 2.10
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {noformat}
> [2021-01-12T05:11:02,142][ERROR][rebalance-#508%---%][] Critical system error
> detected. Will be handled accordingly to configured handler
> [hnd=StopNodeOrHaltFailureHandler [tryStop=false, timeout=0,
> super=AbstractFailureHandler [ignoredFailureTypes=UnmodifiableSet
> [SYSTEM_WORKER_BLOCKED, SYSTEM_CRITICAL_OPERATION_TIMEOUT]]],
> failureCtx=FailureContext [type=CRITICAL_ERROR, err=class
> o.a.i.IgniteCheckedException: Failed to continue supplying
> [grp=SQL_USAGES_EPE, demander=48254935-7aa9-4ab5-b398-fdaec334fab7,
> topVer=AffinityTopologyVersion [topVer=3, minorTopVer=1
> org.apache.ignite.IgniteCheckedException: Failed to continue supplying
> [grp=SQL_1, demander=48254935-7aa9-4ab5-b398-fdaec334fab7,
> topVer=AffinityTopologyVersion [topVer=3, minorTopVer=1]]
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionSupplier.handleDemandMessage(GridDhtPartitionSupplier.java:571)
> [ignite-core.jar]
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPreloader.handleDemandMessage(GridDhtPreloader.java:398)
> [ignite-core.jar]
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$5.apply(GridCachePartitionExchangeManager.java:489)
> [ignite-core.jar]
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$5.apply(GridCachePartitionExchangeManager.java:474)
> [ignite-core.jar]
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1142)
> [ignite-core.jar]
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:591)
> [ignite-core.jar]
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$800(GridCacheIoManager.java:109)
> [ignite-core.jar]
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$OrderedMessageListener.onMessage(GridCacheIoManager.java:1707)
> [ignite-core.jar]
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1721)
> [ignite-core.jar]
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4300(GridIoManager.java:157)
> [ignite-core.jar]
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$GridCommunicationMessageSet.unwind(GridIoManager.java:3011)
> [ignite-core.jar]
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.unwindMessageSet(GridIoManager.java:1662)
> [ignite-core.jar]
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4900(GridIoManager.java:157)
> [ignite-core.jar]
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1629)
> [ignite-core.jar]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> [?:?]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> [?:?]
> at java.lang.Thread.run(Thread.java:834) [?:?]
> Caused by: org.apache.ignite.IgniteCheckedException: Could not find start
> pointer for partition [part=4, partCntrSince=1115]
> at
> org.apache.ignite.internal.processors.cache.persistence.checkpoint.CheckpointHistory.searchEarliestWalPointer(CheckpointHistory.java:557)
> ~[ignite-core.jar]
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager.historicalIterator(GridCacheOffheapManager.java:1121)
> ~[ignite-core.jar]
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.rebalanceIterator(IgniteCacheOffheapManagerImpl.java:1195)
> ~[ignite-core.jar]
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionSupplier.handleDemandMessage(GridDhtPartitionSupplier.java:322)
> ~[ignite-core.jar]
> ... 16 more
> {noformat}
> I believe that it should throw IgniteHistoricalIteratorException instead of
> IgniteCheckedException, so it can be properly handled and rebalance can move
> to the full rebalance instead of killing nodes
--
This message was sent by Atlassian Jira
[jira] [Updated] (IGNITE-14138) Historical rebalance kills cluster
[
https://issues.apache.org/jira/browse/IGNITE-14138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated IGNITE-14138:
-
Fix Version/s: (was: 2.11)
2.10
> Historical rebalance kills cluster
> --
>
> Key: IGNITE-14138
> URL: https://issues.apache.org/jira/browse/IGNITE-14138
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Assignee: Vladislav Pyatkov
>Priority: Major
> Fix For: 2.10
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {noformat}
> [2021-01-12T05:11:02,142][ERROR][rebalance-#508%---%][] Critical system error
> detected. Will be handled accordingly to configured handler
> [hnd=StopNodeOrHaltFailureHandler [tryStop=false, timeout=0,
> super=AbstractFailureHandler [ignoredFailureTypes=UnmodifiableSet
> [SYSTEM_WORKER_BLOCKED, SYSTEM_CRITICAL_OPERATION_TIMEOUT]]],
> failureCtx=FailureContext [type=CRITICAL_ERROR, err=class
> o.a.i.IgniteCheckedException: Failed to continue supplying
> [grp=SQL_USAGES_EPE, demander=48254935-7aa9-4ab5-b398-fdaec334fab7,
> topVer=AffinityTopologyVersion [topVer=3, minorTopVer=1
> org.apache.ignite.IgniteCheckedException: Failed to continue supplying
> [grp=SQL_1, demander=48254935-7aa9-4ab5-b398-fdaec334fab7,
> topVer=AffinityTopologyVersion [topVer=3, minorTopVer=1]]
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionSupplier.handleDemandMessage(GridDhtPartitionSupplier.java:571)
> [ignite-core.jar]
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPreloader.handleDemandMessage(GridDhtPreloader.java:398)
> [ignite-core.jar]
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$5.apply(GridCachePartitionExchangeManager.java:489)
> [ignite-core.jar]
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$5.apply(GridCachePartitionExchangeManager.java:474)
> [ignite-core.jar]
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1142)
> [ignite-core.jar]
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:591)
> [ignite-core.jar]
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$800(GridCacheIoManager.java:109)
> [ignite-core.jar]
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$OrderedMessageListener.onMessage(GridCacheIoManager.java:1707)
> [ignite-core.jar]
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1721)
> [ignite-core.jar]
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4300(GridIoManager.java:157)
> [ignite-core.jar]
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$GridCommunicationMessageSet.unwind(GridIoManager.java:3011)
> [ignite-core.jar]
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.unwindMessageSet(GridIoManager.java:1662)
> [ignite-core.jar]
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4900(GridIoManager.java:157)
> [ignite-core.jar]
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1629)
> [ignite-core.jar]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> [?:?]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> [?:?]
> at java.lang.Thread.run(Thread.java:834) [?:?]
> Caused by: org.apache.ignite.IgniteCheckedException: Could not find start
> pointer for partition [part=4, partCntrSince=1115]
> at
> org.apache.ignite.internal.processors.cache.persistence.checkpoint.CheckpointHistory.searchEarliestWalPointer(CheckpointHistory.java:557)
> ~[ignite-core.jar]
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager.historicalIterator(GridCacheOffheapManager.java:1121)
> ~[ignite-core.jar]
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.rebalanceIterator(IgniteCacheOffheapManagerImpl.java:1195)
> ~[ignite-core.jar]
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionSupplier.handleDemandMessage(GridDhtPartitionSupplier.java:322)
> ~[ignite-core.jar]
> ... 16 more
> {noformat}
> I believe that it should throw IgniteHistoricalIteratorException instead of
> IgniteCheckedException, so it can be properly handled and rebalance can move
> to the full rebalance instead of killing nodes
--
This message was sent by Atlassian Jira
[jira] [Updated] (IGNITE-14168) Wrong help-description for `control.sh --cache validate_indexes`
[ https://issues.apache.org/jira/browse/IGNITE-14168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-14168: - Fix Version/s: (was: 2.11) 2.10 > Wrong help-description for `control.sh --cache validate_indexes` > > > Key: IGNITE-14168 > URL: https://issues.apache.org/jira/browse/IGNITE-14168 > Project: Ignite > Issue Type: Improvement > Components: control.sh >Affects Versions: 2.9.1 >Reporter: Ilya Kazakov >Assignee: Alexey Plotnik >Priority: Minor > Fix For: 2.10 > > Time Spent: 20m > Remaining Estimate: 0h > > It looks like description for validate_index command was copied from > idle_verify command. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14168) Wrong help-description for `control.sh --cache validate_indexes`
[ https://issues.apache.org/jira/browse/IGNITE-14168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17298875#comment-17298875 ] Maxim Muzafarov commented on IGNITE-14168: -- Cherry-picked to 2.10 > Wrong help-description for `control.sh --cache validate_indexes` > > > Key: IGNITE-14168 > URL: https://issues.apache.org/jira/browse/IGNITE-14168 > Project: Ignite > Issue Type: Improvement > Components: control.sh >Affects Versions: 2.9.1 >Reporter: Ilya Kazakov >Assignee: Alexey Plotnik >Priority: Minor > Fix For: 2.11 > > Time Spent: 20m > Remaining Estimate: 0h > > It looks like description for validate_index command was copied from > idle_verify command. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14284) sqlline: `Property "url" is required'
[
https://issues.apache.org/jira/browse/IGNITE-14284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17298862#comment-17298862
]
Maxim Muzafarov commented on IGNITE-14284:
--
Merged to the master branch cherry-picked to 2.10
I've checked under Windows 10.
> sqlline: `Property "url" is required'
> -
>
> Key: IGNITE-14284
> URL: https://issues.apache.org/jira/browse/IGNITE-14284
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.10
>Reporter: Ilya Kasnacheev
>Assignee: Maxim Muzafarov
>Priority: Major
> Labels: sqlline
> Fix For: 2.10
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Currently, when you run sqlline.sh, the following output is shown:
> {code}
> ~/Downloads/2.10/apache-ignite-slim-2.10.0-bin% bin/sqlline.sh
> Property "url" is required
> sqlline version 1.9.0
> sqlline>
> {code}
> We did not have this confusing warning when using sqlline 1.3.0. From this
> on, it will work as expected, with !connect jdbc:ignite:thin://localhost, etc.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14144) Document C++ thin client transactions
[ https://issues.apache.org/jira/browse/IGNITE-14144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-14144: - Fix Version/s: 2.10 > Document C++ thin client transactions > - > > Key: IGNITE-14144 > URL: https://issues.apache.org/jira/browse/IGNITE-14144 > Project: Ignite > Issue Type: Sub-task > Components: documentation >Affects Versions: 2.10 >Reporter: Nikita Safonov >Assignee: Nikita Safonov >Priority: Major > Labels: docuentation > Fix For: 2.10 > > Time Spent: 2h 10m > Remaining Estimate: 0h > > We need to document the C++ thin client transactions functionality. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14144) Document C++ thin client transactions
[ https://issues.apache.org/jira/browse/IGNITE-14144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17298860#comment-17298860 ] Maxim Muzafarov commented on IGNITE-14144: -- Merged to the master branch and cherry-picked to 2.10 Thank you for the contribution. > Document C++ thin client transactions > - > > Key: IGNITE-14144 > URL: https://issues.apache.org/jira/browse/IGNITE-14144 > Project: Ignite > Issue Type: Sub-task > Components: documentation >Affects Versions: 2.10 >Reporter: Nikita Safonov >Assignee: Nikita Safonov >Priority: Major > Labels: docuentation > Time Spent: 2h 10m > Remaining Estimate: 0h > > We need to document the C++ thin client transactions functionality. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (IGNITE-14144) Document C++ thin client transactions
[ https://issues.apache.org/jira/browse/IGNITE-14144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov resolved IGNITE-14144. -- Resolution: Fixed > Document C++ thin client transactions > - > > Key: IGNITE-14144 > URL: https://issues.apache.org/jira/browse/IGNITE-14144 > Project: Ignite > Issue Type: Sub-task > Components: documentation >Affects Versions: 2.10 >Reporter: Nikita Safonov >Assignee: Nikita Safonov >Priority: Major > Labels: docuentation > Fix For: 2.10 > > Time Spent: 2h 10m > Remaining Estimate: 0h > > We need to document the C++ thin client transactions functionality. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14293) .NET: AffinityKey does not work
[
https://issues.apache.org/jira/browse/IGNITE-14293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17298841#comment-17298841
]
Igor Sapego commented on IGNITE-14293:
--
[~ptupitsyn] see my comments in PR. Overall looks good.
> .NET: AffinityKey does not work
> ---
>
> Key: IGNITE-14293
> URL: https://issues.apache.org/jira/browse/IGNITE-14293
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 2.10
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Blocker
> Labels: .NET
> Fix For: 2.10
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {{AffinityKey}} does not work as expected - {{Affinity}} property is not used
> for affinity calculation.
> This is caused by IGNITE-13160: {{AffinityKey}} system type is overwritten by
> {{UnmanagedCallbacks.BinaryTypeGet}} call. As a result, this type becomes a
> regular, user type, and does not map to a corresponding type on the Java side.
> * Add test that combines QueryEntity with AffinityKey
> * Check that other system types (IgniteUuid, etc) don't have this problem,
> add tests
> * Make sure we never overwrite system types during registration
> * Improve examples tests: Thick Sql example provides inconsistent output due
> to this bug
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14176) Calcite improvements. Pk and Affinity key indexes are not considered for planning.
[ https://issues.apache.org/jira/browse/IGNITE-14176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17298836#comment-17298836 ] Stanilovsky Evgeny commented on IGNITE-14176: - [~tledkov-gridgain] [~korlov] guys thanks for review, all fixed, plz check once more ? thanks ! > Calcite improvements. Pk and Affinity key indexes are not considered for > planning. > -- > > Key: IGNITE-14176 > URL: https://issues.apache.org/jira/browse/IGNITE-14176 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Stanilovsky Evgeny >Assignee: Stanilovsky Evgeny >Priority: Major > Labels: calcite > Time Spent: 10m > Remaining Estimate: 0h > > pk and affinity key indexes are not taken into account in planning phase. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14293) .NET: AffinityKey does not work
[
https://issues.apache.org/jira/browse/IGNITE-14293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17298831#comment-17298831
]
Pavel Tupitsyn commented on IGNITE-14293:
-
Release note not required: the bug was never released.
> .NET: AffinityKey does not work
> ---
>
> Key: IGNITE-14293
> URL: https://issues.apache.org/jira/browse/IGNITE-14293
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 2.10
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Blocker
> Labels: .NET
> Fix For: 2.10
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {{AffinityKey}} does not work as expected - {{Affinity}} property is not used
> for affinity calculation.
> This is caused by IGNITE-13160: {{AffinityKey}} system type is overwritten by
> {{UnmanagedCallbacks.BinaryTypeGet}} call. As a result, this type becomes a
> regular, user type, and does not map to a corresponding type on the Java side.
> * Add test that combines QueryEntity with AffinityKey
> * Check that other system types (IgniteUuid, etc) don't have this problem,
> add tests
> * Make sure we never overwrite system types during registration
> * Improve examples tests: Thick Sql example provides inconsistent output due
> to this bug
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14293) .NET: AffinityKey does not work
[
https://issues.apache.org/jira/browse/IGNITE-14293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-14293:
Ignite Flags: (was: Release Notes Required)
> .NET: AffinityKey does not work
> ---
>
> Key: IGNITE-14293
> URL: https://issues.apache.org/jira/browse/IGNITE-14293
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 2.10
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Blocker
> Labels: .NET
> Fix For: 2.10
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {{AffinityKey}} does not work as expected - {{Affinity}} property is not used
> for affinity calculation.
> This is caused by IGNITE-13160: {{AffinityKey}} system type is overwritten by
> {{UnmanagedCallbacks.BinaryTypeGet}} call. As a result, this type becomes a
> regular, user type, and does not map to a corresponding type on the Java side.
> * Add test that combines QueryEntity with AffinityKey
> * Check that other system types (IgniteUuid, etc) don't have this problem,
> add tests
> * Make sure we never overwrite system types during registration
> * Improve examples tests: Thick Sql example provides inconsistent output due
> to this bug
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14298) DEVNOTES should contain clear instructions on how to run check-style
[
https://issues.apache.org/jira/browse/IGNITE-14298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Ivanov updated IGNITE-14298:
--
Summary: DEVNOTES should contain clear instructions on how to run
check-style (was: DEVNOTES should contain clear instructions on how to run
check-style.)
> DEVNOTES should contain clear instructions on how to run check-style
>
>
> Key: IGNITE-14298
> URL: https://issues.apache.org/jira/browse/IGNITE-14298
> Project: Ignite
> Issue Type: Bug
>Reporter: Vyacheslav Koptilin
>Assignee: Peter Ivanov
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-alpha2
>
>
> DEVNOTES should provide clear instructions on how to run the {{checkstyle}}
> && {{apache-rat}} targets for the project/particular sub-module.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-14298) DEVNOTES should contain clear instructions on how to run check-style.
[
https://issues.apache.org/jira/browse/IGNITE-14298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Ivanov reassigned IGNITE-14298:
-
Assignee: Peter Ivanov
> DEVNOTES should contain clear instructions on how to run check-style.
> -
>
> Key: IGNITE-14298
> URL: https://issues.apache.org/jira/browse/IGNITE-14298
> Project: Ignite
> Issue Type: Bug
>Reporter: Vyacheslav Koptilin
>Assignee: Peter Ivanov
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-alpha2
>
>
> DEVNOTES should provide clear instructions on how to run the {{checkstyle}}
> && {{apache-rat}} targets for the project/particular sub-module.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (IGNITE-10394) Try to activate cluster after deactivate. All node exit by handler
[ https://issues.apache.org/jira/browse/IGNITE-10394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin resolved IGNITE-10394. -- Resolution: Cannot Reproduce > Try to activate cluster after deactivate. All node exit by handler > -- > > Key: IGNITE-10394 > URL: https://issues.apache.org/jira/browse/IGNITE-10394 > Project: Ignite > Issue Type: Bug > Components: data structures >Affects Versions: 2.7 >Reporter: ARomantsov >Priority: Critical > > AE: ignite-sys-cache > ..processors.cache.CacheRegistry.update(CacheRegistry.java:188) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14298) DEVNOTES should contain clear instructions on how to run check-style.
[
https://issues.apache.org/jira/browse/IGNITE-14298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-14298:
-
Labels: ignite-3 (was: 3.0)
> DEVNOTES should contain clear instructions on how to run check-style.
> -
>
> Key: IGNITE-14298
> URL: https://issues.apache.org/jira/browse/IGNITE-14298
> Project: Ignite
> Issue Type: Bug
>Reporter: Vyacheslav Koptilin
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-alpha2
>
>
> DEVNOTES should provide clear instructions on how to run the {{checkstyle}}
> && {{apache-rat}} targets for the project/particular sub-module.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-14298) DEVNOTES should contain clear instructions on how to run check-style.
Vyacheslav Koptilin created IGNITE-14298:
Summary: DEVNOTES should contain clear instructions on how to run
check-style.
Key: IGNITE-14298
URL: https://issues.apache.org/jira/browse/IGNITE-14298
Project: Ignite
Issue Type: Bug
Reporter: Vyacheslav Koptilin
Fix For: 3.0.0-alpha2
DEVNOTES should provide clear instructions on how to run the {{checkstyle}} &&
{{apache-rat}} targets for the project/particular sub-module.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14298) DEVNOTES should contain clear instructions on how to run check-style.
[
https://issues.apache.org/jira/browse/IGNITE-14298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-14298:
-
Labels: 3.0 (was: )
> DEVNOTES should contain clear instructions on how to run check-style.
> -
>
> Key: IGNITE-14298
> URL: https://issues.apache.org/jira/browse/IGNITE-14298
> Project: Ignite
> Issue Type: Bug
>Reporter: Vyacheslav Koptilin
>Priority: Major
> Labels: 3.0
> Fix For: 3.0.0-alpha2
>
>
> DEVNOTES should provide clear instructions on how to run the {{checkstyle}}
> && {{apache-rat}} targets for the project/particular sub-module.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14228) Ducktape test of rebalance for in-memory mode
[
https://issues.apache.org/jira/browse/IGNITE-14228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov updated IGNITE-14228:
-
Description:
This test should check the rebalance on in-memory caches in basic scenario:
rebalance triggered by two event types: node join and node left the topology.
The test should be able to run on large amounts of data enough to ensure
rebalancing time about of several minutes.
Test parameters:
# Initial node count (derived from test context);
# Cache count - the count of caches to create and data preload;
# Cache entry count - the count of entries per cache to preload;
# Cache entry size - the size of each cache entry in bytes;
# Rebalance thread pool size - the value for
{{IgniteConfiguration#rebalanceThreadPoolSize}} property (see [configuring
rebalance thread pool
title|https://ignite.apache.org/docs/latest/data-rebalancing#configuring-rebalance-thread-pool]),
expected that greater value makes rebalance faster.
# Rebalance batch size - the value for
{{IgniteConfiguration#rebalanceBatchSize}} property (see [other rebalance
properties|https://ignite.apache.org/docs/latest/data-rebalancing#other-properties]),
expected that greater value makes rebalance faster on large data or
[throttling|https://ignite.apache.org/docs/latest/data-rebalancing#throttling]
enabled (rebalanceThrottling > 0).
# Rebalance throttle - the value for {{IgniteConfiguration.rebalanceThrottle}}
property (see [rebalance message
throttling|https://ignite.apache.org/docs/latest/data-rebalancing#throttling],
[other rebalance
properties|https://ignite.apache.org/docs/latest/data-rebalancing#other-properties]),
0 - throttling disabled, greater value makes rebalance slower.
Test result: time taken to rebalance process.
was:
This test should check the rebalance on in-memory caches in basic scenario:
rebalance triggered by two event types: node join and node left the topology.
The test should be able to run on large amounts of data enough to ensure
rebalancing time about of several minutes.
Test parameters:
# Initial node count (derived from test context);
# Cache count - the count of caches to create and data preload;
# Cache entry count - the count of entries per cache to preload;
# Cache entry size - the size of each cache entry in bytes;
# Rebalance thread pool size - the value for
IgniteConfiguration.rebalanceThreadPoolSize property (see [configuring
rebalance thread pool
title|https://ignite.apache.org/docs/latest/data-rebalancing#configuring-rebalance-thread-pool]),
expected that greater value makes rebalance faster.
# Rebalance batch size - the value for IgniteConfiguration.rebalanceBatchSize
property (see [other rebalance
properties|https://ignite.apache.org/docs/latest/data-rebalancing#other-properties]),
expected that greater value makes rebalance faster on large data or
[throttling|https://ignite.apache.org/docs/latest/data-rebalancing#throttling]
enabled (rebalanceThrottling > 0).
# Rebalance throttle - the value for IgniteConfiguration.rebalanceThrottle
property (see [rebalance message
throttling|https://ignite.apache.org/docs/latest/data-rebalancing#throttling],
[other rebalance
properties|https://ignite.apache.org/docs/latest/data-rebalancing#other-properties]),
0 - throttling disabled, greater value makes rebalance slower.
Test result: time taken to rebalance process.
> Ducktape test of rebalance for in-memory mode
> -
>
> Key: IGNITE-14228
> URL: https://issues.apache.org/jira/browse/IGNITE-14228
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Dmitriy Sorokin
>Assignee: Dmitriy Sorokin
>Priority: Major
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> This test should check the rebalance on in-memory caches in basic scenario:
> rebalance triggered by two event types: node join and node left the topology.
> The test should be able to run on large amounts of data enough to ensure
> rebalancing time about of several minutes.
> Test parameters:
> # Initial node count (derived from test context);
> # Cache count - the count of caches to create and data preload;
> # Cache entry count - the count of entries per cache to preload;
> # Cache entry size - the size of each cache entry in bytes;
> # Rebalance thread pool size - the value for
> {{IgniteConfiguration#rebalanceThreadPoolSize}} property (see [configuring
> rebalance thread pool
> title|https://ignite.apache.org/docs/latest/data-rebalancing#configuring-rebalance-thread-pool]),
> expected that greater value makes rebalance faster.
> # Rebalance batch size - the value for
> {{IgniteConfiguration#rebalanceBatchSize}} property (see [other rebalance
> properties|https://ignite.apache.org/docs/latest/data-rebalancing#other-properties]),
> expected that
[jira] [Assigned] (IGNITE-12033) Callbacks from striped pool due to async/await may hang cluster
[
https://issues.apache.org/jira/browse/IGNITE-12033?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn reassigned IGNITE-12033:
---
Assignee: Pavel Tupitsyn
> Callbacks from striped pool due to async/await may hang cluster
> ---
>
> Key: IGNITE-12033
> URL: https://issues.apache.org/jira/browse/IGNITE-12033
> Project: Ignite
> Issue Type: Bug
> Components: cache, platforms
>Affects Versions: 2.7.5
>Reporter: Ilya Kasnacheev
>Assignee: Pavel Tupitsyn
>Priority: Critical
>
> Discussed on dev-list:
> http://apache-ignite-developers.2346864.n4.nabble.com/Re-EXTERNAL-Re-Replace-or-Put-after-PutAsync-causes-Ignite-to-hang-td42921.html
> *Must use the public pool for callbacks as the most obvious step.*
>
> http://apache-ignite-users.70518.x6.nabble.com/Replace-or-Put-after-PutAsync-causes-Ignite-to-hang-td27871.html#a28051
> There's a reproducer project. Long story short, .Net can invoke cache
> operations with future callbacks, which will be invoked from striped pool. If
> such callbacks are to use cache operations, those will be possibly sheduled
> to the same stripe and cause a deadlock.
> The code is very simple:
> {code}
> Console.WriteLine("PutAsync");
> await cache.PutAsync(1, "Test");
> Console.WriteLine("Replace");
> cache.Replace(1, "Testing"); // Hangs here
> Console.WriteLine("Wait");
> await Task.Delay(Timeout.Infinite);
> {code}
> async/await should absolutely not allow any client code to be run from
> stripes.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14228) Ducktape test of rebalance for in-memory mode
[ https://issues.apache.org/jira/browse/IGNITE-14228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Sorokin updated IGNITE-14228: - Description: This test should check the rebalance on in-memory caches in basic scenario: rebalance triggered by two event types: node join and node left the topology. The test should be able to run on large amounts of data enough to ensure rebalancing time about of several minutes. Test parameters: # Initial node count (derived from test context); # Cache count - the count of caches to create and data preload; # Cache entry count - the count of entries per cache to preload; # Cache entry size - the size of each cache entry in bytes; # Rebalance thread pool size - the value for IgniteConfiguration.rebalanceThreadPoolSize property (see [configuring rebalance thread pool title|https://ignite.apache.org/docs/latest/data-rebalancing#configuring-rebalance-thread-pool]), expected that greater value makes rebalance faster. # Rebalance batch size - the value for IgniteConfiguration.rebalanceBatchSize property (see [other rebalance properties|https://ignite.apache.org/docs/latest/data-rebalancing#other-properties]), expected that greater value makes rebalance faster on large data or [throttling|https://ignite.apache.org/docs/latest/data-rebalancing#throttling] enabled (rebalanceThrottling > 0). # Rebalance throttle - the value for IgniteConfiguration.rebalanceThrottle property (see [rebalance message throttling|https://ignite.apache.org/docs/latest/data-rebalancing#throttling], [other rebalance properties|https://ignite.apache.org/docs/latest/data-rebalancing#other-properties]), 0 - throttling disabled, greater value makes rebalance slower. Test result: time taken to rebalance process. was: This test should check the rebalance on in-memory caches in basic scenario: rebalance triggered by two event types: node join and node left the topology. The test should be able to run on large amounts of data enough to ensure rebalancing time about of several minutes. Test parameters: see IGNITE-14226 description. Test result: time taken to rebalance process. > Ducktape test of rebalance for in-memory mode > - > > Key: IGNITE-14228 > URL: https://issues.apache.org/jira/browse/IGNITE-14228 > Project: Ignite > Issue Type: Sub-task >Reporter: Dmitriy Sorokin >Assignee: Dmitriy Sorokin >Priority: Major > Time Spent: 1h 50m > Remaining Estimate: 0h > > This test should check the rebalance on in-memory caches in basic scenario: > rebalance triggered by two event types: node join and node left the topology. > The test should be able to run on large amounts of data enough to ensure > rebalancing time about of several minutes. > Test parameters: > # Initial node count (derived from test context); > # Cache count - the count of caches to create and data preload; > # Cache entry count - the count of entries per cache to preload; > # Cache entry size - the size of each cache entry in bytes; > # Rebalance thread pool size - the value for > IgniteConfiguration.rebalanceThreadPoolSize property (see [configuring > rebalance thread pool > title|https://ignite.apache.org/docs/latest/data-rebalancing#configuring-rebalance-thread-pool]), > expected that greater value makes rebalance faster. > # Rebalance batch size - the value for > IgniteConfiguration.rebalanceBatchSize property (see [other rebalance > properties|https://ignite.apache.org/docs/latest/data-rebalancing#other-properties]), > expected that greater value makes rebalance faster on large data or > [throttling|https://ignite.apache.org/docs/latest/data-rebalancing#throttling] > enabled (rebalanceThrottling > 0). > # Rebalance throttle - the value for IgniteConfiguration.rebalanceThrottle > property (see [rebalance message > throttling|https://ignite.apache.org/docs/latest/data-rebalancing#throttling], > [other rebalance > properties|https://ignite.apache.org/docs/latest/data-rebalancing#other-properties]), > 0 - throttling disabled, greater value makes rebalance slower. > Test result: time taken to rebalance process. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14228) Ducktape test of rebalance for in-memory mode
[ https://issues.apache.org/jira/browse/IGNITE-14228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Sorokin updated IGNITE-14228: - Description: This test should check the rebalance on in-memory caches in basic scenario: rebalance triggered by two event types: node join and node left the topology. The test should be able to run on large amounts of data enough to ensure rebalancing time about of several minutes. Test parameters: see IGNITE-14226 description. Test result: time taken to rebalance process. was: This test should check the rebalance on in-memory caches in basic scenario. Preloaded data size should be at least 30GB. The runs should be made for different entry sizes: 1, 2, 10, 25 and 50KB. Also, different values of rebalance thread pool size and rebalance batch size should be tested: 2, 4, 8 and 512KiB, 1MiB, 2MiB accordingly. > Ducktape test of rebalance for in-memory mode > - > > Key: IGNITE-14228 > URL: https://issues.apache.org/jira/browse/IGNITE-14228 > Project: Ignite > Issue Type: Sub-task >Reporter: Dmitriy Sorokin >Assignee: Dmitriy Sorokin >Priority: Major > Time Spent: 1h 50m > Remaining Estimate: 0h > > This test should check the rebalance on in-memory caches in basic scenario: > rebalance triggered by two event types: node join and node left the topology. > The test should be able to run on large amounts of data enough to ensure > rebalancing time about of several minutes. > Test parameters: see IGNITE-14226 description. > Test result: time taken to rebalance process. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14226) Ducktape tests of rebalance
[ https://issues.apache.org/jira/browse/IGNITE-14226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Sorokin updated IGNITE-14226: - Description: There should be tests of rebalance for both in-memory caches and persistent caches. In case of persistent caches, the tests also should check both modes of rebalance: full and historical (asserts is needed that the proper mode of rebalance was worked). Basic scenario: Testing of rebalance triggered by two event types: node join and node left the topology (baseline change in persistent mode). Extended scenario: Node join or left during rebalance process. Test parameters: # Initial node count (derived from test context); # Cache count - the count of caches to create and data preload; # Cache entry count - the count of entries per cache to preload; # Cache entry size - the size of each cache entry in bytes; # Rebalance thread pool size - the value for IgniteConfiguration.rebalanceThreadPoolSize property (see [configuring rebalance thread pool title|https://ignite.apache.org/docs/latest/data-rebalancing#configuring-rebalance-thread-pool]), expected that greater value makes rebalance faster. # Rebalance batch size - the value for IgniteConfiguration.rebalanceBatchSize property (see [other rebalance properties|https://ignite.apache.org/docs/latest/data-rebalancing#other-properties]), expected that greater value makes rebalance faster on large data or [throttling|https://ignite.apache.org/docs/latest/data-rebalancing#throttling] enabled (rebalanceThrottling > 0). # Rebalance throttle - the value for IgniteConfiguration.rebalanceThrottle property (see [rebalance message throttling|https://ignite.apache.org/docs/latest/data-rebalancing#throttling], [other rebalance properties|https://ignite.apache.org/docs/latest/data-rebalancing#other-properties]), 0 - throttling disabled, greater value makes rebalance slower. Test result: time taken to rebalance process. was: There should be tests of rebalance for both in-memory caches and persistent caches. In case of persistent caches, the tests also should check both modes of rebalance: full and historical (asserts is needed that the proper mode of rebalance was worked). Basic scenario: Testing of rebalance triggered by two event types: node enter and node leave (baseline change in persistent mode). Extended scenario: Node entering or leaving during rebalance process. Test parameters: # Initial node count (derived from test context); # Cache count; # Cache entry count; # Cache entry size; # Rebalance thread pool size # Rebalance batch size # Rebalance throttle Test result: time taken to rebalance process. > Ducktape tests of rebalance > --- > > Key: IGNITE-14226 > URL: https://issues.apache.org/jira/browse/IGNITE-14226 > Project: Ignite > Issue Type: Test >Reporter: Dmitriy Sorokin >Assignee: Dmitriy Sorokin >Priority: Major > > There should be tests of rebalance for both in-memory caches and persistent > caches. > In case of persistent caches, the tests also should check both modes of > rebalance: full and historical (asserts is needed that the proper mode of > rebalance was worked). > Basic scenario: > Testing of rebalance triggered by two event types: node join and node left > the topology (baseline change in persistent mode). > Extended scenario: > Node join or left during rebalance process. > Test parameters: > # Initial node count (derived from test context); > # Cache count - the count of caches to create and data preload; > # Cache entry count - the count of entries per cache to preload; > # Cache entry size - the size of each cache entry in bytes; > # Rebalance thread pool size - the value for > IgniteConfiguration.rebalanceThreadPoolSize property (see [configuring > rebalance thread pool > title|https://ignite.apache.org/docs/latest/data-rebalancing#configuring-rebalance-thread-pool]), > expected that greater value makes rebalance faster. > # Rebalance batch size - the value for > IgniteConfiguration.rebalanceBatchSize property (see [other rebalance > properties|https://ignite.apache.org/docs/latest/data-rebalancing#other-properties]), > expected that greater value makes rebalance faster on large data or > [throttling|https://ignite.apache.org/docs/latest/data-rebalancing#throttling] > enabled (rebalanceThrottling > 0). > # Rebalance throttle - the value for IgniteConfiguration.rebalanceThrottle > property (see [rebalance message > throttling|https://ignite.apache.org/docs/latest/data-rebalancing#throttling], > [other rebalance > properties|https://ignite.apache.org/docs/latest/data-rebalancing#other-properties]), > 0 - throttling disabled, greater value makes rebalance slower. > Test result: time taken to rebalance process. -- This message was sent by
[jira] [Updated] (IGNITE-14290) Implement Schema builders.
[ https://issues.apache.org/jira/browse/IGNITE-14290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Gerzhedovich updated IGNITE-14290: --- Component/s: sql > Implement Schema builders. > -- > > Key: IGNITE-14290 > URL: https://issues.apache.org/jira/browse/IGNITE-14290 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Andrey Mashenkov >Priority: Major > Labels: iep-54, ignite-3 > > Implement schema configuration API from IGNITE-13748 and internal > SchemaDescriptor. > Initial Schema and Native types implementations are suggested in IGNITE-13617. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14297) API to unregister HandlerProvider from network module
Sergey Chugunov created IGNITE-14297: Summary: API to unregister HandlerProvider from network module Key: IGNITE-14297 URL: https://issues.apache.org/jira/browse/IGNITE-14297 Project: Ignite Issue Type: Sub-task Reporter: Sergey Chugunov Fix For: 3.0.0-alpha2 At the moment client components can register HandlerProviders in network component but cannot unregister them. However this could be important in component lifecycle to properly stop the component. API to unregister handler from the network with clear contract about possible races (one thread unregisteres component's handler, another thread sends a message from the same component) should be implemented. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-11027) CPP: Add support of compact footer for C++
[ https://issues.apache.org/jira/browse/IGNITE-11027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin reassigned IGNITE-11027: Assignee: (was: Vyacheslav Koptilin) > CPP: Add support of compact footer for C++ > -- > > Key: IGNITE-11027 > URL: https://issues.apache.org/jira/browse/IGNITE-11027 > Project: Ignite > Issue Type: Improvement > Components: platforms >Affects Versions: 2.7 >Reporter: Igor Sapego >Priority: Major > > Currently, compact footers are not supported by Ignite C++ and C++ thin > clients. As they both share the same library - binary, we can add this > support for both C++ thin and Ignite C++ at the same time. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14296) Classes' names in network module don't need to start with `Network` prefix
[ https://issues.apache.org/jira/browse/IGNITE-14296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Chugunov updated IGNITE-14296: - Summary: Classes' names in network module don't need to start with `Network` prefix (was: Classe) > Classes' names in network module don't need to start with `Network` prefix > -- > > Key: IGNITE-14296 > URL: https://issues.apache.org/jira/browse/IGNITE-14296 > Project: Ignite > Issue Type: Sub-task >Reporter: Sergey Chugunov >Priority: Trivial > > Classes' names in network module are self-explanatory and don't need a > special prefix, it could be removed to make the code more compact. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14295) Message interface to be introduced
[ https://issues.apache.org/jira/browse/IGNITE-14295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Chugunov updated IGNITE-14295: - Fix Version/s: 3.0.0-alpha2 > Message interface to be introduced > -- > > Key: IGNITE-14295 > URL: https://issues.apache.org/jira/browse/IGNITE-14295 > Project: Ignite > Issue Type: Sub-task >Reporter: Sergey Chugunov >Priority: Major > Fix For: 3.0.0-alpha2 > > > Network module should introduce a public Message interface to handle messages > to send and receive. > This interface should provide at least information about message type (and > possible version) to enable effective serialization/deserialization and > ability to subscribe for a messages of certain type. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14296) Classes' names in network module don't need to start with `Network` prefix
[ https://issues.apache.org/jira/browse/IGNITE-14296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Chugunov updated IGNITE-14296: - Fix Version/s: 3.0.0-alpha2 > Classes' names in network module don't need to start with `Network` prefix > -- > > Key: IGNITE-14296 > URL: https://issues.apache.org/jira/browse/IGNITE-14296 > Project: Ignite > Issue Type: Sub-task >Reporter: Sergey Chugunov >Priority: Trivial > Fix For: 3.0.0-alpha2 > > > Classes' names in network module are self-explanatory and don't need a > special prefix, it could be removed to make the code more compact. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14296) Classe
Sergey Chugunov created IGNITE-14296: Summary: Classe Key: IGNITE-14296 URL: https://issues.apache.org/jira/browse/IGNITE-14296 Project: Ignite Issue Type: Sub-task Reporter: Sergey Chugunov Classes' names in network module are self-explanatory and don't need a special prefix, it could be removed to make the code more compact. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14295) Message interface to be introduced
Sergey Chugunov created IGNITE-14295: Summary: Message interface to be introduced Key: IGNITE-14295 URL: https://issues.apache.org/jira/browse/IGNITE-14295 Project: Ignite Issue Type: Sub-task Reporter: Sergey Chugunov Network module should introduce a public Message interface to handle messages to send and receive. This interface should provide at least information about message type (and possible version) to enable effective serialization/deserialization and ability to subscribe for a messages of certain type. -- This message was sent by Atlassian Jira (v8.3.4#803005)
