[ https://jira.jboss.org/browse/ISPN-575?page=com.atlassian.jira.plugin.sys... ] Sanne Grinovero updated ISPN-575: --------------------------------- Priority: Critical (was: Major) Actually there's no need to stop/restart the cache, just the fact that a Store is configured screws the data "live" -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/browse/ISPN-575?page=com.atlassian.jira.plugin.sys... ] Sanne Grinovero updated ISPN-575: --------------------------------- Summary: Corruption in data when using a permanent store (was: Corruption in data when using a permanent store between stop-start cycles) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/browse/ISPN-575?page=com.atlassian.jira.plugin.sys... ] Galder Zamarreno updated ISPN-575: ---------------------------------- Fix Version/s: 4.1.0.CR3 Affects Version/s: 4.0.0.Final -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/browse/ISPN-575?page=com.atlassian.jira.plugin.sys... ] Sanne Grinovero commented on ISPN-575: -------------------------------------- Hi Galder, you likely missed my lastest commit "cleanup tests in Lucene Directory", please update your sources -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/browse/ISPN-575?page=com.atlassian.jira.plugin.sys... ] Galder Zamarreno updated ISPN-575: ---------------------------------- Attachment: [ISPN-575]_(Corruption_in_data_when_using_a_permanent_store)_Extra_debugging_info_.patch -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/browse/ISPN-575?page=com.atlassian.jira.plugin.sys... ] Sanne Grinovero updated ISPN-575: --------------------------------- Summary: Wrong reordering of data when using Flag.SKIP_LOCKING and having a cache store enabled (was: Corruption in data when using a permanent store) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/browse/ISPN-575?page=com.atlassian.jira.plugin.sys... ] Sanne Grinovero updated ISPN-575: --------------------------------- Description: 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. was: 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. If during the same stress test a permanent store is enabled, all works still fine, until the CacheManager is stopped. No errors during the stop(), but after starting it again the checksum on some data fails and the index is unusable. Steps to Reproduce: see description (was: Reconfigure org.infinispan.lucene.profiling.PerformanceCompareStressTest to use a permanent store, start it, wait it to finish, stop it and try starting it again: it likely won't, but is not always reproduced.) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/browse/ISPN-575?page=com.atlassian.jira.plugin.sys... ] 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) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-575?page=com.atlassian.jira.plugin.s... ] Sanne Grinovero commented on ISPN-575: -------------------------------------- This issue doesn't apply anymore to Lucene Directory users since ISPN-590 is effectively a workaround for this, but I think it could still apply to other use cases. Still now that I know a bit more about Infinispan internals I'm wondering if this should not be documented as a limitation of SKIP_LOCK instead of being fixed as a bug: in absence of a lock I'm not sure how we can mandate proper ordering. Main problem of having now this workaround in Lucene's Directory is that we have no more a test case. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-575?page=com.atlassian.jira.plugin.s... ] Sanne Grinovero closed ISPN-575. -------------------------------- Fix Version/s: (was: 5.1.0.BETA1) (was: 5.1.0.FINAL) Resolution: Out of Date We agreed this is not a supported case: locks are needed to avoid data inconsistencies and should not be skipped lightly. The issue is no longer an issue when using the Lucene Directory, as it no longer attempts to write twice on the same key sipping the lock. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira