[ http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-893?pag... ] Sanne Grinovero updated HSEARCH-893: ------------------------------------ Component/s: massindexer infinispan Fix Version/s: 4.0.0.Alpha3 3.4.2 Assignee: Sanne Grinovero -- 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-893?pag... ] Sanne Grinovero commented on HSEARCH-893: ----------------------------------------- This is a nasty timing situation. It happens on Infinispan only because it's quite faster than a FSDirectory in acquiring the IndexWriter lock, and since Hibernate Search's transactional backend is async and was queued quite some work, when the MassIndexer acquires the lock the transactional backend is still busy. This shouldn't normally be an issue, as the timing different is less than a millisecond, but wasn't detected before as we usually test on FS. Unfortunately reconfiguring the LockFactory to provide a longer timeout is not a solution: Lucene's Lock implementation polls the cache state each second and is not notified that the value is actually released very quickly, so at a minimum the polling period should be set too, but with this Infnispan configuration polling will fail: As the backend attempts to aquire the lock, Infinispan will implicitly start a transaction as this was configured this way, and then you get repeatable read semantics too, which prevents the Lock implementation to _see_ the lock as released: the polling strategy from o.a.l.Lock will look over and over but will never receive a different value. Solution: don't couple the Infinispan cache storing the index to the transaction manager. There is no downside either, I'll update the documentation to recommend this. Also this issue doesn't affect Hibernate Search 4.x as it doesn't contend any lock between the two backends: the IndexWriter is shared. -- 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-893?pag... ] Tom Waterhouse commented on HSEARCH-893: ---------------------------------------- I changed each named cache for Lucene to use org.infinispan.transaction.lookup.DummyTransactionManagerLookup and the test passed. Is this what you meant for decoupling the cache from the transaction manager? -- 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-893?pag... ] Sanne Grinovero commented on HSEARCH-893: ----------------------------------------- to clarify my previous comment: in short yes what you did is correct. An alternative solution is to not define the transactionManager configuration in the default cache, so that it won't be inherited by other caches and configure it only on those caches which are _not_ being used to store Lucene's index. What you did though obtains the same end result. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira