CacheInterceptor ClassCastException in case of cache was updated from thin java client

[antonovsergey93]

Hello, Igniters!

I have ignite node with configured cache. The cache have cache interceptor.
I wiil got ClassCastException on cache interceptor, If I put some entry to
the cache (without keepBinary) from thin java client.

I think it's a bug. I'd like to find out yours view!

Also I made JIRA ticket with reproducer [1].

[1] https://issues.apache.org/jira/browse/IGNITE-10789

--
BR, Sergey Antonov

[antonovsergey93]

I did a little investigation. In o.a.i.i.p.p.c.c.ClientCacheRequest#cache()
enforced cache with keep binary. Why we should always work binary objects?

чт, 24 янв. 2019 г. в 12:29, Sergey Antonov <[hidden email]>:

> Hello, Igniters!
>
> I have ignite node with configured cache. The cache have cache
> interceptor. I wiil got ClassCastException on cache interceptor, If I put
> some entry to the cache (without keepBinary) from thin java client.
>
> I think it's a bug. I'd like to find out yours view!
>
> Also I made JIRA ticket with reproducer [1].
>
> [1] https://issues.apache.org/jira/browse/IGNITE-10789
>
> --
> BR, Sergey Antonov
>

--
BR, Sergey Antonov

[Pavel Tupitsyn]

Hi Sergey,

I don't think this is a bug.

Thick or thin clients always work in binary mode on server side, because
you receive data in serialized form and there is no point in deserializing
it.
Moreover, in most cases you don't have classes on the server, so binary
mode is the only way.

Interceptor should support both modes, binary or not. Any code can call
withKeepBinary(), this should be expected.
Just add if (x instanceof BinaryObject) and go from there.

Thanks,
Pavel

On Thu, Jan 24, 2019 at 12:38 PM Sergey Antonov <[hidden email]>
wrote:

> I did a little investigation. In o.a.i.i.p.p.c.c.ClientCacheRequest#cache()
> enforced cache with keep binary. Why we should always work binary objects?
>
> чт, 24 янв. 2019 г. в 12:29, Sergey Antonov <[hidden email]>:
>
> > Hello, Igniters!
> >
> > I have ignite node with configured cache. The cache have cache
> > interceptor. I wiil got ClassCastException on cache interceptor, If I put
> > some entry to the cache (without keepBinary) from thin java client.
> >
> > I think it's a bug. I'd like to find out yours view!
> >
> > Also I made JIRA ticket with reproducer [1].
> >
> > [1] https://issues.apache.org/jira/browse/IGNITE-10789
> >
> > --
> > BR, Sergey Antonov
> >
>
>
> --
> BR, Sergey Antonov
>

[antonovsergey93]

Hi, Pavel,

"Interceptor should support both modes, binary or not. Any code can call
withKeepBinary(), this should be expected.
Just add if (x instanceof BinaryObject) and go from there. "
I don't agree. The cache interceptor[1] is a parametrized class and you
couldn't pass multiple cache interceptors in cache configuration. So all
cache interceptors must have Object, Object parameters for supporting both
modes: binary and deserialized. In this case parametrized class no sense.

[1]
https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/cache/CacheInterceptor.html

чт, 24 янв. 2019 г. в 13:06, Pavel Tupitsyn <[hidden email]>:

> Hi Sergey,
>
> I don't think this is a bug.
>
> Thick or thin clients always work in binary mode on server side, because
> you receive data in serialized form and there is no point in deserializing
> it.
> Moreover, in most cases you don't have classes on the server, so binary
> mode is the only way.
>
> Interceptor should support both modes, binary or not. Any code can call
> withKeepBinary(), this should be expected.
> Just add if (x instanceof BinaryObject) and go from there.
>
> Thanks,
> Pavel
>
> On Thu, Jan 24, 2019 at 12:38 PM Sergey Antonov <[hidden email]
> >
> wrote:
>
> > I did a little investigation. In
> o.a.i.i.p.p.c.c.ClientCacheRequest#cache()
> > enforced cache with keep binary. Why we should always work binary
> objects?
> >
> > чт, 24 янв. 2019 г. в 12:29, Sergey Antonov <[hidden email]>:
> >
> > > Hello, Igniters!
> > >
> > > I have ignite node with configured cache. The cache have cache
> > > interceptor. I wiil got ClassCastException on cache interceptor, If I
> put
> > > some entry to the cache (without keepBinary) from thin java client.
> > >
> > > I think it's a bug. I'd like to find out yours view!
> > >
> > > Also I made JIRA ticket with reproducer [1].
> > >
> > > [1] https://issues.apache.org/jira/browse/IGNITE-10789
> > >
> > > --
> > > BR, Sergey Antonov
> > >
> >
> >
> > --
> > BR, Sergey Antonov
> >
>

--
BR, Sergey Antonov

[antonovsergey93]

Pavel, I agree your's points about working on server side in binary mode,
but we should add ability to proccessing data in deserialized form too. Of
course, it will add performance drop because of serialization round trip
(serialized -> deserialize -> serialized).

One of possible scenario: User wrote application on Clojure, but he want
use Ignite SQL with indexes. For solving problem he created pojo classes
and store them in the cache. The cache interceptor converts java -> clojure
in onGet() method, and clojure -> java in onBeforePut()/onBeforeRemove()
methods.

чт, 24 янв. 2019 г. в 13:16, Sergey Antonov <[hidden email]>:

> Hi, Pavel,
>
> "Interceptor should support both modes, binary or not. Any code can call
> withKeepBinary(), this should be expected.
> Just add if (x instanceof BinaryObject) and go from there. "
> I don't agree. The cache interceptor[1] is a parametrized class and you
> couldn't pass multiple cache interceptors in cache configuration. So all
> cache interceptors must have Object, Object parameters for supporting both
> modes: binary and deserialized. In this case parametrized class no sense.
>
> [1]
> https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/cache/CacheInterceptor.html
>
> чт, 24 янв. 2019 г. в 13:06, Pavel Tupitsyn <[hidden email]>:
>
>> Hi Sergey,
>>
>> I don't think this is a bug.
>>
>> Thick or thin clients always work in binary mode on server side, because
>> you receive data in serialized form and there is no point in deserializing
>> it.
>> Moreover, in most cases you don't have classes on the server, so binary
>> mode is the only way.
>>
>> Interceptor should support both modes, binary or not. Any code can call
>> withKeepBinary(), this should be expected.
>> Just add if (x instanceof BinaryObject) and go from there.
>>
>> Thanks,
>> Pavel
>>
>> On Thu, Jan 24, 2019 at 12:38 PM Sergey Antonov <
>> [hidden email]>
>> wrote:
>>
>> > I did a little investigation. In
>> o.a.i.i.p.p.c.c.ClientCacheRequest#cache()
>> > enforced cache with keep binary. Why we should always work binary
>> objects?
>> >
>> > чт, 24 янв. 2019 г. в 12:29, Sergey Antonov <[hidden email]
>> >:
>> >
>> > > Hello, Igniters!
>> > >
>> > > I have ignite node with configured cache. The cache have cache
>> > > interceptor. I wiil got ClassCastException on cache interceptor, If I
>> put
>> > > some entry to the cache (without keepBinary) from thin java client.
>> > >
>> > > I think it's a bug. I'd like to find out yours view!
>> > >
>> > > Also I made JIRA ticket with reproducer [1].
>> > >
>> > > [1] https://issues.apache.org/jira/browse/IGNITE-10789
>> > >
>> > > --
>> > > BR, Sergey Antonov
>> > >
>> >
>> >
>> > --
>> > BR, Sergey Antonov
>> >
>>
>
>
> --
> BR, Sergey Antonov
>

--
BR, Sergey Antonov

[Pavel Tupitsyn]

You are exactly right, generic parameters don't make much sense here.
Ignite caches are not restricted to any type, and there is type erasure in
Java so you have no runtime guarantees.

Maybe Interceptor design should be improved (e.g. add a flag to force
binary or non-binary mode),
but Thin or Thick client connector logic is unrelated here.
withKeepBinary() call is valid and should not depend on Interceptor
presence or implementation.

