ситуация:
имеются два COM-класса, скажем, A и B; они реализуют интерфейсы IA и IB;
(выдержки для dual-версии)
[
object,
uuid(27D75F4E-84A7-411A-A9CE-E681E527CC23),
dual,
pointer_default(unique)
]
interface IB : IDispatch
{
[id(1)] HRESULT ping();
};
[
object,
uuid(4DB91673-D91B-40A4-B378-542DAC8A4107),
dual,
pointer_default(unique)
]
interface IA : IDispatch
{
[id(1)] HRESULT ping();
[id(2)] HRESULT putB(IB *p);
};
классы зарегистрированы и созданы их экземпляры на разных машинах;
проверены следующие варианты: IA и IB -- как custom, так и dual;
A и B -- как обыкновенные DCOM-классы, загружаемые в суррогатный процесс,
так и COM+-компоненты серверного приложения; суть дела не меняется. а дело вот в чем:
{
CComPtr<IA> pa;
CComPtr<IB> pb;
pa.CoCreateInstance(CLSID_A);
QueryInterface(IID_IB,(void**)&pb);
pa->ping();
pa->putB(pb);
}
этот фрагмент кода выполняется объектом класса B.
вопрос: в чем отличие вызова метода IA::ping от вызова метода IA::putB
в смысле обмена по сети?
логика подсказывает, что в обоих случаях требуется один цикл обмена
(не считая RPC Bind - RPC Bind Ack) -- RPC Request - RPC Response;
так оно и есть, но только в первом случае. во втором, возврату RPC Response
предшествует одна странная штука, а именно, сервер на которм находится объект
класса A соединяется с сервером объекта класса B и вызывает какие-то методы
какого-то интерфейса с GUID {99FCFEC4-5260-101B-BBCB-00AA0021347A}. причем это
происходит до входа в тело метода putB. и все бы оно ничего, работает, но если
сервер B не отвечает, вызов putB так и зависает. в случае COM+ в папке "Компоненты"
в колонке "Время вызова" напротив класса A начинает идти время и ничем этого не изменишь,
кроме остановки сервера A. (ждал, надеясь на какой-ньть разумный таймаут, довольно
долго -- несколько суток
вопрос: что бы это значило? что за интерфейс участвует в обратном вызове?
а главное -- как с этим бороться???
