Shutting down Hibernate Search gracefully / Tomcat leaks

nullPainter · **Joined:** Tue Oct 09, 2007 10:48 pm **Posts:** 11

Hi,

We are in the process of integrating Hibernate Search in a new project which uses Spring, Hibernate and JPA. The application is being deployed in a war file in Tomcat 7.

Unfortunately it appears that Hibernate Search isn't properly cleaning up after itself on undeploy - MAT is indicating that org.hibernate.search.batchindexing.impl.Executors$BlockPolicy is still in memory, which pulls the Hibernate SessionFactory with it.

I see on the FAQ that I need to close the SessionFactory - I imagine this is done by Spring anyway but even manually closing it in a listener class doesn't seem to achieve anything.

Does anyone have any clues? I'm brand new to Hibernate Search and have already spent much of a day getting nowhere :(

Many thanks,
Matt

sanne.grinovero · **Posted:** Fri Dec 30, 2011 9:02 am

Hi nullPainter,
I'm not aware of such issues, but glad to look into it.
which version of Hibernate Search is that? Do you have any errors logged, especially during shutdown?

Regarding Spring taking care of it, I'm not sure; please check that reading the Search logs for successful shutdown.

nullPainter · **Joined:** Tue Oct 09, 2007 10:48 pm **Posts:** 11

Hi Sanne,

I can confirm that Spring does close the SessionFactory in ContextLoaderListener.contextDestroyed():

The following code in contextDestroyed() in my subclass of ContextLoaderListener:

Code:

      System.out.println("SessionFactory closed: " + sessionFactory.isClosed());
      super.contextDestroyed(event);
      System.out.println("SessionFactory closed: " + sessionFactory.isClosed());

displays the following:

Code:

SessionFactory closed: false
Dec 31, 2011 12:49:31 PM org.apache.catalina.core.ApplicationContext log
INFO: Closing Spring root WebApplicationContext
Closing Root WebApplicationContext: startup date [Sat Dec 31 12:49:16 NZDT 2011]; root of context hierarchy
Destroying singletons in org.springframework.beans.factory.support.DefaultListableBeanFactory@c5e1d4: defining beans [org.springframework.security.access.expression.method.DefaultMethodSecurityExpressionHandler#0,org.springframework.security.access <snip>
Closing JPA EntityManagerFactory for persistence unit 'Archway'
SessionFactory closed: true

We're using Hibernate Search 4.0.0.Final, however the issue also manifested itself in 3.4.0.

There are no errors in the logs for startup or shutdown. Is there anything else I can provide which could assist?

Many thanks,
Matt

sanne.grinovero · **Posted:** Tue Jan 03, 2012 2:24 pm

Hi Matt,
I've been writing some tests, and it seems that simply starting a Search enabled SessionFactory and closing it - even using some of the features - is closing all resources correctly. It's possible you're using some special feature which would lead to this issue, but will need your help to track it down.

I've found https://issues.apache.org/jira/browse/LUCENE-2822, which is a limitation in Lucene we didn't spot before and is being used by Search if you set timeouts on full text queries. Is that possibly your problem?
Created http://opensource.atlassian.com/project ... EARCH-1024

If not, could you post a full threaddump so that I can have a look at which threads are still alive and what are they waiting for?

Another possible option is that the async indexing queue didn't finish in applying all changes, so when shutting down it has to finish writing on the index. Do you still see lot of disk activity when waiting for a shutdown? In that case it's possible that it will shutdown, given enough time to flush all changes.

Quote:

Unfortunately it appears that Hibernate Search isn't properly cleaning up after itself on undeploy - MAT is indicating that org.hibernate.search.batchindexing.impl.Executors$BlockPolicy is still in memory, which pulls the Hibernate SessionFactory with it.

I don't understand this, BlockPolicy has no reference to the SessionFactory. Are you seeing one?

nullPainter · **Joined:** Tue Oct 09, 2007 10:48 pm **Posts:** 11

Hi Sanne,

Quote:

Another possible option is that the async indexing queue didn't finish in applying all changes, so when shutting down it has to finish writing on the index. Do you still see lot of disk activity when waiting for a shutdown? In that case it's possible that it will shutdown, given enough time to flush all changes.

The application is fully shutting down in Tomcat; it was just leaving objects behind in memory. However, I tried waiting for a few minutes and the objects went away - so yes, I think you're right!

Thank you very much for your help; it's been much appreciated.

Regards,
Matt

sanne.grinovero · **Posted:** Tue Jan 03, 2012 6:15 pm

ah nice so it was simpler than expected.
Just one observation: if this happens regularly it seems indexing is not fast enough for you, as it obviously lags behind on your other operations, I'd suggest to look into tuning of indexing parameters as they can speedup a lot; http://docs.jboss.org/hibernate/search/4.0/reference/en-US/html_single/#lucene-indexing-performance

nullPainter · **Joined:** Tue Oct 09, 2007 10:48 pm **Posts:** 11

Thanks Sanne; I'll look into this.