IGNITE-2693: question about setting BinaryMarshaller on a cache

Hello all,

I am working on IGNITE-2693 with Vlad Ozerov's help. I am somewhat of a
Java newbie so please be gentle ;-)

I am curious about something - after reading the Javadocs and Binary
Marshaller docs on Ignite's documentation websites, I think that the
documentation is not very friendly or even somewhat misleading. Or maybe
it is the design that is puzzling to me :-)

For example, we use withKeepBinary() on a cache instance to get a binary
cache that utilizes the binary marshaller. But this is not a setting
that is "settable" on a per cache basis - we do not allow for a
per-cache method to set a desired marshaller, this seems to be reserved
for the IgniteConfiguration() interface/implementation(s)
setMarshaller() method and is a grid-wide setting.

The background to this is that I have "fixed" the withKeepBinary()
interface to throw an exception if the marshaller used is not binary
(the ticket explains the reason why we want this). Apparently we
(silently?) assume a binary marshaller everywhere but in one of the
unrelated tests in the test suite for some reason an optimized
marshaller is used and as a result of this (with my new change) these
tests are failing [1]. I am trying to fix this but in the process I
realized that you cannot set the marshaller through a
CacheConfiguration() method (no such thing exists), this has to be done
at a higher level (the IgniteConfiguration). However, the whole test is
written to inherit a grid configuration with an optimized marshaller (is
what it looks like to me)....

Am I just horribly confused and missing something very obvious? Thanks!

[1]
org.apache.ignite.internal.processors.cache.GridCacheOffHeapTieredEvictionAbstractSelfTest

[Alexey Goncharuk]

Hi,

The current version of test is not very clean and it works only because
withKeepBinary() is a noop. The correct version would be to use plain cache
for non-binary-object entry processor and use withKeepBinary for
binary-object entry processor. You can see that EntryProcessor creation is
encapsulated in a separate method testClosure() which is overridden in test
inheritors. The same thing should be done for the cache.
​

On 3/9/2016 6:43 PM, Alexey Goncharuk wrote:
> Hi,
>
> The current version of test is not very clean and it works only because
> withKeepBinary() is a noop. The correct version would be to use plain cache
> for non-binary-object entry processor and use withKeepBinary for
> binary-object entry processor. You can see that EntryProcessor creation is
> encapsulated in a separate method testClosure() which is overridden in test
> inheritors. The same thing should be done for the cache.

Alexey, thank you for the comment.

On a side note: you do not find it confusing that you can set a
marshaller on a grid but you get a binary cache from another cache via
withKeepBinary()?

Thanks!

[Alexey Goncharuk]

Note that withKeepBinary() is just a way to tell a cache not to deserialize
values when doing a get or running an entry processor. The concept of
binary object does not belong solely to caches - you can get an instance of
IgniteBinary interface from Ignite and use binary objects in computations,
for example.

For me there would be more confusion if each cache had a separate
marshaller. What would then happen if you put an instance of BinaryObject
to a cache with JDK marshaller? When marshaller is global, the answer is
simple - BinaryObject is either available or not :)

On 3/9/2016 7:46 PM, Alexey Goncharuk wrote:

> Note that withKeepBinary() is just a way to tell a cache not to deserialize
> values when doing a get or running an entry processor. The concept of
> binary object does not belong solely to caches - you can get an instance of
> IgniteBinary interface from Ignite and use binary objects in computations,
> for example.
>
> For me there would be more confusion if each cache had a separate
> marshaller. What would then happen if you put an instance of BinaryObject
> to a cache with JDK marshaller? When marshaller is global, the answer is
> simple - BinaryObject is either available or not :)

Alexey, thanks for the taking the time to explain the reasoning!