ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Denis Magda <dma...@gridgain.com>
Subject Re: Marshalling data between Java and other platforms.
Date Sat, 16 May 2015 16:05:50 GMT

I do like and support the idea of introducing a dedicated “InteropMarshaller”.
The high level reasons are the same - InteropMarshaller can evolve independently and current
fully oriented Java marshallers will not became a kind of unmaintainable universal mess.

Plus, since both InteropMarshaller and Ignite(Optimized)Marshaller can(?) operate simultaneously
on a cluster this solution looks good.


> On 15 мая 2015 г., at 23:46, Vladimir Ozerov <vozerov@gridgain.com> wrote:
> Igniters,
> As we are going towards interoperability with other platforms, we need to
> decide how to pass data between Java and native platform.
> Interop layer must be able to handle the following things:
> 1) Process primitives;
> 2) Process some "java.lang" classes (arrays, String, Date, collections,
> maps).
> 3) Process limited subset of Ignite classes (e.g. metrics, events, node,
> etc.).
> 4) Read native platform objects in form of byte array or so (to save them
> in cache, pass over wire to other nodes, and so on).
> 5) Be able to read particular field of native object to support queries.
> I think we must introduce new interface "InteropMarshaller" which will
> support all these features and will be pluggable to interop configuration.
> Another option is try to adopt current IgniteMarshaller to serve interop
> purposes as well. This will allow us to easily reuse some existing
> marshalling codebase. But I do not think this is the right way to go for
> the following reasons:
> 1) IgniteMarshaller serves different purposes - it marshals/unmarshals the
> whole range of Java classes and have support for all regular serialization
> features (like Externalizable). Interop marshaller do not need them.
> 2) Default implementation - OptimizedMarhaller - heavily relies on
> java-specific featues (e.g. fully-qualified class names) and Ignite
> internals (e.g. marshaller cache which is not available direclty in native
> platform). Some platforms might have very specific marshalling rules which
> will OptimizedMarshaller will not be able to handle (e.g. dynamic object
> without a class associated with it, CPP struct without RTTI available,
> etc.).
> 3) As these two marshallers servers different purposes, they must evolve
> independently, so that change in regular marshalling do not break interop
> marshalling and vice versa.
> On the other hand, we can share IgniteMarshalelr some code base with help
> of refactoring.
> Thoughts?
> Vladimir.

View raw message