Привет.

Хочу поинтересоватся опытом опытных разработчиков )

У меня имеется следующая задачка: написать WCF сервис. Но при этом он должен быть максимально живучим. Если возникают исключительные ситуации, то желательно писать в лог, для последующего анализа, но не падать.
Упавший сервис банально не кому будет перезапустить до вечера или следующего утра :)

Я думаю как бы это сделать.

У меня два решения видится:
1. Обрабатывать каждый пришедший запрос в отдельном потоке (Task). В случае исключения, сваливать его в лог для анализа (со стеком вызовов и тем, что еще смогу записать в лог в try catch).
Но есть особо разрушительные исключения, разрушающих программу и домен, после возникновения которых крайней не рекомендуется что-то вообще делать, а по быстрее завершить программу. Получается нужен список этих разрушительных исключений ( он есть ? ), и тогда в программе проверять - что если это одно из них, убиваем все потоки и выходим.

2. Либо запускать каждый запрос в отдельном EXEшнике вообще. Передавать ему как либо параметры (через параметры ком строки, разделенную память, или через COM или через БД или еще как угодно).
После отработки каждого потока этот EXE все равно завершится, так что почти не важно есть ли у него проблемы с разрушительными исключениями или нет. Он может отчитываться о своей работе в БД. Так мы узнаем как завершилось приложение: успешно или с исключением).
Также придется периодически проверять все запущенные EXEшники и убивать зависшие (если EXE уже 20 минут не выполнил порученную задачу, убиваем его).


Кто нибудь писал "живучие" программы ? Что можете подсказать ?

pation
вам кто то про это сказал или вы сами додумались?

Вот исключение, про которое помню
http://msdn.microsoft.com/ru-ru/library/system.stackoverflowexception(v=vs.110).aspx

"В предыдущей версии платформы .NET Framework приложение могло перехватывать объект StackOverflowException (например, для выхода из состояния неограниченной рекурсии). Однако в данный момент такой подход не одобряется, поскольку для надежного перехвата исключения переполнения стека и продолжения выполнения программы необходимо значительное количество дополнительного кода.
Начиная с платформы .NET Framework версии 2.0 объект StackOverflowException нельзя перехватывать с помощью блока try-catch и соответствующий процесс по умолчанию завершается
"
Есть и другие исключения, которые я сам не помню или даже не знаю. Вроде бы при Out of Memory exception тоже не рекомендуется пытаться делать осмысленную работу в программе, а сразу завершаться.

Я и хотел у форумчан узнать список таких исключений.
Думал, раз есть такие рекомендации, значит им кто-то следует :)
А значит, имеет список этих исключений, при которых программу рекомендуется терминейтить на месте.

Arm79MsSql_Study,

Неперехватываемые исключения сделаны такими, так как их обработка изнутри невозможна или сильно затруднена. Например, OutOfMemory. Наиболее приемлемый вариант ИМХО - это перезапуск приложений, что приводит нас к:

Arm791) нужен хост либо win-сервис (в свойствах можно прописывать действия при краше), либо iis (сам перезапускает)

Вы хотите сказать, что "все исключения, после которых нужно завершать программу" и так сделаны не перехватываемыми в try catch и они сами завершают приложение ?
Т.е. самому с этим разбираться не нужно, и можно свободно логировать ЛЮБОЕ исключение ?

buser,

Спасибо. Хотя у меня есть бумажная книга от Леви за 2007 год :) Но думаю информация сжатая в компактный файл, и относящаяся к WCF 4.0 будет очень полезна.

Arm79,

Так я же и задал вопрос "так Microsoft сделали, что исключения, которые разрушают программу до не-работоспособности не отлавливаются в try...catch и валят программу ? Таким образом я могу ловить ВСЕ исключения и безопасно их логгировать (т.к. гарантированно они не относятся к разрушительным)"

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


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

Arm79,

Сделал. Как MSDN и утверждает - try catch не ловит






И вылетело окно с извинениями от Microsoft.

Но вообще. Вопрос стоит в том - ВСЕ ли разрушительные исключения не ловятся.
Теперь думаю, что да. Раз разработчики фреймворка осознают проблему и сделали StackOverflowException не уловимым (по умолчанию), то можно предположить, что и в отношении других столь-же губительных исключениях сделаны соответствующие выводы.

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

Arm79,

Да, по идее тоже разрушительное исключение, которое может вылететь везде. Опасная штука для программ работающих без остановки. Надо будет обдумать как быть. Планирую использовать Taskи, может обойдется :) Не знаю.

LelouchMsSql_Study,

Изучите WCF Concurrency, InstanceContextMode (PerCall например) и хостинг в IIS...

Про WCF Concurrency, InstanceContextMode знаю, хотя не и мастер. Да, PerCall наверное улучшит стабильность программы, по сравнению с синглтоном.
А вот с IIS+WCF дел не имел. Win-Service вполне рабочий вариант.

Сон Веры Павловны,

Ну я не собирался включать данный флаг конечно, я о его существовании даже не знал до сегодня :) Но спасибо за предупреждение.

Разве что если какие-то сторонние библиотеки, в своих глубинах, но это вряд ли. Не думаю, что это распространенная практика, кому это может пригодится вообще...
Так, что думаю можно пренебречь столь малой вероятностью: что у кого-то будет это свойство выставлено, и надо же, в этом методе это исключение и возникнет :)

Даже если кто-то будет ловить это исключение - полагаю, там же будет и throw, пробрасыващий исключение дальше. Не думаю, что кто-то в здравом уме будет скрывать эту ошибку :)
И оно дойдет уже до моего метода, который не обладает этим атрибутом, где благополучно пролетит мимо catch и завалит приложение.
Думаю это событие можно будет наблюдать... раз этак в 2000 лет.