[infinispan-issues] [JBoss JIRA] Commented: (ISPN-939) Index corruption when remote node dies during commit

[ https://issues.jboss.org/browse/ISPN-939?page=com.atlassian.jira.plugin.s... ] Sanne Grinovero commented on ISPN-939: -------------------------------------- ah, right. What about using the SerialMergeScheduler? I now it's not a great solution, just searching for a temporary workaround for you; also it would be great to know if that helps. And you didn't answer about the version you're using :) It's quite different if you have ISPN-930 included or not: since ISPN-930 was committed (4.2.1.CR2, which I suppose you're not using because of the xsd issue), the metadata of existing segments is enabled only at segment close. About your question: the batches are effectively canceled if you're running a transactionmanager and use org.infinispan.lucene.locking.TransactionalLockFactory . For this one to apply index updates and have them visible/committed to the other nodes, you'll have to frequently close the indexWriter (indexwriter close == commit batched changes). So using this approach, index will always be guaranteed in consistent state through the transactionmanager's capabilities but you'll have to wrap your changes in blocks of work (open IW - apply changes - commit & close IW)(repeat). Also note the javadoc of TransactionalLockFactory: you'll need SerialMergeScheduler when using this locking. Still, an unfinished batch shouldn't have affected the other nodes. you might try cancelling the batch but I'm not sure of the rollback capabilities of a dummy transaction manager (which is the implementation behind batching). The better solution is to hide the suspect exception, or understand if we can remove it. I'm going to figure out a unit test. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira