[
https://issues.apache.org/jira/browse/IGNITE-4157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15741923#comment-15741923
]
Sergey Chugunov edited comment on IGNITE-4157 at 12/12/16 1:48 PM:
-------------------------------------------------------------------
h4. Design notes for final version
# Each node holds a local cache of typeId->mappedName mappings. *MappedName*
contains typeName and a status of mappedName (*proposed* or *accepted*).
# Node is allowed to use proposed mappedName only to unmarshal incoming
requests. In order to use it for marshalling it should wait until mappedName
gets transferred to accepted status.
# Requesting new mapping is two-phase process and requires two messages to pass
across the cluster: *MappingProposedMessage* and *MappingAcceptedMessage* as a
successful acknowledge message for the first one.
# Requesting new mapping is synchronous process: when node requests new
mapping, requesting thread is blocked until mapping is accepted or rejected.
# If two nodes simultaneously propose mappings for classes with conflicting
names, only the mapping will be accepted which *MappingProposedMessage* reaches
coordinator node first. Other mapping proposed request will be rejected,
*MappingRejectedMessage* will be sent to requesting node as a failure
acknowledge.
# If two nodes simultaneously propose mapping for exactly the same class, this
situation will be treated by coordinator node as a duplicate request, no
acknowledge message will be sent. Node that sent duplicate request will be
unblocked from waiting on mapping accepted when accept for the first request
passes across the ring.
# Functionality of persisting accepted mappings in filesystem is preserved,
file name format slightly changed as support for mappings on different
platforms was added. Pattern looks like this now:
*<typeId>.classname<platformId>*, e.g. *1033.classname0*
was (Author: sergey-chugunov):
h4. Design notes for final version
# Each node holds a local cache of typeId->mappedName mappings. MappedName
contains typeName and a status of mappedName (*proposed* or *accepted*).
# Node is allowed to use proposed mappedName only to unmarshal incoming
requests. In order to use it for marshalling it should wait until mappedName
gets transferred to accepted status.
# Requesting new mapping is two-phase process and requires two messages to pass
across the cluster: *MappingProposedMessage* and *MappingAcceptedMessage* as a
successful acknowledge message for the first one.
# Requesting new mapping is synchronous process: when node requests new
mapping, requesting thread is blocked until mapping is accepted or rejected.
# If two nodes simultaneously propose mappings for classes with conflicting
names, only the mapping will be accepted which MappingProposedMessage reaches
coordinator node first. Other mapping proposed request will be rejected,
*MappingRejectedMessage* will be sent to requesting node as a failure
acknowledge.
# If two nodes simultaneously propose mapping for exactly the same class, this
situation will be treated by coordinator node as a duplicate request, no
acknowledge message will be sent. Node that sent duplicate request will be
unblocked from waiting on mapping accepted when accept for the first request
passes across the ring.
# Functionality of persisting accepted mappings in filesystem is preserved,
file name format slightly changed as support for mappings on different
platforms was added. Pattern looks like this now:
*<typeId>.classname<platformId>*, e.g. *1033.classname0*
> Use discovery custom messages instead of marshaller 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)