On Thu, Jan 24, 2019 at 1:17 PM Sergey Antonov <[hidden email]>
wrote:

> Hi, Pavel,
>
> "Interceptor should support both modes, binary or not. Any code can call
> withKeepBinary(), this should be expected.
> Just add if (x instanceof BinaryObject) and go from there. "
> I don't agree. The cache interceptor[1] is a parametrized class and you
> couldn't pass multiple cache interceptors in cache configuration. So all
> cache interceptors must have Object, Object parameters for supporting both
> modes: binary and deserialized. In this case parametrized class no sense.
>
> [1]
>
> https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/cache/CacheInterceptor.html
>
> чт, 24 янв. 2019 г. в 13:06, Pavel Tupitsyn <[hidden email]>:
>
> > Hi Sergey,
> >
> > I don't think this is a bug.
> >
> > Thick or thin clients always work in binary mode on server side, because
> > you receive data in serialized form and there is no point in
> deserializing
> > it.
> > Moreover, in most cases you don't have classes on the server, so binary
> > mode is the only way.
> >
> > Interceptor should support both modes, binary or not. Any code can call
> > withKeepBinary(), this should be expected.
> > Just add if (x instanceof BinaryObject) and go from there.
> >
> > Thanks,
> > Pavel
> >
> > On Thu, Jan 24, 2019 at 12:38 PM Sergey Antonov <
> [hidden email]
> > >
> > wrote:
> >
> > > I did a little investigation. In
> > o.a.i.i.p.p.c.c.ClientCacheRequest#cache()
> > > enforced cache with keep binary. Why we should always work binary
> > objects?
> > >
> > > чт, 24 янв. 2019 г. в 12:29, Sergey Antonov <[hidden email]
> >:
> > >
> > > > Hello, Igniters!
> > > >
> > > > I have ignite node with configured cache. The cache have cache
> > > > interceptor. I wiil got ClassCastException on cache interceptor, If I
> > put
> > > > some entry to the cache (without keepBinary) from thin java client.
> > > >
> > > > I think it's a bug. I'd like to find out yours view!
> > > >
> > > > Also I made JIRA ticket with reproducer [1].
> > > >
> > > > [1] https://issues.apache.org/jira/browse/IGNITE-10789
> > > >
> > > > --
> > > > BR, Sergey Antonov
> > > >
> > >
> > >
> > > --
> > > BR, Sergey Antonov
> > >
> >
>
>
> --
> BR, Sergey Antonov
>

[antonovsergey93]

Pavel, how about marker interface DeserializedValueCacheInterceptor? We
will deserialize data and pass it to cache interceptor, if CacheInterceptor
implements marker interface.

чт, 24 янв. 2019 г. в 13:41, Pavel Tupitsyn <[hidden email]>:

> You are exactly right, generic parameters don't make much sense here.
> Ignite caches are not restricted to any type, and there is type erasure in
> Java so you have no runtime guarantees.
>
> Maybe Interceptor design should be improved (e.g. add a flag to force
> binary or non-binary mode),
> but Thin or Thick client connector logic is unrelated here.
> withKeepBinary() call is valid and should not depend on Interceptor
> presence or implementation.
>
> On Thu, Jan 24, 2019 at 1:17 PM Sergey Antonov <[hidden email]>
> wrote:
>
> > Hi, Pavel,
> >
> > "Interceptor should support both modes, binary or not. Any code can call
> > withKeepBinary(), this should be expected.
> > Just add if (x instanceof BinaryObject) and go from there. "
> > I don't agree. The cache interceptor[1] is a parametrized class and you
> > couldn't pass multiple cache interceptors in cache configuration. So all
> > cache interceptors must have Object, Object parameters for supporting
> both
> > modes: binary and deserialized. In this case parametrized class no sense.
> >
> > [1]
> >
> >
> https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/cache/CacheInterceptor.html
> >
> > чт, 24 янв. 2019 г. в 13:06, Pavel Tupitsyn <[hidden email]>:
> >
> > > Hi Sergey,
> > >
> > > I don't think this is a bug.
> > >
> > > Thick or thin clients always work in binary mode on server side,
> because
> > > you receive data in serialized form and there is no point in
> > deserializing
> > > it.
> > > Moreover, in most cases you don't have classes on the server, so binary
> > > mode is the only way.
> > >
> > > Interceptor should support both modes, binary or not. Any code can call
> > > withKeepBinary(), this should be expected.
> > > Just add if (x instanceof BinaryObject) and go from there.
> > >
> > > Thanks,
> > > Pavel
> > >
> > > On Thu, Jan 24, 2019 at 12:38 PM Sergey Antonov <
> > [hidden email]
> > > >
> > > wrote:
> > >
> > > > I did a little investigation. In
> > > o.a.i.i.p.p.c.c.ClientCacheRequest#cache()
> > > > enforced cache with keep binary. Why we should always work binary
> > > objects?
> > > >
> > > > чт, 24 янв. 2019 г. в 12:29, Sergey Antonov <
> [hidden email]
> > >:
> > > >
> > > > > Hello, Igniters!
> > > > >
> > > > > I have ignite node with configured cache. The cache have cache
> > > > > interceptor. I wiil got ClassCastException on cache interceptor,
> If I
> > > put
> > > > > some entry to the cache (without keepBinary) from thin java client.
> > > > >
> > > > > I think it's a bug. I'd like to find out yours view!
> > > > >
> > > > > Also I made JIRA ticket with reproducer [1].
> > > > >
> > > > > [1] https://issues.apache.org/jira/browse/IGNITE-10789
> > > > >
> > > > > --
> > > > > BR, Sergey Antonov
> > > > >
> > > >
> > > >
> > > > --
> > > > BR, Sergey Antonov
> > > >
> > >
> >
> >
> > --
> > BR, Sergey Antonov
> >
>

--
BR, Sergey Antonov

[Pavel Tupitsyn]

I don't think we should complicate things. Leave it as is, use instanceof.
The fact is - you can get anything, BinaryObject or any user class, so be
prepared.
Good example of older API is CacheEvent, which actually has oldValue() and
newValue() as Object.

Igniters, any other thoughts?


On Thu, Jan 24, 2019 at 2:16 PM Sergey Antonov <[hidden email]>
wrote:

> Pavel, how about marker interface DeserializedValueCacheInterceptor? We
> will deserialize data and pass it to cache interceptor, if CacheInterceptor
> implements marker interface.
>
> чт, 24 янв. 2019 г. в 13:41, Pavel Tupitsyn <[hidden email]>:
>
> > You are exactly right, generic parameters don't make much sense here.
> > Ignite caches are not restricted to any type, and there is type erasure
> in
> > Java so you have no runtime guarantees.
> >
> > Maybe Interceptor design should be improved (e.g. add a flag to force
> > binary or non-binary mode),
> > but Thin or Thick client connector logic is unrelated here.
> > withKeepBinary() call is valid and should not depend on Interceptor
> > presence or implementation.
> >
> > On Thu, Jan 24, 2019 at 1:17 PM Sergey Antonov <
> [hidden email]>
> > wrote:
> >
> > > Hi, Pavel,
> > >
> > > "Interceptor should support both modes, binary or not. Any code can
> call
> > > withKeepBinary(), this should be expected.
> > > Just add if (x instanceof BinaryObject) and go from there. "
> > > I don't agree. The cache interceptor[1] is a parametrized class and you
> > > couldn't pass multiple cache interceptors in cache configuration. So
> all
> > > cache interceptors must have Object, Object parameters for supporting
> > both
> > > modes: binary and deserialized. In this case parametrized class no
> sense.
> > >
> > > [1]
> > >
> > >
> >
> https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/cache/CacheInterceptor.html
> > >
> > > чт, 24 янв. 2019 г. в 13:06, Pavel Tupitsyn <[hidden email]>:
> > >
> > > > Hi Sergey,
> > > >
> > > > I don't think this is a bug.
> > > >
> > > > Thick or thin clients always work in binary mode on server side,
> > because
> > > > you receive data in serialized form and there is no point in
> > > deserializing
> > > > it.
> > > > Moreover, in most cases you don't have classes on the server, so
> binary
> > > > mode is the only way.
> > > >
> > > > Interceptor should support both modes, binary or not. Any code can
> call
> > > > withKeepBinary(), this should be expected.
> > > > Just add if (x instanceof BinaryObject) and go from there.
> > > >
> > > > Thanks,
> > > > Pavel
> > > >
> > > > On Thu, Jan 24, 2019 at 12:38 PM Sergey Antonov <
> > > [hidden email]
> > > > >
> > > > wrote:
> > > >
> > > > > I did a little investigation. In
> > > > o.a.i.i.p.p.c.c.ClientCacheRequest#cache()
> > > > > enforced cache with keep binary. Why we should always work binary
> > > > objects?
> > > > >
> > > > > чт, 24 янв. 2019 г. в 12:29, Sergey Antonov <
> > [hidden email]
> > > >:
> > > > >
> > > > > > Hello, Igniters!
> > > > > >
> > > > > > I have ignite node with configured cache. The cache have cache
> > > > > > interceptor. I wiil got ClassCastException on cache interceptor,
> > If I
> > > > put
> > > > > > some entry to the cache (without keepBinary) from thin java
> client.
> > > > > >
> > > > > > I think it's a bug. I'd like to find out yours view!
> > > > > >
> > > > > > Also I made JIRA ticket with reproducer [1].
> > > > > >
> > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-10789
> > > > > >
> > > > > > --
> > > > > > BR, Sergey Antonov
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > BR, Sergey Antonov
> > > > >
> > > >
> > >
> > >
> > > --
> > > BR, Sergey Antonov
> > >
> >
>
>
> --
> BR, Sergey Antonov
>

