Mailing-List: contact dev-help@ignite.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@ignite.apache.org
MIME-Version: 1.0
In-Reply-To: <SNT147-W275F63D4B5366FAAE1F038CF2A0@phx.gbl>
References: 
 <AM4PR06MB15054C7FCE6CC67149947C4AE82C0@AM4PR06MB1505.eurprd06.prod.outlook.com>
 <CAKoNANvA65rRd6N8XUXJxiW=oN=et_Kzt3=O+UJEGXs25npqcw@mail.gmail.com>
 <SNT147-W71ACEA4350127097EAE368CF2C0@phx.gbl>
 <CAKoNANuXuqS=McrXcX85xLL2wKRzsTTpD0VP-k3r_4xEOMijzQ@mail.gmail.com>
 <CAHG4OXubd7C_vhaNq6YGAgOp1F4RgAgHtSrSoGQXL+G_jCiGeQ@mail.gmail.com>
 <CA+0=VoWvxnzZ2fQb-XTKp2B=BW2kXK_yQ17_J7XG3Frj-MBPnQ@mail.gmail.com>
 <CAHG4OXvCP6yKfTQf1D=ikjERvY4PubZNa5NSY+NMGUuijqGm5Q@mail.gmail.com>
 <SNT147-W927545618FB28FBA6CF02BCF2B0@phx.gbl>
 <CAHG4OXtn4SChjjNPmkR3xOycNicrqKtj9TbXzwh7+kCXUOQC6g@mail.gmail.com>
 <CA+0=VoUTdmCOh-96=6AnfhgcJ5J1cWdUjtkhYfAfp2VY87pvZw@mail.gmail.com>
 <SNT147-W275F63D4B5366FAAE1F038CF2A0@phx.gbl>
From: Dmitriy Setrakyan <dsetrakyan@apache.org>
Date: Tue, 3 Nov 2015 19:06:26 -0800
Message-ID: 
 <CA+0=VoX1xD4JNMNchxPUeBNoANoZCV9U0UH-gpdDqdVy1oHgeQ@mail.gmail.com>
Subject: Re: OSGi migration may require a special marshaller
To: dev@ignite.apache.org
Content-Type: multipart/alternative; boundary=047d7b2e463c29b5790523ae4ee1

--047d7b2e463c29b5790523ae4ee1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Andrey, et al,

Can you provide a way on how to get a required Bundle object based on, say,
bundle symbolic name and version?

I have reached the end of the internet trying to find a way in OSGI to look
up a Bundle based on something other than an actual Class belonging to that
bundle, but no luck.

D.

On Tue, Nov 3, 2015 at 5:15 PM, Andrey Kornev <andrewkornev@hotmail.com>
wrote:

