[CORBA] вопрос про разрешение имен

Наверно надо смотреть на сервисе имен, какие имена он знает! Похоже вы пытаетесь получить ссылку, используя неверное имя - те объект фабрики-сервера зарегистрировался в службе имен под другим именем! Другой вариант - вы пишите про несколько серверов, перебираемых в цикле. А как синхронизируются между собой службы имен на разных сервера? может в этом и проблемма? фабрика зарегистрировалась на одном серваке, а клиент пытается резольвить имя, обращаясь к службе имен на другом серваке.

Не очень понятно, что именно делает клиент. Обычно клиенту самому не нужно ничего биндить в службе имен. Имена биндит сервер, поскольку изначально только он знает IORы, которые он хочет опубликовать в NS. Клиенту, как правило, достаточно вызова NamingContext::resolve или, еще удобнее, NamingContextExt::resolve_str.

2 sigurd
по порядку:
Да, проверки не было. Сейчас вывел список байндингов для полученного контекста имен - действительно, того, что я пытаюсь разрезолвить нет. Но я использую не простое (односоставное) имя. Как я понимаю, он его резолвит по частям, последовательно, и у меня нет уверенности, что при этом он работает только в рамках используемого мною контекста имен - судя по документации требуется чтобы в него входил только первый элемент составного имени. Или я не прав и все имена должны быть именно в используемом, текущем контексте?

Имена, которые я использую при попытке получить ссылку, предоставлены заказчиком как работоспособные. Как я предполагаю, имена и объекты регистрируются\перерегистрируются при старте или во время изменении конфигурации самого серверного приложения т.е. клиент на них повлиять не может.

Каждый сервер обрабатывается независимо: т.е. к нему соединяемся, работаем, отсоединяемся (т.е. последовательно освобождаем все клиентские объекты забайнденные на объекты сервера), переходим к следующему серверу (никаких колбеков висеть не остается). Если я все правильно понимаю - в этом случае нет необходимости в синхронизации?

2 gzh
Возможно, я не совсем ясно описал суть проблемы:
Клиент пытается получить ссылку на объект по имени.
При попытке вызова resolve от текущего контекста имен, генерируется исключение о том, что часть имени не корректна и к указанным именам сервер не может предоставить объекты.

Сервер жив, порты открыты. Корба-приложение там крутится. Настройки, якобы, никакие не изменялись, однако, клиентские приложения отказываются по ним взаимодействовать с сервером.

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

resolve и resolve_str отработают вне зависимости от того, простое имя (id.kind) вы пытаетесь разрешить, или составное (id0.kind0/id1.kind1/.../idN.kindN). Если имя простое, то все очевидно - NamingContext ищет элемент в своем плоском списке и отдает клиенту соответствющий имени IOR. Если имя составное, то NamingContext, к которому вы обращаетесь, отчекрыживает от имени первый элемент (id0.kind0), ищет в своем (плоском) списке элемент с именем id0.kind0, кастит его типу NamingContext и вызывает на нем resolve с оставшимся хвостом имени (id1.kind1/.../idN.kindN). Результат этого вызова возвращается клиенту. Если id0.kind0 в составном имени - не NamingContext, или не существует, то клиент получит исключение. Если NamingContext в ходе вызова к "дочернему" контексту имен получит исключение, то возможны варианты, зависящие от типа исключения и от реализации. Например, реализация службы имен в TAO ведет себя в этом случае некорректно. Как в MICO - не знаю.

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

Попробуйте вручную исследовать дерево имен, в частности, добратся до того имени, которое вы хотите разрешить. Вручную - это с помощью nslist, или подобной утилиты.

Спасибо за объяснения про разрешения сложных имен - на его основе, из клиента, раскрутил итеративно дерево запрашиваемых имен, выводя для каждого узла список доступных байндингов - в нем напрочь отсутствовала одна из запрашиваемых мною часть сложного имени.

Сейчас попробую еще посмотреть что такое nslist, но еще больше склоняюсь к тому, что причина всех сложностей - измненение конфы сервера.