[antonovsergey93]

Pavel,

"Leave it as is, use instanceof."
You meant always use CacheInterceptor<Object, Object> and in all methods
check, that passed arguments is BinaryObject?

чт, 24 янв. 2019 г. в 17:10, Pavel Tupitsyn <[hidden email]>:

> I don't think we should complicate things. Leave it as is, use instanceof.
> The fact is - you can get anything, BinaryObject or any user class, so be
> prepared.
> Good example of older API is CacheEvent, which actually has oldValue() and
> newValue() as Object.
>
> Igniters, any other thoughts?
>
>
> On Thu, Jan 24, 2019 at 2:16 PM Sergey Antonov <[hidden email]>
> wrote:
>
> > Pavel, how about marker interface DeserializedValueCacheInterceptor? We
> > will deserialize data and pass it to cache interceptor, if
> CacheInterceptor
> > implements marker interface.
> >
> > чт, 24 янв. 2019 г. в 13:41, Pavel Tupitsyn <[hidden email]>:
> >
> > > You are exactly right, generic parameters don't make much sense here.
> > > Ignite caches are not restricted to any type, and there is type erasure
> > in
> > > Java so you have no runtime guarantees.
> > >
> > > Maybe Interceptor design should be improved (e.g. add a flag to force
> > > binary or non-binary mode),
> > > but Thin or Thick client connector logic is unrelated here.
> > > withKeepBinary() call is valid and should not depend on Interceptor
> > > presence or implementation.
> > >
> > > On Thu, Jan 24, 2019 at 1:17 PM Sergey Antonov <
> > [hidden email]>
> > > wrote:
> > >
> > > > Hi, Pavel,
> > > >
> > > > "Interceptor should support both modes, binary or not. Any code can
> > call
> > > > withKeepBinary(), this should be expected.
> > > > Just add if (x instanceof BinaryObject) and go from there. "
> > > > I don't agree. The cache interceptor[1] is a parametrized class and
> you
> > > > couldn't pass multiple cache interceptors in cache configuration. So
> > all
> > > > cache interceptors must have Object, Object parameters for supporting
> > > both
> > > > modes: binary and deserialized. In this case parametrized class no
> > sense.
> > > >
> > > > [1]
> > > >
> > > >
> > >
> >
> https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/cache/CacheInterceptor.html
> > > >
> > > > чт, 24 янв. 2019 г. в 13:06, Pavel Tupitsyn <[hidden email]>:
> > > >
> > > > > Hi Sergey,
> > > > >
> > > > > I don't think this is a bug.
> > > > >
> > > > > Thick or thin clients always work in binary mode on server side,
> > > because
> > > > > you receive data in serialized form and there is no point in
> > > > deserializing
> > > > > it.
> > > > > Moreover, in most cases you don't have classes on the server, so
> > binary
> > > > > mode is the only way.
> > > > >
> > > > > Interceptor should support both modes, binary or not. Any code can
> > call
> > > > > withKeepBinary(), this should be expected.
> > > > > Just add if (x instanceof BinaryObject) and go from there.
> > > > >
> > > > > Thanks,
> > > > > Pavel
> > > > >
> > > > > On Thu, Jan 24, 2019 at 12:38 PM Sergey Antonov <
> > > > [hidden email]
> > > > > >
> > > > > wrote:
> > > > >
> > > > > > I did a little investigation. In
> > > > > o.a.i.i.p.p.c.c.ClientCacheRequest#cache()
> > > > > > enforced cache with keep binary. Why we should always work binary
> > > > > objects?
> > > > > >
> > > > > > чт, 24 янв. 2019 г. в 12:29, Sergey Antonov <
> > > [hidden email]
> > > > >:
> > > > > >
> > > > > > > Hello, Igniters!
> > > > > > >
> > > > > > > I have ignite node with configured cache. The cache have cache
> > > > > > > interceptor. I wiil got ClassCastException on cache
> interceptor,
> > > If I
> > > > > put
> > > > > > > some entry to the cache (without keepBinary) from thin java
> > client.
> > > > > > >
> > > > > > > I think it's a bug. I'd like to find out yours view!
> > > > > > >
> > > > > > > Also I made JIRA ticket with reproducer [1].
> > > > > > >
> > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-10789
> > > > > > >
> > > > > > > --
> > > > > > > BR, Sergey Antonov
> > > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > BR, Sergey Antonov
> > > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > BR, Sergey Antonov
> > > >
> > >
> >
> >
> > --
> > BR, Sergey Antonov
> >
>

--
BR, Sergey Antonov

[Pavel Tupitsyn]

Yes

On Thu, Jan 24, 2019 at 5:15 PM Sergey Antonov <[hidden email]>
wrote:

