ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Raul Kripalani <ra...@apache.org>
Subject Re: OSGi migration may require a special marshaller
Date Wed, 11 Nov 2015 13:31:04 GMT
On Wed, Nov 11, 2015 at 1:48 AM, Dmitriy Setrakyan <dsetrakyan@apache.org>

> Raul, we cannot be adding package name and version in all cases, as it will
> have a negative impact on performance, especially when there is an
> *optimistic* approach that requires no over-the-wire overhead whatsoever.

Why do we need to add the package name? The OptimizedObjectOutputStream
already encodes the classname, which is then read on line 310 of
OptimizedObjectInputStream (ignite-1.5 branch). Therefore, we already have
the package name. All we need to encode is the version number which will be
an additional String which can be further compressed:

* For "1.0.0" we transmit "1".
* For "1.1.0", we transmit "1.1".
* etc.

And this will only occur on a conditional basis when we detect we're
running in an OSGi environment, although we need to cater for hybrid grid
scenarios (comprising OSGi containers + non-OSGi containers). For all other
cases, it would be skipped.

If you'd still like to avoid these additional bytes, then a mode switch in
OptimizedMarshaller: setTransmitOsgiPkgVer(boolean) should suffice.

As I said, I don't see enough justification for pluggability in this
context. I could see it if we were creating a mechanism for transmitting
generic serialisation context. But everybody seems fixated on tackling
classloader complexity only.

I could also see some level of pluggability if this was applicable to any
other marshallers. But how exactly do you see this being applicable to
Kryo, Protobuf, or other potential ones (which we don't offer now)? How
would you "encode the classloader" and where in the OutputStream? At the
header? Before delegating the serialisation to the selected framework?

Raul, personally I understand your sentiments, but to be honest I dislike
> the names you are proposing even more. I still consider ClassLoaderCodec to
> be the most elegant name here, considering all the other options I have
> seen. It is concise and symmetric. I am open to changing it, but it must be
> for the better, not for the worse.

It's not about sentiment, it's about objectivity. The first step is to move
away from the ClassLoaderCodec name, it's inaccurate. If anything I would
propose SerializationContextCodec. But it implies extending its role to
what I proposed: to provide and interpret information that assists the
serialisation/deserialisation context.

Let’s make sure that we follow the 80/20 rule and keep the default
> implementation suitable for 80% of use cases with zero performance
> overhead.

No one questions that. The additional package version transmission would
only kick in if we're in an OSGi environment.

Having said that, I would be against artificially forcing this change into
> 1.5, especially given the amount of controversy it generated.

I don't think it's impossible to get it into 1.5 if that's the timeline.


*Raúl Kripalani*
PMC & Committer @ Apache Ignite, Apache Camel | Integration, Big Data and
Messaging Engineer
http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani
http://blog.raulkr.net | twitter: @raulvk

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