Hi,

I'm running Hibernate Core 3.5.1 with Hibernate Search 3.2.0.CR1

I've noticed the issue described in http://opensource.atlassian.com/project ... SEARCH-490. It happens sometimes, especially when threads pause for a debugging break and I don't immediately continue them.
But I also notice that sometimes the MassIndexer just doesn't finish and hangs with all the threads still in running state. Nothing seems to be happening or completing. I think that HSEARCH-490 has prevented the threads from completing.
Created an issue for this: http://opensource.atlassian.com/project ... SEARCH-512

I've also noticed an issue when I then kill the JVM, the lock files that are created by the Mass Indexer stay in place and are not automatically cleaned up at initialization, which requires manual intervention. In production this is kind of killing. Lock cleaning during initialization would def be on my wishlist! I've created an issue for this: http://opensource.atlassian.com/project ... SEARCH-511

One final thing of note. The MassIndexer has two purposes:
* Reindex everything
* Do it really fast

I'm most interested in the second aspect. Because I only want to reindex a subset of my data. In my case, my data is only valid between certain dates. I would like to prevent data that is "obsolete" to be reindexed. Would a list of Ids or even better, a Criteria expression, to be included (excluding everything else) for a certain class be something for the roadmap?

Kind regards,

Marc

right, feel free to post suggestions, comments and or patches to:
http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-499
Keep in mind that when updating a partial index the updates need to perform a delete+insert for each updated document, while when updating all the index can be deleted all at once, having N inserts only. So depending on the ration of valid/obsolete entities it might be faster to reindex all.

Avoid a list of Ids, as it might be too large to handle as a list.

Hi Marc,

I had the same problems with hanging MassIndexer. I realized, that I never had problems when setting all threads to 1. I could solve the problem by adjusting the thread-counts of ID-Loader, Lazy-Fetcher and so on to the "right" value. I don't know, what the right value is, but I just incresed the thread count one by one and monitored, how many threads of wich worker were busy to find the values. Sometimes I hit a combination, where it hangs, but after increasing it once more, it worked.

btw: I could speed up the indexing time from 1h45 (without MassIndexer) to 0h20. But now, in production we get problems with this, as the MassIndexer doesn't allow concurrent access to the index. Which means for us a downtime of the production system whenever the index needs to be rebuild, which is hard to accept.