[infinispan-dev] Compatiibility 2.0 dump

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[infinispan-dev] Compatiibility 2.0 dump

Tristan Tarrant-2
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
--
Tristan Tarrant
Infinispan Lead
JBoss, a division of Red Hat
_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [infinispan-dev] Compatiibility 2.0 dump

Radim Vansa
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)

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 <[hidden email]>
JBoss Performance Team

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [infinispan-dev] Compatiibility 2.0 dump

Galder Zamarreño
In reply to this post by Tristan Tarrant-2
Hi Tristan,

Thanks for writing that up the document, one (long) comment:

I think the wiki is not very clear on the difference between type and content type. It often uses the word type when it really means content type.

IOW, a cache can store instances of a single type (e.g. Person) or it can mix it up by storing multiple types (e.g. Person, Car...etc), but that's not the same as the content type (e.g. JSON or XML).

In theory, you could have:

1. A single type and a single content type, e.g. Person instances, stored as JSON.
^ This option makes the most sense to me. We should strive to promote this.

2. A single type and multiple content types, e.g. Person instances, somes stored as JSON, some as Protobuf binary.
^ Is this realistic? I'd imagine that even if you have difference input devices, you'd try to find the format that's common denominator. However, maybe due to lack of capabilities or performance reasons, you might decide to store differently? Also, for querying to work, you'd have to be able to index different source types.

3. Multiple types and a single content type, e.g. Person and Car instances, all stored as JSON.
^ We've had discussions about this in the past: In general I'm in favour of a single type per cache. However, there are some limitations to such set up, e.g. querys can only execute against 1 cache (AFAIK unless this limitation has changed?). So, such limitations can force users to add multiple types in the same cache.

4. Multiple types and multiple content type, e.g. Person and Car instances, Persons stored as JSON, Cars stored as XML.
^ If you are inclined to store multiple types in the same cache, this could certainly happen.

Thoughts?

Cheers,
--
Galder Zamarreño
Infinispan, Red Hat

> On 21 Jun 2016, at 09:49, Tristan Tarrant <[hidden email]> 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
> --
> Tristan Tarrant
> Infinispan Lead
> JBoss, a division of Red Hat
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [infinispan-dev] Compatiibility 2.0 dump

Galder Zamarreño
In reply to this post by Radim Vansa

> On 22 Jun 2016, at 17:44, Radim Vansa <[hidden email]> 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.

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 <[hidden email]>
> JBoss Performance Team
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [infinispan-dev] Compatiibility 2.0 dump

William Burns-3


On Mon, Jul 25, 2016 at 10:03 AM Galder Zamarreño <[hidden email]> wrote:

> On 22 Jun 2016, at 17:44, Radim Vansa <[hidden email]> 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 <[hidden email]>
> JBoss Performance Team
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Loading...