Java appare bloccato

Question

Utilizzo il wrapper del servizio Java in un'applicazione personalizzata da un po 'di tempo e funziona bene. Da quando ha aggiornato la nostra applicazione a una nuova versione negli ultimi giorni, JVM ha iniziato a bloccarsi e quindi wrapper stampa questo nel registro: JVM appare bloccato: Timeout in attesa del segnale da JVM.

Quindi termina automaticamente la JVM e avvia nuovamente l'app. Questo accade dopo circa 10 ore di funzionamento, il che rende solo più difficile il debug.

Naturalmente ho intenzione di guardare attraverso i cambiamenti che abbiamo fatto, ma grandi cambiamenti sono stati fatti che ho il sospetto sta causando questo tipo di problema.

Dove posso cercare di capire cosa sta succedendo? I messaggi di debug dall'applicazione non indicano nulla di interessante. Se la JVM si blocca, di solito creerà un dump, che può aiutare nel debugging, ma è sospeso, quindi non sta creando un dump. Se faccio in modo che non riavvii automaticamente il servizio c'è qualcosa che posso fare per ottenere alcune informazioni utili dalla JVM prima di riavviarlo?

Mi sembra che la JVM non debba bloccarsi da errori di programmazione tipici. Che cosa hai incontrato prima che possa causare l'interruzione della JVM?

Answer 1

Ho avuto un paio diverse versioni di una libreria nel classpath (JBPM). Con il wrapper puoi usare i caratteri jolly per includere i barattoli. Fai attenzione con questo, perché potresti accidentalmente includere più di quanto dovresti.

Questo è un articolo IBM che fornisce informazioni su debugging hangs in Java. E 'in pratica dice che ci sono due cose che possono causare si blocca:

1. Un ciclo infinito,
2. Un deadlock.

Da allora ho dovuto eseguire il debug di altri problemi di sospensione. Su linux puoi inviare a JVM il segnale QUIT per farlo fare un dump di thread alla console. Questo aiuta davvero a capire dove si trova il problema. Utilizzare questo comando per farlo: uccidere -quit

Modifica 6/13/2017

In questi giorni io uso jmap incluso nel JDK per scaricare l'intera memoria del programma. Quindi utilizzo Eclipse Memory Analyzer per vedere lo stato esatto del programma in caso di arresto anomalo. È possibile esaminare l'elenco di thread attivi e quindi controllare le variabili in ogni frame dello stack.

/usr/java/latest/bin/jmap -dump:file=/tmp/app-crash.hprof <PID> 

Dove PID è l'ID di processo del processo java.

Answer 2

In che ambiente ci si trova? OS, versione JVM, architettura hardware?

Che suona come un insetto, e dato che ci vogliono molte ore, suona come un insetto risorse esaurimento di qualche tipo.

Answer 3

Leggere il numero wrapper.ping.timeout property. Il software wrapper comunica con JVM ogni tanto per assicurarsi che sia vivo. Se tale comunicazione non riesce per qualsiasi motivo, il wrapper considera il processo bloccato e tenta di riavviarlo.

A seconda di come l'applicazione è progettato, JVM potrebbe essere occupato ad elaborare qualcosa di diverso quando l'involucro cerca di "ping" di esso.

Answer 4

vedere se è possibile utilizzare la Visual VM per vedere cosa sta succedendo. Chiedi a Visual VM di monitorare l'app per tutto il tempo e, quando smette di funzionare, puoi decidere cosa è sbagliato.

Se la VM si blocca è possibile ottenere lo stato dei thread ... Penso che la Visual VM renderà un po 'più semplice la configurazione rispetto al solito ctrl-break (o qual è la combinazione della chiave).

(Edit sulla base di commenti)

provato questo. L'ultima volta è appeso il numero di thread e la quantità di memoria in uso erano abbastanza basso, in modo nessuno di coloro che stanno causando il problema . Sfortunatamente dopo che si blocca lo e il wrapper lo termina non è possibile ottenere un dump del thread.

C'è un modo per eseguirlo senza il wrapper per eseguirne il debug? Inoltre, se si utilizza il profiler NetBeans, potrebbe darsi la possibilità di affrontarlo quando si interrompe (Verificherò più tardi oggi e vedrò se riesco a scoprire se si comporterebbe diversamente).