[ http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-152?pag... ] Sanne Grinovero commented on HSEARCH-152: ----------------------------------------- This could be needed to solve the issue described at https://forum.hibernate.org/viewtopic.php?f=9&t=1005017 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-152?pag... ] Sanne Grinovero commented on HSEARCH-152: ----------------------------------------- actually we do write out of the lock; was one of the first changes I made to the backend before 3.1; we engage lock only for optimization work (all kinds: use demanded or optimization strategy triggered). The IndexWriting is going anyway to merge segments using the ConcurrentMergeScheduler, so having our thread lock the DP won't prevent the other thread (Lucene internal) from making changes fo FS. Not each add/remove will trigger this error even out of the lock; if a segment is missing it means it was merged by a background thread (pointing to the concurrentMergeScheduler again). Using the SnapshotDeletionPolicy would be a reliable way to ask the mergeScheduler to not delete files until we have finished replication; actually could make the whole DP locks useless. An alternative would be to lock all write operations, but also having to open and close the IndexWriter inside the lock to restart/stop all mergers each time; that would mean to revert all the work I did to improve performance. (that's why Search 3.0 likely didn't have this issue when you designed the FSMaster) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-152?pag... ] Sanne Grinovero updated HSEARCH-152: ------------------------------------ Fix Version/s: 3.3.0 marked to be considered at least in 3.3.0 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-152?pag... ] Sanne Grinovero updated HSEARCH-152: ------------------------------------ Description: Seems we need this according to forum posts (adding references in the comments) (was: Not sure it's really interesting in our environment though) Fix Version/s: 4.0 Summary: Use SnapshotDeletionPolicy for hot backup instead of the old locking scheme (was: Consider using SnapshotDeletionPolicy for hot backup instead of the old locking scheme) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-152?pag... ] Sanne Grinovero commented on HSEARCH-152: ----------------------------------------- This is the thread having most useful feedback so far: https://forum.hibernate.org/viewtopic.php?f=9&t=1007801&start=15 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-152?pag... ] Sanne Grinovero updated HSEARCH-152: ------------------------------------ Fix Version/s: (was: 4.1) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira