We have upgraded our system hibernate to 5.4.12 and hibernate search ORM to 5.11.5 with app server Websphere 18.104.22.168. We are using Elastic Search 5.6.10.
On initial startup we saw lots of threads been created for refreshing the indexes on elastic side. But we do not want this to happen, we searched and found out the property to stop this and that was "hibernate.search.autoregister_listeners". Setting this property to false, stopped creation of all these index refreshing threads.
But now we had other issue. Now we were unable to perform the dropping and creation of indexes at server startup. By using "hibernate.search.default.elasticsearch.index_schema_management_strategy" as drop-and-create. Due to the setting of "hibernate.search.autoregister_listeners" to false, this does not works anymore.
So the question arises, why in the first place we introduced this property("hibernate.search.autoregister_listeners"), answer to that we got on the official documentation side and that reads:
"The good news is that Hibernate Search is enabled out of the box when detected on the classpath by Hibernate ORM. If for some reason you need to disable it set hibernate.search.autoregister_listeners to false. Note that there is no performance penalty when the listeners are enabled but no entities are annotated as indexed."
But what if we have the entities as @Indexed, this fails.
If we have hibernate.search.autoregister_listeners settings as false then while executing fullTextEntityManager.createIndexer().startAndWait() am receiving org.hibernate.search.exception.SearchException: HSEARCH000222: The SearchFactory was not initialized. Why do I suspect the whole meaning of hibernate search ORM usage under a hibernate project is lost with this new version. If hibernate.search.autoregister_listeners is false I can not use the hibernate search at all and if its true than I've the performance issue at startup.
We strongly feel this to be a bug in new version as this functionality of drop-and-create and the mass indexer was working as expected under the older versions without this new property. Though we are sure Hibernate community must have provided this with a thought.
But again this is not working as expected keeping the other functionalities of hibernate search in mind.
Please look into this and share your thoughts.
Hibernate 5.4.12, Hibernate search 5.11.5
Thank You, will revert with the details you asked for.
Just a question, I believe we have full compatibility of hibernate search and Lucene on WebSphere?
I do not know for sure, as I'm not involved in the WebSphere project and personally have never used it. IBM support or the WebSphere community may know better.
That being said, I am not aware of any incompatibility. As long as Hibernate ORM and Lucene work correctly in Websphere, Hibernate Search should theoretically work fine as well. Hibernate Search does not rely on many Java EE features, and can run on Java SE.
I'm going to close this ticket as the original claim was invalid: hibernate.search.autoregister_listeners works as intended, even if its name is confusing.
: if you find more information about your memory problem, and it does point to Hibernate Search, please open a topic on our forums: https://discourse.hibernate.org/c/hibernate-search . We can discuss this more easily there.
Thanks Team, yes it was not an issue with Hibernate Search threads as we tested out application by disabling Hibernate Search and faced the same memory issue. That gave us confidence that its not due to Hibernate Search.
But additionally we did increased the RAM allocation to our application and that too helped in rectification of memory errors.
I’ve mentioned the same explanation on the SO thread.