ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Valentin Kulichenko <valentin.kuliche...@gmail.com>
Subject Re: Binary object inside Externalizable
Date Wed, 24 Feb 2016 04:50:14 GMT
Actually, adding Externalizable support to binary marshaller should not be
difficult, no? BinaryWriterExImpl already implements ObjectOutput, so we
just need to pass to writeExternal (and the same for deserialization). To
be honest, I don't understand why we use optimized marshaller here and
making this change should fix majority of use cases.

The issue will remain for writeObject/readObject which is much more
complicated and where using optimized marshaller makes more sense. But this
is a relatively rare case and I think we can fix this as a next step.

Thoughts?

On Sat, Feb 20, 2016 at 10:01 AM, Dmitriy Setrakyan <dsetrakyan@apache.org>
wrote:

> Andrey, you are absolutely right. I was suggesting a quick fix, which in my
> view, would fix most of the issues. In the long term, we should fix the
> binary serialization to work the way you are describing.
>
> D.
>
> On Sat, Feb 20, 2016 at 9:26 AM, Andrey Kornev <andrewkornev@hotmail.com>
> wrote:
>
> > Val,
> >
> > I think Ignite Serialization should follow the approach similar to what
> > Java serialization does: it can transparently and consistently handle
> both
> > Serializable and Externalizable classes. It can do it because it relies
> on
> > a single class - ObjectOutputStream - to do serialization (and a single
> > class - ObjectInputStream - to do the opposite, but let's ignore it for
> the
> > moment). ObjectOutputStream delegates to proper user callbacks
> (writeObject
> > or writeExternal) at the right moments, but otherwise it fully controls
> the
> > on-the-wire representation and takes care of all the necessary stream
> > framing/marking so that ObjectInputStream can then correctly deserialize
> > the bytes. It's never a problem for Java to serialize an Externalizable
> > field from a Serializable object and vice versa. Users can mix and match
> > serialization APIs as they please.
> >
> > I think Ignite should just have a single marshaller, let's say the
> Binary,
> > which drives the whole serialization process. It doesn't delegate to
> > OptimizedMarshaller as it does today. Instead it detects the
> > Serializable/Externalizable classes and calls their serialization
> callbacks
> > - writeObject/writeExternal - passing in *itself* as
> > ObjectOutputStream/ObjectOutput correspondingly. This way the entire
> > serialization process never leaves the context of a single Binary
> > marshaller and allows Ignite to handle such complex cases as the one
> we're
> > discussing now.
> >
> > I hope it makes sense.
> >
> > Andrey
> >
> > > From: valentin.kulichenko@gmail.com
> > > Date: Fri, 19 Feb 2016 19:15:07 -0800
> > > Subject: Binary object inside Externalizable
> > > To: dev@ignite.apache.org
> > >
> > > Folks,
> > >
> > > I recently faced an issue which seems to be pretty critical. As you
> know,
> > > when binary marshaller meets an Externalizable object, it switches to
> > > optimized marshaller. And if there is a regular object inside, it's
> still
> > > serialized with optimized, even if its type is declared in binary
> > > configuration with custom mapper, etc. This looks wrong.
> > >
> > > It's getting even worse in compute grid, because closure processor
> wraps
> > > user's closures in some internal classes, which are Externalizable, so
> > > these closures are always serialized with optimized marshaller.
> > >
> > > Does anyone have ideas on what is the proper fix for this?
> > >
> > > -Val
> >
> >
>

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