noon
Hi Galder,
Whilst reviewing Tristan's pull request for ISPN-3008[1] I saw that we allow
configuring "fetchInMemoryState" for topology caches and wondering why we do
that? Shouldn't it be enabled by default/enforced?
[1] https://github.com/infinispan/infinispan/pull/1802
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
8:58 a.m.
On May 16, 2013, at 12:00 PM, Mircea Markus <mmarkus(a)redhat.com> wrote:
Hi Galder,
Whilst reviewing Tristan's pull request for ISPN-3008[1] I saw that we allow
configuring "fetchInMemoryState" for topology caches and wondering why we do
that?
^ Not sure exactly what you mean… When a node joins in, it needs to receive the topology
from other nodes to be able to provide topology headers with the correct info to the
clients. That's why the topology caches can be configured with fetching memory.
Alternatively, since the cache is replicated, a similar effect can be achieved with a
cluster cache loader. This was introduced a while back as a result of a bug with state
transfer (I think it was something related to https://issues.jboss.org/browse/EDG-44)
Shouldn't it be enabled by default/enforced?
^ Either that, or the cluster cache loader are used, both of which serve the same
purpouse.
[1] https://github.com/infinispan/infinispan/pull/1802
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
--
Galder Zamarreño
galder(a)redhat.com
twitter.com/galderz
Project Lead, Escalante
http://escalante.io
Engineer, Infinispan
http://infinispan.org
9:30 a.m.
On 05/21/2013 08:58 AM, Galder Zamarreño wrote:
Shouldn't it be enabled by default/enforced?
^ Either that, or the cluster cache loader are used, both of which serve the same
purpouse.
I think what Mircea is getting at, is that there is an intention to
deprecate / remove the CCL. I think that we can do that in 6.0 (with the
CacheStore redesign) and remove all potential users of CCL (including
the lazy topology transfer).
Tristan
11:34 a.m.
On May 21, 2013, at 9:30 AM, Tristan Tarrant <ttarrant(a)redhat.com> wrote:
On 05/21/2013 08:58 AM, Galder Zamarreño wrote:
> Shouldn't it be enabled by default/enforced?
> ^ Either that, or the cluster cache loader are used, both of which serve the same
purpouse.
>
I think what Mircea is getting at, is that there is an intention to deprecate / remove
the CCL. I think that we can do that in 6.0 (with the CacheStore redesign) and remove all
potential users of CCL (including the lazy topology transfer).
Ah, I see. That's fine by me. The use of CCL was a workaround really.
Cheers,
Tristan
--
Galder Zamarreño
galder(a)redhat.com
twitter.com/galderz
Project Lead, Escalante
http://escalante.io
Engineer, Infinispan
http://infinispan.org
3:36 p.m.
On 21 May 2013, at 08:30, Tristan Tarrant <ttarrant(a)redhat.com> wrote:
On 05/21/2013 08:58 AM, Galder Zamarreño wrote:
> Shouldn't it be enabled by default/enforced?
> ^ Either that, or the cluster cache loader are used, both of which serve the same
purpouse.
>
I think what Mircea is getting at, is that there is an intention to
deprecate / remove the CCL. I think that we can do that in 6.0 (with the
CacheStore redesign) and remove all potential users of CCL (including
the lazy topology transfer).
Mind reader :-)
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
5:09 p.m.
I wouldn't want to deprecate CCL, I think it definitely has a purpose - at
least in invalidation mode.
Even in replication mode, having a lazy alternative to state transfer may
be useful. Maybe not for the topology cache, but it might make sense for
large caches.
On Tue, May 21, 2013 at 4:36 PM, Mircea Markus <mmarkus(a)redhat.com> wrote:
On 21 May 2013, at 08:30, Tristan Tarrant <ttarrant(a)redhat.com> wrote:
> On 05/21/2013 08:58 AM, Galder Zamarreño wrote:
>> Shouldn't it be enabled by default/enforced?
>> ^ Either that, or the cluster cache loader are used, both of which
serve the same purpouse.
>>
> I think what Mircea is getting at, is that there is an intention to
> deprecate / remove the CCL. I think that we can do that in 6.0 (with the
> CacheStore redesign) and remove all potential users of CCL (including
> the lazy topology transfer).
Mind reader :-)
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
11:48 a.m.
On 21 May 2013, at 17:09, Dan Berindei <dan.berindei(a)gmail.com> wrote:
I wouldn't want to deprecate CCL, I think it definitely has a
purpose - at least in invalidation mode.
The only use case I'm aware of for
invalidation is 2nd level cache and I don't think that needs a remote cache, Galder
wdyt?
Even in replication mode, having a lazy alternative to state transfer may be useful.
Maybe not for the topology cache, but it might make sense for large caches.
this makes me wonder: what would be the case in which one doesn't want to use state
transfer for a distributed/replicated cache.
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
3:49 p.m.
On Tue, Jul 9, 2013 at 12:48 PM, Mircea Markus <mmarkus(a)redhat.com> wrote:
On 21 May 2013, at 17:09, Dan Berindei <dan.berindei(a)gmail.com> wrote:
> I wouldn't want to deprecate CCL, I think it definitely has a purpose -
at least in invalidation mode.
The only use case I'm aware of for invalidation is 2nd level cache and I
don't think that needs a remote cache, Galder wdyt?
I don't know if 2nd level cache actually uses ClusterCacheLoader, but it
could definitely use it without exposing the cache through HotRod.
> Even in replication mode, having a lazy alternative to state transfer
may be useful. Maybe not for the topology cache, but it might make sense
for large caches.
this makes me wonder: what would be the case in which one doesn't want to
use state transfer for a distributed/replicated cache.
In replication mode, if the cache has a huge (non-shared) cache store, some
users may prefer to disable fetchPersistentState and rely on
ClusterCacheLoader instead for less frequently accessed keys.
I don't know if it ever makes sense to use ClusterCacheLoader in
distribution mode, since it always sends the ClusteredGetCommand to the
entire cluster.
Cheers
Dan
5:03 p.m.
On Jul 10, 2013, at 3:49 PM, Dan Berindei <dan.berindei(a)gmail.com> wrote:
On Tue, Jul 9, 2013 at 12:48 PM, Mircea Markus <mmarkus(a)redhat.com> wrote:
On 21 May 2013, at 17:09, Dan Berindei <dan.berindei(a)gmail.com> wrote:
> I wouldn't want to deprecate CCL, I think it definitely has a purpose - at least
in invalidation mode.
The only use case I'm aware of for invalidation is 2nd level cache and I don't
think that needs a remote cache, Galder wdyt?
I don't know if 2nd level cache actually uses ClusterCacheLoader, but it could
definitely use it without exposing the cache through HotRod.
Invalidation is indeed used by 2LC. It could be used by any application that uses
Infinispan as a cache really.
ClusterCacheLoader is there to provide lazy-loading of data, either for invalidated or
replicated caches. In the past, it was a good workaround if state transfer was slow.
Now, there's one situation where we definitely want to use ClusterCacheLoader with a
replicated cache, and that's with the query cache [1]. The reason for that is that if
you enable state transfer, it forces all replication calls to be synchronous (it used to
be like this, not sure whether any more…), but in the query cache we want an asynchronous
replicated cache, hence we use the CCL to retrieve data from other nodes.
[1]
https://github.com/hibernate/hibernate-orm/blob/master/hibernate-infinisp...
>
> Even in replication mode, having a lazy alternative to state transfer may be useful.
Maybe not for the topology cache, but it might make sense for large caches.
this makes me wonder: what would be the case in which one doesn't want to use state
transfer for a distributed/replicated cache.
If the state is too big for a replicated cache, or if you want to have an asynchronous
replicated cache.
In replication mode, if the cache has a huge (non-shared) cache
store, some users may prefer to disable fetchPersistentState and rely on
ClusterCacheLoader instead for less frequently accessed keys.
I've never seen anyone use fetchPersistentState TBH. We brought it from JBoss Cache,
but we should probably have ditched it.
I don't know if it ever makes sense to use ClusterCacheLoader in
distribution mode, since it always sends the ClusteredGetCommand to the entire cluster.
CCL and distribution do not make sense. Distribution already queries other nodes for
data.
Cheers
Dan
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Galder Zamarreño
galder(a)redhat.com
twitter.com/galderz
Project Lead, Escalante
http://escalante.io
Engineer, Infinispan
http://infinispan.org
3950
days inactive
4005
days old
infinispan-dev@lists.jboss.org
8 comments
4 participants
participants (4)
-
Dan Berindei -
Galder Zamarreño -
Mircea Markus -
Tristan Tarrant