Re: [infinispan-dev] Compatiibility 2.0 dump
On Mon, Jul 25, 2016 at 10:03 AM Galder Zamarreño <galder(a)redhat.com> wrote:
> On 22 Jun 2016, at 17:44, Radim Vansa <rvansa(a)redhat.com> wrote:
>
> I've spotted things like 'decorating cache' in the wiki page. I though
> that the core architecture in Infinispan, modifying the behavior
> according to configurations, is the interceptor stack. While we have
> some doubts about its performance, and there are limitations - e.g. the
> Flags don't allow to add custom parameters and we certainly don't want
> to add Flag.JSON and Flag.XML - I would consider decorating a Cache<K,
> V> vs. adding interceptors.
>
> I am thinking of adding the transcoder information to invocation context
> and only pass different ICF to the CacheImpl. Though, this requires new
> factory, new interceptor and a handful of specialized context classes
> (or a wrapper to the existing ones). Whoo, just decorating Cache sounds
> much simpler (and probably more performant). Or should we have forks in
> interceptor stack? (as an alternative to different wrappers).
>
> The idea of interceptors is that these are common for all operations, if
> we want to do things differently for different endpoints (incl.
> embedded), decorating probably is the answer.
>
> My 2c (or rather just random thoughts and whining)
Will and I had a good discussion on the problems that interceptors had
with data conversion layers while at Summit/DevNation. I don't remember the
details very well, that's what 3 weeks of holiday does to you ;), but Will
will reply with some more details. From what I remember, doing conversion
in interceptors made did not fully work with streams and custom filters.
Sorry for the delay.
The issue from what I remember is mostly what you said Galder. Streams in
particular are interesting because you may have a Stream<byte[], byte[]>
but underneath it is really a Stream<Object, Object> so if you try to pass
an intermediate operation such as filter or map, you would pass a
Predicate<? super byte[]> but that can't be applied to the underlying
stream without first unboxing the key/value but then the value returned
from the stream may not know if the value is unboxed or not. It is just
quite messy. I don't even remember how this works when protobuf is also in
the mix :(
Filters are somewhat similar but they are mostly okay because they only
apply at most 1 filter/map method and then use an iterator where as a
stream could be any number.
Cheers,
>
> Radim
>
> On 06/21/2016 09:49 AM, Tristan Tarrant wrote:
>> Hi all,
>>
>> I've created a wiki [1] for the "compatibility 2.0" ideas we
talked
>> about recently at the query meeting.
>>
>> This is mostly a dump of the minutes, so the form is not complete, but
>> initial comments are welcome.
>>
>>
>> Tristan
>>
>> [1] https://github.com/infinispan/infinispan/wiki/Compatibility-2.0
>
>
> --
> Radim Vansa <rvansa(a)redhat.com>
> JBoss Performance Team
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Attachments:
- attachment.html (text/html — 4.6 KB)