[infinispan-issues] [JBoss JIRA] (ISPN-3665) SingleFileStore is not thread-safe for passivation

[Dan Berindei (JIRA)]

    [ https://issues.jboss.org/browse/ISPN-3665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12923041#comment-12923041 ] 

Dan Berindei commented on ISPN-3665:
------------------------------------

* The start() and stop() methods are fine, ComponentRegistry also does some synchronization that ensures any thread that can access the component will see all the values set during its startup. Plus we use that trick all over the place...
* As you said, the entries monitor guarantees visibility for the FileEntry updates. However, it is possible for a _load() to use those FileEntry fields after it released both the entries monitor (allowing a write() to proceed) and the pseudo-read lock in FileEntry (allowing allocate() to allocate the entry for a new write()). I'm making FileEntry immutable to avoid this.
* Actually I was wrong about free(). The key length bytes are zeroed in the file, but the FileEntry still has the proper keyLen, and _load() can still read the entry from the file (assuming it got a hold of it before it was removed from the entries map). The actual data is only overwritten after all the readers have released their pseudo-read lock on the FileEntry.

I did notice another problem with clear(): write()/free() could write past the end of the file when a clear() happened in parallel. This would create an invalid file with a lot of zeroes. I'm adding a global read-write lock to deal with that.

                
> SingleFileStore is not thread-safe for passivation
> --------------------------------------------------
>
>                 Key: ISPN-3665
>                 URL: https://issues.jboss.org/browse/ISPN-3665
>             Project: Infinispan
>          Issue Type: Bug
>          Components: Loaders and Stores
>    Affects Versions: 6.0.0.CR1
>            Reporter: Paul Ferraro
>            Assignee: Dan Berindei
>            Priority: Blocker
>              Labels: 620
>             Fix For: 6.0.0.CR2
>
>         Attachments: Test.java
>
>
> SingleFileStore never makes use of FileChannel.force(...) to flush changes to disk.  This causes problems for the passivation use case.
> If one thread evicts a cache entry, while immediately after another thread attempts to read the same cache entry, the Cache.get(...) can return null.  This is because the entry is never flushed to disk.
> I've attached a test to reproduce the problem.
> I also ran the same test with the addition of FileChannel.force(false) to the write(...) method, and the test succeeds.
> A proper fix should probably make this a configurable property (as it was with the old file store implementation).  It would be nice if the flush could defer until just before tx commit, but, off hand, I don't know how feasible that is.
> I suspect this lack of flush also accounts for much of the bold claim of a 100x performance improvement over the old file store implementation.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira