2:49 a.m.
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
10:44 a.m.
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 <rvansa(a)redhat.com>
JBoss Performance Team
9:03 a.m.
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.
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
7:50 a.m.
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
8:28 a.m.
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 <ttarrant(a)redhat.com>
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
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
2856
days inactive
2899
days old
infinispan-dev@lists.jboss.org
4 comments
4 participants
participants (4)
-
Galder Zamarreño -
Radim Vansa -
Tristan Tarrant -
William Burns