[jira] [Commented] (IGNITE-4157) Use discovery custom messages instead of marshaller and system cache
[
https://issues.apache.org/jira/browse/IGNITE-4157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15629035#comment-15629035
]
Pavel Tupitsyn commented on IGNITE-4157:
Let's make sure to make this eaasily extensible. Platforms (.NET for now) also
need to maintain typeId -> typeName mapping, but this should be separate from
Java mapping.
Ideally, interface should be something like
{code}
String getTypeName(int platform, int typeId);
void putTypeName(int platform, int typeId, String typeName);
{code}
> Use discovery custom messages instead of marshaller and system cache
>
>
> Key: IGNITE-4157
> URL: https://issues.apache.org/jira/browse/IGNITE-4157
> Project: Ignite
> Issue Type: Improvement
> Components: cache
>Reporter: Alexey Goncharuk
>Assignee: Sergey Chugunov
> Fix For: 2.0
>
>
> Currently we use system caches for keeping classname to class ID mapping and
> for storing binary metadata
> This has several serious disadvantages:
> 1) We need to introduce at least two additional thread pools for each of
> these caches
> 2) Since cache operations require stable topology, registering a class ID or
> updating metadata inside a transaction or another cache operation is tricky
> and deadlock-prone.
> 3) It may be beneficial in some cases to have nodes with no caches at all,
> currently this is impossible because system caches are always present.
> 4) Reading binary metadata leads to huge local contention, caching metadata
> values in a local map doubles memory consumption
> I suggest we use discovery custom events for these purposes. Each node will
> have a corresponding local map (state) which will be updated inside custom
> event handler. From the first point of view, this should remove all the
> disadvantages above.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-4157) Use discovery custom messages instead of marshaller and system cache
[ https://issues.apache.org/jira/browse/IGNITE-4157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15633793#comment-15633793 ] Sergey Chugunov commented on IGNITE-4157: - h5. Design proposal for mapping refactoring h6. Storing mapping locally instead of using cache Instead using marshaller cache for typeId->typeName mapping each node has it's own local copy of mapping in, for instance, ConcurrentHashMap. Each time when a node wants to use new class and therefore to create new mapping it notifies other nodes using DiscoveryCustomMessage; every other node updates its local mapping upon receiving this notification. As DCMs are guaranteed to be delivered to all nodes in the cluster it is possible to keep these local mappings in sync across the cluster. When a node joins the cluster it can obtain current state of mapping using existing collectDiscoveryData/onDiscoveryDataReceived methods in GridCacheProcessor class. h6. Extended mapping API Right now marshaller mapping API is very simple and allows only to register or get a single class name under/by a single typeId. This restriction has implications on .NET platform and described in IGNITE-2703. To get rid of this restriction I'm going to add additional byte parameter to registerClass and getClass methods indicating for which platform class is registered or requested. This should allow platforms other than Java to use typeId<->typeName mapping. > Use discovery custom messages instead of marshaller and system cache > > > Key: IGNITE-4157 > URL: https://issues.apache.org/jira/browse/IGNITE-4157 > Project: Ignite > Issue Type: Improvement > Components: cache >Reporter: Alexey Goncharuk >Assignee: Sergey Chugunov > Fix For: 2.0 > > > Currently we use system caches for keeping classname to class ID mapping and > for storing binary metadata > This has several serious disadvantages: > 1) We need to introduce at least two additional thread pools for each of > these caches > 2) Since cache operations require stable topology, registering a class ID or > updating metadata inside a transaction or another cache operation is tricky > and deadlock-prone. > 3) It may be beneficial in some cases to have nodes with no caches at all, > currently this is impossible because system caches are always present. > 4) Reading binary metadata leads to huge local contention, caching metadata > values in a local map doubles memory consumption > I suggest we use discovery custom events for these purposes. Each node will > have a corresponding local map (state) which will be updated inside custom > event handler. From the first point of view, this should remove all the > disadvantages above. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-4157) Use discovery custom messages instead of marshaller and system cache
[ https://issues.apache.org/jira/browse/IGNITE-4157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15645158#comment-15645158 ] Sergey Chugunov commented on IGNITE-4157: - Implemented basic happy-path flow for exchanging type mapping information between already running nodes. Next steps: 1) address case with new node joining Ignite cluster; 2) address collisions with two classes mapped to the same typeId; 3) refactor backing up mapping to filesystem and restoring from it on node startup. > Use discovery custom messages instead of marshaller and system cache > > > Key: IGNITE-4157 > URL: https://issues.apache.org/jira/browse/IGNITE-4157 > Project: Ignite > Issue Type: Improvement > Components: cache >Reporter: Alexey Goncharuk >Assignee: Sergey Chugunov > Fix For: 2.0 > > > Currently we use system caches for keeping classname to class ID mapping and > for storing binary metadata > This has several serious disadvantages: > 1) We need to introduce at least two additional thread pools for each of > these caches > 2) Since cache operations require stable topology, registering a class ID or > updating metadata inside a transaction or another cache operation is tricky > and deadlock-prone. > 3) It may be beneficial in some cases to have nodes with no caches at all, > currently this is impossible because system caches are always present. > 4) Reading binary metadata leads to huge local contention, caching metadata > values in a local map doubles memory consumption > I suggest we use discovery custom events for these purposes. Each node will > have a corresponding local map (state) which will be updated inside custom > event handler. From the first point of view, this should remove all the > disadvantages above. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-4157) Use discovery custom messages instead of marshaller and system cache
[ https://issues.apache.org/jira/browse/IGNITE-4157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15648074#comment-15648074 ] Sergey Chugunov commented on IGNITE-4157: - Redeveloped first implementation so collisions (second point in previous comment) are prevented. > Use discovery custom messages instead of marshaller and system cache > > > Key: IGNITE-4157 > URL: https://issues.apache.org/jira/browse/IGNITE-4157 > Project: Ignite > Issue Type: Improvement > Components: cache >Reporter: Alexey Goncharuk >Assignee: Sergey Chugunov > Fix For: 2.0 > > > Currently we use system caches for keeping classname to class ID mapping and > for storing binary metadata > This has several serious disadvantages: > 1) We need to introduce at least two additional thread pools for each of > these caches > 2) Since cache operations require stable topology, registering a class ID or > updating metadata inside a transaction or another cache operation is tricky > and deadlock-prone. > 3) It may be beneficial in some cases to have nodes with no caches at all, > currently this is impossible because system caches are always present. > 4) Reading binary metadata leads to huge local contention, caching metadata > values in a local map doubles memory consumption > I suggest we use discovery custom events for these purposes. Each node will > have a corresponding local map (state) which will be updated inside custom > event handler. From the first point of view, this should remove all the > disadvantages above. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-4157) Use discovery custom messages instead of marshaller and system cache
[ https://issues.apache.org/jira/browse/IGNITE-4157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15651287#comment-15651287 ] Sergey Chugunov commented on IGNITE-4157: - Implemented first version of supplying a newly joined node with mapping information existing on other nodes in Ignite cluster. > Use discovery custom messages instead of marshaller and system cache > > > Key: IGNITE-4157 > URL: https://issues.apache.org/jira/browse/IGNITE-4157 > Project: Ignite > Issue Type: Improvement > Components: cache >Reporter: Alexey Goncharuk >Assignee: Sergey Chugunov > Fix For: 2.0 > > > Currently we use system caches for keeping classname to class ID mapping and > for storing binary metadata > This has several serious disadvantages: > 1) We need to introduce at least two additional thread pools for each of > these caches > 2) Since cache operations require stable topology, registering a class ID or > updating metadata inside a transaction or another cache operation is tricky > and deadlock-prone. > 3) It may be beneficial in some cases to have nodes with no caches at all, > currently this is impossible because system caches are always present. > 4) Reading binary metadata leads to huge local contention, caching metadata > values in a local map doubles memory consumption > I suggest we use discovery custom events for these purposes. Each node will > have a corresponding local map (state) which will be updated inside custom > event handler. From the first point of view, this should remove all the > disadvantages above. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-4157) Use discovery custom messages instead of marshaller and system cache
[ https://issues.apache.org/jira/browse/IGNITE-4157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15654980#comment-15654980 ] Sergey Chugunov commented on IGNITE-4157: - Mapping information exchange on joining new node needs to be massively optimized as current implementation consumes a lot of traffic with duplicated mappings in the same message. I'm going to propose a redesign of several interfaces and post it here for documentation purposes. > Use discovery custom messages instead of marshaller and system cache > > > Key: IGNITE-4157 > URL: https://issues.apache.org/jira/browse/IGNITE-4157 > Project: Ignite > Issue Type: Improvement > Components: cache >Reporter: Alexey Goncharuk >Assignee: Sergey Chugunov > Fix For: 2.0 > > > Currently we use system caches for keeping classname to class ID mapping and > for storing binary metadata > This has several serious disadvantages: > 1) We need to introduce at least two additional thread pools for each of > these caches > 2) Since cache operations require stable topology, registering a class ID or > updating metadata inside a transaction or another cache operation is tricky > and deadlock-prone. > 3) It may be beneficial in some cases to have nodes with no caches at all, > currently this is impossible because system caches are always present. > 4) Reading binary metadata leads to huge local contention, caching metadata > values in a local map doubles memory consumption > I suggest we use discovery custom events for these purposes. Each node will > have a corresponding local map (state) which will be updated inside custom > event handler. From the first point of view, this should remove all the > disadvantages above. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-4157) Use discovery custom messages instead of marshaller and system cache
[ https://issues.apache.org/jira/browse/IGNITE-4157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15659144#comment-15659144 ] Sergey Chugunov commented on IGNITE-4157: - Did first integration with .NET platform, started optimizing traffic on NodeAdded event. > Use discovery custom messages instead of marshaller and system cache > > > Key: IGNITE-4157 > URL: https://issues.apache.org/jira/browse/IGNITE-4157 > Project: Ignite > Issue Type: Improvement > Components: cache >Reporter: Alexey Goncharuk >Assignee: Sergey Chugunov > Fix For: 2.0 > > > Currently we use system caches for keeping classname to class ID mapping and > for storing binary metadata > This has several serious disadvantages: > 1) We need to introduce at least two additional thread pools for each of > these caches > 2) Since cache operations require stable topology, registering a class ID or > updating metadata inside a transaction or another cache operation is tricky > and deadlock-prone. > 3) It may be beneficial in some cases to have nodes with no caches at all, > currently this is impossible because system caches are always present. > 4) Reading binary metadata leads to huge local contention, caching metadata > values in a local map doubles memory consumption > I suggest we use discovery custom events for these purposes. Each node will > have a corresponding local map (state) which will be updated inside custom > event handler. From the first point of view, this should remove all the > disadvantages above. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-4157) Use discovery custom messages instead of marshaller and system cache
[ https://issues.apache.org/jira/browse/IGNITE-4157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15664259#comment-15664259 ] Sergey Chugunov commented on IGNITE-4157: - implemented traffic-optimized solution of NodeAdded message for MarshallerMapping component. > Use discovery custom messages instead of marshaller and system cache > > > Key: IGNITE-4157 > URL: https://issues.apache.org/jira/browse/IGNITE-4157 > Project: Ignite > Issue Type: Improvement > Components: cache >Reporter: Alexey Goncharuk >Assignee: Sergey Chugunov > Fix For: 2.0 > > > Currently we use system caches for keeping classname to class ID mapping and > for storing binary metadata > This has several serious disadvantages: > 1) We need to introduce at least two additional thread pools for each of > these caches > 2) Since cache operations require stable topology, registering a class ID or > updating metadata inside a transaction or another cache operation is tricky > and deadlock-prone. > 3) It may be beneficial in some cases to have nodes with no caches at all, > currently this is impossible because system caches are always present. > 4) Reading binary metadata leads to huge local contention, caching metadata > values in a local map doubles memory consumption > I suggest we use discovery custom events for these purposes. Each node will > have a corresponding local map (state) which will be updated inside custom > event handler. From the first point of view, this should remove all the > disadvantages above. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-4157) Use discovery custom messages instead of marshaller and system cache
[ https://issues.apache.org/jira/browse/IGNITE-4157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15668013#comment-15668013 ] Sergey Chugunov commented on IGNITE-4157: - Refactored IgnitePluginProcessor and ClusterProcessor to use new discovery sharing solution. > Use discovery custom messages instead of marshaller and system cache > > > Key: IGNITE-4157 > URL: https://issues.apache.org/jira/browse/IGNITE-4157 > Project: Ignite > Issue Type: Improvement > Components: cache >Reporter: Alexey Goncharuk >Assignee: Sergey Chugunov > Fix For: 2.0 > > > Currently we use system caches for keeping classname to class ID mapping and > for storing binary metadata > This has several serious disadvantages: > 1) We need to introduce at least two additional thread pools for each of > these caches > 2) Since cache operations require stable topology, registering a class ID or > updating metadata inside a transaction or another cache operation is tricky > and deadlock-prone. > 3) It may be beneficial in some cases to have nodes with no caches at all, > currently this is impossible because system caches are always present. > 4) Reading binary metadata leads to huge local contention, caching metadata > values in a local map doubles memory consumption > I suggest we use discovery custom events for these purposes. Each node will > have a corresponding local map (state) which will be updated inside custom > event handler. From the first point of view, this should remove all the > disadvantages above. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-4157) Use discovery custom messages instead of marshaller and system cache
[ https://issues.apache.org/jira/browse/IGNITE-4157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15672872#comment-15672872 ] Sergey Chugunov commented on IGNITE-4157: - Refactored all existing components to use new discovery data sharing solution. > Use discovery custom messages instead of marshaller and system cache > > > Key: IGNITE-4157 > URL: https://issues.apache.org/jira/browse/IGNITE-4157 > Project: Ignite > Issue Type: Improvement > Components: cache >Reporter: Alexey Goncharuk >Assignee: Sergey Chugunov > Fix For: 2.0 > > > Currently we use system caches for keeping classname to class ID mapping and > for storing binary metadata > This has several serious disadvantages: > 1) We need to introduce at least two additional thread pools for each of > these caches > 2) Since cache operations require stable topology, registering a class ID or > updating metadata inside a transaction or another cache operation is tricky > and deadlock-prone. > 3) It may be beneficial in some cases to have nodes with no caches at all, > currently this is impossible because system caches are always present. > 4) Reading binary metadata leads to huge local contention, caching metadata > values in a local map doubles memory consumption > I suggest we use discovery custom events for these purposes. Each node will > have a corresponding local map (state) which will be updated inside custom > event handler. From the first point of view, this should remove all the > disadvantages above. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-4157) Use discovery custom messages instead of marshaller and system cache
[ https://issues.apache.org/jira/browse/IGNITE-4157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15684070#comment-15684070 ] Sergey Chugunov commented on IGNITE-4157: - Implemented file-based storage for type mappings, fixed two tests. > Use discovery custom messages instead of marshaller and system cache > > > Key: IGNITE-4157 > URL: https://issues.apache.org/jira/browse/IGNITE-4157 > Project: Ignite > Issue Type: Improvement > Components: cache >Reporter: Alexey Goncharuk >Assignee: Sergey Chugunov > Fix For: 2.0 > > > Currently we use system caches for keeping classname to class ID mapping and > for storing binary metadata > This has several serious disadvantages: > 1) We need to introduce at least two additional thread pools for each of > these caches > 2) Since cache operations require stable topology, registering a class ID or > updating metadata inside a transaction or another cache operation is tricky > and deadlock-prone. > 3) It may be beneficial in some cases to have nodes with no caches at all, > currently this is impossible because system caches are always present. > 4) Reading binary metadata leads to huge local contention, caching metadata > values in a local map doubles memory consumption > I suggest we use discovery custom events for these purposes. Each node will > have a corresponding local map (state) which will be updated inside custom > event handler. From the first point of view, this should remove all the > disadvantages above. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-4157) Use discovery custom messages instead of marshaller and system cache
[ https://issues.apache.org/jira/browse/IGNITE-4157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15687126#comment-15687126 ] Sergey Chugunov commented on IGNITE-4157: - Implemented requesting of mapping by client when it doesn't have a mapping in local cache it needs to unmarshal some data. This may happen because discovery events are sent to clients asynchronously so it is possible that servers already accepted new mapping but clients aren't aware of it. > Use discovery custom messages instead of marshaller and system cache > > > Key: IGNITE-4157 > URL: https://issues.apache.org/jira/browse/IGNITE-4157 > Project: Ignite > Issue Type: Improvement > Components: cache >Reporter: Alexey Goncharuk >Assignee: Sergey Chugunov > Fix For: 2.0 > > > Currently we use system caches for keeping classname to class ID mapping and > for storing binary metadata > This has several serious disadvantages: > 1) We need to introduce at least two additional thread pools for each of > these caches > 2) Since cache operations require stable topology, registering a class ID or > updating metadata inside a transaction or another cache operation is tricky > and deadlock-prone. > 3) It may be beneficial in some cases to have nodes with no caches at all, > currently this is impossible because system caches are always present. > 4) Reading binary metadata leads to huge local contention, caching metadata > values in a local map doubles memory consumption > I suggest we use discovery custom events for these purposes. Each node will > have a corresponding local map (state) which will be updated inside custom > event handler. From the first point of view, this should remove all the > disadvantages above. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-4157) Use discovery custom messages instead of marshaller and system cache
[ https://issues.apache.org/jira/browse/IGNITE-4157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15690522#comment-15690522 ] ASF GitHub Bot commented on IGNITE-4157: GitHub user sergey-chugunov-1985 opened a pull request: https://github.com/apache/ignite/pull/1271 IGNITE-4157 Use discovery custom events instead of marshaller and system cache First version of feature's implementation. You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-4157 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/1271.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #1271 commit 4a094b424d02fc18ecedf9c895c72fe1594f919d Author: Sergey Chugunov Date: 2016-11-09T12:02:41Z IGNITE-4147 MarshallerContext API change and draft implementation are added commit 7b1d321bca8a3513603667dd1f05d8760d23d67c Author: Sergey Chugunov Date: 2016-11-23T15:18:30Z IGNITE-4157 file-based persistence and requesting missing mapping are added > Use discovery custom messages instead of marshaller and system cache > > > Key: IGNITE-4157 > URL: https://issues.apache.org/jira/browse/IGNITE-4157 > Project: Ignite > Issue Type: Improvement > Components: cache >Reporter: Alexey Goncharuk >Assignee: Sergey Chugunov > Fix For: 2.0 > > > Currently we use system caches for keeping classname to class ID mapping and > for storing binary metadata > This has several serious disadvantages: > 1) We need to introduce at least two additional thread pools for each of > these caches > 2) Since cache operations require stable topology, registering a class ID or > updating metadata inside a transaction or another cache operation is tricky > and deadlock-prone. > 3) It may be beneficial in some cases to have nodes with no caches at all, > currently this is impossible because system caches are always present. > 4) Reading binary metadata leads to huge local contention, caching metadata > values in a local map doubles memory consumption > I suggest we use discovery custom events for these purposes. Each node will > have a corresponding local map (state) which will be updated inside custom > event handler. From the first point of view, this should remove all the > disadvantages above. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
