[
https://issues.jboss.org/browse/ISPN-939?page=com.atlassian.jira.plugin.s...
]
Sanne Grinovero edited comment on ISPN-939 at 2/18/11 11:07 AM:
----------------------------------------------------------------
it's a wiki you should be able to write there ;)
I have to admit it's not there because I didn't know. Also I think my suggestion
above should work, but please confirm it before we make it a recommendation.
Also, this is a workaround, I'll have to figure out how to prevent it from happening
at all! Usually workarounds are better described in the JIRA, so people having the same
issue in the short time will find it, hopefully for the long time the issue should be
solved.
Patch implementation ideas?
was (Author: sannegrinovero):
it's a wiki you should be able to write there ;)
I have to admit it's not there because I didn't know. Also I think my suggestion
above should work, but please confirm it before we make it a recommendation.
Also, this is a workaround, I'll have to figure out how to prevent it from happening
at all! Usually workarounds are better described in the JIRA, so people having the same
issue in the short time will find it, hopefully for the long time the issue should be
solved.
Index corruption when remote node dies during commit
----------------------------------------------------
Key: ISPN-939
URL:
https://issues.jboss.org/browse/ISPN-939
Project: Infinispan
Issue Type: Bug
Components: Lucene Directory
Affects Versions: 4.2.1.CR2
Reporter: Tristan Tarrant
Assignee: Sanne Grinovero
Attachments: read_past_eof.log, suspect_exception_node1.log
Using a scenario similar to the one described in ISPN-909:
Infinispan: 3 caches: lockCache (replicated, volatile, no eviction), metadataCache
(replicated, persisted, no eviction), dataCache (distributed, persisted, eviction, hash
numOwners=2)
Node 1: coordinator, IndexWriter open constantly and writing a stream of documents,
committing after each one
Node 2: opens a read-only IndexReader to perform queries, using reopen to keep in sync
with the updates coming from node 1
If we "kill -9" node 2 (to simulate a crash), we get a SuspectException in node
1 during the pre-commit phase (within IndexWriter.commit()). Catching the Throwable we
then close() the writer but from then on we get "Read past EOF" errors when
trying to access the index (both with readers and writers).
--
This message is automatically generated by JIRA.
For more information on JIRA, see:
http://www.atlassian.com/software/jira