> Pavel,
>
> "Leave it as is, use instanceof."
> You meant always use CacheInterceptor<Object, Object> and in all methods
> check, that passed arguments is BinaryObject?
>
> чт, 24 янв. 2019 г. в 17:10, Pavel Tupitsyn <[hidden email]>:
>
> > I don't think we should complicate things. Leave it as is, use
> instanceof.
> > The fact is - you can get anything, BinaryObject or any user class, so be
> > prepared.
> > Good example of older API is CacheEvent, which actually has oldValue()
> and
> > newValue() as Object.
> >
> > Igniters, any other thoughts?
> >
> >
> > On Thu, Jan 24, 2019 at 2:16 PM Sergey Antonov <
> [hidden email]>
> > wrote:
> >
> > > Pavel, how about marker interface DeserializedValueCacheInterceptor? We
> > > will deserialize data and pass it to cache interceptor, if
> > CacheInterceptor
> > > implements marker interface.
> > >
> > > чт, 24 янв. 2019 г. в 13:41, Pavel Tupitsyn <[hidden email]>:
> > >
> > > > You are exactly right, generic parameters don't make much sense here.
> > > > Ignite caches are not restricted to any type, and there is type
> erasure
> > > in
> > > > Java so you have no runtime guarantees.
> > > >
> > > > Maybe Interceptor design should be improved (e.g. add a flag to force
> > > > binary or non-binary mode),
> > > > but Thin or Thick client connector logic is unrelated here.
> > > > withKeepBinary() call is valid and should not depend on Interceptor
> > > > presence or implementation.
> > > >
> > > > On Thu, Jan 24, 2019 at 1:17 PM Sergey Antonov <
> > > [hidden email]>
> > > > wrote:
> > > >
> > > > > Hi, Pavel,
> > > > >
> > > > > "Interceptor should support both modes, binary or not. Any code can
> > > call
> > > > > withKeepBinary(), this should be expected.
> > > > > Just add if (x instanceof BinaryObject) and go from there. "
> > > > > I don't agree. The cache interceptor[1] is a parametrized class and
> > you
> > > > > couldn't pass multiple cache interceptors in cache configuration.
> So
> > > all
> > > > > cache interceptors must have Object, Object parameters for
> supporting
> > > > both
> > > > > modes: binary and deserialized. In this case parametrized class no
> > > sense.
> > > > >
> > > > > [1]
> > > > >
> > > > >
> > > >
> > >
> >
> https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/cache/CacheInterceptor.html
> > > > >
> > > > > чт, 24 янв. 2019 г. в 13:06, Pavel Tupitsyn <[hidden email]
> >:
> > > > >
> > > > > > Hi Sergey,
> > > > > >
> > > > > > I don't think this is a bug.
> > > > > >
> > > > > > Thick or thin clients always work in binary mode on server side,
> > > > because
> > > > > > you receive data in serialized form and there is no point in
> > > > > deserializing
> > > > > > it.
> > > > > > Moreover, in most cases you don't have classes on the server, so
> > > binary
> > > > > > mode is the only way.
> > > > > >
> > > > > > Interceptor should support both modes, binary or not. Any code
> can
> > > call
> > > > > > withKeepBinary(), this should be expected.
> > > > > > Just add if (x instanceof BinaryObject) and go from there.
> > > > > >
> > > > > > Thanks,
> > > > > > Pavel
> > > > > >
> > > > > > On Thu, Jan 24, 2019 at 12:38 PM Sergey Antonov <
> > > > > [hidden email]
> > > > > > >
> > > > > > wrote:
> > > > > >
> > > > > > > I did a little investigation. In
> > > > > > o.a.i.i.p.p.c.c.ClientCacheRequest#cache()
> > > > > > > enforced cache with keep binary. Why we should always work
> binary
> > > > > > objects?
> > > > > > >
> > > > > > > чт, 24 янв. 2019 г. в 12:29, Sergey Antonov <
> > > > [hidden email]
> > > > > >:
> > > > > > >
> > > > > > > > Hello, Igniters!
> > > > > > > >
> > > > > > > > I have ignite node with configured cache. The cache have
> cache
> > > > > > > > interceptor. I wiil got ClassCastException on cache
> > interceptor,
> > > > If I
> > > > > > put
> > > > > > > > some entry to the cache (without keepBinary) from thin java
> > > client.
> > > > > > > >
> > > > > > > > I think it's a bug. I'd like to find out yours view!
> > > > > > > >
> > > > > > > > Also I made JIRA ticket with reproducer [1].
> > > > > > > >
> > > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-10789
> > > > > > > >
> > > > > > > > --
> > > > > > > > BR, Sergey Antonov
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > BR, Sergey Antonov
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > BR, Sergey Antonov
> > > > >
> > > >
> > >
> > >
> > > --
> > > BR, Sergey Antonov
> > >
> >
>
>
> --
> BR, Sergey Antonov
>

[antonovsergey93]

I think it's bad idea. This contract nowhere defined and it's not clear for
users.

чт, 24 янв. 2019 г. в 17:18, Pavel Tupitsyn <[hidden email]>:

> Yes
>
> On Thu, Jan 24, 2019 at 5:15 PM Sergey Antonov <[hidden email]>
> wrote:
>
> > Pavel,
> >
> > "Leave it as is, use instanceof."
> > You meant always use CacheInterceptor<Object, Object> and in all methods
> > check, that passed arguments is BinaryObject?
> >
> > чт, 24 янв. 2019 г. в 17:10, Pavel Tupitsyn <[hidden email]>:
> >
> > > I don't think we should complicate things. Leave it as is, use
> > instanceof.
> > > The fact is - you can get anything, BinaryObject or any user class, so
> be
> > > prepared.
> > > Good example of older API is CacheEvent, which actually has oldValue()
> > and
> > > newValue() as Object.
> > >
> > > Igniters, any other thoughts?
> > >
> > >
> > > On Thu, Jan 24, 2019 at 2:16 PM Sergey Antonov <
> > [hidden email]>
> > > wrote:
> > >
> > > > Pavel, how about marker interface DeserializedValueCacheInterceptor?
> We
> > > > will deserialize data and pass it to cache interceptor, if
> > > CacheInterceptor
> > > > implements marker interface.
> > > >
> > > > чт, 24 янв. 2019 г. в 13:41, Pavel Tupitsyn <[hidden email]>:
> > > >
> > > > > You are exactly right, generic parameters don't make much sense
> here.
> > > > > Ignite caches are not restricted to any type, and there is type
> > erasure
> > > > in
> > > > > Java so you have no runtime guarantees.
> > > > >
> > > > > Maybe Interceptor design should be improved (e.g. add a flag to
> force
> > > > > binary or non-binary mode),
> > > > > but Thin or Thick client connector logic is unrelated here.
> > > > > withKeepBinary() call is valid and should not depend on Interceptor
> > > > > presence or implementation.
> > > > >
> > > > > On Thu, Jan 24, 2019 at 1:17 PM Sergey Antonov <
> > > > [hidden email]>
> > > > > wrote:
> > > > >
> > > > > > Hi, Pavel,
> > > > > >
> > > > > > "Interceptor should support both modes, binary or not. Any code
> can
> > > > call
> > > > > > withKeepBinary(), this should be expected.
> > > > > > Just add if (x instanceof BinaryObject) and go from there. "
> > > > > > I don't agree. The cache interceptor[1] is a parametrized class
> and
> > > you
> > > > > > couldn't pass multiple cache interceptors in cache configuration.
> > So
> > > > all
> > > > > > cache interceptors must have Object, Object parameters for
> > supporting
> > > > > both
> > > > > > modes: binary and deserialized. In this case parametrized class
> no
> > > > sense.
> > > > > >
> > > > > > [1]
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/cache/CacheInterceptor.html
> > > > > >
> > > > > > чт, 24 янв. 2019 г. в 13:06, Pavel Tupitsyn <
> [hidden email]
> > >:
> > > > > >
> > > > > > > Hi Sergey,
> > > > > > >
> > > > > > > I don't think this is a bug.
> > > > > > >
> > > > > > > Thick or thin clients always work in binary mode on server
> side,
> > > > > because
> > > > > > > you receive data in serialized form and there is no point in
> > > > > > deserializing
> > > > > > > it.
> > > > > > > Moreover, in most cases you don't have classes on the server,
> so
> > > > binary
> > > > > > > mode is the only way.
> > > > > > >
> > > > > > > Interceptor should support both modes, binary or not. Any code
> > can
> > > > call
> > > > > > > withKeepBinary(), this should be expected.
> > > > > > > Just add if (x instanceof BinaryObject) and go from there.
> > > > > > >
> > > > > > > Thanks,
> > > > > > > Pavel
> > > > > > >
> > > > > > > On Thu, Jan 24, 2019 at 12:38 PM Sergey Antonov <
> > > > > > [hidden email]
> > > > > > > >
> > > > > > > wrote:
> > > > > > >
> > > > > > > > I did a little investigation. In
> > > > > > > o.a.i.i.p.p.c.c.ClientCacheRequest#cache()
> > > > > > > > enforced cache with keep binary. Why we should always work
> > binary
> > > > > > > objects?
> > > > > > > >
> > > > > > > > чт, 24 янв. 2019 г. в 12:29, Sergey Antonov <
> > > > > [hidden email]
> > > > > > >:
> > > > > > > >
> > > > > > > > > Hello, Igniters!
> > > > > > > > >
> > > > > > > > > I have ignite node with configured cache. The cache have
> > cache
> > > > > > > > > interceptor. I wiil got ClassCastException on cache
> > > interceptor,
> > > > > If I
> > > > > > > put
> > > > > > > > > some entry to the cache (without keepBinary) from thin java
> > > > client.
> > > > > > > > >
> > > > > > > > > I think it's a bug. I'd like to find out yours view!
> > > > > > > > >
> > > > > > > > > Also I made JIRA ticket with reproducer [1].
> > > > > > > > >
> > > > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-10789
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > BR, Sergey Antonov
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > BR, Sergey Antonov
> > > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > BR, Sergey Antonov
> > > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > BR, Sergey Antonov
> > > >
> > >
> >
> >
> > --
> > BR, Sergey Antonov
> >
>

