IGNITE-4157 design proposal

[Sergey Chugunov]

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.

[Semyon Boikov]

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 <[hidden email]>
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.
>