Отладчик Eclipse всегда блокирует ThreadPoolExecutor без каких-либо явных исключений, почему?


209

Я работаю над своими обычными проектами на Eclipse, это приложение J2EE, созданное с помощью Spring, Hibernate и так далее. Я использую Tomcat 7 для этого (без особой причины, я не использую никаких новых функций, я просто хотел попробовать это). Каждый раз, когда я отлаживаю свое приложение, случается, что отладчик Eclipse выскакивает, как будто он достиг точки останова, но это не так, фактически он останавливается на исходном файле Java ThreadPoolExecutor. На консоли нет трассировки стека, она просто останавливается. Затем, если я нажимаю на резюме, оно продолжается, и приложение работает отлично. Вот что показано в окне отладчика:

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

Я действительно не могу объяснить это, потому что я не использую ThreadPoolExecutorвообще. Должно быть что-то из Tomcat, Hibernate или Spring. Это очень раздражает, потому что мне всегда приходится возобновлять работу во время отладки.

Есть какие-нибудь подсказки?


1
@ AmosM.Carpenter - это не Java EE, не JEE? Кажется, даже ваша собственная ссылка
такова

Ответы:


290

Опубликованная трассировка стека указывает на то, что RuntimeException обнаружен в потоке Daemon. Обычно это не выполняется во время выполнения, если только первоначальный разработчик не уловил и не обработал исключение.

Как правило, отладчик в Eclipse настроен на приостановку выполнения в месте, где было сгенерировано исключение , для всех неперехваченных исключений . Обратите внимание, что исключение может быть обработано позже, ниже в кадре стека и может не привести к завершению потока. Это будет причиной наблюдаемого поведения.

Настройка поведения Eclipse просто:
Перейти к Window > Preferences > Java > Debug и снимите флажок Приостановить выполнение на неперехваченных исключениях .


В моем случае stackoverflow.com/questions/8911146/… это не помогло :-(
Gangnus

5
Я написал об ошибке Eclipse 384073 об этом, так как это делает эту опцию непригодной для отладки веб-приложений.
Даниэль Серодио

9
Отключение «Приостановить выполнение на необработанных исключениях» в Eclipse - плохой обходной путь: что, если вы хотите, чтобы Eclipse приостанавливал действие на реальных необработанных исключениях, например, происходящих из вашего собственного кода? Мне кажется, это ошибка в Tomcat ...

3
@Luis: я удивился тому же! Согласно bugs.eclipse.org/bugs/show_bug.cgi?id=384073#c4 , можно: отключить глобальные точки останова, создать новую точку останова на java.lang.Exception и применить исключительный фильтр к этой вновь созданной точке останова.
ректиде

3
@ Даниэль ... Может быть, лучше подать вопрос в команду Tomcat. Я думаю, что это поведение является новым в Tomcat 7 ... Eclipse делает то, что он должен делать ... (никогда не думал, что однажды я буду защищать Eclipse ... :)
Stijn de Witt

48

Существует более конкретное решение, которое предотвращает взлом Eclipse RuntimeExceptionтолько для заданного класса.

  1. Добавить новую точку останова исключения с точки зрения отладки
  2. Перейти к его свойствам
  3. Перейти к фильтрации
  4. В разделе «Ограничить выбранные места» нажмите « Добавить класс ».
  5. Добавить java.util.concurrent.ThreadPoolExecutor
  6. Снимите флажок , означающий, что они будут игнорироваться

1
Я не могу заставить его работать с Tomcat 7 и Eclipse / STS 3.4.0. Есть ли другие необходимые настройки? Должна ли эта точка останова быть зарегистрирована RuntimeException? Должен ли он быть включен или отключен? Должны ли «Пойманные места» и «Пойманные места» быть включены или выключены?
Хенрик Хаймбюргер

2
Похоже, что точка останова исключения должна быть java.lang.RuntimeException, должна быть включена, должна быть только для необработанного местоположения и не должна проверяться класс java.util.concurrent.ThreadPoolExecutor.
Марио

К сожалению, в Ubuntu 14.04 «Ограничение выбранных местоположений» недоступно для Eclipse Luna 4.4.0.
eeezyy


2

Я заметил, что это часто происходит после изменения файлов сервера (jsp или java), и у STS возникают проблемы с перезагрузкой приложения.

Обычно это приводит к перезапуску сервера, чтобы синхронизировать изменения.

После введения JRebel - кажется, ушел. Итак, я хотел бы думать, что это является воспроизводимой проблемой в STS при горячей замене кода в режиме отладки.

Удаляя нативную горячую замену, она устраняет проблему с ее разрывом внутри класса ThreadPoolExecutor.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.