--
BR, Sergey Antonov

[Ivan Pavlukhin]

Sergey,

There are couple of things which should be addressed:
1. Unnecessary deserialization.
2. Inconsistent behavior.
3. Unclear documentation.

Deserialization is not free and in my mind should be avoided where possible. I think that if some feature (like interceptors) requires deserialization then it should be enabled explicitly and an impact should be clear to user. I can imagine a toggle “withAllowedDeserialization”.

If there is an inconsistency between thick and thin clients it should be eliminated. I do not see a reason why behavior should be different.

If something is a good thing but it is not intuitive it could be documented. But if there is s really good reason for it. Otherwise simplicity and consistency are better alias.

> On 24 Jan 2019, at 17:42, Sergey Antonov <[hidden email]> wrote:
>
> I think it's bad idea. This contract nowhere defined and it's not clear for
> users.
>
> чт, 24 янв. 2019 г. в 17:18, Pavel Tupitsyn <[hidden email]>:
>
>> Yes
>>
>> On Thu, Jan 24, 2019 at 5:15 PM Sergey Antonov <[hidden email]>
>> wrote:
>>
>>> Pavel,
>>>
>>> "Leave it as is, use instanceof."
>>> You meant always use CacheInterceptor<Object, Object> and in all methods
>>> check, that passed arguments is BinaryObject?
>>>
>>> чт, 24 янв. 2019 г. в 17:10, Pavel Tupitsyn <[hidden email]>:
>>>
>>>> I don't think we should complicate things. Leave it as is, use
>>> instanceof.
>>>> The fact is - you can get anything, BinaryObject or any user class, so
>> be
>>>> prepared.
>>>> Good example of older API is CacheEvent, which actually has oldValue()
>>> and
>>>> newValue() as Object.
>>>>
>>>> Igniters, any other thoughts?
>>>>
>>>>
>>>> On Thu, Jan 24, 2019 at 2:16 PM Sergey Antonov <
>>> [hidden email]>
>>>> wrote:
>>>>
>>>>> Pavel, how about marker interface DeserializedValueCacheInterceptor?
>> We
>>>>> will deserialize data and pass it to cache interceptor, if
>>>> CacheInterceptor
>>>>> implements marker interface.
>>>>>
>>>>> чт, 24 янв. 2019 г. в 13:41, Pavel Tupitsyn <[hidden email]>:
>>>>>
>>>>>> You are exactly right, generic parameters don't make much sense
>> here.
>>>>>> Ignite caches are not restricted to any type, and there is type
>>> erasure
>>>>> in
>>>>>> Java so you have no runtime guarantees.
>>>>>>
>>>>>> Maybe Interceptor design should be improved (e.g. add a flag to
>> force
>>>>>> binary or non-binary mode),
>>>>>> but Thin or Thick client connector logic is unrelated here.
>>>>>> withKeepBinary() call is valid and should not depend on Interceptor
>>>>>> presence or implementation.
>>>>>>
>>>>>> On Thu, Jan 24, 2019 at 1:17 PM Sergey Antonov <
>>>>> [hidden email]>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi, Pavel,
>>>>>>>
>>>>>>> "Interceptor should support both modes, binary or not. Any code
>> can
>>>>> call
>>>>>>> withKeepBinary(), this should be expected.
>>>>>>> Just add if (x instanceof BinaryObject) and go from there. "
>>>>>>> I don't agree. The cache interceptor[1] is a parametrized class
>> and
>>>> you
>>>>>>> couldn't pass multiple cache interceptors in cache configuration.
>>> So
>>>>> all
>>>>>>> cache interceptors must have Object, Object parameters for
>>> supporting
>>>>>> both
>>>>>>> modes: binary and deserialized. In this case parametrized class
>> no
>>>>> sense.
>>>>>>>
>>>>>>> [1]
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>> https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/cache/CacheInterceptor.html
>>>>>>>
>>>>>>> чт, 24 янв. 2019 г. в 13:06, Pavel Tupitsyn <
>> [hidden email]
>>>> :
>>>>>>>
>>>>>>>> Hi Sergey,
>>>>>>>>
>>>>>>>> I don't think this is a bug.
>>>>>>>>
>>>>>>>> Thick or thin clients always work in binary mode on server
>> side,
>>>>>> because
>>>>>>>> you receive data in serialized form and there is no point in
>>>>>>> deserializing
>>>>>>>> it.
>>>>>>>> Moreover, in most cases you don't have classes on the server,
>> so
>>>>> binary
>>>>>>>> mode is the only way.
>>>>>>>>
>>>>>>>> Interceptor should support both modes, binary or not. Any code
>>> can
>>>>> call
>>>>>>>> withKeepBinary(), this should be expected.
>>>>>>>> Just add if (x instanceof BinaryObject) and go from there.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Pavel
>>>>>>>>
>>>>>>>> On Thu, Jan 24, 2019 at 12:38 PM Sergey Antonov <
>>>>>>> [hidden email]
>>>>>>>>>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> I did a little investigation. In
>>>>>>>> o.a.i.i.p.p.c.c.ClientCacheRequest#cache()
>>>>>>>>> enforced cache with keep binary. Why we should always work
>>> binary
>>>>>>>> objects?
>>>>>>>>>
>>>>>>>>> чт, 24 янв. 2019 г. в 12:29, Sergey Antonov <
>>>>>> [hidden email]
>>>>>>>> :
>>>>>>>>>
>>>>>>>>>> Hello, Igniters!
>>>>>>>>>>
>>>>>>>>>> I have ignite node with configured cache. The cache have
>>> cache
>>>>>>>>>> interceptor. I wiil got ClassCastException on cache
>>>> interceptor,
>>>>>> If I
>>>>>>>> put
>>>>>>>>>> some entry to the cache (without keepBinary) from thin java
>>>>> client.
>>>>>>>>>>
>>>>>>>>>> I think it's a bug. I'd like to find out yours view!
>>>>>>>>>>
>>>>>>>>>> Also I made JIRA ticket with reproducer [1].
>>>>>>>>>>
>>>>>>>>>> [1] https://issues.apache.org/jira/browse/IGNITE-10789
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> BR, Sergey Antonov
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> BR, Sergey Antonov
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> BR, Sergey Antonov
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> BR, Sergey Antonov
>>>>>
>>>>
>>>
>>>
>>> --
>>> BR, Sergey Antonov
>>>
>>
>
>
> --
> BR, Sergey Antonov

[Pavel Tupitsyn]

Ivan,

There is no inconsistency between thick and thin clients.
All of them work with caches in binary mode, see ClientCacheRequest (thin)
and PlatformCache (thick) classes.

On Thu, Jan 24, 2019 at 10:26 PM Ivan Pavlukhina <[hidden email]>
wrote:

