Absolute ratlos darüber.
Ich habe zwei Controller-Integrationstests erfolgreich bestanden. Wenn JVM jedoch in Intellij oder via gradle check ausgeführt wird, wird die JVM nicht beendet. Wenn ich die gesamten Integrationstests auskommentiere, wird die JVM sauber beendet.
Wenn ich einen der Integrationstests debugge, kann ich eine Pause machen und sehen, dass es mehrere Threads in verschiedenen Zuständen gibt: WAITING, RUNNING, SLEEPING.
Die in application.yml verwendete Datenbank ist eine rein speicherinterne:
Wenn Sie dies auf dateibasiert ändern, wird das Problem nicht behoben. Das Ändern von DB_CLOSE_ON_EXIT=TRUE hilft auch nicht.
Ich habe versucht, @Rollback zu entfernen und sogar @Transactional mit einem Timeout zu verwenden, aber das behebt es nicht.
Das Erstellen eines Integrationstests für ein neues Projekt funktioniert ohne Deadlock / Hängen / Warten.
Ich habe die Revisionen zurückverfolgt, um den Changeset zu finden, in dem dieses Verhalten begann, aber die Änderungen waren rein in GSPs, Controllern und einer zusätzlichen Assertion & amp; Testmethode in einem der Integrationstests.
Die letzten Zeilen in den Protokollen lauten:
%Vor%Ich habe versucht, die Integrationstestmethoden auf eine Methode zu reduzieren, und das Problem tritt immer noch auf.
Die Versionen, die ich verwende, sind:
%Vor%Windows 10 64bit.
Hier ist ein Thread-Dump.
Ich habe keine Ahnung, wie ich das weiter debuggen kann. Irgendwelche Ideen?
Ich würde die Debug-Level-Protokollierung aktivieren. Auch wenn ich kann, würde ich Grails auf etwas nach 3.1.9 aktualisieren. (3.1.11 ist aktuell, wie ich dies schreibe.)
In der Nähe von grails v3.1.5 gab es Konfigurationsinkonsistenzen zwischen Grails und Hibernate. Das Grails-Team hat schnell mehrere Schnittstellen aktualisiert und sie haben es schnell geschafft.
Das Ergebnis war, dass Sie nicht die Konfiguration ausgeführt haben, von der Sie dachten, dass Sie sie wäre. Es hat sich auch auf das Cache- und Transaktionsmanagement ausgewirkt.
Zu der Zeit musste ich redundante Konfigurationen erstellen, um sicherzustellen, dass Grails auf einer Ebene eine Konfiguration erhielt, auf einer anderen eine Ruheebene. Sie müssen das nicht mehr tun, aber zu der Zeit musste ich eine Konfiguration wie die gelistete verwenden hier .
Um das Problem zu finden, habe ich die Debug-Protokollierung für Grails, den Ruhezustand und alle meine Datenbanktreiber aktiviert und den ganzen Weg durchforstet.
Dieses Plugin hilft auch bei den detaillierten Überwachungsinformationen:
Tags und Links grails grails-3.1