[jira] [Commented] (IGNITE-14076) Quadratic putAll performance degradation in transactional cache
[
https://issues.apache.org/jira/browse/IGNITE-14076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17308391#comment-17308391
]
Stanilovsky Evgeny commented on IGNITE-14076:
-
i believe it improve code reading and clearing.
> Quadratic putAll performance degradation in transactional cache
> ---
>
> Key: IGNITE-14076
> URL: https://issues.apache.org/jira/browse/IGNITE-14076
> Project: Ignite
> Issue Type: Improvement
> Components: cache
>Affects Versions: 2.10
>Reporter: Pavel Tupitsyn
>Assignee: Stanilovsky Evgeny
>Priority: Critical
> Time Spent: 40m
> Remaining Estimate: 0h
>
> {{putAll}} execution time grows almost exponentially while the number of keys
> grows linearly in the following test:
> {code:java}
> public class PutAllTxTest extends GridCommonAbstractTest {
> @Test
> public void testPutAll() throws Exception {
> Ignition.start(getConfiguration("server1"));
> Ignition.start(getConfiguration("server2"));
> Ignite ignite =
> Ignition.start(getConfiguration("client").setClientMode(true));
> IgniteCache cache = ignite.createCache(
> new CacheConfiguration("c")
> .setAtomicityMode(CacheAtomicityMode.TRANSACTIONAL));
> int count = 5;
> Map data = new TreeMap<>();
> for (int i = 0; i < count; i++)
> data.put(i, i);
> long begin = System.nanoTime();
> cache.putAll(data);
> long dur = System.nanoTime() - begin;
> System.out.println("> " + dur / 100);
> }
> }
> {code}
> ||Entries||Seconds||
> |1000|0.4|
> |5000|1.9|
> |1|3.8|
> |2|10.7|
> |3|23.5|
> |4|41|
> |5|64|
> |6|90|
> |10|254|
> This does not reproduce with 1 server node, and does not reproduce on
> {{ATOMIC}} caches with any number of nodes.
> *Observations:*
> - Not a GC issue (it barely runs)
> - Not a memory issue (heap is under 1GB)
> - GridDhtTxPrepareFuture#localDhtPendingVersions ->
> GridCacheMapEntry.localCandidates is the bottleneck. For 1K keys,
> localCandidates gets called 123K times, 2K keys - 484K times, etc.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-14394) Baseline auto-adjustment does not happen when 2+ nodes join the cluster
Vyacheslav Koptilin created IGNITE-14394: Summary: Baseline auto-adjustment does not happen when 2+ nodes join the cluster Key: IGNITE-14394 URL: https://issues.apache.org/jira/browse/IGNITE-14394 Project: Ignite Issue Type: Bug Reporter: Vyacheslav Koptilin Assignee: Vyacheslav Koptilin In the case of baseline topology autoadjustment is enabled and a few server nodes join the cluster the autoadjustment may not be triggered. Steps to reproduce: 1. start ignite cluster and enable baseline autoadjustment 2. start 2+ server nodes (in order to reproduce the issue, the corresponding exchange should be merged) 3. wait for baseline autoadjustment -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14076) Quadratic putAll performance degradation in transactional cache
[
https://issues.apache.org/jira/browse/IGNITE-14076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17308114#comment-17308114
]
Vladislav Pyatkov commented on IGNITE-14076:
[~zstan] I have watched your patch and didn't understand what the purpose of
change in GridNearOptimisticTxPrepareFuture.java.
> Quadratic putAll performance degradation in transactional cache
> ---
>
> Key: IGNITE-14076
> URL: https://issues.apache.org/jira/browse/IGNITE-14076
> Project: Ignite
> Issue Type: Improvement
> Components: cache
>Affects Versions: 2.10
>Reporter: Pavel Tupitsyn
>Assignee: Stanilovsky Evgeny
>Priority: Critical
> Time Spent: 40m
> Remaining Estimate: 0h
>
> {{putAll}} execution time grows almost exponentially while the number of keys
> grows linearly in the following test:
> {code:java}
> public class PutAllTxTest extends GridCommonAbstractTest {
> @Test
> public void testPutAll() throws Exception {
> Ignition.start(getConfiguration("server1"));
> Ignition.start(getConfiguration("server2"));
> Ignite ignite =
> Ignition.start(getConfiguration("client").setClientMode(true));
> IgniteCache cache = ignite.createCache(
> new CacheConfiguration("c")
> .setAtomicityMode(CacheAtomicityMode.TRANSACTIONAL));
> int count = 5;
> Map data = new TreeMap<>();
> for (int i = 0; i < count; i++)
> data.put(i, i);
> long begin = System.nanoTime();
> cache.putAll(data);
> long dur = System.nanoTime() - begin;
> System.out.println("> " + dur / 100);
> }
> }
> {code}
> ||Entries||Seconds||
> |1000|0.4|
> |5000|1.9|
> |1|3.8|
> |2|10.7|
> |3|23.5|
> |4|41|
> |5|64|
> |6|90|
> |10|254|
> This does not reproduce with 1 server node, and does not reproduce on
> {{ATOMIC}} caches with any number of nodes.
> *Observations:*
> - Not a GC issue (it barely runs)
> - Not a memory issue (heap is under 1GB)
> - GridDhtTxPrepareFuture#localDhtPendingVersions ->
> GridCacheMapEntry.localCandidates is the bottleneck. For 1K keys,
> localCandidates gets called 123K times, 2K keys - 484K times, etc.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-14393) Describe components interactions with metastorage
[ https://issues.apache.org/jira/browse/IGNITE-14393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk reassigned IGNITE-14393: - Assignee: Alexey Goncharuk > Describe components interactions with metastorage > - > > Key: IGNITE-14393 > URL: https://issues.apache.org/jira/browse/IGNITE-14393 > Project: Ignite > Issue Type: Improvement > Components: documentation >Affects Versions: 3.0.0-alpha1 >Reporter: Alexey Goncharuk >Assignee: Alexey Goncharuk >Priority: Major > Labels: iep-61, ignite-3 > Fix For: 3.0.0-alpha2 > > > We want to use metastorage as the golden source of the cluster state. Need to > describe how components will interact with each other based on metastorage > key writes and watches. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14393) Describe components interactions with metastorage
[ https://issues.apache.org/jira/browse/IGNITE-14393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-14393: -- Ignite Flags: (was: Docs Required,Release Notes Required) > Describe components interactions with metastorage > - > > Key: IGNITE-14393 > URL: https://issues.apache.org/jira/browse/IGNITE-14393 > Project: Ignite > Issue Type: Improvement > Components: documentation >Affects Versions: 3.0.0-alpha1 >Reporter: Alexey Goncharuk >Priority: Major > Labels: iep-61, ignite-3 > Fix For: 3.0.0-alpha2 > > > We want to use metastorage as the golden source of the cluster state. Need to > describe how components will interact with each other based on metastorage > key writes and watches. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14393) Describe components interactions with metastorage
[ https://issues.apache.org/jira/browse/IGNITE-14393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-14393: -- Labels: iep-61 ignite-3 (was: ) > Describe components interactions with metastorage > - > > Key: IGNITE-14393 > URL: https://issues.apache.org/jira/browse/IGNITE-14393 > Project: Ignite > Issue Type: Improvement > Components: documentation >Affects Versions: 3.0.0-alpha1 >Reporter: Alexey Goncharuk >Priority: Major > Labels: iep-61, ignite-3 > Fix For: 3.0.0-alpha2 > > > We want to use metastorage as the golden source of the cluster state. Need to > describe how components will interact with each other based on metastorage > key writes and watches. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14393) Describe components interactions with metastorage
Alexey Goncharuk created IGNITE-14393: - Summary: Describe components interactions with metastorage Key: IGNITE-14393 URL: https://issues.apache.org/jira/browse/IGNITE-14393 Project: Ignite Issue Type: Improvement Components: documentation Affects Versions: 3.0.0-alpha1 Reporter: Alexey Goncharuk Fix For: 3.0.0-alpha2 We want to use metastorage as the golden source of the cluster state. Need to describe how components will interact with each other based on metastorage key writes and watches. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14388) Add affinity key support.
[ https://issues.apache.org/jira/browse/IGNITE-14388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov updated IGNITE-14388: -- Description: For now, we calculate key hash for a whole key chunk represented with byte[]. Let's calculate key hash for affinity columns only. > Add affinity key support. > - > > Key: IGNITE-14388 > URL: https://issues.apache.org/jira/browse/IGNITE-14388 > Project: Ignite > Issue Type: Improvement >Reporter: Andrey Mashenkov >Priority: Major > Labels: iep-54, ignite-3 > > For now, we calculate key hash for a whole key chunk represented with byte[]. > Let's calculate key hash for affinity columns only. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14388) Add affinity key support.
[ https://issues.apache.org/jira/browse/IGNITE-14388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov updated IGNITE-14388: -- Environment: (was: For now, we calculate key hash for a whole key chunk represented with byte[]. Let's calculate key hash for affinity columns only.) > Add affinity key support. > - > > Key: IGNITE-14388 > URL: https://issues.apache.org/jira/browse/IGNITE-14388 > Project: Ignite > Issue Type: Improvement >Reporter: Andrey Mashenkov >Priority: Major > Labels: iep-54, ignite-3 > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (IGNITE-14387) [Ignite Website] Update for events schedule
[ https://issues.apache.org/jira/browse/IGNITE-14387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mauricio Stekl resolved IGNITE-14387. - Resolution: Fixed [~romanova.ks.spb] I've added the event to the calendar. > [Ignite Website] Update for events schedule > --- > > Key: IGNITE-14387 > URL: https://issues.apache.org/jira/browse/IGNITE-14387 > Project: Ignite > Issue Type: Task > Components: website >Reporter: Kseniya Romanova >Assignee: Mauricio Stekl >Priority: Minor > > [~mstekl] please add new event to [the schedule > :|https://ignite.apache.org/events.html] > Distributed Java DBs Under the Hood: Components & Interactions Between Them > Chicago PostgreSQL Meetup Group, Val Kulichenko > April 13, 2021 > During the session, we create a simple (although fully workable) distributed > cache in Java, almost from scratch. We use the cache to demonstrate basic > CRUD operations, as well as to demonstrate how scalability can be improved by > adding resources to the system. > Read more = > https://www.meetup.com/Chicago-PostgreSQL-User-Group/events/277073375/ > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-14387) [Ignite Website] Update for events schedule
[ https://issues.apache.org/jira/browse/IGNITE-14387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mauricio Stekl reassigned IGNITE-14387: --- Assignee: Mauricio Stekl > [Ignite Website] Update for events schedule > --- > > Key: IGNITE-14387 > URL: https://issues.apache.org/jira/browse/IGNITE-14387 > Project: Ignite > Issue Type: Task > Components: website >Reporter: Kseniya Romanova >Assignee: Mauricio Stekl >Priority: Minor > > [~mstekl] please add new event to [the schedule > :|https://ignite.apache.org/events.html] > Distributed Java DBs Under the Hood: Components & Interactions Between Them > Chicago PostgreSQL Meetup Group, Val Kulichenko > April 13, 2021 > During the session, we create a simple (although fully workable) distributed > cache in Java, almost from scratch. We use the cache to demonstrate basic > CRUD operations, as well as to demonstrate how scalability can be improved by > adding resources to the system. > Read more = > https://www.meetup.com/Chicago-PostgreSQL-User-Group/events/277073375/ > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14392) Remove the SQL Transactions page from Apache Ignite docs
Nikita Safonov created IGNITE-14392: --- Summary: Remove the SQL Transactions page from Apache Ignite docs Key: IGNITE-14392 URL: https://issues.apache.org/jira/browse/IGNITE-14392 Project: Ignite Issue Type: Improvement Components: documentation Reporter: Nikita Safonov Assignee: Nikita Safonov The page: [https://ignite.apache.org/docs/latest/SQL/sql-transactions|https://www.gridgain.com/docs/latest/developers-guide/SQL/sql-transactions] * We should remove it from the menu (toc.yaml) * We should make sure it's not indexed by Google -> need to update robot.txt * We should check references to this page from other pages. The references do exist. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14391) Multi-node cache data preloading
[
https://issues.apache.org/jira/browse/IGNITE-14391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Sorokin updated IGNITE-14391:
-
Description:
Need to add the test parameter {{preloaders}} and use it as {{num_nodes}}
parameter on creation {{IgniteApplicationService}} instance used for data
preloading.
The keys of preloading data entries should be distributed between client nodes
as equal sized ranges.
was:
Need to add the test parameter {{client_node_count}} and use it as
{{num_nodes}} parameter on creation {{IgniteApplicationService}} instance used
for data preloading.
The keys of preloading data entries should be distributed between client nodes
as equal sized ranges.
> Multi-node cache data preloading
>
>
> Key: IGNITE-14391
> URL: https://issues.apache.org/jira/browse/IGNITE-14391
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Dmitriy Sorokin
>Assignee: Dmitriy Sorokin
>Priority: Major
>
> Need to add the test parameter {{preloaders}} and use it as {{num_nodes}}
> parameter on creation {{IgniteApplicationService}} instance used for data
> preloading.
> The keys of preloading data entries should be distributed between client
> nodes as equal sized ranges.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-14391) Multi-node cache data preloading
Dmitriy Sorokin created IGNITE-14391:
Summary: Multi-node cache data preloading
Key: IGNITE-14391
URL: https://issues.apache.org/jira/browse/IGNITE-14391
Project: Ignite
Issue Type: Sub-task
Reporter: Dmitriy Sorokin
Assignee: Dmitriy Sorokin
Need to add the test parameter {{client_node_count}} and use it as
{{num_nodes}} parameter on creation {{IgniteApplicationService}} instance used
for data preloading.
The keys of preloading data entries should be distributed between client nodes
as equal sized ranges.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-14390) Add rebalance statistic to test result data
Dmitriy Sorokin created IGNITE-14390: Summary: Add rebalance statistic to test result data Key: IGNITE-14390 URL: https://issues.apache.org/jira/browse/IGNITE-14390 Project: Ignite Issue Type: Sub-task Reporter: Dmitriy Sorokin Assignee: Dmitriy Sorokin Need to add to test result data the rebalance statistic data derived from node rebalance metrics: start_time [min, max] end_time [min, max] duration [min, max, sum] received_bytes [min, max, sum] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14389) Implement simple in-memory meta storage
[ https://issues.apache.org/jira/browse/IGNITE-14389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey N. Gura updated IGNITE-14389: Labels: iep-61 ignite-3 (was: ignite-3) > Implement simple in-memory meta storage > --- > > Key: IGNITE-14389 > URL: https://issues.apache.org/jira/browse/IGNITE-14389 > 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 > > > Simple in-memory meta storage should be implemented in order to: > - Unblock development of dependent components. > - Provide ability to develop integration tests. > - Verify concepts and approaches defined by interface. > In-memory meta storage should satisfy to the following requirements: > - It should implement interface (not literally of course) defined in > IGNITE-14198 issue. > - It should use simple in-memory data structures as storage. > - It should be single-threaded for read-write requests (except of watch). > - Ranges reads could be processed in another thread but it is not mandatory > in first iteration. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14269) Design conditional multi update functionality for meta storage client
[
https://issues.apache.org/jira/browse/IGNITE-14269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey N. Gura updated IGNITE-14269:
Labels: iep-61 ignite-3 (was: ignite-3)
> Design conditional multi update functionality for meta storage client
> -
>
> Key: IGNITE-14269
> URL: https://issues.apache.org/jira/browse/IGNITE-14269
> 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
>
>
> Define entities required for implementation of conditional multi updates (aka
> "transactions") for meta storage.
> Requirements:
> - Design should provide possibility to define conditional updates in
> if-then-else manner with nested branches.
> - Update always starts with condition.
> - Any nested branch must start with condition.
> - Update can't precede to condition.
> - Every branch can yield exactly one custom result (limited by number of
> simple types) and any number of entries. Corresponding expression always must
> be at the end of branch.
> - Condition for entry revision allows the following comparisons: equal,
> !equal, less, greater.
> - Condition for entry value allows the following operations (byte-wise):
> equal, !equal.
> - Update allows the following operations: put, remove, no-op.
> - Condition can not use previously defined condition instance again because
> it will lead to graph cycle and infinite update execution.
> Assumptions:
> - It seems that conditions and updates entities can be conveniently linked
> using chaining.
> Simple example (pseudocode):
> {code}
> CompletableFuture> = invoke(valCond(EQUAL,
> perstEnabled, true)._then(
> valCond(EQUAL, walEnabled, true)._then(
> update(walEnabled, true)).
> _else(
> update(walEnabled, false))
> )._else(NoopUpdate))
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14389) Implement simple in-memory meta storage
[ https://issues.apache.org/jira/browse/IGNITE-14389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey N. Gura updated IGNITE-14389: Labels: ignite-3 (was: ) > Implement simple in-memory meta storage > --- > > Key: IGNITE-14389 > URL: https://issues.apache.org/jira/browse/IGNITE-14389 > Project: Ignite > Issue Type: New Feature >Reporter: Andrey N. Gura >Assignee: Andrey N. Gura >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha2 > > > Simple in-memory meta storage should be implemented in order to: > - Unblock development of dependent components. > - Provide ability to develop integration tests. > - Verify concepts and approaches defined by interface. > In-memory meta storage should satisfy to the following requirements: > - It should implement interface (not literally of course) defined in > IGNITE-14198 issue. > - It should use simple in-memory data structures as storage. > - It should be single-threaded for read-write requests (except of watch). > - Ranges reads could be processed in another thread but it is not mandatory > in first iteration. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14269) Design conditional multi update functionality for meta storage client
[
https://issues.apache.org/jira/browse/IGNITE-14269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey N. Gura updated IGNITE-14269:
Labels: ignite-3 (was: )
> Design conditional multi update functionality for meta storage client
> -
>
> Key: IGNITE-14269
> URL: https://issues.apache.org/jira/browse/IGNITE-14269
> Project: Ignite
> Issue Type: New Feature
>Reporter: Andrey N. Gura
>Assignee: Andrey N. Gura
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-alpha2
>
>
> Define entities required for implementation of conditional multi updates (aka
> "transactions") for meta storage.
> Requirements:
> - Design should provide possibility to define conditional updates in
> if-then-else manner with nested branches.
> - Update always starts with condition.
> - Any nested branch must start with condition.
> - Update can't precede to condition.
> - Every branch can yield exactly one custom result (limited by number of
> simple types) and any number of entries. Corresponding expression always must
> be at the end of branch.
> - Condition for entry revision allows the following comparisons: equal,
> !equal, less, greater.
> - Condition for entry value allows the following operations (byte-wise):
> equal, !equal.
> - Update allows the following operations: put, remove, no-op.
> - Condition can not use previously defined condition instance again because
> it will lead to graph cycle and infinite update execution.
> Assumptions:
> - It seems that conditions and updates entities can be conveniently linked
> using chaining.
> Simple example (pseudocode):
> {code}
> CompletableFuture> = invoke(valCond(EQUAL,
> perstEnabled, true)._then(
> valCond(EQUAL, walEnabled, true)._then(
> update(walEnabled, true)).
> _else(
> update(walEnabled, false))
> )._else(NoopUpdate))
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-14389) Implement simple in-memory meta storage
Andrey N. Gura created IGNITE-14389: --- Summary: Implement simple in-memory meta storage Key: IGNITE-14389 URL: https://issues.apache.org/jira/browse/IGNITE-14389 Project: Ignite Issue Type: New Feature Reporter: Andrey N. Gura Assignee: Andrey N. Gura Fix For: 3.0.0-alpha2 Simple in-memory meta storage should be implemented in order to: - Unblock development of dependent components. - Provide ability to develop integration tests. - Verify concepts and approaches defined by interface. In-memory meta storage should satisfy to the following requirements: - It should implement interface (not literally of course) defined in IGNITE-14198 issue. - It should use simple in-memory data structures as storage. - It should be single-threaded for read-write requests (except of watch). - Ranges reads could be processed in another thread but it is not mandatory in first iteration. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14388) Add affinity key support.
Andrey Mashenkov created IGNITE-14388: - Summary: Add affinity key support. Key: IGNITE-14388 URL: https://issues.apache.org/jira/browse/IGNITE-14388 Project: Ignite Issue Type: Improvement Environment: For now, we calculate key hash for a whole key chunk represented with byte[]. Let's calculate key hash for affinity columns only. Reporter: Andrey Mashenkov -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14076) Quadratic putAll performance degradation in transactional cache
[
https://issues.apache.org/jira/browse/IGNITE-14076?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-14076:
-
Reviewer: Vladislav Pyatkov (was: Slava Koptilin)
> Quadratic putAll performance degradation in transactional cache
> ---
>
> Key: IGNITE-14076
> URL: https://issues.apache.org/jira/browse/IGNITE-14076
> Project: Ignite
> Issue Type: Improvement
> Components: cache
>Affects Versions: 2.10
>Reporter: Pavel Tupitsyn
>Assignee: Stanilovsky Evgeny
>Priority: Critical
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> {{putAll}} execution time grows almost exponentially while the number of keys
> grows linearly in the following test:
> {code:java}
> public class PutAllTxTest extends GridCommonAbstractTest {
> @Test
> public void testPutAll() throws Exception {
> Ignition.start(getConfiguration("server1"));
> Ignition.start(getConfiguration("server2"));
> Ignite ignite =
> Ignition.start(getConfiguration("client").setClientMode(true));
> IgniteCache cache = ignite.createCache(
> new CacheConfiguration("c")
> .setAtomicityMode(CacheAtomicityMode.TRANSACTIONAL));
> int count = 5;
> Map data = new TreeMap<>();
> for (int i = 0; i < count; i++)
> data.put(i, i);
> long begin = System.nanoTime();
> cache.putAll(data);
> long dur = System.nanoTime() - begin;
> System.out.println("> " + dur / 100);
> }
> }
> {code}
> ||Entries||Seconds||
> |1000|0.4|
> |5000|1.9|
> |1|3.8|
> |2|10.7|
> |3|23.5|
> |4|41|
> |5|64|
> |6|90|
> |10|254|
> This does not reproduce with 1 server node, and does not reproduce on
> {{ATOMIC}} caches with any number of nodes.
> *Observations:*
> - Not a GC issue (it barely runs)
> - Not a memory issue (heap is under 1GB)
> - GridDhtTxPrepareFuture#localDhtPendingVersions ->
> GridCacheMapEntry.localCandidates is the bottleneck. For 1K keys,
> localCandidates gets called 123K times, 2K keys - 484K times, etc.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13056) SchemaManager refactoring
[ https://issues.apache.org/jira/browse/IGNITE-13056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17307793#comment-17307793 ] Konstantin Orlov commented on IGNITE-13056: --- Hi, [~timonin.maksim]. Now the patch looks good to me. Thanks for your effort! [~tledkov-gridgain], could you please also take a look and merge if you are OK with these changes? > SchemaManager refactoring > - > > Key: IGNITE-13056 > URL: https://issues.apache.org/jira/browse/IGNITE-13056 > Project: Ignite > Issue Type: New Feature > Components: sql >Affects Versions: 2.8 >Reporter: Nikolay Izhikov >Assignee: Maksim Timonin >Priority: Major > Labels: IEP-49, calcite > Time Spent: 10h 20m > Remaining Estimate: 0h > > Since Ignite wants to leverage from several SQL engines we need to make work > with index independent from the used SQL engine. > We also should consider moving all machinery related to an index to the core > module to make it available from any module that wants to use it. > Requirements so far: > * Ability to track indexes in several engines -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14387) [Ignite Website] Update for events schedule
Kseniya Romanova created IGNITE-14387: - Summary: [Ignite Website] Update for events schedule Key: IGNITE-14387 URL: https://issues.apache.org/jira/browse/IGNITE-14387 Project: Ignite Issue Type: Task Components: website Reporter: Kseniya Romanova [~mstekl] please add new event to [the schedule :|https://ignite.apache.org/events.html] Distributed Java DBs Under the Hood: Components & Interactions Between Them Chicago PostgreSQL Meetup Group, Val Kulichenko April 13, 2021 During the session, we create a simple (although fully workable) distributed cache in Java, almost from scratch. We use the cache to demonstrate basic CRUD operations, as well as to demonstrate how scalability can be improved by adding resources to the system. Read more = https://www.meetup.com/Chicago-PostgreSQL-User-Group/events/277073375/ -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13670) Skip writing null-map and varlen table when possible
[ https://issues.apache.org/jira/browse/IGNITE-13670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-13670: -- Summary: Skip writing null-map and varlen table when possible (was: Upgrade nullmap to null-defaults map) > Skip writing null-map and varlen table when possible > > > Key: IGNITE-13670 > URL: https://issues.apache.org/jira/browse/IGNITE-13670 > Project: Ignite > Issue Type: Improvement >Reporter: Alexey Goncharuk >Priority: Major > Labels: iep-54, ignite-3 > > The nullmap is currently always written to the tuple layout for all columns > (even if there are no nullable columns). This data structure can be further > used to encode default values for non-nullable columns (either a > user-specified value or 0 for primitives). > The bits will still be left unused for non-null non-primitive types (UUID, > String, byte[], etc). > Also, need to add support for skipping writing nullmaps (use the flags bit). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14386) Failure handler triggered on doneFut.get() in Checkpointer.syncUpdatedStores@db-checkpoint-thread
Ilya Kasnacheev created IGNITE-14386:
Summary: Failure handler triggered on doneFut.get() in
Checkpointer.syncUpdatedStores@db-checkpoint-thread
Key: IGNITE-14386
URL: https://issues.apache.org/jira/browse/IGNITE-14386
Project: Ignite
Issue Type: Bug
Components: persistence
Affects Versions: 2.10
Reporter: Ilya Kasnacheev
Assignee: Ilya Kasnacheev
{code}
Thread [name="binary-metadata-writer-#71", id=97, state=RUNNABLE, blockCnt=0,
waitCnt=8612]
at java.base@11.0.6/sun.nio.ch.FileDispatcherImpl.force0(Native Method)
at java.base@11.0.6/sun.nio.ch.FileDispatcherImpl.force(Unknown Source)
at
java.base@11.0.6/sun.nio.ch.SimpleAsynchronousFileChannelImpl.force(Unknown
Source)
at
app//o.a.i.i.processors.cache.persistence.file.AsyncFileIO.force(AsyncFileIO.java:216)
at
app//o.a.i.i.processors.cache.persistence.file.AsyncFileIO.force(AsyncFileIO.java:211)
at
app//o.a.i.i.processors.cache.binary.BinaryMetadataFileStore.writeMetadata(BinaryMetadataFileStore.java:143)
at
app//o.a.i.i.processors.cache.binary.BinaryMetadataFileStore$WriteOperationTask.execute(BinaryMetadataFileStore.java:653)
at
app//o.a.i.i.processors.cache.binary.BinaryMetadataFileStore$BinaryMetadataAsyncWriter.body0(BinaryMetadataFileStore.java:463)
at
app//o.a.i.i.processors.cache.binary.BinaryMetadataFileStore$BinaryMetadataAsyncWriter.body(BinaryMetadataFileStore.java:435)
at app//o.a.i.i.util.worker.GridWorker.run(GridWorker.java:119)
at java.base@11.0.6/java.lang.Thread.run(Unknown Source)
Thread [name="db-checkpoint-thread-#116", id=148, state=WAITING, blockCnt=3,
waitCnt=13147]
at java.base@11.0.6/jdk.internal.misc.Unsafe.park(Native Method)
at java.base@11.0.6/java.util.concurrent.locks.LockSupport.park(Unknown
Source)
at
app//o.a.i.i.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:186)
at
app//o.a.i.i.util.future.GridFutureAdapter.get(GridFutureAdapter.java:149)
at
app//o.a.i.i.processors.cache.persistence.checkpoint.Checkpointer.syncUpdatedStores(Checkpointer.java:631)
at
app//o.a.i.i.processors.cache.persistence.checkpoint.Checkpointer.writePages(Checkpointer.java:550)
at
app//o.a.i.i.processors.cache.persistence.checkpoint.Checkpointer.doCheckpoint(Checkpointer.java:428)
at
app//o.a.i.i.processors.cache.persistence.checkpoint.Checkpointer.body(Checkpointer.java:264)
at app//o.a.i.i.util.worker.GridWorker.run(GridWorker.java:119)
at java.base@11.0.6/java.lang.Thread.run(Unknown Source)
Thread [name="checkpoint-runner-IO-#131", id=163, state=RUNNABLE, blockCnt=35,
waitCnt=5157152]
at java.base@11.0.6/sun.nio.ch.FileDispatcherImpl.force0(Native Method)
at java.base@11.0.6/sun.nio.ch.FileDispatcherImpl.force(Unknown Source)
at
java.base@11.0.6/sun.nio.ch.SimpleAsynchronousFileChannelImpl.force(Unknown
Source)
at
app//o.a.i.i.processors.cache.persistence.file.AsyncFileIO.force(AsyncFileIO.java:216)
at
app//o.a.i.i.processors.cache.persistence.file.AsyncFileIO.force(AsyncFileIO.java:211)
at
app//o.a.i.i.processors.cache.persistence.file.FilePageStore.sync(FilePageStore.java:715)
at
app//o.a.i.i.processors.cache.persistence.checkpoint.Checkpointer.lambda$syncUpdatedStores$0(Checkpointer.java:608)
at
app//o.a.i.i.processors.cache.persistence.checkpoint.Checkpointer$$Lambda$760/0x7f877929a500.run(Unknown
Source)
at
java.base@11.0.6/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown
Source)
at
java.base@11.0.6/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown
Source)
at java.base@11.0.6/java.lang.Thread.run(Unknown Source)
Thread [name="client-connector-#1849", id=3130, state=WAITING, blockCnt=11,
waitCnt=77047]
at java.base@11.0.6/jdk.internal.misc.Unsafe.park(Native Method)
at java.base@11.0.6/java.util.concurrent.locks.LockSupport.park(Unknown
Source)
at
app//o.a.i.i.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:186)
at
app//o.a.i.i.util.future.GridFutureAdapter.get(GridFutureAdapter.java:149)
at
app//o.a.i.i.processors.cache.binary.BinaryMetadataFileStore$BinaryMetadataAsyncWriter.waitForWriteCompletion(BinaryMetadataFileStore.java:586)
at
app//o.a.i.i.processors.cache.binary.BinaryMetadataFileStore.waitForWriteCompletion(BinaryMetadataFileStore.java:294)
at
app//o.a.i.i.processors.cache.binary.CacheObjectBinaryProcessorImpl.metadata0(CacheObjectBinaryProcessorImpl.java:733)
at
app//o.a.i.i.processors.cache.binary.CacheObjectBinaryProcessorImpl.metadata(CacheObjectBinaryProcessorImpl.java:646)
at
[jira] [Issue Comment Deleted] (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 updated IGNITE-12033:
Comment: was deleted
(was: {panel:title=Branch: [pull/8870/head] Base: [master] : Possible Blockers
(2)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Cache 7{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=5930552]]
* IgniteCacheTestSuite7:
TxRollbackAsyncWithPersistenceTest.testMixedAsyncRollbackTypes - Test has low
fail rate in base branch 0,0% and is not flaky
{color:#d04437}PDS 4{color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=5930564]]
{panel}
{panel:title=Branch: [pull/8870/head] Base: [master] : New Tests
(10)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Cache 1{color} [[tests
4|https://ci.ignite.apache.org/viewLog.html?buildId=5930546]]
* {color:#013220}IgniteBinaryCacheTestSuite:
CacheAsyncContinuationExecutorTest.testRemoteOperationContinuesOnDefaultExecutor
- PASSED{color}
* {color:#013220}IgniteBinaryCacheTestSuite:
CacheAsyncContinuationSynchronousExecutorTest.testLocalOperationExecutesSynchronously
- PASSED{color}
* {color:#013220}IgniteBinaryCacheTestSuite:
CacheAsyncContinuationExecutorTest.testLocalOperationExecutesSynchronously -
PASSED{color}
* {color:#013220}IgniteBinaryCacheTestSuite:
CacheAsyncContinuationSynchronousExecutorTest.testRemoteOperationContinuesOnDefaultExecutor
- PASSED{color}
{color:#8b}Platform .NET (Core Linux){color} [[tests
6|https://ci.ignite.apache.org/viewLog.html?buildId=5930608]]
* {color:#013220}dll: ComputeTestAsyncAwait.TestComputeExecuteAsyncContinuation
- PASSED{color}
* {color:#013220}dll: ComputeTestAsyncAwait.TestComputeRunAsyncContinuation -
PASSED{color}
* {color:#013220}dll:
CacheTestAsyncAwait.TestSynchronousExecutorRunsContinuationsOnStripedPool -
PASSED{color}
* {color:#013220}dll:
CacheTestAsyncAwait.TestInvalidExecutorConfigurationFailsOnStart - PASSED{color}
* {color:#013220}dll:
CacheTestAsyncAwait.TestLocalOperationExecutesSynchronously - PASSED{color}
* {color:#013220}dll:
CacheTestAsyncAwait.TestAsyncAwaitContinuationIsExecutedWithConfiguredExecutor
- PASSED{color}
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5930592buildTypeId=IgniteTests24Java8_RunAll])
> 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
> Labels: iep-70
> Fix For: 2.11
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> 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] [Commented] (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:comment-tabpanel=17307706#comment-17307706
]
Ignite TC Bot commented on IGNITE-12033:
{panel:title=Branch: [pull/8870/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/8870/head] Base: [master] : New Tests
(10)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Cache 1{color} [[tests
4|https://ci.ignite.apache.org/viewLog.html?buildId=5930546]]
* {color:#013220}IgniteBinaryCacheTestSuite:
CacheAsyncContinuationExecutorTest.testRemoteOperationContinuesOnDefaultExecutor
- PASSED{color}
* {color:#013220}IgniteBinaryCacheTestSuite:
CacheAsyncContinuationSynchronousExecutorTest.testLocalOperationExecutesSynchronously
- PASSED{color}
* {color:#013220}IgniteBinaryCacheTestSuite:
CacheAsyncContinuationExecutorTest.testLocalOperationExecutesSynchronously -
PASSED{color}
* {color:#013220}IgniteBinaryCacheTestSuite:
CacheAsyncContinuationSynchronousExecutorTest.testRemoteOperationContinuesOnDefaultExecutor
- PASSED{color}
{color:#8b}Platform .NET (Core Linux){color} [[tests
6|https://ci.ignite.apache.org/viewLog.html?buildId=5930608]]
* {color:#013220}dll: ComputeTestAsyncAwait.TestComputeExecuteAsyncContinuation
- PASSED{color}
* {color:#013220}dll: ComputeTestAsyncAwait.TestComputeRunAsyncContinuation -
PASSED{color}
* {color:#013220}dll:
CacheTestAsyncAwait.TestSynchronousExecutorRunsContinuationsOnStripedPool -
PASSED{color}
* {color:#013220}dll:
CacheTestAsyncAwait.TestInvalidExecutorConfigurationFailsOnStart - PASSED{color}
* {color:#013220}dll:
CacheTestAsyncAwait.TestLocalOperationExecutesSynchronously - PASSED{color}
* {color:#013220}dll:
CacheTestAsyncAwait.TestAsyncAwaitContinuationIsExecutedWithConfiguredExecutor
- PASSED{color}
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5930592buildTypeId=IgniteTests24Java8_RunAll]
> 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
> Labels: iep-70
> Fix For: 2.11
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> 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] [Commented] (IGNITE-14372) Fix REST json configuration update requests
[ https://issues.apache.org/jira/browse/IGNITE-14372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17307663#comment-17307663 ] Sergey Chugunov commented on IGNITE-14372: -- [~ibessonov], Patch looks good to me, checks have passed on the PR. I think it is ready for merge to main branch. > Fix REST json configuration update requests > --- > > Key: IGNITE-14372 > URL: https://issues.apache.org/jira/browse/IGNITE-14372 > Project: Ignite > Issue Type: Sub-task >Reporter: Ivan Bessonov >Priority: Major > Time Spent: 4.5h > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14385) Add start/end time of checkpoint, rebalance, PME to performance statistics.
Sergei Ryzhov created IGNITE-14385: -- Summary: Add start/end time of checkpoint, rebalance, PME to performance statistics. Key: IGNITE-14385 URL: https://issues.apache.org/jira/browse/IGNITE-14385 Project: Ignite Issue Type: Sub-task Reporter: Sergei Ryzhov Assignee: Sergei Ryzhov Add start/end time of checkpoint, rebalance, PME to performance statistics. Add these labels to the performance statistics graphs. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14345) There is a spelling error in the debug information
[ https://issues.apache.org/jira/browse/IGNITE-14345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] xin.ch...@intotech.com.cn updated IGNITE-14345: --- Priority: Trivial (was: Minor) > There is a spelling error in the debug information > -- > > Key: IGNITE-14345 > URL: https://issues.apache.org/jira/browse/IGNITE-14345 > Project: Ignite > Issue Type: Improvement >Reporter: xin.ch...@intotech.com.cn >Priority: Trivial > Attachments: Snipaste_2021-03-19_10-13-23.png > > > > This code is in the > org.apache.ignite.spi.discovery.tcp.ServerImpl.spiStart(String).I think it > should be TCP, not TPC. > !Snipaste_2021-03-19_10-13-23.png|width=677,height=203! -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14377) Enchance log of node ping failure.
[ https://issues.apache.org/jira/browse/IGNITE-14377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Vinogradov updated IGNITE-14377: -- Fix Version/s: 2.11 > Enchance log of node ping failure. > -- > > Key: IGNITE-14377 > URL: https://issues.apache.org/jira/browse/IGNITE-14377 > Project: Ignite > Issue Type: Sub-task >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Minor > Fix For: 2.11 > > Time Spent: 20m > Remaining Estimate: 0h > > Log of unsuccessful ping during the joining is insufficient. No failure > reason is logged. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14377) Enchance log of node ping failure.
[ https://issues.apache.org/jira/browse/IGNITE-14377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17307638#comment-17307638 ] Anton Vinogradov commented on IGNITE-14377: --- Merged into master. Thanks for your contribution. > Enchance log of node ping failure. > -- > > Key: IGNITE-14377 > URL: https://issues.apache.org/jira/browse/IGNITE-14377 > Project: Ignite > Issue Type: Sub-task >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Minor > Time Spent: 20m > Remaining Estimate: 0h > > Log of unsuccessful ping during the joining is insufficient. No failure > reason is logged. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14378) Remove delay from node ping.
[ https://issues.apache.org/jira/browse/IGNITE-14378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Vinogradov updated IGNITE-14378: -- Fix Version/s: 2.11 > Remove delay from node ping. > > > Key: IGNITE-14378 > URL: https://issues.apache.org/jira/browse/IGNITE-14378 > Project: Ignite > Issue Type: Bug >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Minor > Fix For: 2.11 > > Time Spent: 20m > Remaining Estimate: 0h > > Remove U.sleep(200) from the node ping. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14384) Remove diagnostics at the stop of the node in case of CorruptedTreeException
Kirill Tkalenko created IGNITE-14384: Summary: Remove diagnostics at the stop of the node in case of CorruptedTreeException Key: IGNITE-14384 URL: https://issues.apache.org/jira/browse/IGNITE-14384 Project: Ignite Issue Type: Improvement Components: persistence Reporter: Kirill Tkalenko Assignee: Kirill Tkalenko Fix For: 2.11 When an error *CorruptedTreeException*, diagnostics are launched, which may take a long time and do not allow the node to be stopped until it completes. Instead of waiting for a long time to complete the diagnostics, a command will be output that will allow to do it offline. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14383) No need to update metastorage if cache statistics disabled.
Stanilovsky Evgeny created IGNITE-14383: --- Summary: No need to update metastorage if cache statistics disabled. Key: IGNITE-14383 URL: https://issues.apache.org/jira/browse/IGNITE-14383 Project: Ignite Issue Type: Improvement Components: cache Affects Versions: 2.10 Reporter: Stanilovsky Evgeny Assignee: Stanilovsky Evgeny Id cache statistics disabled there is no need to update metastorage and send numerous DistributedMetaStorageUpdateMessage as a result. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14382) Network module API structuring
Sergey Chugunov created IGNITE-14382: Summary: Network module API structuring Key: IGNITE-14382 URL: https://issues.apache.org/jira/browse/IGNITE-14382 Project: Ignite Issue Type: Sub-task Components: networking Reporter: Sergey Chugunov Fix For: 3.0.0-alpha2 First version of the network module introduced a NetworkCluster interface providing access to all functionality of the module: sending and receiving messages in p2p fashion, topology API (current set of online nodes, node join and left events) and some lifecycle-related methods. Further development has shown that it makes sense to gather these pieces of functionality under separate interfaces that should be accessible from NetworkCluster or similar single entry point. Suggestions for naming of these interfaces: *Topology* and *Messaging*. Keeping lifecycle callbacks and methods under the same interface seems natural at the moment. -- This message was sent by Atlassian Jira (v8.3.4#803005)
