IndexManagerHolder picks up full name from the hierarchy root



Recently I've done huge migration from hibernate-search-3.0.0.GA to hibernate-search-orm-5.6.1.Final. In our project we have a lot of @Indexed entities and quite sophisticated hierarchy. There's abstract @Indexed @MappedSuperclass which has @Indexed subclasses. Simplifying thing it could be written like following:

I found it very interesting, that after switch all the entities started to be populated in the index for class (we're using FSDirectoryProvider as a provider) A, even though I'm trying to index B instances. Quick analysis shows, that during creation of IndexManagerGroupHolder there's wrong name passed as first argument for Following that further one could see, that in there appears to be index name evaluation:

which then followed by return statement:

If I do get comment before the loop right, this method should return the most specific index name either from or fully-qualified class name of the @Indexed entity.

Question is is my understanding correct? If so that in my case, when indexing subclass B I should get as an index name fully qualified name of class B. Problem is, that I get fqcn of A instead.

Problem appears to be serious, when one's using exclusive_index_use=true, which is default now.




Sergey Ustimenko
April 12, 2018, 2:45 PM

Hi , thanks for a quick response!

What I was implying on, talking about exclusive_index_use, that we have multiple JVMs which share the same FS index, and thus we have a lot of, which causes indexing batches to fail. Though that the other story

With your explanation that totally make sense. Could it be reflected in the documentation somehow? Maybe a short line anywhere, as I didn't find anything.

Sergey Ustimenko
April 12, 2018, 2:54 PM

>Right, in some cases you have a non-abstract entity with some non-abstract entities extending it. If you want each of those classes in its own index, you will have to use @Indexed(index = "myIndexName" on the child classes.

Right, as pointed out, I missed here the notion of non-default:

>The keyword in those comments is the "non default" index name

Sergey Ustimenko
April 12, 2018, 3:01 PM

Thanks for an explanation, & , could someone please close the ticket then, as it works as designed?

Sanne Grinovero
April 12, 2018, 3:04 PM

works as intended

Sanne Grinovero
April 12, 2018, 3:06 PM

Thanks, closing this.

Regarding your setup, I'd highly recommend to not use "shared writers". Best to point each app to a separate index, or if you really want them to share "index state" it might be preferrable to setup a JMS backend:




Sergey Ustimenko


Suitable for new contributors

Yes, likely

Pull Request


Feedback Requested