ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dmitriy Setrakyan <dsetrak...@apache.org>
Subject Re: Custom Java serialization and BinaryMarshaller
Date Tue, 15 Dec 2015 06:17:56 GMT
Vova,

I think I am beginning to see your point. However, my concern is that users
may wish to ignore Externalizable and use the Binary protocol. Is it
possible to have a configuration flag on per-cache basis?

Also, why delegate to OptimizedMarshaller for Externalizalbe classes? Can’t
we have this logic for the Binary marshaller?

D.

On Mon, Dec 14, 2015 at 9:58 PM, Vladimir Ozerov <vozerov@gridgain.com>
wrote:

> Dima,
>
> I do not think it is possible to get list of such classes because this can
> be any class from any library. Can you explain what is your concerns?
>
> On Tue, Dec 15, 2015 at 1:46 AM, Dmitriy Setrakyan <dsetrakyan@apache.org>
> wrote:
>
> > Vladimir,
> >
> > I am not sure I like the approach you are suggesting. I am thinking that
> by
> > “unstable” classes you are referring to classes like HashMap or
> ArrayList,
> > in which case, providing field metadata for them does not make sense, as
> > well as deserializing them on the server side does not make sense.
> >
> > Let’s dig a bit deeper. Can you provide a list of the “unstable” classes?
> >
> > D.
> >
> > On Mon, Dec 14, 2015 at 1:30 PM, Vladimir Ozerov <vozerov@gridgain.com>
> > wrote:
> >
> > > Folks,
> > >
> > > Currently BinaryMarshaller works in a very non-trivial way:
> > > 1) If class is Serializable or Binarylizable, it is written in binary
> > > format and can be used without deserialization.
> > > 2) If class implements Externalizable, it is written in binary format,
> > but
> > > without fields metadata.
> > > 3) If class has writeObject/readObject methods, it is written with
> > > OptimizedMarshaller, also without fields metadata.
> > >
> > > Class from p.2 and p.3 must always be deserialized on server side to
> > allow
> > > queries.
> > >
> > > There was an idea to ignore Externalizable/writeObject/readObject and
> > > always write object fields directly with binary format and metadata.
> And
> > > let user fallback to default Java logic if needed.
> > > I tried this approach today and it appears to be very unstable. Lots of
> > > classes from JDK and other libraries has custom serialization logic. As
> > we
> > > ignore it, it produces weird exceptions (such as NPE) which we cannot
> > > handle and cannot give user any advice on what is going on.
> > >
> > > I think we should resolve this problem as follows:
> > > 1) Both Externalizable and writeObject/readObject cases *by default*
> are
> > > handled in a similar way - with OptimizedMarshaller. *I.e. they are
> > > deserialized on server by default.*
> > > 2) User can optionally fallback to binary format if he thinks it is
> safe.
> > > But he must do it explicitly via configuration.
> > > 3) When we met such classes for the first time, a warning is printed to
> > the
> > > user. Something like: "Binary format cannot be applied to the [class]
> > > because it implements Externalizable interface; instances will be
> > > deserialized on server (to enable binary format please implement
> > > Binarylizable interface, or enable [property] or define custom
> > > serializer)".
> > > 4) Only one exception class is possible on the server - ClassNotFound.
> We
> > > will throw it with sensible error message as well.
> > >
> > > Thoughts?
> > >
> > > Vladimir.
> > >
> >
>

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