Raul, if you don't mind, for posterity, could you please collect all your ideas spread all over this two-week long email thread and update the wiki page here https://cwiki.apache.org/confluence/display/IGNITE/OSGI+Compatibility? The details of your de-/serialization implementation would be especially interesting as personally I still don't understand what's being proposed. Also, please update the "Bundlezation" section with your approach to determining when an optional Ignite dependency should be a bundle and when a fragment.
Thanks a lot! Andrey > From: [email protected] > Date: Wed, 11 Nov 2015 13:31:04 +0000 > Subject: Re: OSGi migration may require a special marshaller > To: [email protected] > > On Wed, Nov 11, 2015 at 1:48 AM, Dmitriy Setrakyan <[email protected]> > wrote: > > > 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. > > Regards, > > *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
