Mailing-List: contact dev-help@ignite.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@ignite.apache.org
Message-ID: <SNT147-W737D3942C043795AACBF68CFE10@phx.gbl>
Content-Type: multipart/alternative;
	boundary="_9cf256bd-30ec-4ce5-8be7-77ed0c254248_"
From: Andrey Kornev <andrewkornev@hotmail.com>
To: "dev@ignite.apache.org" <dev@ignite.apache.org>
Subject: RE: CacheEntry serialization failure
Date: Fri, 18 Dec 2015 10:05:26 -0800
Importance: Normal
In-Reply-To: 
 <CAGt6o8kzzgx2KdR4ewcgNsC3hK2bNyRbHTY4OiJTH414p49ZoA@mail.gmail.com>
References: 
 <CABuYRcppY7-r0KmwopHTHhDUZdUz+T6nZOEmtg1ZKj=tbNv8Rg@mail.gmail.com>,<CAGt6o8n2JQ1t3YzJarpoVvE7n3hf_8MZWvZHANcpiCbxLg1y2A@mail.gmail.com>,<SNT147-W7736591BD8D17852326156CFE10@phx.gbl>,<CAGt6o8mB-gPkgr6A4iXFZWHogRcMtripjfXS1y_ayHThGeNvWQ@mail.gmail.com>,<CAGt6o8=7sqAtgDviq8y4wUqgx_f+SV400RWamobd6JYaLGPWcQ@mail.gmail.com>,<CAGt6o8kzzgx2KdR4ewcgNsC3hK2bNyRbHTY4OiJTH414p49ZoA@mail.gmail.com>
MIME-Version: 1.0

--_9cf256bd-30ec-4ce5-8be7-77ed0c254248_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

In this particular case=2C the class that fails is a non-static inner class=
 that extends another non-static inner class=2C so they both end up having =
the compiler-generated "this$0" field.

Regards
Andrey

> Date: Fri=2C 18 Dec 2015 20:44:12 +0300
> Subject: Re: CacheEntry serialization failure
> From: vozerov@gridgain.com
> To: dev@ignite.apache.org
>=20
> The most straightforward solution which comes to my mind - *do not ever u=
se
> BinaryMarshaller by default*. Always fallback to OptimizedMarshaller unle=
ss
> user explicitly asked us to use binary format (e.g. through package
> wildcards).
>=20
> BTW=2C we already do this for Externalizable and readObject/writeObject.
>=20
> On Fri=2C Dec 18=2C 2015 at 8:41 PM=2C Vladimir Ozerov <vozerov@gridgain.=
com>
> wrote:
>=20
> > Ah=2C I saw your problem with DirectedSpecifics. We need to think about=
 how
> > to solve it. Here is the case:
> > 1) Class is Serilzable and cannot be changed=3B
> > 2) There are several duplicated field names=3B
> > =3D> BinaryMarshaller cannot handle it.
> >
> > Any thoughts?
> >
> > On Fri=2C Dec 18=2C 2015 at 8:34 PM=2C Vladimir Ozerov <vozerov@gridgai=
n.com>
> > wrote:
> >
> >> I fixed the problem=2C it was a bug actually.
> >>
> >> By default classes which has some custom Java logic (e.g. Externalizab=
le=2C
> >> or with writeObject/readObject methods) will be written using
> >> OptimizedMarshaller=2C so similar field names is not a problem.
> >> If you want to serialize such class in binary format and have duplicat=
e
> >> field names=2C you should provide your own BinarySerializer=2C which w=
ill write
> >> these fields with different names.
> >>
> >> On Fri=2C Dec 18=2C 2015 at 8:07 PM=2C Andrey Kornev <andrewkornev@hot=
mail.com>
> >> wrote:
> >>
> >>> How am I supposed to handle this situation if the class comes from a =
3d
> >>> party I can't modify?
> >>>
> >>> Thanks
> >>> Andrey
> >>>
> >>> > Date: Fri=2C 18 Dec 2015 09:12:22 +0300
> >>> > Subject: Re: CacheEntry serialization failure
> >>> > From: vozerov@gridgain.com
> >>> > To: dev@ignite.apache.org
> >>> >
> >>> > I'll take a look.
> >>> >
> >>> > On Fri=2C Dec 18=2C 2015 at 4:37 AM=2C Valentin Kulichenko <
> >>> > valentin.kulichenko@gmail.com> wrote:
> >>> >
> >>> > > Folks=2C
> >>> > >
> >>> > > It looks like CacheEntry implementation (i.e.=2C the entry that
> >>> contains
> >>> > > version) can't be properly serialized with the BinaryMarshaller. =
I
> >>> created
> >>> > > the test and the ticket:
> >>> https://issues.apache.org/jira/browse/IGNITE-2203
> >>> > >
> >>> > > Can someone take a look?
> >>> > >
> >>> > > -Val
> >>> > >
> >>>
> >>>
> >>
> >>
> >
 		 	   		  =

--_9cf256bd-30ec-4ce5-8be7-77ed0c254248_--