> Sergey,
>
> There are couple of things which should be addressed:
> 1. Unnecessary deserialization.
> 2. Inconsistent behavior.
> 3. Unclear documentation.
>
> Deserialization is not free and in my mind should be avoided where
> possible. I think that if some feature (like interceptors) requires
> deserialization then it should be enabled explicitly and an impact should
> be clear to user. I can imagine a toggle “withAllowedDeserialization”.
>
> If there is an inconsistency between thick and thin clients it should be
> eliminated. I do not see a reason why behavior should be different.
>
> If something is a good thing but it is not intuitive it could be
> documented. But if there is s really good reason for it. Otherwise
> simplicity and consistency are better alias.
>
> > On 24 Jan 2019, at 17:42, Sergey Antonov <[hidden email]>
> wrote:
> >
> > I think it's bad idea. This contract nowhere defined and it's not clear
> for
> > users.
> >
> > чт, 24 янв. 2019 г. в 17:18, Pavel Tupitsyn <[hidden email]>:
> >
> >> Yes
> >>
> >> On Thu, Jan 24, 2019 at 5:15 PM Sergey Antonov <
> [hidden email]>
> >> wrote:
> >>
> >>> Pavel,
> >>>
> >>> "Leave it as is, use instanceof."
> >>> You meant always use CacheInterceptor<Object, Object> and in all
> methods
> >>> check, that passed arguments is BinaryObject?
> >>>
> >>> чт, 24 янв. 2019 г. в 17:10, Pavel Tupitsyn <[hidden email]>:
> >>>
> >>>> I don't think we should complicate things. Leave it as is, use
> >>> instanceof.
> >>>> The fact is - you can get anything, BinaryObject or any user class, so
> >> be
> >>>> prepared.
> >>>> Good example of older API is CacheEvent, which actually has oldValue()
> >>> and
> >>>> newValue() as Object.
> >>>>
> >>>> Igniters, any other thoughts?
> >>>>
> >>>>
> >>>> On Thu, Jan 24, 2019 at 2:16 PM Sergey Antonov <
> >>> [hidden email]>
> >>>> wrote:
> >>>>
> >>>>> Pavel, how about marker interface DeserializedValueCacheInterceptor?
> >> We
> >>>>> will deserialize data and pass it to cache interceptor, if
> >>>> CacheInterceptor
> >>>>> implements marker interface.
> >>>>>
> >>>>> чт, 24 янв. 2019 г. в 13:41, Pavel Tupitsyn <[hidden email]>:
> >>>>>
> >>>>>> You are exactly right, generic parameters don't make much sense
> >> here.
> >>>>>> Ignite caches are not restricted to any type, and there is type
> >>> erasure
> >>>>> in
> >>>>>> Java so you have no runtime guarantees.
> >>>>>>
> >>>>>> Maybe Interceptor design should be improved (e.g. add a flag to
> >> force
> >>>>>> binary or non-binary mode),
> >>>>>> but Thin or Thick client connector logic is unrelated here.
> >>>>>> withKeepBinary() call is valid and should not depend on Interceptor
> >>>>>> presence or implementation.
> >>>>>>
> >>>>>> On Thu, Jan 24, 2019 at 1:17 PM Sergey Antonov <
> >>>>> [hidden email]>
> >>>>>> wrote:
> >>>>>>
> >>>>>>> Hi, Pavel,
> >>>>>>>
> >>>>>>> "Interceptor should support both modes, binary or not. Any code
> >> can
> >>>>> call
> >>>>>>> withKeepBinary(), this should be expected.
> >>>>>>> Just add if (x instanceof BinaryObject) and go from there. "
> >>>>>>> I don't agree. The cache interceptor[1] is a parametrized class
> >> and
> >>>> you
> >>>>>>> couldn't pass multiple cache interceptors in cache configuration.
> >>> So
> >>>>> all
> >>>>>>> cache interceptors must have Object, Object parameters for
> >>> supporting
> >>>>>> both
> >>>>>>> modes: binary and deserialized. In this case parametrized class
> >> no
> >>>>> sense.
> >>>>>>>
> >>>>>>> [1]
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/cache/CacheInterceptor.html
> >>>>>>>
> >>>>>>> чт, 24 янв. 2019 г. в 13:06, Pavel Tupitsyn <
> >> [hidden email]
> >>>> :
> >>>>>>>
> >>>>>>>> Hi Sergey,
> >>>>>>>>
> >>>>>>>> I don't think this is a bug.
> >>>>>>>>
> >>>>>>>> Thick or thin clients always work in binary mode on server
> >> side,
> >>>>>> because
> >>>>>>>> you receive data in serialized form and there is no point in
> >>>>>>> deserializing
> >>>>>>>> it.
> >>>>>>>> Moreover, in most cases you don't have classes on the server,
> >> so
> >>>>> binary
> >>>>>>>> mode is the only way.
> >>>>>>>>
> >>>>>>>> Interceptor should support both modes, binary or not. Any code
> >>> can
> >>>>> call
> >>>>>>>> withKeepBinary(), this should be expected.
> >>>>>>>> Just add if (x instanceof BinaryObject) and go from there.
> >>>>>>>>
> >>>>>>>> Thanks,
> >>>>>>>> Pavel
> >>>>>>>>
> >>>>>>>> On Thu, Jan 24, 2019 at 12:38 PM Sergey Antonov <
> >>>>>>> [hidden email]
> >>>>>>>>>
> >>>>>>>> wrote:
> >>>>>>>>
> >>>>>>>>> I did a little investigation. In
> >>>>>>>> o.a.i.i.p.p.c.c.ClientCacheRequest#cache()
> >>>>>>>>> enforced cache with keep binary. Why we should always work
> >>> binary
> >>>>>>>> objects?
> >>>>>>>>>
> >>>>>>>>> чт, 24 янв. 2019 г. в 12:29, Sergey Antonov <
> >>>>>> [hidden email]
> >>>>>>>> :
> >>>>>>>>>
> >>>>>>>>>> Hello, Igniters!
> >>>>>>>>>>
> >>>>>>>>>> I have ignite node with configured cache. The cache have
> >>> cache
> >>>>>>>>>> interceptor. I wiil got ClassCastException on cache
> >>>> interceptor,
> >>>>>> If I
> >>>>>>>> put
> >>>>>>>>>> some entry to the cache (without keepBinary) from thin java
> >>>>> client.
> >>>>>>>>>>
> >>>>>>>>>> I think it's a bug. I'd like to find out yours view!
> >>>>>>>>>>
> >>>>>>>>>> Also I made JIRA ticket with reproducer [1].
> >>>>>>>>>>
> >>>>>>>>>> [1] https://issues.apache.org/jira/browse/IGNITE-10789
> >>>>>>>>>>
> >>>>>>>>>> --
> >>>>>>>>>> BR, Sergey Antonov
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> --
> >>>>>>>>> BR, Sergey Antonov
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> --
> >>>>>>> BR, Sergey Antonov
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> BR, Sergey Antonov
> >>>>>
> >>>>
> >>>
> >>>
> >>> --
> >>> BR, Sergey Antonov
> >>>
> >>
> >
> >
> > --
> > BR, Sergey Antonov
>

[Ivan Pavlukhin]

Pavel,

Initially I meant Java thick client. And I see the difference between
thin and thick Java clients. As was already mentioned thin Java client
behaves in way like each cache is enforced to not unwrap binary
objects (withKeepBinary()). You can see a test demonstrating current
behavior [1].

[1] https://gist.github.com/pavlukhin/2c76d11cde5243a73f01019cdd15d243

чт, 24 янв. 2019 г. в 23:01, Pavel Tupitsyn <[hidden email]>:

