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

2019-01-25 Thread Sergey Antonov
Ivan, thank you. I started wrote same test today) пт, 25 янв. 2019 г. в 10:16, Павлухин Иван : > 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

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

2019-01-24 Thread Павлухин Иван
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].

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

2019-01-24 Thread 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 wrote: > Sergey, > > There are couple of things which should be

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

2019-01-24 Thread Ivan Pavlukhina
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

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

2019-01-24 Thread Sergey Antonov
I think it's bad idea. This contract nowhere defined and it's not clear for users. чт, 24 янв. 2019 г. в 17:18, Pavel Tupitsyn : > Yes > > On Thu, Jan 24, 2019 at 5:15 PM Sergey Antonov > wrote: > > > Pavel, > > > > "Leave it as is, use instanceof." > > You meant always use CacheInterceptor and

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

2019-01-24 Thread Pavel Tupitsyn
Yes On Thu, Jan 24, 2019 at 5:15 PM Sergey Antonov wrote: > Pavel, > > "Leave it as is, use instanceof." > You meant always use CacheInterceptor and in all methods > check, that passed arguments is BinaryObject? > > чт, 24 янв. 2019 г. в 17:10, Pavel Tupitsyn : > > > I don't think we should

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

2019-01-24 Thread Sergey Antonov
Pavel, "Leave it as is, use instanceof." You meant always use CacheInterceptor and in all methods check, that passed arguments is BinaryObject? чт, 24 янв. 2019 г. в 17:10, Pavel Tupitsyn : > I don't think we should complicate things. Leave it as is, use instanceof. > The fact is - you can get

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

2019-01-24 Thread 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,

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

2019-01-24 Thread Sergey Antonov
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 : > You are exactly right, generic parameters don't make much sense here. >

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

2019-01-24 Thread Sergey Antonov
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

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

2019-01-24 Thread 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

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

2019-01-24 Thread Sergey Antonov
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

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

2019-01-24 Thread 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.

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

2019-01-24 Thread Sergey Antonov
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 : > Hello, Igniters! > > I have ignite node with configured cache. The cache have cache >