2016-05-30 33 views
9

Assolutamente imputato su questo.Grails Controller/Test di integrazione ha esito positivo ma si blocca per sempre

Ho due test di integrazione del controller che superano con successo. Tuttavia, quando si esegue in Intellij o tramite gradle check, la JVM non esce mai. Se commento gli interi test di integrazione, la JVM esce in modo pulito.

Durante il debug di uno qualsiasi dei test di integrazione, riesco a premere pausa e vedere che ci sono diversi thread in stati diversi: WAITING, RUNNING, SLEEPING.

Il database utilizzato in application.yml è puramente un in-memory uno:

url: jdbc:h2:mem:testDb;MVCC=TRUE;LOCK_TIMEOUT=10000;DB_CLOSE_ON_EXIT=FALSE 

La modifica di questo file in base a non risolvere il problema. Modifica DB_CLOSE_ON_EXIT=TRUE non aiuta neanche.

Ho provato a rimuovere @Rollback e anche a usare @Transactional con un timeout, ma questo non lo aggiusta.

Creazione di un test di integrazione su un nuovo progetto funziona senza deadlock/sospensione/attesa.

Sono tornato indietro attraverso le revisioni per trovare il changeset in cui è stato avviato questo comportamento, ma le modifiche riguardavano esclusivamente GSP, Controllers e un ulteriore metodo di prova & in uno dei test di integrazione.

Le ultime righe nei registri sono:

INFO org.springframework.boot.context.embedded.AnnotationConfigEmbeddedWebApplicationContext - Closing org.springframework.boot[email protected]73386d72: startup date [Mon May 30 18:48:25 BST 2016]; root of context hierarchy 
INFO org.springframework.context.support.DefaultLifecycleProcessor - Stopping beans in phase -2147483648 
INFO org.grails.plugins.datasource.TomcatJDBCPoolMBeanExporter - Unregistering JMX-exposed beans on shutdown 
INFO org.grails.plugins.datasource.TomcatJDBCPoolMBeanExporter - Unregistering JMX-exposed beans 
INFO org.hibernate.tool.hbm2ddl.SchemaExport - HHH000227: Running hbm2ddl schema export 
INFO org.hibernate.tool.hbm2ddl.SchemaExport - HHH000230: Schema export complete 

ho provato tagliando i metodi di prova di integrazione verso il basso per un metodo e la questione ancora si verifica.

Le versioni che sto usando sono:

$ ~/apps/grails-3.1.5/bin/grails --version 
|Grails Version: 3.1.5 
|Groovy Version: 2.4.6 
|JVM Version: 1.8.0_92 

di Windows 10 a 64 bit.

Here's una discarica di filo.

Non ho idea di come eseguire il debug di questo ulteriore. Qualche idea?

+1

Avete provato con per impostare 'DB_CLOSE_ON_EXIT = TRUE sull'URL database? – Joch

+0

L'ho appena provato, non lo aggiusta. Grazie comunque. Post aggiornato. –

+1

Non si dispone di alcun thread che non è stato arrestato o impostato come daemon? La JVM si è fermata quando si eseguono test di integrazione su un nuovo progetto? – Joch

risposta

1

Accenderei la registrazione del livello di debug. Inoltre, se è possibile, vorrei aggiornare Grails a qualcosa di post 3.1.9. (3.1.11 è attuale mentre scrivo questo.)

Proprio attorno al grails v3.1.5 c'erano incoerenze di configurazione tra Grails e Hibernate. Il team di Grails stava rapidamente aggiornando diverse interfacce, e ci riuscirono rapidamente.

Il risultato è stato che non hai eseguito la configurazione che pensavi di essere. Ha inoltre influito sulla gestione della cache e delle transazioni.

A quel tempo, dovevo creare configurazioni ridondanti per assicurarmi che Grails stesse ottenendo configs a un livello, ibernato a un altro. Non devi farlo più, ma al momento, ho dovuto usare una configurazione come quella elencata here.

Per trovare il problema, ho attivato la registrazione di debug per Grails e Hibernate e tutti i miei driver di database e l'ho passato completamente.

This plugin aiuta anche con il dettaglio di monitoraggio Informazioni: