ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vladimir Ozerov <voze...@gridgain.com>
Subject Re: Custom Java serialization and BinaryMarshaller
Date Tue, 15 Dec 2015 05:58:49 GMT
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