ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vladimir Ozerov <voze...@gridgain.com>
Subject Custom Java serialization and BinaryMarshaller
Date Mon, 14 Dec 2015 21:30:53 GMT
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