>
> Ivan,
>
> There is no inconsistency between thick and thin clients.
> All of them work with caches in binary mode, see ClientCacheRequest (thin)
> and PlatformCache (thick) classes.
>
> On Thu, Jan 24, 2019 at 10:26 PM Ivan Pavlukhina <[hidden email]>
> wrote:
>
> > Sergey,
> >
> > There are couple of things which should be addressed:
> > 1. Unnecessary deserialization.
> > 2. Inconsistent behavior.
> > 3. Unclear documentation.
> >
> > Deserialization is not free and in my mind should be avoided where
> > possible. I think that if some feature (like interceptors) requires
> > deserialization then it should be enabled explicitly and an impact should
> > be clear to user. I can imagine a toggle “withAllowedDeserialization”.
> >
> > If there is an inconsistency between thick and thin clients it should be
> > eliminated. I do not see a reason why behavior should be different.
> >
> > If something is a good thing but it is not intuitive it could be
> > documented. But if there is s really good reason for it. Otherwise
> > simplicity and consistency are better alias.
> >
> > > On 24 Jan 2019, at 17:42, Sergey Antonov <[hidden email]>
> > wrote:
> > >
> > > I think it's bad idea. This contract nowhere defined and it's not clear
> > for
> > > users.
> > >
> > > чт, 24 янв. 2019 г. в 17:18, Pavel Tupitsyn <[hidden email]>:
> > >
> > >> Yes
> > >>
> > >> On Thu, Jan 24, 2019 at 5:15 PM Sergey Antonov <
> > [hidden email]>
> > >> wrote:
> > >>
> > >>> Pavel,
> > >>>
> > >>> "Leave it as is, use instanceof."
> > >>> You meant always use CacheInterceptor<Object, Object> and in all
> > methods
> > >>> check, that passed arguments is BinaryObject?
> > >>>
> > >>> чт, 24 янв. 2019 г. в 17:10, Pavel Tupitsyn <[hidden email]>:
> > >>>
> > >>>> I don't think we should complicate things. Leave it as is, use
> > >>> instanceof.
> > >>>> The fact is - you can get anything, BinaryObject or any user class, so
> > >> be
> > >>>> prepared.
> > >>>> Good example of older API is CacheEvent, which actually has oldValue()
> > >>> and
> > >>>> newValue() as Object.
> > >>>>
> > >>>> Igniters, any other thoughts?
> > >>>>
> > >>>>
> > >>>> On Thu, Jan 24, 2019 at 2:16 PM Sergey Antonov <
> > >>> [hidden email]>
> > >>>> wrote:
> > >>>>
> > >>>>> Pavel, how about marker interface DeserializedValueCacheInterceptor?
> > >> We
> > >>>>> will deserialize data and pass it to cache interceptor, if
> > >>>> CacheInterceptor
> > >>>>> implements marker interface.
> > >>>>>
> > >>>>> чт, 24 янв. 2019 г. в 13:41, Pavel Tupitsyn <[hidden email]>:
> > >>>>>
> > >>>>>> You are exactly right, generic parameters don't make much sense
> > >> here.
> > >>>>>> Ignite caches are not restricted to any type, and there is type
> > >>> erasure
> > >>>>> in
> > >>>>>> Java so you have no runtime guarantees.
> > >>>>>>
> > >>>>>> Maybe Interceptor design should be improved (e.g. add a flag to
> > >> force
> > >>>>>> binary or non-binary mode),
> > >>>>>> but Thin or Thick client connector logic is unrelated here.
> > >>>>>> withKeepBinary() call is valid and should not depend on Interceptor
> > >>>>>> presence or implementation.
> > >>>>>>
> > >>>>>> On Thu, Jan 24, 2019 at 1:17 PM Sergey Antonov <
> > >>>>> [hidden email]>
> > >>>>>> wrote:
> > >>>>>>
> > >>>>>>> Hi, Pavel,
> > >>>>>>>
> > >>>>>>> "Interceptor should support both modes, binary or not. Any code
> > >> can
> > >>>>> call
> > >>>>>>> withKeepBinary(), this should be expected.
> > >>>>>>> Just add if (x instanceof BinaryObject) and go from there. "
> > >>>>>>> I don't agree. The cache interceptor[1] is a parametrized class
> > >> and
> > >>>> you
> > >>>>>>> couldn't pass multiple cache interceptors in cache configuration.
> > >>> So
> > >>>>> all
> > >>>>>>> cache interceptors must have Object, Object parameters for
> > >>> supporting
> > >>>>>> both
> > >>>>>>> modes: binary and deserialized. In this case parametrized class
> > >> no
> > >>>>> sense.
> > >>>>>>>
> > >>>>>>> [1]
> > >>>>>>>
> > >>>>>>>
> > >>>>>>
> > >>>>>
> > >>>>
> > >>>
> > >>
> > https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/cache/CacheInterceptor.html
> > >>>>>>>
> > >>>>>>> чт, 24 янв. 2019 г. в 13:06, Pavel Tupitsyn <
> > >> [hidden email]
> > >>>> :
> > >>>>>>>
> > >>>>>>>> Hi Sergey,
> > >>>>>>>>
> > >>>>>>>> I don't think this is a bug.
> > >>>>>>>>
> > >>>>>>>> Thick or thin clients always work in binary mode on server
> > >> side,
> > >>>>>> because
> > >>>>>>>> you receive data in serialized form and there is no point in
> > >>>>>>> deserializing
> > >>>>>>>> it.
> > >>>>>>>> Moreover, in most cases you don't have classes on the server,
> > >> so
> > >>>>> binary
> > >>>>>>>> mode is the only way.
> > >>>>>>>>
> > >>>>>>>> Interceptor should support both modes, binary or not. Any code
> > >>> can
> > >>>>> call
> > >>>>>>>> withKeepBinary(), this should be expected.
> > >>>>>>>> Just add if (x instanceof BinaryObject) and go from there.
> > >>>>>>>>
> > >>>>>>>> Thanks,
> > >>>>>>>> Pavel
> > >>>>>>>>
> > >>>>>>>> On Thu, Jan 24, 2019 at 12:38 PM Sergey Antonov <
> > >>>>>>> [hidden email]
> > >>>>>>>>>
> > >>>>>>>> wrote:
> > >>>>>>>>
> > >>>>>>>>> I did a little investigation. In
> > >>>>>>>> o.a.i.i.p.p.c.c.ClientCacheRequest#cache()
> > >>>>>>>>> enforced cache with keep binary. Why we should always work
> > >>> binary
> > >>>>>>>> objects?
> > >>>>>>>>>
> > >>>>>>>>> чт, 24 янв. 2019 г. в 12:29, Sergey Antonov <
> > >>>>>> [hidden email]
> > >>>>>>>> :
> > >>>>>>>>>
> > >>>>>>>>>> Hello, Igniters!
> > >>>>>>>>>>
> > >>>>>>>>>> I have ignite node with configured cache. The cache have
> > >>> cache
> > >>>>>>>>>> interceptor. I wiil got ClassCastException on cache
> > >>>> interceptor,
> > >>>>>> If I
> > >>>>>>>> put
> > >>>>>>>>>> some entry to the cache (without keepBinary) from thin java
> > >>>>> client.
> > >>>>>>>>>>
> > >>>>>>>>>> I think it's a bug. I'd like to find out yours view!
> > >>>>>>>>>>
> > >>>>>>>>>> Also I made JIRA ticket with reproducer [1].
> > >>>>>>>>>>
> > >>>>>>>>>> [1] https://issues.apache.org/jira/browse/IGNITE-10789
> > >>>>>>>>>>
> > >>>>>>>>>> --
> > >>>>>>>>>> BR, Sergey Antonov
> > >>>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>> --
> > >>>>>>>>> BR, Sergey Antonov
> > >>>>>>>>>
> > >>>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>> --
> > >>>>>>> BR, Sergey Antonov
> > >>>>>>>
> > >>>>>>
> > >>>>>
> > >>>>>
> > >>>>> --
> > >>>>> BR, Sergey Antonov
> > >>>>>
> > >>>>
> > >>>
> > >>>
> > >>> --
> > >>> BR, Sergey Antonov
> > >>>
> > >>
> > >
> > >
> > > --
> > > BR, Sergey Antonov
> >

--
Best regards,
Ivan Pavlukhin

[antonovsergey93]

Ivan, thank you. I started wrote same test today)

пт, 25 янв. 2019 г. в 10:16, Павлухин Иван <[hidden email]>:

