Что следует учитывать при использовании CORBA.TRANSIENT: начальный и перенаправленный IOR, недоступный vmcid: второстепенный код IBM: ошибка E07

BLUF: исключение, которое я получил при попытке подключить автономный клиент к кэшу Extreme Scale, размещенному в WebSphere, несколько вводило в заблуждение, поэтому я предоставил решение здесь.

Я успешно установил WebSphere Extreme Scale (WXS) v8.5 в WebSphere Application Server (WAS) v8.5 (примечание: не пытайтесь сделать это одновременно в Менеджере установки, иначе файлы будут отсутствовать — установите их отдельно). Мне также удалось установить клиентский и серверный EAR, чтобы я мог использовать службы REST для клиента, который, в свою очередь, подключался к серверу для доступа к кешу. Однако, когда я пытался запустить автономный клиент из командной строки java (или из Eclipse), я получал такие исключения, как:

java.lang.Throwable: org.omg.CORBA.TRANSIENT: initial and forwarded IOR inaccessible  vmcid: IBM  minor code: E07  completed: No
at com.ibm.rmi.corba.ClientDelegate.createRequest(ClientDelegate.java:1272)
...
Caused by: java.lang.Throwable: connect: Address is invalid on local machine, or port is not valid on remote machine
at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:381)

при вызове подключения к ObjectGridManager:

_client = _ogManager.connect(hostport, null, clientObjectGridURL);

Первое, что нужно проверить, это правильность номеров хоста и порта в файле objectGridClient.properties (например, номер порта должен совпадать с портом BOOTSTRAP в списке портов сервера приложений). В моем случае это было правильно. Используйте netstat -an |grep, чтобы узнать, прослушивает ли кто-нибудь порт, или подключитесь к хост-порту через telnet.

Следующее, что нужно проверить, это то, что брандмауэры не мешают подключению к порту. Также существует обратный вызов клиента с сервера, поэтому вы должны убедиться, что это не создает проблемы. В моем случае это не было проблемой.


person Nathaniel Mills    schedule 05.11.2012    source источник


Ответы (2)


Что действительно оказалось проблемой, так это то, что я настроил WAS с включенной общей безопасностью, поэтому консоль администратора требовала идентификатор пользователя и пароль. Однако, когда я вызывал ObjectGridManager для подключения, я передавал null в качестве второго параметра вместо передачи надлежащего объекта ClientSecurityConfiguration. Очевидно, что если вы защитили WAS, то внешние клиенты, пытающиеся подключиться к кешу, размещенному в WAS, должны предоставить информацию о безопасности, чтобы подтвердить, что им разрешено подключение.

Я решил отключить безопасность WAS, используя консоль администратора/Безопасность/Глобальная безопасность и сняв флажок Включить административную безопасность. Это позволило мне продолжить тестирование, передав нулевое значение, и отложить включение безопасности и добавление соответствующих параметров конфигурации безопасности и предоставление надлежащего объекта в вызове подключения, пока мы не были готовы к тестированию в общей среде (моя среда разработки была автономной на мой ноутбук, который не был подключен к общедоступной сети).

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

person Nathaniel Mills    schedule 05.11.2012

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

Так что причины этой ошибки могут быть разнообразными.

person Peter Wippermann    schedule 11.07.2013