Не удается подключиться к очереди Tibco с натп-ip - PullRequest
0 голосов
/ 31 августа 2010

Прежде всего, я не очень знаком с Tibco, пожалуйста, имейте это в виду;).

У меня есть задача написать приложение, которое читает / пишет в очередь jms (не имеет большого значения). Проблема в том, что клиент использует Tibco и разрешил мне подключиться к их серверу, чтобы выполнить некоторые тесты. К сожалению, мне разрешено подключаться только через натированные IP-адреса, и как только я пытаюсь подключиться к QueueConnectionFactory, я получаю сообщение об ошибке, поскольку Tibco сама пытается подключиться к «частному» IP.

Интересно то, что получение Queue, QueueConnectionFactory, ... объектов из контекста работает нормально - но когда я делаю toString (), я вижу, что полученный cf настроил «частный» IP.

Пример: я установил этот URL как URL поставщика -> tibjmsnaming: //213.133.111.182: 7222

Получение объекта QueueConnectionFactory работает нормально, выполнение строки to возвращает «QueueConnectionFactory [URL = tcp: //145.12.51.4: 7222; clientID = null]"

Поэтому, как только я вызываю «createQueueConnectionFactory ()», я получаю следующее исключение:

javax.jms.JMSException: не удалось подключиться к серверу по tcp: //145.12.51.4: 7222

Есть ли способ переопределить это поведение и указать серверу Tibco использовать вместо этого настроенный URL-адрес провайдера?

Ответы [ 3 ]

1 голос
/ 04 января 2011

1) Проверьте с клиентского компьютера, можете ли вы пропинговать IP-адрес сервера EMS. 2) Проверьте, можете ли вы подключиться к EMS IP: порт через Telnet. 3) Если оба успешно, то ваш клиент EMS должен подключиться к серверу EMS,если он по-прежнему не подключается, то вы 4) должны проверить, правильно ли подключена библиотека EMS DLL, если вы, по крайней мере, можете подключиться, когда вы запускаете клиент и сервер EMS с одной и той же машины.5) если пункт 4 успешен, вы должны проверить политики брандмауэра клиента и брандмауэра сервера у администратора сети.

-hB

1 голос
/ 01 июня 2017

Я знаю, что это древнее, но если вы - как и я - пришли из Google, вот правильный ответ:

URL выше использует JNDI для поиска фактического соединения;соединитель напрямую не подключается к IP-адресу с NAT, но подключается к IP-адресу с NAT (213.133.111.182) для поиска «реального» IP (145.12.51.4), который не работает из-за NATting.

Решение: измените зарегистрированный IP-адрес в хранилище JNDI или подключитесь напрямую, обходя JNDI.

0 голосов
/ 31 августа 2010

Единственный способ, с помощью которого вы сможете напрямую отправлять специальные сообщения на частный порт, - это если брандмауэр / маршрутизатор, выполняющий NAT, настроен на передачу сообщений через этот порт в правильный пункт назначения. Иначе они никуда не денутся.

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

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

...