]
Mircea Markus updated ISPN-575:
-------------------------------
Fix Version/s: 5.1.0.BETA1
5.1.0.Final
(was: 4.1.0.Final)
(was: 4.1.0.CR3)
Wrong reordering of data when using Flag.SKIP_LOCKING and having a
cache store enabled
--------------------------------------------------------------------------------------
Key: ISPN-575
URL:
https://jira.jboss.org/browse/ISPN-575
Project: Infinispan
Issue Type: Bug
Components: Loaders and Stores
Affects Versions: 4.0.0.Final, 4.1.0.CR2
Reporter: Sanne Grinovero
Assignee: Mircea Markus
Priority: Critical
Fix For: 5.1.0.BETA1, 5.1.0.Final
Attachments:
[ISPN-575]_(Corruption_in_data_when_using_a_permanent_store)_Extra_debugging_info_.patch,
ISPN-575-previewOfTest-dontapply.patch, more_logs.patch
We verified the issue while using the Lucene Directory; using the Directory under stress
leads to no issues even during long running tests of several hours.
To verify the Lucene Directory under stress, use
org.infinispan.lucene.profiling.PerformanceCompareStressTest.
The same exact test - but having a jdbc store enabled - breaks:
org.infinispan.lucene.profiling.CacheStoreStressTest (*)
Lucene's error says "invalid checksum", the truth is that the checksum data
is missing as there where two consecutive put operations: one containing the correct data
but missing the checksum signature, and then again putting the same data but with the
correct signature; both puts are using SKIP_LOCKING, and it appears that some readers in
other threads - which definitely start after the second put - are getting the first
unsigned values (under load only - must be a race condition).
* The CacheStoreStressTest was committed with ISPN-590 as #2187, but same commit also
works around the issue in the Lucene implementation, so keep the implementation at a
previous revision.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: