Question about OBJ binary representation

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Question about OBJ binary representation

daradurvs
Hello everyone.

Please, explain me, in which cases at marshalling after object header (24
bytes) it needs to write Class.getName?

I understand that it means that this class isn't registered in
BinaryContext, and at deserializing we use it for loading Class with
ClassLoader.

Please explain real scenarios.

--
Best Regards, Vyacheslav
Reply | Threaded
Open this post in threaded view
|

Re: Question about OBJ binary representation

daradurvs
Following second question.

In which cases it needs to write postWriteHashCode?

2017-03-23 12:27 GMT+03:00 Vyacheslav Daradur <[hidden email]>:

> Hello everyone.
>
> Please, explain me, in which cases at marshalling after object header (24
> bytes) it needs to write Class.getName?
>
> I understand that it means that this class isn't registered in
> BinaryContext, and at deserializing we use it for loading Class with
> ClassLoader.
>
> Please explain real scenarios.
>
> --
> Best Regards, Vyacheslav
>



--
Best Regards, Vyacheslav
Reply | Threaded
Open this post in threaded view
|

Re: Question about OBJ binary representation

al.psc
Hi Vyacheslav,

1: Yes, exactly.

2: Hash code is written for all BinaryObjects. Starting with Ignite
1.9, hashCode implementations of original classes are never used to
compute hash codes for corresponding binary objects.

- Alex

2017-03-23 12:58 GMT+03:00 Vyacheslav Daradur <[hidden email]>:

> Following second question.
>
> In which cases it needs to write postWriteHashCode?
>
> 2017-03-23 12:27 GMT+03:00 Vyacheslav Daradur <[hidden email]>:
>
>> Hello everyone.
>>
>> Please, explain me, in which cases at marshalling after object header (24
>> bytes) it needs to write Class.getName?
>>
>> I understand that it means that this class isn't registered in
>> BinaryContext, and at deserializing we use it for loading Class with
>> ClassLoader.
>>
>> Please explain real scenarios.
>>
>> --
>> Best Regards, Vyacheslav
>>
>
>
>
> --
> Best Regards, Vyacheslav
Reply | Threaded
Open this post in threaded view
|

Re: Question about OBJ binary representation

Alexey Goncharuk
Vyacheslav,

As for the real scenarios for a class name not be registered, this can
happen when Ignite attempts to register a mapping on a locked topology (for
example, inside a started user transaction) and the primary node for the
corresponding mapping key has left. In this case, the mapping attempt would
throw a topology exception, and marshaller has to write the full class name.

--AG

2017-03-23 22:20 GMT+03:00 Alexander Paschenko <
[hidden email]>:

> Hi Vyacheslav,
>
> 1: Yes, exactly.
>
> 2: Hash code is written for all BinaryObjects. Starting with Ignite
> 1.9, hashCode implementations of original classes are never used to
> compute hash codes for corresponding binary objects.
>
> - Alex
>
> 2017-03-23 12:58 GMT+03:00 Vyacheslav Daradur <[hidden email]>:
> > Following second question.
> >
> > In which cases it needs to write postWriteHashCode?
> >
> > 2017-03-23 12:27 GMT+03:00 Vyacheslav Daradur <[hidden email]>:
> >
> >> Hello everyone.
> >>
> >> Please, explain me, in which cases at marshalling after object header
> (24
> >> bytes) it needs to write Class.getName?
> >>
> >> I understand that it means that this class isn't registered in
> >> BinaryContext, and at deserializing we use it for loading Class with
> >> ClassLoader.
> >>
> >> Please explain real scenarios.
> >>
> >> --
> >> Best Regards, Vyacheslav
> >>
> >
> >
> >
> > --
> > Best Regards, Vyacheslav
>
Reply | Threaded
Open this post in threaded view
|

Re: Question about OBJ binary representation

daradurvs
Alexey, one more question.

In which cases, classLoader won't find Class by class-name?

2017-03-24 10:00 GMT+03:00 Alexey Goncharuk <[hidden email]>:

> Vyacheslav,
>
> As for the real scenarios for a class name not be registered, this can
> happen when Ignite attempts to register a mapping on a locked topology (for
> example, inside a started user transaction) and the primary node for the
> corresponding mapping key has left. In this case, the mapping attempt would
> throw a topology exception, and marshaller has to write the full class
> name.
>
> --AG
>
> 2017-03-23 22:20 GMT+03:00 Alexander Paschenko <
> [hidden email]>:
>
> > Hi Vyacheslav,
> >
> > 1: Yes, exactly.
> >
> > 2: Hash code is written for all BinaryObjects. Starting with Ignite
> > 1.9, hashCode implementations of original classes are never used to
> > compute hash codes for corresponding binary objects.
> >
> > - Alex
> >
> > 2017-03-23 12:58 GMT+03:00 Vyacheslav Daradur <[hidden email]>:
> > > Following second question.
> > >
> > > In which cases it needs to write postWriteHashCode?
> > >
> > > 2017-03-23 12:27 GMT+03:00 Vyacheslav Daradur <[hidden email]>:
> > >
> > >> Hello everyone.
> > >>
> > >> Please, explain me, in which cases at marshalling after object header
> > (24
> > >> bytes) it needs to write Class.getName?
> > >>
> > >> I understand that it means that this class isn't registered in
> > >> BinaryContext, and at deserializing we use it for loading Class with
> > >> ClassLoader.
> > >>
> > >> Please explain real scenarios.
> > >>
> > >> --
> > >> Best Regards, Vyacheslav
> > >>
> > >
> > >
> > >
> > > --
> > > Best Regards, Vyacheslav
> >
>



