Здравствуйте, jedi, Вы писали:
J>Вы пробовали написать асинхронное приложение. Если да, то должны знать, что у того кто сокет создал (читай — заакцептил) нет ну ни малейшей информации о том, сколько сокету жить.
Поэтому я и предложил аж три варианта.
J>>>Почему это плохо, я уже написал выше (и не раз в этом обсужденими). Вы же в очередной раз проводите мне ликбез. Спасибо, я знаком с алгоритмом работы сборщика мусора. _FR>>Тогда что ты называешь "утечкой ресурсов"? Ознакомь тогда пожалуйста со своей терминологией
J>Это обозначает, что сокет будет недоступен для использования, заблокированный файл нельзя будет читать другим итп. Да, понятно что когда-нибудь сборщик мусора все почистит.
По сравнению с возникновением OutOfMemory это цветочки. И всё дело именно в этом. Если вдруг OutOfMemory у вас является нормой, то исправлять в первую очередь следует эту ситуацию, а не разбираться с тем, что делать с сокетом. В крайнем случае, вы можете поставить catch на OutOfMemory и вызвать в нём сборку мусора.
J>Но когда это случится — сказать нельзя. Тем более учитывая, что объекты с финализатором в нулевом поколении не чистятся. Вот и все. J>Мне странно, что такому уважаемому человеку как Вы, это нужно объяснять
Объясняется это просто — я ни разу в жизни не считал возникновение OutOfMomory "нормальной ситуацией". Если это исключение возникает, то либо в программе либо в окружении системы что-то не в порядке. Исправлять это я считаю глупо. Это надо устранять. Между прочим, я не обращаю и не провожу эксперименты с OutOfMomory и жизнью после него. Я следую рекомендации не пытаться обработать это исключение.
_FR>>http://rsdn.ru/Info/Howtoask.xml ты прочитал? Тебе требовалось конкретно описать проблему. Я не вижу где в своём ответе я обратился к тебе как к "ламеру"? J>Вы мне начали читать лекцию о работе сборщика мусора, видимо предполагая, что я о нем впервые слышу.
Вы первый стали говорить об утечке ресурсов.
_FR>>Если ты знаешь, что утечки системных ресурсов благодаря сборщику мусора и реализации класса Socket не будет, то объясни как понимать, что "утечка" таки будет? J>Я это объяснил уже раз пять по ходу ветки (втом числе еще раз выше в этом сообщении), я не знаю что еще тут добавить...
J>И 90% этой ветки — в таком духе. Внимание, вопрос — оно мне надо тратить время читая эти "высокоумные советы"?
На свой вопрос вы лучше сам сможете ответить себе, а не я — вам, согласны?
Говорить о том, в чём вы не правы (относительно отношения к вашим сообщениям и вашего отношения к отвечающим) мне не интересно. Лучше задумайтесь о том, почему вам так отвечают, и вы, быть может, поймёте, что из ваших сообщений ни разу не понятно, с чем вы боретесь. Вы в своих сообщениях не следуете простому правилу — точно описать проблему, с которой боретесь.
Вы задаёте очень общие вопросы и справедливо получате не ответы, на которые, быть может, рассчитываете. Попробуйте задать вопрос так, что бы лыло понятно, что именно вы не знаете, чего подозреваете и тому подобное.
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, _FRED_, Вы писали:
_FR>> В крайнем случае, вы можете поставить catch на OutOfMemory и вызвать в нём сборку мусора.
AVK>Совершенно бесполезная вещь. Если уж OOM вылетел, никакая сборка мусора уже не поможет.
Просто сборка не поможет. Но если что-то предпринять, отпустить кое-какие ссылки, почистить какие-нибудь кэши, то может и помочь.
Здравствуйте, _FRED_, Вы писали:
_FR>Поэтому я и предложил аж три варианта.
Они все мимо кассы при OutOfMemoryException...
J>>>>Почему это плохо, я уже написал выше (и не раз в этом обсужденими). Вы же в очередной раз проводите мне ликбез. Спасибо, я знаком с алгоритмом работы сборщика мусора. _FR>>>Тогда что ты называешь "утечкой ресурсов"? Ознакомь тогда пожалуйста со своей терминологией
J>>Это обозначает, что сокет будет недоступен для использования, заблокированный файл нельзя будет читать другим итп. Да, понятно что когда-нибудь сборщик мусора все почистит.
_FR>По сравнению с возникновением OutOfMemory это цветочки. И всё дело именно в этом. Если вдруг OutOfMemory у вас является нормой, то исправлять в первую очередь следует эту ситуацию, а не разбираться с тем, что делать с сокетом. В крайнем случае, вы можете поставить catch на OutOfMemory и вызвать в нём сборку мусора.
Почему это может возникнуть и почему его нужно обрабатывать — я написал не раз. Например здесь
. Я же не могу в каждой подветке повторять одни и те же аргументы?
_FR>Объясняется это просто — я ни разу в жизни не считал возникновение OutOfMomory "нормальной ситуацией". Если это исключение возникает, то либо в программе либо в окружении системы что-то не в порядке. Исправлять это я считаю глупо. Это надо устранять. Между прочим, я не обращаю и не провожу эксперименты с OutOfMomory и жизнью после него. Я следую рекомендации не пытаться обработать это исключение.
Я в общем-то давно с этим согласился. Например здесь
Но для 42/7 приложения единственный способ 100% гарантировать себя от OutOfMemory — это ограничить количество подключений. Но для этого нужно знать максимально количество памяти, которое может понадобится каждому клиенту. Что, как Вы понимаете, в общем случае сделать непросто. И если уж все пошло плохо и памяти таки не хватило — это не повод тушить свет и перезапускать сервер. Вполне можно отказате паре клиентов и жить дальше.
_FR>>>http://rsdn.ru/Info/Howtoask.xml ты прочитал? Тебе требовалось конкретно описать проблему. Я не вижу где в своём ответе я обратился к тебе как к "ламеру"? J>>Вы мне начали читать лекцию о работе сборщика мусора, видимо предполагая, что я о нем впервые слышу.
_FR>Вы первый стали говорить об утечке ресурсов.
Таки утечка есть ... Ибо объекты, требующие завершения надо завершать вовремя. Иначе — это утечка, несмотря на то что сборщик подберет когда-то.
А если это не утечка, то утечек вообще нет, ибо ось все почистит после закрытия процесса
_FR>>>Если ты знаешь, что утечки системных ресурсов благодаря сборщику мусора и реализации класса Socket не будет, то объясни как понимать, что "утечка" таки будет? J>>Я это объяснил уже раз пять по ходу ветки (втом числе еще раз выше в этом сообщении), я не знаю что еще тут добавить...
J>>И 90% этой ветки — в таком духе. Внимание, вопрос — оно мне надо тратить время читая эти "высокоумные советы"?
_FR>На свой вопрос вы лучше сам сможете ответить себе, а не я — вам, согласны?
Да я уже собственно ответил. Синдром бакалавра.
_FR>Говорить о том, в чём вы не правы (относительно отношения к вашим сообщениям и вашего отношения к отвечающим) мне не интересно. Лучше задумайтесь о том, почему вам так отвечают, и вы, быть может, поймёте, что из ваших сообщений ни разу не понятно, с чем вы боретесь. Вы в своих сообщениях не следуете простому правилу — точно описать проблему, с которой боретесь. _FR>Вы задаёте очень общие вопросы и справедливо получате не ответы, на которые, быть может, рассчитываете. Попробуйте задать вопрос так, что бы лыло понятно, что именно вы не знаете, чего подозреваете и тому подобное.
С этим я согласен, вопрос был сформулирован коряво. Но это не опрадывает отвечавших, писавыших явную глупость абы написать что-то. Или я не прав?
Здравствуйте, AndrewVK, Вы писали:
_FR>> В крайнем случае, вы можете поставить catch на OutOfMemory и вызвать в нём сборку мусора.
AVK>Совершенно бесполезная вещь. Если уж OOM вылетел, никакая сборка мусора уже не поможет.
Не поможет от чего?
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, _FRED_, Вы писали:
_FR>Здравствуйте, AndrewVK, Вы писали:
_FR>>> В крайнем случае, вы можете поставить catch на OutOfMemory и вызвать в нём сборку мусора.
AVK>>Совершенно бесполезная вещь. Если уж OOM вылетел, никакая сборка мусора уже не поможет.
_FR>Не поможет от чего?
Не поможет освободить память. Как я понимаю перед тем как выбросить OOM CLR сначала сама попытается вызывать сборку мусора.
Здравствуйте, MozgC, Вы писали:
_FR>>>> В крайнем случае, вы можете поставить catch на OutOfMemory и вызвать в нём сборку мусора. AVK>>>Совершенно бесполезная вещь. Если уж OOM вылетел, никакая сборка мусора уже не поможет. _FR>>Не поможет от чего? MC>Не поможет освободить память. Как я понимаю перед тем как выбросить OOM CLR сначала сама попытается вызывать сборку мусора.
Тогда после возникновения OOM никакой работы невозможно даже если очень хочется?
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, _FRED_, Вы писали:
_FR>Тогда после возникновения OOM никакой работы невозможно даже если очень хочется?
OOMException может быть выброшено в разных ситуациях. В некоторых случаях продолжение работы возможно. jedi как раз привел тестовый пример в этой ветке
Здравствуйте, _FRED_, Вы писали:
_FR>Здравствуйте, MozgC, Вы писали:
_FR>>>>> В крайнем случае, вы можете поставить catch на OutOfMemory и вызвать в нём сборку мусора. AVK>>>>Совершенно бесполезная вещь. Если уж OOM вылетел, никакая сборка мусора уже не поможет. _FR>>>Не поможет от чего? MC>>Не поможет освободить память. Как я понимаю перед тем как выбросить OOM CLR сначала сама попытается вызывать сборку мусора.
_FR>Тогда после возникновения OOM никакой работы невозможно даже если очень хочется?
Самы тупой пример — пытаемя загрузить в память гигантскую картинку. Хватило памяти — хорошо, обрбатываем ее. Не хватило — перехватили OOM, сказали клиенту "извините" и живем спокойно дальше. Но даже если это произошло мы не должны бросать открытый файл открытым. Вот собственно весь пойнт моих рассуждений в этой ветке
Здравствуйте, jedi, Вы писали:
_FR>>>>>> В крайнем случае, вы можете поставить catch на OutOfMemory и вызвать в нём сборку мусора. AVK>>>>>Совершенно бесполезная вещь. Если уж OOM вылетел, никакая сборка мусора уже не поможет. _FR>>>>Не поможет от чего? MC>>>Не поможет освободить память. Как я понимаю перед тем как выбросить OOM CLR сначала сама попытается вызывать сборку мусора. _FR>>Тогда после возникновения OOM никакой работы невозможно даже если очень хочется?
J>Самы тупой пример — пытаемя загрузить в память гигантскую картинку. Хватило памяти — хорошо, обрбатываем ее. Не хватило — перехватили OOM, сказали клиенту "извините" и живем спокойно дальше.
Так память-то освобождается всё-таки, после неудачной попытки загрузить в ней картинку?
J>Но даже если это произошло мы не должны бросать открытый файл открытым. Вот собственно весь пойнт моих рассуждений в этой ветке
И при чём здесь обработка OutOfMemoryException? То есть, файл можно закрыть и не обрабатывая специальным OutOfMemoryException, потому что очистка памяти — не наша забота, а того, кто выбросил OutOfMemoryException.
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, jedi, Вы писали:
J>Здравствуйте, MozgC, Вы писали:
MC>>Может, но исключения OutOfMemoryException, StackOverflowException и ExecutionEngineException не отлавливаются вообще никак, и в этом случае происходит неизбежное закрытие программы.
J>Кстати. Я тоже об этом читал у товарища Рихтера. J>Но вот это:
J>
J>namespace ConsoleApplication1
J>{
J> using System;
J> using System.Collections.Generic;
J> class Program
J> {
J> static void Main(string[] args)
J> {
J> for (; ; )
J> {
J> try
J> {
J> var list = new List<byte[]>();
J> for (; ; )
J> list.Add(new byte[1024 * 1024]);
J> }
J> catch (OutOfMemoryException)
J> {
J> Console.WriteLine("OutOfMemoryException caught");
J> }
J> }
J> }
J> }
J>}
J>
J>Прекрасно работает. Кому верить?
Вообще-то, OutOfMemoryException, в общем случае обработать не удастся. А приведенный тобой пример, следует переписать, согласно предписаниям того самого Рихтера с учетом MemoryFailPoint (в русскоязычном издании посмотри раздел с названием "Прогнозирование успеха операции, требующем много памяти" главы 20) следующим образом:
using System;
using System.Runtime;
public static class Program {
public static void Main() {
try {
// Logically reserve 1.5 GB of memoryusing (MemoryFailPoint mfp = new MemoryFailPoint(1500)) {
// Perform memory-hungry algorithm in here
} // Dispose will logically free the 1.5 GB of memory
}
catch (InsufficientMemoryException e) {
// The memory could not be reserved
Console.WriteLine(e);
}
}
}
Здравствуйте, _FRED_, Вы писали:
_FR>Здравствуйте, jedi, Вы писали:
_FR>>>>>>> В крайнем случае, вы можете поставить catch на OutOfMemory и вызвать в нём сборку мусора. AVK>>>>>>Совершенно бесполезная вещь. Если уж OOM вылетел, никакая сборка мусора уже не поможет. _FR>>>>>Не поможет от чего? MC>>>>Не поможет освободить память. Как я понимаю перед тем как выбросить OOM CLR сначала сама попытается вызывать сборку мусора. _FR>>>Тогда после возникновения OOM никакой работы невозможно даже если очень хочется?
J>>Самы тупой пример — пытаемя загрузить в память гигантскую картинку. Хватило памяти — хорошо, обрбатываем ее. Не хватило — перехватили OOM, сказали клиенту "извините" и живем спокойно дальше.
_FR>Так память-то освобождается всё-таки, после неудачной попытки загрузить в ней картинку?
Она не освобождается, она не была даже выделена.
J>>Но даже если это произошло мы не должны бросать открытый файл открытым. Вот собственно весь пойнт моих рассуждений в этой ветке
_FR>И при чём здесь обработка OutOfMemoryException? То есть, файл можно закрыть и не обрабатывая специальным OutOfMemoryException, потому что очистка памяти — не наша забота, а того, кто выбросил OutOfMemoryException.
OutOfMemoryException выбросил оператор new. Он не умеет магически вызывать Dispose() нужным объектам. Ему надо помочь.
Еще раз. Посмотри пример с TcpLinstener.EndAccept и StreamWriter-ом, которые я приводил выше по ветке. Там есть проблема, на которую парни из Microsoft забили. Осознанно или нет — я не знаю.
Здравствуйте, SergeyT., Вы писали:
ST>Вообще-то, OutOfMemoryException, в общем случае обработать не удастся.
Поподробнее — почему?
ST>А приведенный тобой пример, следует переписать, согласно предписаниям того самого Рихтера с учетом MemoryFailPoint (в русскоязычном издании посмотри раздел с названием "Прогнозирование успеха операции, требующем много памяти" главы 20) следующим образом:
Это интересная техника, но она не имеет отношения к обсуждаемому вопросу. Циатата:
Внимание! Если конструктор MemoryFailPoint не генерирует исключе-
ние, запрошенная память была логически зарезервирована и можно
выполнять алгоритм, требующий много памяти. Однако учтите, что
физически память не была выделена. Это значит, что лишь немного
повысилась вероятность успешного выполнения алгоритма и получения
необходимой памяти. Класс MemoryFailPoint не может гарантировать, что
алгоритм получит необходимую память, даже если конструктор не
сгенерировал исключение. Этот класс призван лишь помочь разработчику
сделать приложение более надежным.
Здравствуйте, jedi, Вы писали:
J>Уважаемый SergeyT, с чем конкретно Вы не согласны?
Я только о том, что OutOfMemoryException обработать никак не удастся. Например, что делать если при упаковке значимого типа вылетит это исключение? Мест, где неявно выделяется память великое множество и все их обрамить try catch(OOME) будет весьма сложно.
Выбрасывание OOM говорит либо о неверных настройках серверного приложения (т.е. выбрано неверное количество максимально-допустимых подключений или еще чего-то такого), либо об ошибках (багах), которые не обойти простым отловом исключений OOM.
Я не согласен с примером исключения, которое вы пытаетесь обработать. Некоторые типы исключений очень сложно обработать. Попробуйте обработать StackOverflowException. Что у вас получится?
Я уже лет 6 занимаюсь разработкой серверных приложений 24/7 и ни разу не пришлось обрабатывать OOM.
При этом совсем недавно наткнулся на OOM в клиенском приложении. Утечка закралась в один из компонентов, который мы использовали. Так вот, это приложение на разных сборках винды вело себя по разному. На некоторых машинах приложение тупо закрывалось, даже в логе винды не было никаких собощений, не говоря уже о вызове нормальных обработчиков исключений. Кроме того, только лишь на некоторых машинах вызывался и обрабатывался DomainAnhandleException.
Чем бы мне в этом случае помогли catch(OOM)?
Здравствуйте, SergeyT., Вы писали:
ST>Я только о том, что OutOfMemoryException обработать никак не удастся. Например, что делать если при упаковке значимого типа вылетит это исключение? Мест, где неявно выделяется память великое множество и все их обрамить try catch(OOME) будет весьма сложно.
Ну и что? В конечном счете оно будет поймано на верхнем уровне и соединение закроется. Главное, что при этом не останутся висеть не закрытые сокеты, файлы итп.
ST>Выбрасывание OOM говорит либо о неверных настройках серверного приложения (т.е. выбрано неверное количество максимально-допустимых подключений или еще чего-то такого), либо об ошибках (багах), которые не обойти простым отловом исключений OOM.
Я уже писал здесь, что OOM ни в коем случае не является штатной ситуацией. Администратору будет немедленно послано письмо и он примет меры.
А по поводу максимального числа соединений — ну как знать его заранее? Или пессимизировать и ограничивать заведомо маленьким числом?
ST>Я не согласен с примером исключения, которое вы пытаетесь обработать. Некоторые типы исключений очень сложно обработать. Попробуйте обработать StackOverflowException. Что у вас получится?
StackOverflowException я и не предлагал обрабатывать ... Но как бы и добиться его сложно, если вы конечно не используете рекурсивные алгоритмы. Я — не использую никогда.
ST>Я уже лет 6 занимаюсь разработкой серверных приложений 24/7 и ни разу не пришлось обрабатывать OOM.
Я тоже в этом не новичок. Правда раньше писал в основном на с++. Но и под .NET есть сервер, который крутится уже три года без всяких проблем. Сейчас встал вопрос о расширении количества клиентов, и сервер переписывается чтобы соответсвовать новым нуждам. Вот и появился такой вопрос. Мне он не кажется праздным и таким уж очевидным.
ST>При этом совсем недавно наткнулся на OOM в клиенском приложении. Утечка закралась в один из компонентов, который мы использовали. Так вот, это приложение на разных сборках винды вело себя по разному. На некоторых машинах приложение тупо закрывалось, даже в логе винды не было никаких собощений, не говоря уже о вызове нормальных обработчиков исключений. Кроме того, только лишь на некоторых машинах вызывался и обрабатывался DomainAnhandleException. ST>Чем бы мне в этом случае помогли catch(OOM)?
Я не знаю ситуации, тут сложно сказать. Возможно компонент был неуправляемым и на нехватку памяти накладывались еще какие чудеса. Кто знает?
А в целом — спасибо, интересно услышать мнение человека, который в теме
Здравствуйте, jedi, Вы писали:
J>А в целом — спасибо, интересно услышать мнение человека, который в теме
И последнее. Не могу сказать, что мое серверное приложение уж через чур здоровое и мощное, но к нему коннектятся два десятка клиентов через WCF, сервер обрабатывает 5 десятков сообщений в секунду от различного оборудования, рассылает новые состояния объектов клиентам. Все это благополучно кушает до 50 мегабайт памяти и работает на P4 2.4 с 512 метрами памяти.
Но при этом клиентские приложения "кушают" под 200мб памяти и куда прожорливее на процессорное время.
Я это все к тому, что по моему опыту, чтобы серверное приложение съело всю доступную память — нужно здорово постараться.
З.Ы. От темы отвлеклись, но и так понятно, что с ней завязывать уже нужно
Здравствуйте, jedi, Вы писали:
_FR>>Так память-то освобождается всё-таки, после неудачной попытки загрузить в ней картинку? J>Она не освобождается, она не была даже выделена.
Ну вот видишь, ты сам меня принимаешься учить ;о) а я-то всего имел в виду, что память не остается чем-то занятой :о))
J>>>Но даже если это произошло мы не должны бросать открытый файл открытым. Вот собственно весь пойнт моих рассуждений в этой ветке _FR>>И при чём здесь обработка OutOfMemoryException? То есть, файл можно закрыть и не обрабатывая специальным OutOfMemoryException, потому что очистка памяти — не наша забота, а того, кто выбросил OutOfMemoryException. J>OutOfMemoryException выбросил оператор new.
Я говорил о другом: можно написать код, который ставит файл в порядке и без обработки OOM:
using(var file = OpenLargeFile()) {
// …
}//using
то есть можно обойтись без catch(OutOfMemory) и жить припеваючи.
А ловить OOM на любом new — это паранойя. Если есть метод, который, по спецификации такое может выбросить — ну что ж делать, но ожидать подлянки откуда угодно — глупо, повторю. Пример простой — так же как и OOM, может произойти и ThreadAbortException, и это даже имеет реальные проблемы, так как так же возможны утечки ресурсов. Однако, было бы странно писать код с оглядкой на такое. Так же и здесь. Если ты знаешь, что при некоторых условиях сожет вылететь исключение, то ситуация одна.
При каких условиях может вылететь исключение в коде
new TcpClient(socket2);
И как ты видишь работу приложения после возникновения OutOfMemory в данном случае? Я вижу только один вариант — перезапуститься. При этом утечек не произойдёт.
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, SergeyT., Вы писали:
ST>И последнее. Не могу сказать, что мое серверное приложение уж через чур здоровое и мощное, но к нему коннектятся два десятка клиентов через WCF, сервер обрабатывает 5 десятков сообщений в секунду от различного оборудования, рассылает новые состояния объектов клиентам. Все это благополучно кушает до 50 мегабайт памяти и работает на P4 2.4 с 512 метрами памяти. ST>Но при этом клиентские приложения "кушают" под 200мб памяти и куда прожорливее на процессорное время.Я это все к тому, что по моему опыту, чтобы серверное приложение съело всю доступную память — нужно здорово постараться.
У меня как раз клиентов тысячи, все они коннектятся неругялрно, бывают наплывы, бывет полный простой. Поэтому, если все приконнектятся сразу и сожрут весь сервер, вполне можно отказать парочке — они попробуют позже.
ST>З.Ы. От темы отвлеклись, но и так понятно, что с ней завязывать уже нужно
Здравствуйте, _FRED_, Вы писали:
_FR>Здравствуйте, jedi, Вы писали:
_FR>>>Так память-то освобождается всё-таки, после неудачной попытки загрузить в ней картинку? J>>Она не освобождается, она не была даже выделена.
_FR>Ну вот видишь, ты сам меня принимаешься учить ;о) а я-то всего имел в виду, что память не остается чем-то занятой :о))
Вы спросили: "Так память-то освобождается всё-таки, после неудачной попытки загрузить в ней картинку?". Я ответил Если что, извините.
J>>>>Но даже если это произошло мы не должны бросать открытый файл открытым. Вот собственно весь пойнт моих рассуждений в этой ветке _FR>>>И при чём здесь обработка OutOfMemoryException? То есть, файл можно закрыть и не обрабатывая специальным OutOfMemoryException, потому что очистка памяти — не наша забота, а того, кто выбросил OutOfMemoryException. J>>OutOfMemoryException выбросил оператор new.
_FR>Я говорил о другом: можно написать код, который ставит файл в порядке и без обработки OOM: _FR>
_FR>то есть можно обойтись без catch(OutOfMemory) и жить припеваючи.
Это все хорошо если обработка происходит в одном месте. В реальном же приложении, файл открывается и начинается обработка в отдельном потоке. закрыть файл там где его открывали не получится. Ровно то же самое с сокетом в моем изначальном примере.
_FR>А ловить OOM на любом new — это паранойя. Если есть метод, который, по спецификации такое может выбросить — ну что ж делать, но ожидать подлянки откуда угодно — глупо, повторю.
Я и не предлагал его ловить при каждом new, а всего лишь там где в new передается объект, требующий вызов Dispose.
_FR> Пример простой — так же как и OOM, может произойти и ThreadAbortException, и это даже имеет реальные проблемы, так как так же возможны утечки ресурсов. Однако, было бы странно писать код с оглядкой на такое. Так же и здесь. Если ты знаешь, что при некоторых условиях сожет вылететь исключение, то ситуация одна.
Это та ситуация, где уже точно от меня ничего не зависит
_FR>При каких условиях может вылететь исключение в коде _FR>
_FR>new TcpClient(socket2);
_FR>
_FR> И как ты видишь работу приложения после возникновения OutOfMemory в данном случае? Я вижу только один вариант — перезапуститься. При этом утечек не произойдёт.
_FRED_, ну серьезно, я уже несколько раз написал, как я вижу работу — несколько клиентов отвалилось, остальные счастливо живут. Ну в самом деле, читайте что Вам пишут, ей-богу.
Вы думаете ваш любимый веб-сервер (apache, iis — подставить нужное) перезапускается когда у него возникает OutOfMemory при обработке очередного запроса? И херит при этом все
существующие сессии? Вы бы очень ругались если бы это было так.
Но для 42/7 приложения единственный способ 100% гарантировать себя от OutOfMemory — это ограничить количество подключений. Но для этого нужно знать максимально количество памяти, которое может понадобится каждому клиенту. Что, как Вы понимаете, в общем случае сделать непросто. И если уж все пошло плохо и памяти таки не хватило — это не повод тушить свет и перезапускать сервер. Вполне можно отказате паре клиентов и жить дальше. 
