[infinispan-dev] no eviction on indexing

[Sanne Grinovero]

On 22 November 2012 13:27, Ales Justin <ales.justin at 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.justin at 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.justin at 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 at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev