Michal
Michal

Reputation: 2423

Hibernate Search Massindexer Error

I have a problem using Hibernate Search mass indexer. The Mass Indexer produces the following error:

3815 06 Mar 2015 18:16:06 LogErrorHandler ERROR 3819571 kb HSEARCH000058: Exception occurred org.apache.lucene.index.IndexNotFoundException: no segments* file found in MMapDirectory@/srv/www/test.e-galexis.com/devlSearchIndex/com.galexis.search.importer.search.searchdb.model.Product lockFactory=NativeFSLockFactory@/srv/www/test.e-galexis.com/devlSearchIndex/com.galexis.search.importer.search.searchdb.model.Product: files: [write.lock]
 Primary Failure:
    Entity com.galexis.search.importer.search.searchdb.model.Product  Id null  Work Type  org.hibernate.search.backend.PurgeAllLuceneWork

org.apache.lucene.index.IndexNotFoundException: no segments* file found in MMapDirectory@/srv/www/test.e-galexis.com/devlSearchIndex/com.galexis.search.importer.search.searchdb.model.Product lockFactory=NativeFSLockFactory@/srv/www/test.e-galexis.com/devlSearchIndex/com.galexis.search.importer.search.searchdb.model.Product: files: [write.lock]
    at org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:864)

I checked that the Java process has the rights to create the folders and files as needed. Actually the folders and the write.lock gets created. Before the Java process starts the index.base folder is empty.

These are my versions:

        <dependency>
            <groupId>org.hibernate</groupId>
            <artifactId>hibernate-core</artifactId>
            <version>4.3.8.Final</version>
        </dependency>
        <dependency>
            <groupId>org.hibernate</groupId>
            <artifactId>hibernate-entitymanager</artifactId>
            <version>4.3.8.Final</version>
        </dependency>
        <dependency>
            <groupId>org.hibernate</groupId>
            <artifactId>hibernate-search</artifactId>
            <version>5.0.1.Final</version>
        </dependency>

I use JDK 1.8 and integrated Hibernate Search together with Spring 3.2.1.RELEASE.

The error occurs regardless the customisation I perform on the mass indexer API. At the moment I call the reindex() method from posted code, which uses the simplest form of the mass indexer API:

@PersistenceContext
private EntityManager entityManager;

@Transactional
@Override
public void reindex() throws InterruptedException {
    logger.debug("Re-indexing started");
    fullTextEntityManager().createIndexer().startAndWait();
    logger.info("Re-indexing finished");
}


protected FullTextEntityManager fullTextEntityManager() {
    return Search.getFullTextEntityManager(entityManager);
}

The injected EntityManager is instance of org.springframework.orm.jpa.SharedEntityManagerCreator$SharedEntityManagerInvocationHandler, the reindex() method is called from standalone process (i.e., no Spring/JPA JTA set-up is involved).

We are actually migrating from Hibernate Search 3.4.2.Final, where we also had problems with mass indexer only on the Linux machine, but we were able to workaround these problems by customizing the different mass indexer threads counts to one, like

  fullTextEntityManager().createIndexer(Product.class).threadsForIndexWriter(1).threadsForSubsequentFetching(1).threadsToLoadObjects(1).startAndWait();

Not all of these methods are however still available, I believe one is missing, and another one is deprecated. But I also believe it was different problem we had with the older version, it might be not related to the current one. Anyway as I mentioned I tried to customize the number of threads to 1 using the available methods but to no avail.

Upvotes: 1

Views: 1932

Answers (1)

Michal
Michal

Reputation: 2423

It turns out that this was self-made problem. I had code which deleted all files from index.base directory before the reindexing was started (...yes, I known that is what purgeAllOnStartup() is about...). This code was contained in spring bean and triggered by @PostConstruct callback at programm start-up. It turns out that the Hibernate Search/Lucene starts reading the index.base directory content (asynchronously, could it be?) at start-up too (somewhere near the place the EntityManagerFactory gets constructed I recall) and this collides with code which is deleting the files at the very moment.

Removing the code which deleted the index.base content fixed it nicely.

Upvotes: 1

Related Questions