ignite-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sergey Chugunov (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (IGNITE-4157) Use discovery custom messages instead of marshaller cache
Date Mon, 12 Dec 2016 13:44:00 GMT

    [ https://issues.apache.org/jira/browse/IGNITE-4157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15741923#comment-15741923

Sergey Chugunov commented on IGNITE-4157:

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

View raw message