2017-08-09 3 views
0

Ich bin sehr neu in Hibernate Search und versuche, es mit meiner Anwendung zu integrieren. Mit einem Memory-Leak-Problem konfrontiert (Threads in den Wartestatus/Park-Status).Hibernate Search Konfigurationsprobleme

Die Hibernate-Suchkonfiguration (sehr minimal) wird annotationsgesteuert. Mit:

@Indexed(index = "<index_name>") 
@IndexedEmbedded 

UND

@Field(name = "title", store = Store.YES, analyzer = @Analyzer(definition = "standardAnalyzer") 

Hibernate Search Eigenschaften:

<property name="hibernate.search.default.indexBase" value="../lucene/indexes" /> 
<property name="hibernate.search.default.directory_provider" value="filesystem" /> 
<property name="hibernate.search.default.exclusive_index_use" 
      value="false" /> 

Mit Tomcat 8 die Anwendung bereitstellen.

Mein Hauptproblem ist, dass

VisualVM zeigt deutlich, dass Hibernate Suche für jeden Index einen Sync-Verbraucher Thread erstellt. Es tut dies für jeden einzelnen Anruf, den ich an meinen Server mache (in meinem Fall sind zwei neue Threads erzeugt worden und bei jedem Anruf im geparkten Zustand). Schließlich steigt die Anzahl der Threads, bis mein Server nicht mehr reagiert.

On Server Shutdown, erhalte ich die Fehlermeldung:

09-Aug-2017 17:15:28.151 WARNING [localhost-startStop-2] org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The web application [procurewise] appears to have started a thread named [Hibernate Search sync consumer thread for index Category] but has failed to stop it. This is very likely to create a memory leak. Stack trace of thread: sun.misc.Unsafe.park(Native Method) java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:338) org.hibernate.search.backend.impl.lucene.SyncWorkProcessor.parkCurrentThread(SyncWorkProcessor.java:175) org.hibernate.search.backend.impl.lucene.SyncWorkProcessor.access$300(SyncWorkProcessor.java:35) org.hibernate.search.backend.impl.lucene.SyncWorkProcessor$Consumer.run(SyncWorkProcessor.java:147) java.lang.Thread.run(Thread.java:745)

Ich verwende Spring, Hibernate, JPA, AOP und JAX-RS, Jersey.

Umwelt Details:

Hibernate version 5.2.10.Final

Hibernate Search version 5.7.0.Final

Spring version 4.3.6.RELEASE

JPA 2.1

JAVA 8

Jersey 1.8

+0

Dies ist nicht verwandt, aber Sie sollten 'hibernate.search.default.exclusive_index_use' nicht verwenden, es sei denn, Sie wissen wirklich, warum Sie es brauchen. Ja wirklich. Welche Version der Hibernate-Suche verwenden Sie? –

+0

@ YoannRodière. Ich habe die von mir verwendete Hibernate-Suchversion hinzugefügt. Die exclusive_index_use-Eigenschaft war auch ein Versuch, die Verwendung von Sperren aufzuheben, wenn man annimmt, dass der MassIndexer mehrere Threads erzeugt, was meiner Meinung nach das Problem war. Aber Punkt bemerkt. –

Antwort

0

Dieser Thread sollte automatisch stoppen, wenn Hibernate Search heruntergefahren, was automatisch geschieht, wenn Hibernate ORM heruntergefahren wird.

Ich sehe zwei Gründe für diese Warnung: Entweder hat Tomcat die Threads überprüft, während Hibernate ORM noch heruntergefahren wurde, oder Sie haben Hibernate ORM überhaupt nicht gestoppt.

Ich würde vorschlagen, überprüfen Sie Ihren Shutdown-Prozess, sehen, ob Hibernate ORM korrekt geschlossen ist (normalerweise verwenden Sie org.hibernate.SessionFactory.close(), aber ich würde Spring erwarten, dass selbst zu kümmern), (so dass Ihr Tomcat erst nach Abschluss aller Schließungen Prüfungen durchführt).

+0

Mein Problem hier ist nicht die Warnung/der Fehler, den Tomcat beim Herunterfahren gibt. Das Problem ist, dass für jeden Anruf 2 neue Threads erzeugt und in den geparkten Zustand versetzt werden. Im Laufe der Zeit gibt es so viele Threads, dass mein Server nicht mehr reagiert. Ist es –

+0

@HarshvardhanDudeja Von dem, was Sie mir sagen, scheint es, als ob Sie eine Hibernate ORM SessionFactory für jeden Anruf auf Ihrem Server erstellen und es nicht sogar schließen. Was wirklich, wirklich schlecht ist, egal ob Sie Hibernate Search verwenden oder nicht. Sie sollten Ihre Hibernate-ORM/JPA-Konfiguration überprüfen, insbesondere, wie Sie Persistenz-bezogene Beans konfiguriert haben und wie Sie den EntityManager/die Sitzung abrufen. –

+0

Wie schon erwähnt, ist die Konfiguration Annotation-getrieben. Ich verwende @PersistenceContext, um den Entity Manager automatisch zu starten. Die JPA-Konfiguration enthält nur einige Hibernate-Eigenschaften (z. B. show-sql).Nur um zu erwähnen, dass ich Spring Servlet als Brücke benutze, um Spring und Jersey zu integrieren. Ich werde die Frage auch aktualisieren –