Суть проблемы:
Аутофпроцессный сервер не умирает, если какой-нибудь из клиентов забыл его релизнуть, или же случайно скончался, никого об этом не уведомив.
Похожая проблема уже обсуждалась в форуме см. "Обрыв соединения в DCOM". Там некто "Аноним" заметил, что ссылка автоматически освобождается если клиент безвременно скончается а VladD2 это подтвердил. Должен заметить, что это не совсем так. При некорректной смерти последнего клиента, объект подолжает жить еще несколько минут (что-то около 12), независимо от того синглтоновый он или нет.
Если кто исследовал эту проблему, поделитесь пжлста.
Здравствуйте Павел, вы писали:
П>Суть проблемы: П>Аутофпроцессный сервер не умирает, если какой-нибудь из клиентов забыл его релизнуть, или же случайно скончался, никого об этом не уведомив. П>Похожая проблема уже обсуждалась в форуме см. "Обрыв соединения в DCOM". Там некто "Аноним" заметил, что ссылка автоматически освобождается если клиент безвременно скончается а VladD2 это подтвердил. Должен заметить, что это не совсем так. При некорректной смерти последнего клиента, объект подолжает жить еще несколько минут (что-то около 12), независимо от того синглтоновый он или нет. П>Если кто исследовал эту проблему, поделитесь пжлста.
Я ставил эксперементы, и вообще не видел что-б он умирал. Единственный способ, который я занаю, после недели ковыряния в этом вопросе — когда клиент подключается к серверу, он отдает серверу интерфейс на себя, чтобы сервер мог дергать какой нить пустой метод этого интерфейса для проверки наличия соединения. Если вызов метода ругается, сервер прекращает соединение. При этом надо быть готовым к ситуации — клиент умер во время вызова этого, или другого метода, тогда вызов надо прерывать по timeout вызовом CoCancelCall.
В целом, используя описанное выше и еще CoDisconnectObject, при удалении сессионых объектов, мне удалось построить соединение между несколькими клиентами одновременно использующих один удаленный сервер. При этом соединение корректно разрывается, если одина из сторон умирает скоропостижной (Например: GPF) смертью, или физическое соединение коротковременно, или долговременно разрывается. Хочу обратить внимание, что при коротковрменном разрыве могут возникать проблемы, если одна сторона заметит разрыв, а вторая нет.
Если все это интересно, я могу попробовать собрать пример, но на это уйдет пару дней
ZORK>Я ставил эксперементы, и вообще не видел что-б он умирал. Единственный способ, который я занаю, после недели ковыряния в этом вопросе — когда клиент подключается к серверу, он отдает серверу интерфейс на себя, чтобы сервер мог дергать какой нить пустой метод этого интерфейса для проверки наличия соединения. Если вызов метода ругается, сервер прекращает соединение. При этом надо быть готовым к ситуации — клиент умер во время вызова этого, или другого метода, тогда вызов надо прерывать по timeout вызовом CoCancelCall.
ZORK>В целом, используя описанное выше и еще CoDisconnectObject, при удалении сессионых объектов, мне удалось построить соединение между несколькими клиентами одновременно использующих один удаленный сервер. При этом соединение корректно разрывается, если одина из сторон умирает скоропостижной (Например: GPF) смертью, или физическое соединение коротковременно, или долговременно разрывается. Хочу обратить внимание, что при коротковрменном разрыве могут возникать проблемы, если одна сторона заметит разрыв, а вторая нет.
ZORK>Если все это интересно, я могу попробовать собрать пример, но на это уйдет пару дней
Все это, конечно, понято, поэтому не очень интересно. Я думал, что есть какая-нибудь хитрость, позволяющая серверу сразу словить момент, когда отваливается клиент, без использования ручной обратной связи. Говорят у ДКОМа есть какой-то встроеный пинг. Может есть возможность настраивать его таймауты?
Сегодня обнаружил, что при корректном завершении клиентского процесса, даже если он не закрыл ссылку, серверная прокся успевает сообщить серверу, что клиент помер. В этом случае рефкаунт на сервере декрементится как положено. Поэтому проблема забывчивых клиентов снимается. Проблема же больных клиентов а так же некачественных соединений до сих пор не решена. Если ее невозможно решить без ручного пинга, то просто непонятно о чем они там, в MS-е, думали, когда проектировали ДКОМ?
Здравствуйте Павел, вы писали:
П>Все это, конечно, понято, поэтому не очень интересно. Я думал, что есть какая-нибудь хитрость, позволяющая серверу сразу словить момент, когда отваливается клиент, без использования ручной обратной связи. Говорят у ДКОМа есть какой-то встроеный пинг. Может есть возможность настраивать его таймауты?
Existing implementations of DCOM use pingPeriod = 2 minutes and numPingsToTimeOut = 3. These values can not be changed ...так что не судьба.
П>Сегодня обнаружил, что при корректном завершении клиентского процесса, даже если он не закрыл ссылку, серверная прокся успевает сообщить серверу, что клиент помер. В этом случае рефкаунт на сервере декрементится как положено. Поэтому проблема забывчивых клиентов снимается. Проблема же больных клиентов а так же некачественных соединений до сих пор не решена. Если ее невозможно решить без ручного пинга, то просто непонятно о чем они там, в MS-е, думали, когда проектировали ДКОМ?
Есть мненеие, что MS DCOM не проектировала, а COM наращивал. А так как COM не проектировался для ненадежных сетевых соединений, то и DCOM получился хорошим, только для кластеров, где разрыв сети маловероятен ...а для настоящей сети с ним проблем, возможно больше чем со старыми, добрыми сокетами. Ну не зря же сам MS так сейчас любит SOAP, который, как я представляю должен накрыть идеи использования DCOM в Интеренет. Хотя, как я уже упомянул, для кластеров и интранетов возможно DCOM еще поработает.
Здравствуйте ZORK, вы писали:
ZORK>Тут — http://msdn.microsoft.com/library/en-us/dndcom/html/msdn_dcomarch.asp , я нашел следующую фразу:
ZORK>Existing implementations of DCOM use pingPeriod = 2 minutes and numPingsToTimeOut = 3. These values can not be changed ...так что не судьба.
ZORK>Есть мненеие, что MS DCOM не проектировала, а COM наращивал. А так как COM не проектировался для ненадежных сетевых соединений, то и DCOM получился хорошим, только для кластеров, где разрыв сети маловероятен ...а для настоящей сети с ним проблем, возможно больше чем со старыми, добрыми сокетами. Ну не зря же сам MS так сейчас любит SOAP, который, как я представляю должен накрыть идеи использования DCOM в Интеренет. Хотя, как я уже упомянул, для кластеров и интранетов возможно DCOM еще поработает.
Ну что-ж, тогда придется все делать ручками :-( Спасибо за внимание.
