ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrey Kornev <andrewkor...@hotmail.com>
Subject RE: All BinaryObjects created by BinaryObjectBuilder stored at the same partition by default
Date Thu, 24 Mar 2016 20:07:39 GMT
This is a nasty problem that is very difficult to track especially for beginners. But I think
it's easy to solve: since the BinaryObjects are built exclusively using the BinaryObjectBuilder,
you can simply implement a check in the BinaryObjectBuilder.build() to see whether or not
BinaryObjectBuilder.hashCode(int hashCode) has been called. If it has not, Ignite may log
one of those helpful warnings. (Goes without saying it should be possible to suppress the
warning before it gets too annoying.)

Regards
Andrey

> Date: Thu, 24 Mar 2016 17:39:45 +0700
> Subject: Re: All BinaryObjects created by BinaryObjectBuilder stored at the same partition
by default
> From: akuznetsov@gridgain.com
> To: dev@ignite.apache.org
> 
> As for JdbcPojoStore it has an option to configure "hasher".
> 
> On Thu, Mar 24, 2016 at 5:20 PM, Denis Magda <dmagda@gridgain.com> wrote:
> 
> > +1 for the improvement of JavaDoc because the problem arises only when
> > BinaryObjects are used as keys.
> > Readme.io already has a warning regarding this
> >
> > https://apacheignite.readme.io/docs/binary-marshaller#modifying-binary-objects-using-binaryobjectbuilder
> >
> > --
> > Denis
> >
> >
> > On 3/24/2016 12:38 PM, Vladimir Ozerov wrote:
> >
> >> When object has been built, there is no way to know, whether hash code was
> >> set or not. Zero could be real hash code, as well as not set hash code.
> >>
> >> Random is not an option. Any kind of automatic generation is not an option
> >> as well, because we do not know, how hash code of real class instance is
> >> calculated.
> >>
> >> I honestly do not see a big problem here. We can simply improve JavaDocs.
> >>
> >> It could be a problem in some specific cases, like JDBC store. This
> >> situation require the same solution as already mentioned problems with
> >> equals and comparators.
> >>
> >> Vladimir.
> >> 24 марта 2016 г. 11:52 пользователь "Yakov Zhdanov" <yzhdanov@apache.org>
> >> написал:
> >>
> >> Random hash code is not an option.
> >>>
> >>> I would suggest cache throws exception on update if binary object created
> >>> with builder does not have hash code initialized.
> >>>
> >>> Vladimir, can we somehow make it possible to know whether hash code was
> >>> or
> >>> was not inited on a binary object?
> >>>
> >>> --Yakov
> >>>
> >>> 2016-03-24 11:43 GMT+03:00 Anton Vinogradov <avinogradov@gridgain.com>:
> >>>
> >>> Hello,
> >>>>
> >>>> I found that every BinaryObject created by BinaryObjectBuilder has
> >>>>
> >>> hashcode
> >>>
> >>>> == 0 by default.
> >>>> This can cause situation that all objects created by code similar to:
> >>>>
> >>>> *BinaryObject key = builder.setField("id", i).build();*
> >>>> *streamer.addData(key, key);*
> >>>>
> >>>> will be stored at one partition and this cause grid performance drop.
> >>>>
> >>>> Of course user can set hashcode:
> >>>>
> >>>> *BinaryObject key = builder.setField("id",
> >>>>
> >>> i).hashCode(random()).build();*
> >>>
> >>>> but there is no guarantee that he will.
> >>>>
> >>>> I propose to generate random hashcode or hashcode based on field's
> >>>> hashcodes in case no hashcode set or to warn user somehow that he have
> >>>> to
> >>>> specify it.
> >>>>
> >>>> Thoughts?
> >>>>
> >>>>
> >
> 
> 
> -- 
> Alexey Kuznetsov
> GridGain Systems
> www.gridgain.com
 		 	   		  
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message