Hi all,
Thanks for the help with this issue. I thought I'd just clarify that
the situation is pretty much resolved (or worked around) for me now by
use of the clusterLoader. I'll watch the JIRA issue and be sure to try
again without a clusterLoader when that's taken care of at some point.
Best,
J
FYI I've created a JIRA to track this: https://issues.jboss.org/browse/ISPN-2950
Whilst quite a performance issues, I don't think that this is an
critical/consistency issue for async stores: by using an async store you might
loose data (expect inconsistencies) during a node crash anyway, so what
On 19 Mar 2013, at 17:38, Dan Berindei wrote:
> >
> > Implementation-wise, just changing the interceptor order is probably not
> > enough. If the key doesn't exist in the cache, the CacheLoaderInterceptor
> > will still try to load it from the cache store after the remote lookup, so
> > we'll
>
> > Implementation-wise, just changing the interceptor order is probably not
> enough. If the key doesn't exist in the cache, the CacheLoaderInterceptor
> will still try to load it from the cache store after the remote lookup, so
> we'll need a marker in the invocation context to avoid the extr
On 19 Mar 2013, at 16:15, Dan Berindei wrote:
> Hi Sanne
>
> On Tue, Mar 19, 2013 at 4:12 PM, Sanne Grinovero wrote:
> Mircea,
> what I was most looking forward was to you comment on the interceptor
> order generated for DIST+cachestores
> - we don't think the ClusteredCacheLoader should be ne
On 19 Mar 2013, at 14:12, Sanne Grinovero wrote:
> Mircea,
> what I was most looking forward was to you comment on the interceptor
> order generated for DIST+cachestores
> - we don't think the ClusteredCacheLoader should be needed at all
> - each DIST node is loading from the CacheLoader (any) ra
Hi Sanne
On Tue, Mar 19, 2013 at 4:12 PM, Sanne Grinovero wrote:
> Mircea,
> what I was most looking forward was to you comment on the interceptor
> order generated for DIST+cachestores
> - we don't think the ClusteredCacheLoader should be needed at all
>
Agree, ClusteredCacheLoader should not
James, to workaround ISPN-2938
you could use preloading=true on the "lucene-index" cacheloader, and
preloading="false" on the "lucene-metadata" cacheloader.
Not particularly critical, but would save you a bunch of memory.
Sanne
On 19 March 2013 14:12, Sanne Grinovero wrote:
> Mircea,
> what I wa
Mircea,
what I was most looking forward was to you comment on the interceptor
order generated for DIST+cachestores
- we don't think the ClusteredCacheLoader should be needed at all
- each DIST node is loading from the CacheLoader (any) rather than
loading from its peer nodes for non-owned entries
On 16 Mar 2013, at 01:19, Sanne Grinovero wrote:
> Hi Adrian,
> let's forget about Lucene details and focus on DIST.
> With numOwners=1 and having two nodes the entries should be stored
> roughly 50% on each node, I see nothing wrong with that
> considering you don't need data failover in a read-
Hi,
Thanks for the tips, but I think there will be a couple of issues:
* By mistake, I actually tried creating the lucene-metadata cache
without the loader to start with, and the Directory is unusable
without it, as it isn't able to list the index files when Lucene's
IndexReader asks for them. So
Hi James,
By specifying the LuceneCacheLoader as a loader for the default cache, it will
added to both the "lucene-index" (where it is needed) and the other two caches
(lucene-metadata and lucene-locks) - where I don't think it is needed. I think
it should only be configured for the "lucene-ind
Hi all,
So, in my previous update it seems I had numOwners=2, but was only
using two servers. Therefore, what I was seeing made complete sense,
actually. After changing numOwners to 1, distribution appears to work
as expected with that clusterLoader added to the config as suggested.
Thanks for the
> there should
> be no need to use a ClusterCacheLoader,
I agree. This looked consistent w/ what I saw a couple weeks ago in a
different thread. Use of ClusterCacheLoader didn't make sense to me
either...
On Mar 18, 2013, at 5:55, Sanne Grinovero wrote:
> I'm glad you're finding a workaround f
I'm glad you're finding a workaround for the disk IO but there should
be no need to use a ClusterCacheLoader,
the intention of that would be to be able to chain multiple grids;
this is a critical problem IMHO.
Seems there are multiple other issues at hand, let me comment per bullet:
On 18 March 2
Update:
I tried again - I think I misconfigured that ClusterCacheLoader on my
last attempt. With this configuration [1] it actually appears to be
loading keys over the network from the peer node. I'm seeing a lot of
network IO between the nodes when requesting from either one of them
(30-50 MBp/s)
Hi Adrian,
let's forget about Lucene details and focus on DIST.
With numOwners=1 and having two nodes the entries should be stored
roughly 50% on each node, I see nothing wrong with that
considering you don't need data failover in a read-only use case
having all the index available in the shared Ca
Not sure if I've done exactly what you had in mind... here is my updated XML:
https://www.refheap.com/paste/12601
I added the loader to the lucene-index namedCache, which is the one
I'm using for distribution.
This didn't appear to change anything, as far as I can see. Still
seeing a lot of disk
Can you try adding a ClusterCacheLoader to see if that helps?
Thanks,
On Fri, Mar 15, 2013 at 8:49 AM, James Aley wrote:
> Apologies - forgot to copy list.
>
> On 15 March 2013 15:48, James Aley wrote:
> > Hey Adrian,
> >
> > Thanks for the response. I was chatting to Sanne on IRC yesterday, a
Apologies - forgot to copy list.
On 15 March 2013 15:48, James Aley wrote:
> Hey Adrian,
>
> Thanks for the response. I was chatting to Sanne on IRC yesterday, and
> he suggested this to me. Actually the logging I attached was from a
> cluster of 4 servers with numOwners=2. Sorry, I should have m
Hi James,
I'm not an expert on InfinispanDirectory but I've noticed in [1] that
the lucene-index cache is distributed with numOwners = 1. That means
each cache entry is owned by just one cluster node and there's nowhere
else to go in the cluster if the key is not available in local memory,
thu
Hi Ray,
Yeah - I've tried with shared=true/false and preload=true/false. I'm
using org.infinispan.lucene.cachestore.LuceneCacheLoader.
Sorry, I also should have mentioned previously that I'm building from
master, as I need access to the Lucene v4 support.
James.
On 15 March 2013 15:31, Ray Tsa
Was the cache loader shared? Which cache loader were you using?
On Fri, Mar 15, 2013 at 8:03 AM, James Aley wrote:
> Hey all,
>
>
> Seeing as this is my first post, I wanted to just quickly thank you
> all for Infinispan. So far I'm really enjoying working with it - great
> product!
>
>
> I'm
Hey all,
Seeing as this is my first post, I wanted to just quickly thank you
all for Infinispan. So far I'm really enjoying working with it - great
product!
I'm using the InfinispanDirectory for a Lucene project at the moment.
We use Lucene directly to build a search product, which has high rea
24 matches
Mail list logo