--
Best Regards, Vyacheslav
Reply | Threaded
Open this post in threaded view
|

Re: Question about OBJ binary representation

Alexey Goncharuk
I guess when the class is not in the classpath of the Ignite node :) To
deserialize the value, either
 * the class should be either in the classpath
 * or it should be accessible via the configured class loader
 * or optimized marshaller should be used and peer class loading is enabled.

2017-03-24 12:02 GMT+03:00 Vyacheslav Daradur <[hidden email]>:

> Alexey, one more question.
>
> In which cases, classLoader won't find Class by class-name?
>
> 2017-03-24 10:00 GMT+03:00 Alexey Goncharuk <[hidden email]>:
>
> > Vyacheslav,
> >
> > As for the real scenarios for a class name not be registered, this can
> > happen when Ignite attempts to register a mapping on a locked topology
> (for
> > example, inside a started user transaction) and the primary node for the
> > corresponding mapping key has left. In this case, the mapping attempt
> would
> > throw a topology exception, and marshaller has to write the full class
> > name.
> >
> > --AG
> >
> > 2017-03-23 22:20 GMT+03:00 Alexander Paschenko <
> > [hidden email]>:
> >
> > > Hi Vyacheslav,
> > >
> > > 1: Yes, exactly.
> > >
> > > 2: Hash code is written for all BinaryObjects. Starting with Ignite
> > > 1.9, hashCode implementations of original classes are never used to
> > > compute hash codes for corresponding binary objects.
> > >
> > > - Alex
> > >
> > > 2017-03-23 12:58 GMT+03:00 Vyacheslav Daradur <[hidden email]>:
> > > > Following second question.
> > > >
> > > > In which cases it needs to write postWriteHashCode?
> > > >
> > > > 2017-03-23 12:27 GMT+03:00 Vyacheslav Daradur <[hidden email]>:
> > > >
> > > >> Hello everyone.
> > > >>
> > > >> Please, explain me, in which cases at marshalling after object
> header
> > > (24
> > > >> bytes) it needs to write Class.getName?
> > > >>
> > > >> I understand that it means that this class isn't registered in
> > > >> BinaryContext, and at deserializing we use it for loading Class with
> > > >> ClassLoader.
> > > >>
> > > >> Please explain real scenarios.
> > > >>
> > > >> --
> > > >> Best Regards, Vyacheslav
> > > >>
> > > >
> > > >
> > > >
> > > > --
> > > > Best Regards, Vyacheslav
> > >
> >
>
>
>
> --
> Best Regards, Vyacheslav
>
Reply | Threaded
Open this post in threaded view
|

Re: Question about OBJ binary representation

daradurvs
Alexander, Alexey thanks for your explanations.

2017-03-24 12:13 GMT+03:00 Alexey Goncharuk <[hidden email]>:

> I guess when the class is not in the classpath of the Ignite node :) To
> deserialize the value, either
>  * the class should be either in the classpath
>  * or it should be accessible via the configured class loader
>  * or optimized marshaller should be used and peer class loading is
> enabled.
>
> 2017-03-24 12:02 GMT+03:00 Vyacheslav Daradur <[hidden email]>:
>
> > Alexey, one more question.
> >
> > In which cases, classLoader won't find Class by class-name?
> >
> > 2017-03-24 10:00 GMT+03:00 Alexey Goncharuk <[hidden email]
> >:
> >
> > > Vyacheslav,
> > >
> > > As for the real scenarios for a class name not be registered, this can
> > > happen when Ignite attempts to register a mapping on a locked topology
> > (for
> > > example, inside a started user transaction) and the primary node for
> the
> > > corresponding mapping key has left. In this case, the mapping attempt
> > would
> > > throw a topology exception, and marshaller has to write the full class
> > > name.
> > >
> > > --AG
> > >
> > > 2017-03-23 22:20 GMT+03:00 Alexander Paschenko <
> > > [hidden email]>:
> > >
> > > > Hi Vyacheslav,
> > > >
> > > > 1: Yes, exactly.
> > > >
> > > > 2: Hash code is written for all BinaryObjects. Starting with Ignite
> > > > 1.9, hashCode implementations of original classes are never used to
> > > > compute hash codes for corresponding binary objects.
> > > >
> > > > - Alex
> > > >
> > > > 2017-03-23 12:58 GMT+03:00 Vyacheslav Daradur <[hidden email]>:
> > > > > Following second question.
> > > > >
> > > > > In which cases it needs to write postWriteHashCode?
> > > > >
> > > > > 2017-03-23 12:27 GMT+03:00 Vyacheslav Daradur <[hidden email]
> >:
> > > > >
> > > > >> Hello everyone.
> > > > >>
> > > > >> Please, explain me, in which cases at marshalling after object
> > header
> > > > (24
> > > > >> bytes) it needs to write Class.getName?
> > > > >>
> > > > >> I understand that it means that this class isn't registered in
> > > > >> BinaryContext, and at deserializing we use it for loading Class
> with
> > > > >> ClassLoader.
> > > > >>
> > > > >> Please explain real scenarios.
> > > > >>
> > > > >> --
> > > > >> Best Regards, Vyacheslav
> > > > >>
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Best Regards, Vyacheslav
> > > >
> > >
> >
> >
> >
> > --
> > Best Regards, Vyacheslav
> >
>



--
Best Regards, Vyacheslav