2009-09-02 23 views
37

L'esecuzione di Tomcat tramite eclipse funziona correttamente in modalità non di debug, ma non in modalità di debug. Quando provo ad avviare il server Tomcat in modalità di debug, l'output della console sembra buono per un po ', ma poi inizia a rallentare e alla fine si ferma, pegging la cpu al 100%. Non penso che sia rilevante, ma nel caso in cui - ecco l'uscita della console proprio quando inizia a rallentare e alla fine fermarsi (fermandomi intendo non più uscita in console, ma ancora CPU al 100%).Accelerazione di Tomcat in modalità di debug con Eclipse IDE

2009-09-02 14:35:30,859 INFO NONE org.springframework.context.weaving.DefaultContextLoadTimeWeaver:72 - Found Spring's JVM agent for instrumentation 
2009-09-02 14:35:49,562 INFO NONE org.springframework.beans.factory.support.DefaultListableBeanFactory:414 - Pre-instantiating singletons in org.s[email protected]ed889d: defining beans [... 
2009-09-02 14:37:31,031 INFO NONE org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean:221 - Building JPA container EntityManagerFactory for persistence unit ... 

Ho provato tutto quello che potevo pensare di risolvere il problema:

    directory di lavoro
  • cleanesd Tomcat
  • riavviato eclissare
  • riavviato Windows
  • Rinnovati/puliti tutti i progetti

Ho avuto questo primo problema m la scorsa settimana usando eclipse ganimede. Stavo correndo bene in modalità debug per diversi mesi prima di questo problema. Non ho apportato modifiche significative al nostro progetto che lo avrebbero causato. Alla fine, ho aggiornato a eclissi galileo che ha risolto il mio problema. Ora, 2 giorni dopo, ho lo stesso problema in galileo. Come ho detto, funziona in modalità non-debug. Ogni aiuto è molto apprezzato.

Dovrei aggiungere che altre cose funzionano in modalità di debug, ad esempio i test di junit, quindi è qualcosa di specifico per Tomcat.

+0

Hai provato a pulire lo spazio di lavoro. A volte capita a me, quindi mi limiterò a pulire il mio spazio di lavoro. Una volta che l'area di lavoro è stata pulita, funziona perfettamente. –

+0

FYI: lo stesso vale per Intellij IDEA. Ho appena provato questo con IntelliJ 10 e sono passato da 7 minuti di avvio per tomcat 5.5.31 a 20 secondi per la mia app .... –

risposta

126

Ho superato il problema! Una volta capito, ricordo che questo è successo prima. Ho eliminato tutti i miei punti di interruzione e funziona bene. Non ho idea del motivo per cui ciò causerebbe il risultato, ma funziona.

+6

ha funzionato anche per me quando stavo avendo questo problema oggi – Ayrad

+6

Grazie per questo consiglio, puo ' ti invitare di più! =)) –

+0

è successo anche a me e la pulizia dei punti di rottura ha aiutato .. È strano però .. :) – kane77

15

Mi sono imbattuto in questo problema e questa soluzione mi ha aiutato. Tuttavia, ho avuto solo 1 punto di interruzione, anziché il 20+ di altri poster. Il mio unico punto di interruzione, tuttavia, era un breakpoint di metodo e non un punto di interruzione di linea: mi chiedo se il gran numero di chiamate di metodo all'avvio di tomcat combinato con il metodo breakpoint possa causare questo problema ... Ho appena provato un piccolo esperimento:

  1. Impostare un punto di interruzione di linea e avviato la modalità di debug - 5 secondi avvio (normale)
  2. Impostazione di un metodo di punto di interruzione e l'avvio modalità di debug - ..... non disposti ad aspettare (> 90 secondi).

Suppongo che questo sia il problema.

+4

Sì, i breakpoint e i punti di controllo del metodo (punti di interruzione sui campi) sono molto, molto più lenti dei punti di interruzione di riga. Favorisci i punti di interruzione di linea, laddove possibile, a meno che tu non sia sicuro della fonte con cui sei stato abbinato alla classe di cui stai eseguendo il debug. Ad esempio, inserire un punto di interruzione nella prima istruzione all'interno di un metodo anziché nella firma del metodo stesso. Consulta http://stackoverflow.com/a/787753/277307 per informazioni sul motivo per cui i breakpoint del metodo sono più lenti. –

+0

Grazie @ nodescript1 Conosco il motivo per cui la mia eclissi rallenta e risolvo il problema. – janwen

1

livello di registrazione passaggio automatico dal:

<root> 
    <level value="DEBUG" /> 
    <appender-ref ref="ConsoleAppender" /> 
</root> 

A:

<root> 
    <level value="OFF" /> 
    <appender-ref ref="ConsoleAppender" /> 
</root> 
3

Ho avuto questo stesso problema in Galileo. Esecuzione rapida ma scansione debug. Grazie ai post sopra, ho eliminato tutti i breakpoint e riavviato Tomcat. Questo ha risolto magicamente il problema. fyi - Avevo 2 punti di interruzione del metodo e altri breakpoint in precedenza. Ho eseguito i test per confermare la teoria precedente sui rallentamenti del metodo. Ecco cosa ho trovato.Sembra che il problema non sia il breakpoint del metodo, il problema era il breakpoint del metodo che veniva ancora visualizzato nell'elenco dei punti di interruzione nella vista di debug, ma non era presente nel codice. Intendo dire che ho cambiato i parametri di quel metodo ma il vecchio breakpoint con parametri precedenti era ancora presente nell'elenco dei punti di interruzione. Questo è stato il colpevole, quando l'ho rimosso, gli altri breakpoint del metodo non hanno rallentato il server. Quindi sembra che Eclipse stia cercando di cercare qualcosa di non esistente che sembra averlo rallentato. Spero che questo aiuti.

Problemi correlati