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

204

Я работаю над своими обычными проектами на 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? Кажется, даже ваша собственная ссылка
Теги:
tomcat
debugging

4 ответа

256
Лучший ответ

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

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

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

Поделиться
  • 0
    В моем случае stackoverflow.com/questions/8911146/… это не помогло :-(
  • 5
    Я написал об ошибке Eclipse 384073 об этом, так как это делает эту опцию непригодной для отладки веб-приложений.
Показать ещё 4 комментария
43

Здесь есть более конкретное решение, которое предотвращает разбиение Eclipse на RuntimeException только на заданный класс.

  • Добавить новую точку останова исключений с точки зрения отладки
  • Перейдите в его свойства
  • Перейдите в Фильтрация
  • В разделе "Ограничить выбранные местоположения" нажмите " Добавить класс"
  • Добавить java.util.concurrent.ThreadPoolExecutor
  • Снимите флажок, что означает, что они будут игнорироваться
Поделиться
  • 1
    Я не могу заставить его работать с Tomcat 7 и Eclipse / STS 3.4.0. Есть ли другие необходимые настройки? Должна ли эта точка останова быть зарегистрирована в RuntimeException ? Должен ли он быть включен или отключен? Должны ли «Пойманные места» и «Пойманные места» быть включены или выключены?
  • 0
    Это улучшило качество моей жизни в Eclipse, спасибо.
Показать ещё 2 комментария
22

Это поведение запускается tomcat при перезагрузке webapp. Это часть функции tomcat защиты от утечки памяти, которая (помимо прочего) заставляет возобновить его потоки.

Теперь это исправлено из версий 7.0.54 и 8.0.6 из tomcat: https://issues.apache.org/bugzilla/show_bug.cgi?id=56492

Поделиться
  • 0
    та же проблема и для Jboss ...
2

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

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

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

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

Поделиться

Ещё вопросы

Сообщество Overcoder
Наверх
Меню