Определите, когда приложение перестает отвечать на запросы, убейте его и перезапустите

Question

Я занимаюсь разработкой высокопроизводительного приложения, которое, по-видимому, приводит к тому, что основной процесс перестает отвечать и время от времени зависает из-за перегрузки (появляется диалоговое окно закрытия приложения, поэтому приложение никогда не завершает работу само по себе , просто зависает, что раздражает)

Я приветствую любой чистый способ программно определять, когда приложение заморожено, поэтому я могу использовать BAT (или другое) для автоматического завершения процесса и перезапуска.

Конечно, это временное исправление при проверке приложения, но в то же время это очень удобно.

TieBreaker: Кстати, есть ли способ переопределить окна?Экран исключения и просто выйти из приложения ???В большинстве случаев это раздражающая особенность.

РЕДАКТИРОВАТЬ:
ДЛЯ БОГА: приложение IS ужасное замораживание, THOUGH каждая задача запускается в BG Workers и потоках !!!И я указал это в комментариях.Давай, я не такой тупой.То, что ваше приложение работает с работниками BG, не означает, что оно никогда не зависает!И, как я уже сказал, пожалуйста, ПРОСТО ответьте на мой вопрос, я не ищу уроков о том, как создать свое приложение, над которым я уже работаю, и я знаю, что нужно сделать.Как указано много раз, мне просто нужно исправить на сервере в то же время.Спасибо.

Answer 1

Я скажу это, если никто другой не сделает :) Создайте отдельное приложение для форм, которое ...

Process[] prs = Process.GetProcesses();

foreach (Process pr in prs)
{
    if (!pr.Responding) 
    {
        try
        {
            pr.Kill();
        }
        catch { }
    }
}

//then to restart-
var process = new Process
{
    StartInfo = new ProcessStartInfo
    {
        FileName = @"C:\yourapp.exe"
    }
};
process.Start();

Очевидно, упрощенно.

Answer 2

Мы справляемся с этим в службе, так как основная служба exe должна быть чуть больше, чем оболочка, запускающая дочерние потоки.

Затем дочерние потоки отвечают за сообщение родительскому потоку всякий раз, когда онизапишите последнюю дату / время, когда они были «просмотрены».

Через регулярные промежутки времени приложение-служба проверяет список дочерних процессов и, если они не были просмотрены в течение заранее определенного периода времени (т. е. 2минут), но не сообщил, что он был закрыт, родительский процесс сначала попытается присоединиться к потоку и корректно завершить его (обычно не удается), а затем, если это не сработало, прерывает поток.

Мы успешно использовали этот подход в течение многих лет, начиная с того момента, когда запущенная нами служба OCR постоянно зависала из-за ошибок в программном обеспечении OCR.

Answer 3

Удалите все интенсивные задачи процессора из графического интерфейса и снова откройте графический интерфейс, чтобы сообщать о любых статусах.

Основное приложение никогда не должно зависать . Я написал приложение, которое генерировало более 500 потоков (все сразу) и управляло ими, поскольку они асинхронно (.net 2) обрабатывали несколько вызовов базы данных. Я считаю, что вам нужно систематически переводить все процессы в безопасную для потоков ситуацию и удалять любые прямые вызовы GUI.

ADDENDUM Как я запустил 500+ потоков:

1. Использование интеллектуальных блокировок, выполненных с самого начала во всех общих местах данных. См. Статьи в моем блоге
   
   Интеллектуальная блокировка ресурсов в C # .Net для безопасного потока кода
   C # Многопоточность с использованием ThreadPool, анонимных делегатов и блокировок
   
   
2. Создан интерфейс, в котором указана операция с данными, состояние ошибки в качестве свойства.
3. Создан базовый класс Threading (для классов в # 4 и # 5), который создал, запустил и очистил операции потока. Нет бизнес-логики, только метод обработки потоков в одном месте.
4. Класс создан на основе интерфейса в # 2 и также получен из шага # 3. Класс через интерфейс был необходим для получения данных и размещения данных (потокобезопасность через локализованную блокировку) и отчета о его состоянии. Класс также предназначен для отказа от цикла потока, если работа не выполняется через поток. Sleep (0) вместо ожидания "занято".
5. Создан класс менеджера (который работал в своем собственном потоке и был получен из # 3). Он запустил классы 1-N # 4 для выполнения работы. Каждый из этих экземпляров был помещен в рабочий список.
6. Класс Manager просто просматривал рабочий список на наличие экземпляров, которые сообщали, что их работа была выполнена, если это было сделано, он перемещал экземпляр к выполненной работе. Класс Manager также хранит записи о состоянии (потокобезопасности с помощью блокировок) для открытых свойств (а также о любых сообщениях об ошибках дочерних экземпляров). Менеджер отказывался от цикла обработки после каждого запуска и просидел 250 миллисекунд, прежде чем начать снова.
7. В потоке графического интерфейса были рабочие таймеры, связанные с получением определенного статуса от менеджера. Они будут извлекать данные из свойств менеджера и вызывать обратно графический интерфейс для нацеливания на элемент управления (gridview), который сообщает обо всех состояниях и ошибках.

Этим я смог добиться того, чтобы отдельные потоки выполняли определенную работу, и если процесс столкнулся с проблемой, он сообщил об этом или сообщил об успехе или сбое. Эти сообщения пузырились до менеджера, который пузырился до таймеров, которые пузырились до GUI. Графический интерфейс не обрабатывал никакой бизнес-логики, кроме как запускать менеджер и таймеры.

---

Я понимаю, что это не помогает вашей ситуации прямо сейчас, и я чувствую вашу боль . Но до тех пор, пока вы не сможете отделить бизнес-логику от графического интерфейса и обрабатывать ситуации с ошибками в потоках (фоновые рабочие) и передавать их в GUI, у вас все еще будет это разочарование текущим кодом.

Если что-то блокируется, это признак того, что бизнес-логика слишком тесно связана с операцией графического интерфейса, и это необходимо развести, прежде чем вы получите желаемую производительность из графического интерфейса.

НТН