Проблема
СЕРВЕР и КЛИЕНТ расположены на разных машинах. СЕРВЕР стреляет события КЛИЕНТУ. Некоторое время работает без проблем, но в конце концов возвращается ошибка RPC_E_DISCONNECTED. Прочитал в МСДН о этой ошибке (http://support.microsoft.com/default.aspx?scid=kb;EN-US;q293631. Говорится, что надо поставить SP3. Пставили его, но проблема не решилась. Как я понял, эта ошибка возникает, если в течении 6 минут OR на машине КЛИЕНТА не получает пинговый сигнал от СЕРВЕРА. Вопрос, почему так получается, что пинг не шлется в течении 6 минут? На проблемы с сеткой вроде скосить не удалось, CoDisconnect тоже никто не думал вызывать, SP4 установлени на той и на другой машине на всякий случай. Причем проблема то бывает, то не бывает. На некоторых машинах бывает , на некоторых не бывает. Никак не удается найти причину этой ошибки. Есть конечно подозрение на то что сетевой трафик как-то на это влияет, но опять же доказать это не удается. В чем может быть загвоздка?
Спасибо за участие.

Здравствуйте, faridX, Вы писали:

X>СЕРВЕР и КЛИЕНТ расположены на разных машинах. СЕРВЕР стреляет события КЛИЕНТУ. Некоторое время работает без проблем, но в конце концов возвращается ошибка RPC_E_DISCONNECTED.

А ты уверен, что ненароком не удаляешь объекта, который сообщения принимает? Проверяется мессаджбоксом в деструкторе или чем-то в таком роде.

X>Прочитал в МСДН о этой ошибке (http://support.microsoft.com/default.aspx?scid=kb;EN-US;q293631. Говорится, что надо поставить SP3. Пставили его, но проблема не решилась. Как я понял, эта ошибка возникает, если в течении 6 минут OR на машине КЛИЕНТА не получает пинговый сигнал от СЕРВЕРА.

А у тебя сервер — клиент, и не сигнал, а ответ. Ни разу не видел помирания пинга без помирания сервера. Уверен, что просто клиентская программа не померла, забыв отписаться от сообщений?

Здравствуйте, George Seryakov, Вы писали:

GS>Здравствуйте, faridX, Вы писали:

X>>СЕРВЕР и КЛИЕНТ расположены на разных машинах. СЕРВЕР стреляет события КЛИЕНТУ. Некоторое время работает без проблем, но в конце концов возвращается ошибка RPC_E_DISCONNECTED.

GS>А ты уверен, что ненароком не удаляешь объекта, который сообщения принимает? Проверяется мессаджбоксом в деструкторе или чем-то в таком роде.
Не удаляю, объект, который сообщения принимает, продолжает прекрасно работать, только без получения событий. Уверен на 90 %, это бага на уровне ОС. Клиент дельфевый, и все что он делает — это ConnectTo к моему серверу. Я могу перехватить Advise, в котором мне передается объект реализующий интерфейс событий. Насколько я понимаю — этот объект в делфи создается неявно при вызове ConnectTo. В делфи не силен, мое дело написать СОM-сервер. Проблема в том что через некоторое время я не могу кидать событие. Поэтому все шишки валятся на меня, хотя может быть я здесь ни причем. Скорее всего в течении 6 минут RPCSS не кидает пинги, поэтому машина с КЛИЕНТОМ, который на этот момент выступает в качестве сервера, решает, что меня уже нет, срабатывает гебидж коллектор и отписывают меня, вызвает там Release, уничтожается администратор заглушек. Ситуация примерно таая же, как вот здесь написаноhttp://www.geocities.com/techpages2000/DCOMBUG.htm Тут написано как исправить эту проблему найдя виноватую программу, но нельзя ли исправить это патчами-фиксами и тд?

X>>Прочитал в МСДН о этой ошибке (http://support.microsoft.com/default.aspx?scid=kb;EN-US;q293631. Говорится, что надо поставить SP3. Пставили его, но проблема не решилась. Как я понял, эта ошибка возникает, если в течении 6 минут OR на машине КЛИЕНТА не получает пинговый сигнал от СЕРВЕРА.

GS>А у тебя сервер — клиент, и не сигнал, а ответ. Ни разу не видел помирания пинга без помирания сервера.
В статье написано почему пинги помирают.
GS> Уверен, что просто клиентская программа не померла, забыв отписаться от сообщений?
Уверен, все работает замечательно, но события перестают идти ни стого не сиго. Фишка в том, что таких клиентов еще 50 штук(одинаковых), а проблемы только с несколькими. Почему только с ними -непонятно. Хотелось бы контролировать этот процесс

Здравствуйте, faridX, Вы писали:

X>Не удаляю, объект, который сообщения принимает, продолжает прекрасно работать, только без получения событий. Уверен на 90 %, это бага на уровне ОС. Клиент дельфевый, и все что он делает — это ConnectTo к моему серверу. Я могу перехватить Advise, в котором мне передается объект реализующий интерфейс событий. Насколько я понимаю — этот объект в делфи создается неявно при вызове ConnectTo. В делфи не силен, мое дело написать СОM-сервер. Проблема в том что через некоторое время я не могу кидать событие. Поэтому все шишки валятся на меня, хотя может быть я здесь ни причем.

Напиши своего клиента на васике.

dim o as <тип приемника> with events

Кидай ему сам (из своего же васикового клиента) события по таймеру, чтоб быть 100% уверенным, что клиент ОК. После этого подпишись на события своего сервера.

X>Скорее всего в течении 6 минут RPCSS не кидает пинги, поэтому машина с КЛИЕНТОМ, который на этот момент выступает в качестве сервера, решает, что меня уже нет, срабатывает гебидж коллектор и отписывают меня, вызвает там Release, уничтожается администратор заглушек.

Кидает он. Их просто на сервере (клиентской машине) не обрабатывают.

X>Ситуация примерно таая же, как вот здесь написаноhttp://www.geocities.com/techpages2000/DCOMBUG.htm

Не совсем. У тебя есть работающие клиенты, ситуация не такая.

X>Тут написано как исправить эту проблему найдя виноватую программу, но нельзя ли исправить это патчами-фиксами и тд?

Сильно в этом сомневаюсь. Завис потока RPCSS связан с ошибкой программирования пользовательской программы и патчами операционки не решится.

X>Уверен, все работает замечательно, но события перестают идти ни стого не сиго. Фишка в том, что таких клиентов еще 50 штук(одинаковых), а проблемы только с несколькими. Почему только с ними -непонятно. Хотелось бы контролировать этот процесс

А-а. События ты шлешь всем, а получают — не все. Т.е. этим ты уже отмазан от того, что ошибка твоя.

А чем отличаются эти проблемные клиенты от остальных? Я бы начал со сравнения списков бегущих задач. Unilizing procexp.

Здравствуйте, George Seryakov, Вы писали:

GS>Кидает он. Их просто на сервере (клиентской машине) не обрабатывают.

А почему их могут на клиенте не обрабатывать? Проблемы с RPCSS?

X>>Тут написано как исправить эту проблему найдя виноватую программу, но нельзя ли исправить это патчами-фиксами и тд?

GS>Сильно в этом сомневаюсь. Завис потока RPCSS связан с ошибкой программирования пользовательской программы и патчами операционки не решится.

А как же статья в МСДНе (http://support.microsoft.com/default.aspx?scid=kb;EN-US;q293631)

X>>Уверен, все работает замечательно, но события перестают идти ни стого не сиго. Фишка в том, что таких клиентов еще 50 штук(одинаковых), а проблемы только с несколькими. Почему только с ними -непонятно. Хотелось бы контролировать этот процесс

GS>А-а. События ты шлешь всем, а получают — не все. Т.е. этим ты уже отмазан от того, что ошибка твоя.

GS>А чем отличаются эти проблемные клиенты от остальных? Я бы начал со сравнения списков бегущих задач. Unilizing procexp.

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

Есть предположение(я)
1. Что проблема возникает из за того, что клиент в течении какого то времени не отвечает на вызов евента. Скорее всего твой клиент (точнее обьект который подписался на события) сидит в STA. Затем сервер вызывает метод, а клиент (допустим) занимается обработкой чего то большого и долгого и соответственно не обрабатывает входящий вызов. Думаю сервер не будет ждать 6 минут и отвалиться раньше.

2. А ты увеврен, что клиенский обьект жив?

Здравствуйте, faridX, Вы писали:

GS>>Кидает он. Их просто на сервере (клиентской машине) не обрабатывают.

X>А почему их могут на клиенте не обрабатывать? Проблемы с RPCSS?

Например.

GS>>Сильно в этом сомневаюсь. Завис потока RPCSS связан с ошибкой программирования пользовательской программы и патчами операционки не решится.

X>А как же статья в МСДНе (http://support.microsoft.com/default.aspx?scid=kb;EN-US;q293631)

CAUSE
This problem can occur when a single-threaded apartment (STA) does not properly process messages in one or more COM applications

Написано, что решится. Но я подозреваю, что всегда можно придумать такую ошибку программирования, что STA будет завешена.

GS>>А чем отличаются эти проблемные клиенты от остальных? Я бы начал со сравнения списков бегущих задач. Unilizing procexp.

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

А на машине-то самой что-то специфическое установлено?

X>Самое противное в том что отписывает-отписывает, вдруг перестает ни стого ни сего и опять долгое время работает нормально. Вообщем чертовщина какая-то.

Кул. Оно что, еще раз Advise делает? На сервере это отследить можно?

Здравствуйте, Tom, Вы писали:

Tom>Есть предположение(я)
Tom>1. Что проблема возникает из за того, что клиент в течении какого то времени не отвечает на вызов евента. Скорее всего твой клиент (точнее обьект который подписался на события) сидит в STA. Затем сервер вызывает метод, а клиент (допустим) занимается обработкой чего то большого и долгого и соответственно не обрабатывает входящий вызов. Думаю сервер не будет ждать 6 минут и отвалиться раньше.

Мало того, специфика программы сервера в том, что если клиент не отвечает >30 сек, сервер этот поток убивает(TerminateThread) и создает заново. Но это бывает редко, судя по логам. RPC_E_DISCONNECTED чаще намного.

Tom>2. А ты увеврен, что клиенский обьект жив?
100 %. Если б он еще раз подконнектился, он и дальше бы работал без проблем, пока опять эта чертова ошибка не возвратится.

Здравствуйте, George Seryakov, Вы писали:

X>>А как же статья в МСДНе (http://support.microsoft.com/default.aspx?scid=kb;EN-US;q293631)

GS>

GS>CAUSE
GS>This problem can occur when a single-threaded apartment (STA) does not properly process messages in one or more COM applications

As a result, a "bad" STA application can cause RPC_E_DISCONNECTED errors for any COM applications on the same computer.

GS>>>А чем отличаются эти проблемные клиенты от остальных? Я бы начал со сравнения списков бегущих задач. Unilizing procexp.

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

GS>А на машине-то самой что-то специфическое установлено?

Клиентский процесс загружает на них некуюю дллку (тоже COM), которая гоняет по RTP голос(передача голоса). Однозначно сказать, что на таких компах чаще встречается RPC_E_DISCONNECTED чем на клиентах без этой дллки, сказать не можем, просто подозрение.

X>>Самое противное в том что отписывает-отписывает, вдруг перестает ни стого ни сего и опять долгое время работает нормально. Вообщем чертовщина какая-то.

GS>Кул. Оно что, еще раз Advise делает? На сервере это отследить можно?

Не, это я не так выразился. Я имел в виду естественно с переподключением. Т.е ошибка- переподключился, опять ошибка, опять переподключился, нет ошибки, может довольно долгое время без неё работать, так что мы уж решаем что проблема исчезла, потом опять — бац.

Здравствуйте, faridX, Вы писали:

X>>>Самое противное в том что отписывает-отписывает, вдруг перестает ни стого ни сего и опять долгое время работает нормально. Вообщем чертовщина какая-то.

GS>>Кул. Оно что, еще раз Advise делает? На сервере это отследить можно?

X>Не, это я не так выразился. Я имел в виду естественно с переподключением. Т.е ошибка- переподключился, опять ошибка, опять переподключился, нет ошибки, может довольно долгое время без неё работать, так что мы уж решаем что проблема исчезла, потом опять — бац.

Нет, не понимаю. Вот клиент создал инстанс на сервере, т.е. подключился. Далее он подписал свою CP на этот интерфейс. Технически это передача интерфейса инстанса точки соединения на сервер. Еще раз подключился. Что такое в твоем описании переподключился?

X>Мало того, специфика программы сервера в том, что если клиент не отвечает >30 сек, сервер этот поток убивает(TerminateThread) и создает заново. Но это бывает редко, судя по логам. RPC_E_DISCONNECTED чаще намного.
Надо сделать в логах сколько длился вызов после возврата RPC_E_DISCONNECTED. Тоесть засеч время прямо перед вызовом и после и если возникла ошибка то кинуть в лог и сказать нам.

Здравствуйте, Tom, Вы писали:

X>>Мало того, специфика программы сервера в том, что если клиент не отвечает >30 сек, сервер этот поток убивает(TerminateThread) и создает заново. Но это бывает редко, судя по логам. RPC_E_DISCONNECTED чаще намного.
Tom>Надо сделать в логах сколько длился вызов после возврата RPC_E_DISCONNECTED. Тоесть засеч время прямо перед вызовом и после и если возникла ошибка то кинуть в лог и сказать нам.


Попробовать надо. Вообщем будем исследовать, если проблема решится, сообщу. Или надо искать пути обхода. Спасибо за советы.

Здравствуйте, faridX, Вы писали:


X>Попробовать надо. Вообщем будем исследовать, если проблема решится, сообщу. Или надо искать пути обхода. Спасибо за советы.

Добавлю 5 коп.
Я тоже наблюдал такую проблему с год назад (здесь где-то обсуждали). Вот что понял:
1. Проблема не проявляется на NT4 sp6a
2. SP3 для Win2k сильно снижает вероятность, но не до 0.
3. На некоторых клиентах возникает чаще, не некоторых не возникает практ никогда. Вообще есть ощущение, что если у тебя запущено ТОЛЬКО оное клиентское приложение , то проблемы не будет.
4. Проблему удалось прикопать только через аварийное завершение сервера (затем клиент его сам поднимает, когда почует, что тот отвалился).
5. Клиент -- вне подозрений (HMI Iconics GraphWorx32).

А бывает это примерно так (лог своего OPC-сервера):

2003-06-17 08:39:01 <disp1> --------->COPCServer::AddGroup(,1,1000,51008720,...)
2003-06-17 08:39:01 <disp1> --------->COPCGroup::SetState <0>
2003-06-17 08:39:01 <disp1> COPCGroup::SetState --> Active
2003-06-17 08:39:01 <disp1> <---------COPCServer::AddGroup(...) hResult=00000000
2003-06-17 08:39:01 <disp1> --------->COPCGroup::Advise <51008720>
2003-06-17 08:39:01 <disp1> <---------COPCGroup::Advise = 0x00000000
2003-06-17 08:39:01 <disp1> --------->COPCGroup::AddItems(518<51008720>...)
2003-06-17 08:39:01 <disp1> COPCGroup::AddItems(518)
2003-06-17 08:39:01 <disp1> <---------COPCGroup::AddItems(...) = 0x00000000
2003-06-17 08:39:01 <disp1> --------->COPCGroup::CreateEnumerator
2003-06-17 08:39:01 <disp1> <---------COPCGroup::CreateEnumerator: 0x00000000
2003-06-17 08:39:01 <disp1> --------->COPCGroup::IOPCAsyncIO2::Refresh2(51008720), dt=297.76
2003-06-17 08:39:01 <disp1> --------->COPCGroup::IOPCAsyncIO2::Refresh2 = 0x00000000
2003-06-17 08:39:01 <disp1> --------->Refresh2 proc started <51008720>, dt=297.91
2003-06-17 08:39:01 <disp1> COPCGroup::IOPCAsyncIO2::Refresh2 Proc: 14.91 (3 chanded)
2003-06-17 08:39:01 <disp1> --------->Refresh2 Proc completed, dt=313.02
2003-06-17 09:18:22 <disp1> --------->COPCGroup::RemoveItems(518<51008720>...)
2003-06-17 09:18:22 <disp1> <---------COPCGroup::RemoveItems = 0x00000000
2003-06-17 09:18:22 <disp1> --------->COPCGroup::Unadvise <51008720>
2003-06-17 09:18:22 <disp1> <---------COPCGroup::Unadvise = 0x00000000
2003-06-17 09:18:22 <disp1> --------->COPCServer::RemoveGroup(8,0)
2003-06-17 09:18:22 <disp1> <---------COPCServer::RemoveGroup(...) hResult=00000000
2003-06-17 09:18:22 <disp1> --------->COPCServer::AddGroup(,1,1000,47589536,...)
**************************************************
... Долгая безупречная работа...
**************************************************
2003-06-24 10:17:47 <disp1> <---------COPCServer::AddGroup(...) hResult=00000000
2003-06-24 10:17:47 <disp1> --------->COPCGroup::Advise <36636712>
2003-06-24 10:17:47 <disp1> <---------COPCGroup::Advise = 0x00000000
2003-06-24 10:17:47 <disp1> --------->COPCGroup::AddItems(26<36636712>...)
2003-06-24 10:17:47 <disp1> COPCGroup::AddItems(26) :
2003-06-24 10:17:47 <disp1> <---------COPCGroup::AddItems(...) = 0x00000000
2003-06-24 10:17:47 <disp1> --------->COPCGroup::CreateEnumerator
2003-06-24 10:17:47 <disp1> <---------COPCGroup::CreateEnumerator: 0x00000000
2003-06-24 10:17:47 <disp1> --------->COPCGroup::IOPCAsyncIO2::Refresh2(36636712), dt=18.40
2003-06-24 10:17:47 <disp1> --------->COPCGroup::IOPCAsyncIO2::Refresh2 = 0x00000000
2003-06-24 10:17:47 <disp1> --------->Refresh2 proc started <36636712>, dt=18.49
2003-06-24 10:17:47 <disp1> COPCGroup::IOPCAsyncIO2::Refresh2 Proc: 0.06 (0 chanded)
2003-06-24 10:17:47 <disp1> --------->Refresh2 Proc completed, dt=18.64
2003-06-24 10:24:23 <disp1> Fire_OnDataChange FAILED ( hResult = 0x80010108, Group = 36636712, dt = 0.57)
2003-06-24 10:24:23 <disp1> Fire_OnDataChange FAILED ( hResult = 0x80010108, Group = 36636712, dt = 1.38)
2003-06-24 10:24:23 <disp1> Fire_OnDataChange FAILED ( hResult = 0x80010108, Group = 36636712, dt = 0.34)
2003-06-24 10:24:23 <disp1> Fire_OnDataChange DISABLED (Group = 36636712)
2003-06-24 10:24:23 <disp1> ===========================>Server shutting down!!! (Group = 36636712)

Клиент прицепился в 2003-06-17 08:39:01, поработал минут 40, в 2003-06-17 09:18:22 закончил работу с одной группой, создал новую и продолжал работать нормально до 2003-06-24 10:24:23, когда callback завершился неуспехом (с момента вызова последнего метода клиентом прошло минут 7 -- это время примерно одинаково). После этого сервер немного погоревал и решил застрелиться...