[infinispan-issues] [JBoss JIRA] Issue Comment Edited: (ISPN-909) Segments locked during merge

[Sanne Grinovero (JIRA)]

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

Sanne Grinovero edited comment on ISPN-909 at 5/30/11 7:01 AM:
---------------------------------------------------------------

thank you, that's great to hear as it confirms a theory I had on locking, when thinking about locking improvements in transactions. closing this.
The issue with locking is that the atomic replace operations we use in the readlock operations are not really atomic when used in a transactional environment as they are isolated from the real state of the value by the repeatable read semantics; indeed tricky to have a concurrentMap implementation with such options, I didn't think about that before. Generally we should never use the current "readlock" implementations on a transactions-enabled cache. I'll have to improve on that, thinking about alternative implementations or make this configuration illegal.

      was (Author: sannegrinovero):
    thank you, that's great to hear as it confirms a theory I had on locking, when thinking about locking improvements in transactions. closing this.
  
> Segments locked during merge
> ----------------------------
>
>                 Key: ISPN-909
>                 URL: https://issues.jboss.org/browse/ISPN-909
>             Project: Infinispan
>          Issue Type: Bug
>          Components: Lucene Directory
>    Affects Versions: 4.2.0.Final
>            Reporter: Tristan Tarrant
>            Assignee: Sanne Grinovero
>         Attachments: rabbit-1-mergelock.log, rabbit-2-mergelock.log
>
>
> We're getting failures on acquiring locks during merges. Here is the configuration:
> Infinispan: 3 caches: lockCache (replicated, volatile, no eviction), metadataCache (replicated, persisted, no eviction), dataCache (distributed, persisted, eviction).
> Node 1: coordinator, IndexWriter open constantly and writing a stream of documents
> Node 2: opens a read-only IndexReader on-demand to perform queries (we're moving to use IndexReader.reopen() ).
> Occasionally when performing queries on node 2 we get the attached stack traces. We then get corrupt indexes (java.io.IOException: Read past EOF).
> We are using the default Distributed Segment Lock Reader, default 16K chunks and no tuning of the merge policies.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira