[
https://issues.jboss.org/browse/ISPN-930?page=com.atlassian.jira.plugin.s...
]
Sanne Grinovero commented on ISPN-930:
--------------------------------------
The workaround is to avoid writing two different values under the same key.
With Lucene, the first bytes are rewritten at file close time to add checksum
information to the head of the file.
Previously we where writing each file chunk as soon as possible to be
memory friendly, getting the first chunk back as needed to edit it and putting
it into the cache modified - apparently if these operations are close enough in
time, the value without the checksum might end up to be the value stored (ISPN-575).
What we do with this patch is hold the writing of the first chunk up to the file
close operation, so that each chunk is written only once.
As a side effect, we can simplify the batch operations and the intermediate flush
operations, as they don't need to detect if we are in closing phase.
race condition in Lock reordering could cause Lucene Index corruption
when a CacheLoader is enabled
---------------------------------------------------------------------------------------------------
Key: ISPN-930
URL:
https://issues.jboss.org/browse/ISPN-930
Project: Infinispan
Issue Type: Bug
Components: Lucene Directory
Affects Versions: 4.2.0.Final, 4.2.1.CR1, 5.0.0.ALPHA2
Reporter: Sanne Grinovero
Assignee: Sanne Grinovero
Fix For: 4.2.1.CR2, 4.2.1.Final, 5.0.0.ALPHA3, 5.0.0.Final
Original Estimate: 4 days
Remaining Estimate: 4 days
This is related to ISPN-575; the Lucene Directory used to be able to workaround the issue
but this doesn't seem to be the case anymore:
org.infinispan.lucene.profiling.CacheStoreStressTest
fails on both master and 4.2.x branches.
--
This message is automatically generated by JIRA.
For more information on JIRA, see:
http://www.atlassian.com/software/jira