[
https://issues.jboss.org/browse/ISPN-909?page=com.atlassian.jira.plugin.s...
]
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