[infinispan-issues] [JBoss JIRA] Resolved: (ISPN-680) Unintentional Segment Removal

Sanne Grinovero (JIRA) jira-events at lists.jboss.org
Mon Oct 4 16:24:39 EDT 2010


     [ https://jira.jboss.org/browse/ISPN-680?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Sanne Grinovero resolved ISPN-680.
----------------------------------

    Fix Version/s: 5.0.0.BETA1
                   5.0.0.Final
       Resolution: Done


This was technically fixed by ISPN-616 as it's no longer allowed to use a cache having eviction enabled to store the locks; with ISPN-616 you can now use separate caches to configure up to three caches, it's of course possible to enable eviction on the other two caches, which contain the significant part of the index size.

> Unintentional Segment Removal
> -----------------------------
>
>                 Key: ISPN-680
>                 URL: https://jira.jboss.org/browse/ISPN-680
>             Project: Infinispan
>          Issue Type: Bug
>          Components: Lucene Directory
>    Affects Versions: 4.1.0.Final
>         Environment: linux ubuntu 10.04 x386 32 bits
> hot spot jvm 1.6_018
>            Reporter: Franck Garcia
>            Assignee: Sanne Grinovero
>             Fix For: 4.2.0.BETA1, 4.2.0.Final, 5.0.0.BETA1, 5.0.0.Final
>
>
> During a lucene directory.copy() using an InfinispanDirectory as source and an FSDirectory as destination, an unintentional Delete is made on the infinispan lucene segment while closing the input stream.
> The problem is that the FileReadLockKey put in the cache at the beginning of the copy process could be eligible for eviction leading to unpredictable result on close.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


More information about the infinispan-issues mailing list