> Pavel,
>
> Initially I meant Java thick client. And I see the difference between
> thin and thick Java clients. As was already mentioned thin Java client
> behaves in way like each cache is enforced to not unwrap binary
> objects (withKeepBinary()). You can see a test demonstrating current
> behavior [1].
>
> [1] https://gist.github.com/pavlukhin/2c76d11cde5243a73f01019cdd15d243
>
> чт, 24 янв. 2019 г. в 23:01, Pavel Tupitsyn <[hidden email]>:
> >
> > Ivan,
> >
> > There is no inconsistency between thick and thin clients.
> > All of them work with caches in binary mode, see ClientCacheRequest
> (thin)
> > and PlatformCache (thick) classes.
> >
> > On Thu, Jan 24, 2019 at 10:26 PM Ivan Pavlukhina <[hidden email]>
> > wrote:
> >
> > > Sergey,
> > >
> > > There are couple of things which should be addressed:
> > > 1. Unnecessary deserialization.
> > > 2. Inconsistent behavior.
> > > 3. Unclear documentation.
> > >
> > > Deserialization is not free and in my mind should be avoided where
> > > possible. I think that if some feature (like interceptors) requires
> > > deserialization then it should be enabled explicitly and an impact
> should
> > > be clear to user. I can imagine a toggle “withAllowedDeserialization”.
> > >
> > > If there is an inconsistency between thick and thin clients it should
> be
> > > eliminated. I do not see a reason why behavior should be different.
> > >
> > > If something is a good thing but it is not intuitive it could be
> > > documented. But if there is s really good reason for it. Otherwise
> > > simplicity and consistency are better alias.
> > >
> > > > On 24 Jan 2019, at 17:42, Sergey Antonov <[hidden email]>
> > > wrote:
> > > >
> > > > I think it's bad idea. This contract nowhere defined and it's not
> clear
> > > for
> > > > users.
> > > >
> > > > чт, 24 янв. 2019 г. в 17:18, Pavel Tupitsyn <[hidden email]>:
> > > >
> > > >> Yes
> > > >>
> > > >> On Thu, Jan 24, 2019 at 5:15 PM Sergey Antonov <
> > > [hidden email]>
> > > >> wrote:
> > > >>
> > > >>> Pavel,
> > > >>>
> > > >>> "Leave it as is, use instanceof."
> > > >>> You meant always use CacheInterceptor<Object, Object> and in all
> > > methods
> > > >>> check, that passed arguments is BinaryObject?
> > > >>>
> > > >>> чт, 24 янв. 2019 г. в 17:10, Pavel Tupitsyn <[hidden email]
> >:
> > > >>>
> > > >>>> I don't think we should complicate things. Leave it as is, use
> > > >>> instanceof.
> > > >>>> The fact is - you can get anything, BinaryObject or any user
> class, so
> > > >> be
> > > >>>> prepared.
> > > >>>> Good example of older API is CacheEvent, which actually has
> oldValue()
> > > >>> and
> > > >>>> newValue() as Object.
> > > >>>>
> > > >>>> Igniters, any other thoughts?
> > > >>>>
> > > >>>>
> > > >>>> On Thu, Jan 24, 2019 at 2:16 PM Sergey Antonov <
> > > >>> [hidden email]>
> > > >>>> wrote:
> > > >>>>
> > > >>>>> Pavel, how about marker interface
> DeserializedValueCacheInterceptor?
> > > >> We
> > > >>>>> will deserialize data and pass it to cache interceptor, if
> > > >>>> CacheInterceptor
> > > >>>>> implements marker interface.
> > > >>>>>
> > > >>>>> чт, 24 янв. 2019 г. в 13:41, Pavel Tupitsyn <
> [hidden email]>:
> > > >>>>>
> > > >>>>>> You are exactly right, generic parameters don't make much sense
> > > >> here.
> > > >>>>>> Ignite caches are not restricted to any type, and there is type
> > > >>> erasure
> > > >>>>> in
> > > >>>>>> Java so you have no runtime guarantees.
> > > >>>>>>
> > > >>>>>> Maybe Interceptor design should be improved (e.g. add a flag to
> > > >> force
> > > >>>>>> binary or non-binary mode),
> > > >>>>>> but Thin or Thick client connector logic is unrelated here.
> > > >>>>>> withKeepBinary() call is valid and should not depend on
> Interceptor
> > > >>>>>> presence or implementation.
> > > >>>>>>
> > > >>>>>> On Thu, Jan 24, 2019 at 1:17 PM Sergey Antonov <
> > > >>>>> [hidden email]>
> > > >>>>>> wrote:
> > > >>>>>>
> > > >>>>>>> Hi, Pavel,
> > > >>>>>>>
> > > >>>>>>> "Interceptor should support both modes, binary or not. Any code
> > > >> can
> > > >>>>> call
> > > >>>>>>> withKeepBinary(), this should be expected.
> > > >>>>>>> Just add if (x instanceof BinaryObject) and go from there. "
> > > >>>>>>> I don't agree. The cache interceptor[1] is a parametrized class
> > > >> and
> > > >>>> you
> > > >>>>>>> couldn't pass multiple cache interceptors in cache
> configuration.
> > > >>> So
> > > >>>>> all
> > > >>>>>>> cache interceptors must have Object, Object parameters for
> > > >>> supporting
> > > >>>>>> both
> > > >>>>>>> modes: binary and deserialized. In this case parametrized class
> > > >> no
> > > >>>>> sense.
> > > >>>>>>>
> > > >>>>>>> [1]
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>
> > > >>>>>
> > > >>>>
> > > >>>
> > > >>
> > >
> https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/cache/CacheInterceptor.html
> > > >>>>>>>
> > > >>>>>>> чт, 24 янв. 2019 г. в 13:06, Pavel Tupitsyn <
> > > >> [hidden email]
> > > >>>> :
> > > >>>>>>>
> > > >>>>>>>> Hi Sergey,
> > > >>>>>>>>
> > > >>>>>>>> I don't think this is a bug.
> > > >>>>>>>>
> > > >>>>>>>> Thick or thin clients always work in binary mode on server
> > > >> side,
> > > >>>>>> because
> > > >>>>>>>> you receive data in serialized form and there is no point in
> > > >>>>>>> deserializing
> > > >>>>>>>> it.
> > > >>>>>>>> Moreover, in most cases you don't have classes on the server,
> > > >> so
> > > >>>>> binary
> > > >>>>>>>> mode is the only way.
> > > >>>>>>>>
> > > >>>>>>>> Interceptor should support both modes, binary or not. Any code
> > > >>> can
> > > >>>>> call
> > > >>>>>>>> withKeepBinary(), this should be expected.
> > > >>>>>>>> Just add if (x instanceof BinaryObject) and go from there.
> > > >>>>>>>>
> > > >>>>>>>> Thanks,
> > > >>>>>>>> Pavel
> > > >>>>>>>>
> > > >>>>>>>> On Thu, Jan 24, 2019 at 12:38 PM Sergey Antonov <
> > > >>>>>>> [hidden email]
> > > >>>>>>>>>
> > > >>>>>>>> wrote:
> > > >>>>>>>>
> > > >>>>>>>>> I did a little investigation. In
> > > >>>>>>>> o.a.i.i.p.p.c.c.ClientCacheRequest#cache()
> > > >>>>>>>>> enforced cache with keep binary. Why we should always work
> > > >>> binary
> > > >>>>>>>> objects?
> > > >>>>>>>>>
> > > >>>>>>>>> чт, 24 янв. 2019 г. в 12:29, Sergey Antonov <
> > > >>>>>> [hidden email]
> > > >>>>>>>> :
> > > >>>>>>>>>
> > > >>>>>>>>>> Hello, Igniters!
> > > >>>>>>>>>>
> > > >>>>>>>>>> I have ignite node with configured cache. The cache have
> > > >>> cache
> > > >>>>>>>>>> interceptor. I wiil got ClassCastException on cache
> > > >>>> interceptor,
> > > >>>>>> If I
> > > >>>>>>>> put
> > > >>>>>>>>>> some entry to the cache (without keepBinary) from thin java
> > > >>>>> client.
> > > >>>>>>>>>>
> > > >>>>>>>>>> I think it's a bug. I'd like to find out yours view!
> > > >>>>>>>>>>
> > > >>>>>>>>>> Also I made JIRA ticket with reproducer [1].
> > > >>>>>>>>>>
> > > >>>>>>>>>> [1] https://issues.apache.org/jira/browse/IGNITE-10789
> > > >>>>>>>>>>
> > > >>>>>>>>>> --
> > > >>>>>>>>>> BR, Sergey Antonov
> > > >>>>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>> --
> > > >>>>>>>>> BR, Sergey Antonov
> > > >>>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>> --
> > > >>>>>>> BR, Sergey Antonov
> > > >>>>>>>
> > > >>>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>> --
> > > >>>>> BR, Sergey Antonov
> > > >>>>>
> > > >>>>
> > > >>>
> > > >>>
> > > >>> --
> > > >>> BR, Sergey Antonov
> > > >>>
> > > >>
> > > >
> > > >
> > > > --
> > > > BR, Sergey Antonov
> > >
>
>
>
> --
> Best regards,
> Ivan Pavlukhin
>

--
BR, Sergey Antonov