ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Semyon Boikov <sboi...@gridgain.com>
Subject Re: IGNITE-4157 design proposal
Date Fri, 04 Nov 2016 06:33:24 GMT
Hi Sergey,

I have few comments:

- when new node joins cluster all existing nodes provide current data from
'collectDiscoveryData' callback and then this data is sent in
TcpDiscoveryNodeAddedMessage as 'nodeId -> nodeData' map. In case of
'typeId->typeName' mapping it is supposed that when 'collectDiscoveryData'
is called all nodes will have the same mapping, and we should avoid send
duplicated data in TcpDiscoveryNodeAddedMessage (otherwise it can grow too
large in case there are many nodes in topology). Probably for this we will
need to change DiscoverySpiDataExchange interface (actually now we have the
same issue with duplicated caches configurations sent in
TcpDiscoveryNodeAddedMessage, but this can be fixed separately).

- when new mapping is added there can be typeId collision error, make sure
new implementation will also handle such errors

- please take into account that after all server nodes processed custom
discovery event there is no guarantee that all client nodes also processed
this event (discovery events are sent to clients asynchronously)

Thanks,
Semyon

On Thu, Nov 3, 2016 at 5:43 PM, Sergey Chugunov <sergey.chugunov@gmail.com>
wrote:

> Hello everyone,
>
> I've started working on marshaller-related part of IGNITE-4157
> <https://issues.apache.org/jira/browse/IGNITE-4157> and think that
> solution
> may look like this:
>
> *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.
>
> *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
> <https://issues.apache.org/jira/browse/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.
>
> If you have any suggestions or concerns about proposed solution please
> reply to this email or comment under corresponding JIRA (IGNITE-4157
> <https://issues.apache.org/jira/browse/IGNITE-4157>).
>
> Thanks,
> Sergey.
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message