I am always in favor of easy fixes :) On Tue, Feb 23, 2016 at 8:50 PM, Valentin Kulichenko < valentin.kuliche...@gmail.com> wrote:
> 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 <dsetrak...@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 <andrewkor...@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.kuliche...@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 > > > > > > > > >
