On 22 November 2012 13:27, Ales Justin <ales.jus...@gmail.com> wrote: >> Right you should never enable eviction on a cache used to store >> permanent data - like the Lucene index segment. > > But couldn't you still have eviction if you used store to persist overflown > data.
No not for ReadLocks, they aren't safe on a passivated cache. Actually you want to avoid needing ReadLocks at all, you can tune Lucene's options to not need them but it's an approximate science so the way I've implemented them is they will kick-in only when need is detected: with good size tuning that will happen only occasionally, and with bad tuning you won't screw data up. Note that this is a surrogate readlock as Infinispan doesn't provide support for them, hence the limitation of no-passivation. ReadLocks are used only on the cache named name="LuceneIndexesLocking" , for which you should disable file-store as it's not needed: all values are volatile lock metadata which is only meaningful with at least one node alive. > >> How would you phrase the error message? > > Well, at least put in the *right* cache name somewhere in the msg. ;-) > I though I was going blind, as requesting cache - the indexing one - clearly > had NONE set as eviction strategy. > >> On 22 November 2012 12:21, Ales Justin <ales.jus...@gmail.com> wrote: >>> Ah, OK, it should really be disabled on Lucene caches: >>> >>> <replicated-cache name="LuceneIndexesMetadata" mode="SYNC"> >>> <transaction mode="NONE"/> >>> <eviction strategy="NONE"/> >>> <file-store preload="true" purge="false"/> >>> </replicated-cache> >>> <replicated-cache name="LuceneIndexesData" mode="SYNC"> >>> <transaction mode="NONE"/> >>> <eviction strategy="NONE"/> >>> <file-store preload="true" purge="false"/> >>> </replicated-cache> >>> <replicated-cache name="LuceneIndexesLocking" mode="SYNC"> >>> <transaction mode="NONE"/> >>> <eviction strategy="NONE"/> >>> <file-store preload="false" purge="true"/> >>> </replicated-cache> remove the last file-store >>> >>> Horrible err msg ... +1, let's improve on that. Did you open the JIRA Galder asked? >>> >>> On Nov 22, 2012, at 12:53 PM, Ales Justin <ales.jus...@gmail.com> wrote: >>> >>> I was changing cache config a bit, and got this: >>> * https://gist.github.com/4130728 >>> >>> private static void verifyCacheHasNoEviction(AdvancedCache<?, ?> cache) { >>> if (cache.getConfiguration().getEvictionStrategy().isEnabled()) >>> throw new IllegalArgumentException("DistributedSegmentReadLocker is >>> not reliable when using a cache with eviction enabled, disable eviction on >>> this cache instance"); >>> } >>> >>> >>> How do you then handle memory overflow on no-eviction caches? The only cache which could get big is LuceneIndexesData, the others won't ever use more than some kb of metadata. To recap: LuceneIndexesMetadata : needs CacheStore, no need for passivation (but won't hurt) LuceneIndexesData : needs CacheStore, passivation + eviction recommended to cap memory usage (but optional) LuceneIndexesLocking : no need for a CacheStore, eviction/passivation are illegal Sanne >>> >>> >>> -Ales >>> >>> >>> >>> _______________________________________________ >>> infinispan-dev mailing list >>> infinispan-dev@lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >> _______________________________________________ >> infinispan-dev mailing list >> infinispan-dev@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev _______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev