[
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)