> Dmitriy,
>
> I think your approach will work, but I let Romain respond.
>
> Also, in terms of the implementation, please keep in mind that the
> resolver must be called for each non-JDK and non-Ignite core class (it
> would probably make sense to eschew storing class loaders for such classe=
s
> in favor of compactness of the serialized representation -- see below).
> Also, it's worth keeping a cache of already resolved class loaders per
> marshaller invocation (this is probably the context that Romain has
> mentioned in his previous posting) to minimize the number of the resolver
> calls.
>
> In terms of the resolver's implementation, the simplest way to serialize
> the class loader would be by capturing two pieces of information (both
> strings): the bundle symbolic name and the bundle version. This approach
> however may result in bloating of the serialized representation: I'd
> roughly estimate the overhead per element to be at least 20-30 bytes (the
> length of the symbolic name string, plus the length of the version string=
).
> There are way to reduce the overhead (like serializing the hash code of t=
he
> bundle id string rather than the string itself, and then come up with a
> clever way of resolving the hash collisions), but they all come at cost o=
f
> increased complexity...
>
> An alternative approach would be rely on the special bundle id which is a=
n
> integer and is generated by the OSGi container. But in this case, all nod=
es
> must ensure that all the bundles have consistent ids (bundle A with id 42
> on node N1, has the same id on every other node) which is not easy -- whi=
le
> not entirely impossible -- to guarantee. As long as the nodes are
> homogeneous (have the same set of bundles deployed) the OSGi container is
> guaranteed to assign to the bundles the same ids.
>
> Thanks
> Andrey
>
> > From: dsetrakyan@apache.org
> > Date: Tue, 3 Nov 2015 16:29:41 -0800
> > Subject: Re: OSGi migration may require a special marshaller
> > To: dev@ignite.apache.org
> >
> > Romain,
> >
> > In the upcoming release we will be deprecating the OptimizedMarshaller
> and
> > will be switching to a default internal marshaller (which is based on t=
he
> > new PortableMarshaller donated by GridGain).
> >
> > Having said that, we may be able to pass BinaryWriter and BinaryReader
> > instead of byte arrays. This will be pretty close to passing the stream=
,
> as
> > suggested by Andrey.
> >
> > Also, I still think that we should only resolve class loaders and not t=
he
> > class itself. The main reason is that Ignite will encode class names in=
to
> > an integer hash code and will store the integer->class-fqn mapping in
> > internal replicated cache. I doubt users will get more efficient than a=
n
> > integer (4 bytes) for a class name.
> >
> > On the receiving side, once we are able to get the right class loader, =
we
> > can easily get the proper class by calling
> ClassLoader.findClass(class-fqn).
> >
> > Thoughts?
> >
> > D.
> >
> > On Tue, Nov 3, 2015 at 2:01 PM, Romain Gilles <romain.gilles@gmail.com>
> > wrote:
> >
> > > Hi,
> > > Maybe a missing point. I think but I'm not sure that in the
> > > OptimizedMarshaller there is a caching of already serialized classes.
> Due
> > > to the dynamic nature of OSGi this may lead to memory leak. In fact i=
f
> a
> > > bundle is refreshed, it will produce a new BundleRevision and
> therefore a
> > > new classloader. And if you don't release the class from the previous
> > > BundleRevision then you endup with memory leak. So maybe the Marshall=
er
> > > interface or somewhere should provide a way to free those classes /
> > > classloaders.
> > >
> > > Regards,
> > >
> > > Romain
> > >
> > > Le mar. 3 nov. 2015 =C3=A0 22:42, Andrey Kornev <andrewkornev@hotmail=
.com>
> a
> > > =C3=A9crit :
> > >
> > > > Romain/Dmitriy,
> > > >
> > > > I prefer Romain's approach, but just curious, in the API you guys a=
re
> > > > proposing why use a byte[] rather than OutputStream/InputStream?
> With a
> > > > byte[], one would inevitably end up wrapping it into a byte stream
> class.
> > > > Also, the stream-based interface would be more in line with the
> > > Marshaller
> > > > API.
> > > >
> > > > Also for symmetry with the readClass() method, I suggest the
> writeClass()
> > > > take a Class<?> rather than an object.
> > > >
> > > > Regards
> > > > Andrey
> > > >
> > > > > From: romain.gilles@gmail.com
> > > > > Date: Tue, 3 Nov 2015 21:24:01 +0000
> > > > > Subject: Re: OSGi migration may require a special marshaller
> > > > > To: dev@ignite.apache.org
> > > > >
> > > > > Hi Dmitriy,
> > > > > I think your solution is good. Maybe I will change it a little
> bit...
> > > :P
> > > > > I think you should delegate the Class resolution to the resolver.
> > > Because
> > > > > for example with your current solution the marshaller may before
> (or
> > > > after)
> > > > > store the fqn of the class (maybe only the first time it encounte=
r
> it)
> > > > but
> > > > > in order to save the classloader context resolution the
> implementation
> > > of
> > > > > the resolver may have to save the package name of the given objec=
t
> and
> > > > some
> > > > > extra info therefore the content package name will be serialized
> two
> > > > times.
> > > > > Ok, it's not a big deal.
> > > > > But now if the resolver identify that it can reuse the same class
> > > loader
> > > > > for a couple of classes. It will be interesting for it to have a
> > > > > serialization context in order to save, let say, classloader/id
> mapping
> > > > in
> > > > > order to save the id instead of a more longer representation.
> > > > > So I propose something like that:
> > > > > *public interface ClassResolver {*
> > > > > *    // This method is invoked on the sender side to *
> > > > > *    // marshal the information about the class.*
> > > > > *    // where the context is a map style object that is reset/new
> for
> > > > each
> > > > > object graph serialization.*
> > > > > *    public byte[] writeClass(Object o, Context context) throws
> > > > > IgniteException;*
> > > > >
> > > > > *    // This method is invoked on the receiving side to*
> > > > > *    // retrieve the class based on provided information.*
> > > > > *    // where the context is a map style object that is reset/new
> for
> > > > each
> > > > > object graph serialization.*
> > > > > *    public Class<?> readClass(byte[], Context context) throws
> > > > > IgniteException;*
> > > > > *}*
> > > > >
> > > > > I think your proposal will solve our issue and maybe also open a
> door
> > > for
> > > > > the osgi development.
> > > > > Let me know what do you think about me proposal? :)
> > > > >
> > > > > Thanks,
> > > > >
> > > > > Romain
> > > > >
> > > > > Le mar. 3 nov. 2015 =C3=A0 20:05, Dmitriy Setrakyan <
> dsetrakyan@apache.org>
> > > a
> > > > > =C3=A9crit :
> > > > >
> > > > > > Romain,
> > > > > >
> > > > > > Can you comment on the ClassLoaderResolver suggestion that I
> proposed
> > > > > > earlier? Will it solve your problem?
> > > > > >
> > > > > > D.
> > > > > >
> > > > > > On Tue, Nov 3, 2015 at 2:38 AM, Romain Gilles <
> > > romain.gilles@gmail.com
> > > > >
> > > > > > wrote:
> > > > > >
> > > > > > > Hi Raul,
> > > > > > >  - Do you plan to use the TCCL when marshalling in OSGi env?
> If yes
> > > > how?
> > > > > > >  - I like the point 2. Maybe for a graph of object that come
> from
> > > > > > different
> > > > > > > packages / bundles you may have to recursively capture the
> package
> > > > > > version
> > > > > > > of the individual element of your graph.
> > > > > > >  - For the point 3 I wonder if it will not over-complexify th=
e
> > > > solution.
> > > > > > As
> > > > > > > a developer you will have to think about it. And it is not
> obvious
> > > > in the
> > > > > > > code where things are serialized or not. You may use lambda i=
n
> your
> > > > > > > application code therefore the current package become what yo=
u
> call
> > > > a DTO
> > > > > > > package. The current state of ignite does not enforce you to
> > > specify
> > > > it
> > > > > > for
> > > > > > > "classical" classloading application. If you introduce this
> extra
> > > > step
> > > > > > for
> > > > > > > OSGi ready application you will maybe discourage people to us=
e
> > > OSGi.
> > > > > > >
> > > > > > > To comeback to our solution. We start we a strong assumption:
> our
> > > > cluster
> > > > > > > is homogeneous in term of code so, of course, it simplify our
> life
> > > > :).
> > > > > > >
> > > > > > > BTW if you can introduce an extension point in the class
> resolution
> > > > > > > mechanism it can be interesting for end user in order to allo=
w
> them
> > > > to
> > > > > > > optimize it based on there specific use cases.
> > > > > > >
> > > > > > > Romain.
> > > > > > >
> > > > > > > Le mar. 3 nov. 2015 =C3=A0 00:21, Raul Kripalani <raul@evosen=
t.com>
> a
> > > > =C3=A9crit :
> > > > > > >
> > > > > > > > Hi Andrey,
> > > > > > > >
> > > > > > > > Thanks for the participation in this topic.
> > > > > > > >
> > > > > > > > I don't like the solution to incorporate the bundle symboli=
c
> name
> > > > in
> > > > > > the
> > > > > > > > serialised form. Nothing guarantees that the classdef will =
be
> > > > located
> > > > > > > under
> > > > > > > > the same bundle in both source and target machines. We also
> have
> > > to
> > > > > > take
> > > > > > > > into account that OSGi allows for multiple versions of the
> same
> > > > > > > > bundle/packages to co-exist in the same  container. So it
> becomes
> > > > more
> > > > > > > > complex.
> > > > > > > >
> > > > > > > > Using the TCCL should work when serialising, but it'll
> probably
> > > be
> > > > of
> > > > > > no
> > > > > > > > use when deserialising on the other end.
> > > > > > > >
> > > > > > > > I need to enhance Ignite to:
> > > > > > > >
> > > > > > > > 1. Use the TCCL when marshalling on one end.
> > > > > > > > 2. Incorporate the package version of the class in the
> serialised
> > > > form
> > > > > > if
> > > > > > > > Ignite is running in an OSGi environment.
> > > > > > > > 3. On the receiver end, discover cache entities / DTOs in a=
ll
> > > > bundles
> > > > > > > > through a custom OSGi manifest header or the like, as I
> explained
> > > > > > before.
> > > > > > > > Package version must be taken into account.
> > > > > > > >
> > > > > > > > What do you think?
> > > > > > > >
> > > > > > > > Ra=C3=BAl.
> > > > > > > > On 2 Nov 2015 17:25, "Andrey Kornev" <
> andrewkornev@hotmail.com>
> > > > wrote:
> > > > > > > >
> > > > > > > > > Raul,
> > > > > > > > >
> > > > > > > > > The fundamental hurdle we need to jump over to make Ignit=
e
> > > > > > OSGi-enabled
> > > > > > > > is
> > > > > > > > > the marshalling. More specifically the issue is with
> > > > deserialization
> > > > > > of
> > > > > > > > the
> > > > > > > > > classes that are provided by the bundles other than the
> Ignite
> > > > bundle
> > > > > > > > > itself.
> > > > > > > > >
> > > > > > > > > When the Ignite transport layer receives a message it
> needs to
> > > > figure
> > > > > > > out
> > > > > > > > > how to deserialize the bytes and for that it needs to kno=
w
> the
> > > > bundle
> > > > > > > > that
> > > > > > > > > provides the class to be deserailized. At this point TCCL
> is of
> > > > no
> > > > > > use.
> > > > > > > > To
> > > > > > > > > make things more complex, the class may contain other
> classes
> > > > that
> > > > > > come
> > > > > > > > > from other bundles, and so on recursively. This means tha=
t
> each
> > > > > > object
> > > > > > > in
> > > > > > > > > the hierarchy must be serialized with its bundle name (or
> > > bundle
> > > > id),
> > > > > > > so
> > > > > > > > > that the deserializer will then be able to correctly
> resolve
> > > the
> > > > > > class
> > > > > > > > > while traversing the object hierarchy during
> deserialization.
> > > > > > > > >
> > > > > > > > > Unfortunately, Ignite's OptimizedMarshaller is lacking th=
e
> > > > ability to
> > > > > > > > plug
> > > > > > > > > in a custom class resolver. Romain's solution was to use
> Kryo
> > > > that
> > > > > > does
> > > > > > > > > provide a way to customize class resolution. It has solve=
d
> the
> > > > > > problem
> > > > > > > of
> > > > > > > > > capturing the bundle info and he was able to successfully
> run
> > > > Ignite
> > > > > > > as a
> > > > > > > > > bundle in an OSGi container (after some repackaging and
> > > > inclusion of
> > > > > > > the
> > > > > > > > > manifest). But Kryo-based marshalling introduced a lot of
> > > > complexity
> > > > > > to
> > > > > > > > the
> > > > > > > > > code and incorrect use of Kryo's numerous serializers
> caused
> > > some
> > > > > > weird
> > > > > > > > > hard-to-debug issues in the Ignite core (like duplicate
> cache
> > > > entries
> > > > > > > due
> > > > > > > > > to incorrect marshalling of the GridDhtPArtitonFullMap
> class --
> > > > go
> > > > > > > > > figure!). Overall the Kryo-based solution is brittle and
> hard
> > > to
> > > > > > > > maintain.
> > > > > > > > >
> > > > > > > > > I feel the correct solution to OSGi problem would be to
> > > > > > > > > 1) enhance the OptimizedMarshaller to allow custom class
> > > > resolution.
> > > > > > > > > 2) provide an OSGi-enabled OptimizedMarshaller (in
> addition to
> > > > the
> > > > > > > > > original one) to be used in OSGi environment.
> > > > > > > > >
> > > > > > > > > Regards
> > > > > > > > > Andrey
> > > > > > > > >
> > > > > > > > > > From: raulk@apache.org
> > > > > > > > > > Date: Mon, 2 Nov 2015 12:41:47 +0000
> > > > > > > > > > Subject: Re: OSGi migration may require a special
> marshaller
> > > > > > > > > > To: dev@ignite.apache.org
> > > > > > > > > >
> > > > > > > > > > Hi Romain,
> > > > > > > > > >
> > > > > > > > > > I'm working on the OSGi compatibility of Ignite. I
> appreciate
> > > > your
> > > > > > > > input.
> > > > > > > > > >
> > > > > > > > > > I'm thinking about the situation you describe and I
> wonder if
> > > > > > you're
> > > > > > > > > > exporting Ignite as an OSGi service which is then
> consumed
> > > from
> > > > > > other
> > > > > > > > > > bundles. Under this situation, it would be quite easy t=
o
> > > > reproduce
> > > > > > > the
> > > > > > > > > > behaviour you describe if Ignite is not resolving
> classes via
> > > > the
> > > > > > > TCCL.
> > > > > > > > > > Need to dig deeper into that.
> > > > > > > > > >
> > > > > > > > > > Off the top of my head, there are two alternatives to
> solve
> > > it:
> > > > > > > > > >
> > > > > > > > > > 1. Use the TCCL for marshalling/unmarshalling (if not
> already
> > > > > > used) =E2=80=93
> > > > > > > > we
> > > > > > > > > > gotta be wary of possible regressions.
> > > > > > > > > > 2. Create a special OSGi header Ignite-Export-Package s=
o
> that
> > > > > > bundles
> > > > > > > > > > containing DTOs can expose packages to Ignite's
> marshallers.
> > > > > > > > > >
> > > > > > > > > > Regards,
> > > > > > > > > >
> > > > > > > > > > *Ra=C3=BAl 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
> > > > > > > > > >
> > > > > > > > > > On Mon, Nov 2, 2015 at 9:56 AM, Gilles, Romain <
> > > > > > > > romain.gilles@misys.com>
> > > > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > > Hi all,
> > > > > > > > > > >
> > > > > > > > > > > I'm really interested in this issue:
> > > > > > > > > > > https://issues.apache.org/jira/browse/IGNITE-1270 . W=
e
> > > some
> > > > > > stuff
> > > > > > > to
> > > > > > > > > make
> > > > > > > > > > > it work in our osgi environment. The main issue for u=
s
> now
> > > > is the
> > > > > > > > > > > serialization. I think it you will have to rework the
> > > > > > > > > OptimizedMarshaller
> > > > > > > > > > > or any other marshaller that works with object that
> come
> > > from
> > > > > > > outside
> > > > > > > > > your
> > > > > > > > > > > class space.
> > > > > > > > > > >
> > > > > > > > > > > We have try kryo that works. Kryo provide an extensio=
n
> > > point
> > > > in
> > > > > > > order
> > > > > > > > > to
> > > > > > > > > > > resolve the classes:
> > > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > >
> > >
> https://github.com/EsotericSoftware/kryo/blob/master/src/com/esotericsoft=
ware/kryo/ClassResolver.java
> > > > > > > > > > > . With this extension we are able to solve the proble=
m
> of
> > > > > > external
> > > > > > > > > classes.
> > > > > > > > > > > The only issue with kryo is that some classes need a
> > > certain
> > > > care
> > > > > > > in
> > > > > > > > > the
> > > > > > > > > > > serialization process and therefore a specialized
> > > serializer.
> > > > > > > > > > >
> > > > > > > > > > > So I would like to know from the community what do
> think of
> > > > > > > changing
> > > > > > > > > the
> > > > > > > > > > > way the optimized marshaller works or introducing the
> > > > support of
> > > > > > > yet
> > > > > > > > > > > another marshaller based on a kryo like technology?
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > Thanks in advance,
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > Best regards,
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > Romain.
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > PS: I'm ready to help in the both cases.
> > > > > > > > > > > "Misys" is the trade name of the Misys group of
> companies.
> > > > This
> > > > > > > email
> > > > > > > > > and
> > > > > > > > > > > any attachments have been scanned for known viruses
> using
> > > > > > multiple
> > > > > > > > > > > scanners. This email message is intended for the name=
d
> > > > recipient
> > > > > > > > only.
> > > > > > > > > It
> > > > > > > > > > > may be privileged and/or confidential. If you are not
> the
> > > > named
> > > > > > > > > recipient
> > > > > > > > > > > of this email please notify us immediately and do not
> copy
> > > > it or
> > > > > > > use
> > > > > > > > > it for
> > > > > > > > > > > any purpose, nor disclose its contents to any other
> person.
> > > > This
> > > > > > > > email
> > > > > > > > > does
> > > > > > > > > > > not constitute the commencement of legal relations
> between
> > > > you
> > > > > > and
> > > > > > > > > Misys.
> > > > > > > > > > > Please refer to the executed contract between you and
> the
> > > > > > relevant
> > > > > > > > > member
> > > > > > > > > > > of the Misys group for the identity of the contractin=
g
> > > party
> > > > with
> > > > > > > > > which you
> > > > > > > > > > > are dealing.
> > > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > >
> > >
>
>

--047d7b2e463c29b5790523ae4ee1--