Debuger Eclipse zawsze blokuje na ThreadPoolExecutor bez żadnego oczywistego wyjątku, dlaczego?

209

Pracuję nad moimi zwykłymi projektami w Eclipse, jest to aplikacja J2EE, wykonana w Spring, Hibernacja i tak dalej. Używam do tego Tomcat 7 (bez konkretnego powodu, nie wykorzystuję żadnej nowej funkcji, chciałem tylko spróbować). Za każdym razem, gdy debuguję moją aplikację, zdarza się, że debuger Eclipse wyskakuje, jakby osiągnął punkt przerwania, ale tak nie jest, w rzeczywistości zatrzymuje się na źródłowym pliku Java ThreadPoolExecutor. Na konsoli nie ma śladu stosu, po prostu się zatrzymuje. Następnie, jeśli kliknę przycisk Wznów, będzie on kontynuowany, a aplikacja będzie działać idealnie. Oto, co pokazuje okno debugera:

Daemon Thread ["http-bio-8080"-exec-2] (Suspended (exception RuntimeException)) 
    ThreadPoolExecutor$Worker.run() line: 912   
    TaskThread(Thread).run() line: 619

Naprawdę nie potrafię tego wyjaśnić, ponieważ w ogóle nie używam ThreadPoolExecutor. Musi to być coś z Tomcat, Hibernacji lub Wiosny. To bardzo denerwujące, ponieważ zawsze muszę wznawiać pracę podczas debugowania.

Jakieś wskazówki?

— gotch4
źródło

1

@ AmosM.Carpenter, czy to nie Java EE, a nie JEE? Nawet własny związek wydaje się sugerować, tak

— eis

290

Wysłany ślad stosu wskazuje, że w wątku Daemon napotkano wyjątek RuntimeException. Zwykle nie jest to rejestrowane w środowisku wykonawczym, chyba że pierwotny programista wychwycił wyjątek i zajął się nim.

Zwykle debuger w środowisku Eclipse jest skonfigurowany do zawieszania wykonywania w miejscu, w którym został zgłoszony wyjątek , dla wszystkich nieprzechwyconych wyjątków . Zauważ, że wyjątek może być obsłużony później, niżej w ramce stosu i może nie doprowadzić do zakończenia wątku. Byłoby to przyczyną obserwowanego zachowania.

Konfiguracja zachowania Eclipse jest prosta:
Przejdź do Window > Preferencje > Java > Debuguj i usuń zaznaczenie Wstrzymaj wykonywanie w przypadku nieprzechwyconych wyjątków .

— Vineet Reynolds
źródło

W moim przypadku stackoverflow.com/questions/8911146/... to nie pomogło :-(

— Gangnus

5

Złożyłem o tym błąd 384073 w Eclipse, ponieważ zasadniczo uniemożliwia korzystanie z tej opcji podczas debugowania aplikacji internetowych.

— Daniel Serodio

9

Wyłączenie „Zawieszenia wykonywania w przypadku nieprzechwyconych wyjątków” w Eclipse jest złym obejściem: co zrobić, jeśli chcesz, aby Eclipse zawieszał się w przypadku prawdziwych nieprzechwyconych wyjątków, np. Pochodzących z własnego kodu? Wydaje mi się, że to błąd w Tomcat ...

3

@Luis: Zastanawiałem się tak samo! Zgodnie z bugs.eclipse.org/bugs/show_bug.cgi?id=384073#c4 można: wyłączyć globalne punkty przerwania, utworzyć nowy punkt przerwania w java.lang.Exception i zastosować filtr wyłączny w stosunku do nowo utworzonego punktu przerwania.

— rektide

3

@Daniel ... Może lepiej zgłosić problem z zespołem Tomcat. Myślę, że takie zachowanie jest nowe w Tomcat 7 ... Eclipse robi to, co powinno ... (nigdy nie myślałem, że kiedyś obronię Eclipse ... :)

— Stijn de Witt

47

Istnieje bardziej specyficzne rozwiązanie, które zapobiega zrywaniu się Eclipse na RuntimeExceptions rzucanym tylko z danej klasy.

Dodaj nowy punkt przerwania wyjątku z perspektywy debugowania
Przejdź do jego właściwości
Przejdź do Filtrowania
W „Ogranicz do wybranych lokalizacji” kliknij „ Dodaj klasę ”
Dodaj java.util.concurrent.ThreadPoolExecutor
Odznacz pole wyboru , co oznacza, że zostaną zignorowane

— EngineerBetter_DJ
źródło

1

Nie mogę sprawić, żeby działał z Tomcat 7 i Eclipse / STS 3.4.0. Czy konieczne są jakieś inne ustawienia? Czy ten punkt przerwania powinien zostać zarejestrowany RuntimeException? Czy to musi być włączone lub wyłączone? Czy „Złapane lokalizacje” i „Nie złapane lokalizacje” powinny być włączone, czy wyłączone?

— Henrik Heimbuerger,

2

Wygląda na to, że punktem przerwania wyjątku musi być wyjątek java.lang.RuntimeException, musi być włączony, musi być tylko dla lokalizacji nieprzechwyconej i nie może mieć sprawdzonej klasy java.util.concurrent.ThreadPoolExecutor.

— mario

Niestety w Ubuntu 14.04 „Ogranicz do wybranych lokalizacji” nie jest dostępne, dla Eclipse Luna 4.4.0.

— eeezyy

24

To zachowanie jest wyzwalane przez tomcat podczas ponownego ładowania aplikacji internetowej. Jest to część funkcji tomcat „ochrona przed wyciekiem pamięci”, która (między innymi) wymusza odnowienie swoich wątków.

Zostało to naprawione w wersjach 7.0.54 i 8.0.6 tomcat: https://issues.apache.org/bugzilla/show_bug.cgi?id=56492

— slaurent
źródło

2

Zauważyłem, że często występuje to po modyfikacji plików serwera (jsp lub java) i STS ma problem z ponownym załadowaniem aplikacji.

Zwykle prowadzi to do ponownego uruchomienia serwera w celu zsynchronizowania zmian.

Po wprowadzeniu JRebel - wygląda na to, że zniknął. Chciałbym więc pomyśleć, że jest to powtarzalny problem w STS, kiedy kod wymiany w trybie debugowania jest gorący.

Usuwając natywną funkcję wymiany hots, eliminuje problem z awarią wewnątrz klasy ThreadPoolExecutor.

— DaCrazyCoder
źródło