从 natted ip 连接到 Tibco 队列失败
首先，我对 Tibco 不太熟悉，请记住这一点；）。
我的任务是编写一个读取/写入 jms 队列的应用程序（没什么大不了的）。问题是，客户使用 Tibco &允许我连接到他们的服务器来运行一些测试。不幸的是，我只能通过 natted IP 和 IP 地址进行连接。当我尝试连接到 QueueConnectionFactory 时，我收到一条错误，因为 Tibco 本身尝试连接到“私有”IP。
有趣的是，从上下文接收队列，QueueConnectionFactory，...对象工作正常 - 但当我执行 toString() 时，我看到收到的 cf 已配置“私有”IP。
示例：我将此 url 设置为提供商 url -> tibjmsnaming://213.133.111.182:7222
接收 QueueConnectionFactory 对象工作正常，执行 to string 返回 "QueueConnectionFactory[URL=tcp://145.12.51.4:7222; clientID=null]”
因此，一旦我调用“createQueueConnectionFactory()”，我就会收到此异常：
javax.jms.JMSException: 无法连接到位于 tcp://145.12.51.4:7222 的服务器
有没有办法覆盖此异常行为与告诉 Tibco 服务器使用配置的提供程序 url？
first of all, I am not very familiar with Tibco, please keep that in mind ;).
I have a task to write an application which reads/writes to a jms queue (not a big deal). The problem is, the customer uses Tibco & allowed me to connect to their server to run some tests. Unfortunatly, I am only allowed to connect via natted IPs & as soon as I try to connect to a QueueConnectionFactory, I receive an error because Tibco itself tries to connect to the "private" IP.
The interesting thing is, receiving the Queue, QueueConnectionFactory,... objects from the context works fine - but when I do a toString() I see that the cf received has configured the 'private' IP.
Example: I set this url as provider url -> tibjmsnaming://213.133.111.182:7222
Receiving the QueueConnectionFactory object works fine, doing a to string returns "QueueConnectionFactory[URL=tcp://145.12.51.4:7222;clientID=null]"
So as soon as I call "createQueueConnectionFactory()" I receive this exception:
javax.jms.JMSException: Failed to connect to the server at tcp://145.12.51.4:7222
Is there a way to override this behavior & tell the Tibco server to use the configured provider url instead?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我知道这很古老，但如果您像我一样来自 Google，那么正确的答案是：
上面的 URL 使用 JNDI 来查找实际连接；连接器不直接连接到 NATted IP，而是连接到 NATted IP (213.133.111.182) 以查找“真实”IP (145.12.51.4)，由于 NATting，该 IP 不起作用。
解决方案：要么更改JNDI存储中注册的IP，要么直接连接，绕过JNDI。
I know this is ancient, but if you - like me - come from Google, here's the correct answer:
the URL above uses JNDI to look up the actual connection; the connector does not directly connect to the NATted IP, but connects to the NATted IP (213.133.111.182) to look for the "real" IP (145.12.51.4), which doesn't work due to the NATting.
Solution: either change the registered IP in the JNDI store or connect directly, circumventing JNDI.
1) 从客户端机器检查是否能够 ping 通 EMS 服务器 IP
2) 检查是否可以通过 Telnet 连接到 EMS IP:Port
3) 如果两者都成功，那么您的 EMS 客户端应该连接到 EMS 服务器，如果仍然没有连接，那么您 4) 必须检查 EMS DLL 是否正确，至少当您从同一台运行 EMS 客户端和服务器时能够连接机器。 5) 如果第 4 点成功，那么您必须与网络管理员一起检查客户端防火墙和服务器防火墙策略。
-hB
1) Check from the client machine, if you are able to ping the EMS server IP
2) Check if you can connect to EMS IP:Port via Telnet
3) If both succeed then your EMS client should connect to EMS Server, if still it is not connecting, then you 4) must review the EMS DLL is proper is at least able to connect when u run the EMS client and server from the same machine. 5) if point 4 is successful then you must review the client firewall and server firewall policies with your network admin.
-hB
能够直接将临时消息发送到专用端口的唯一方法是，执行 NAT 的防火墙/路由器配置为通过该端口上的消息传递到正确的目的地。否则他们将无处可去。
我认为您必须调查 JMS 或 Tibco 是否具有允许客户端维持与服务器的连接或轮询服务器以获取消息的模式，因为它将无法接收另一个方向的临时消息。
在极端情况下（例如，所有端口都被禁止的公司防火墙和代理），客户端甚至可能无法在某些随机端口上连接到您的服务器。它可能必须通过 HTTP/1.1 管道打开连接才能接收来自服务器的任何消息。
The only way you're going to be able to directly send ad hoc messages to a private port is if the firewall / router that is doing the NAT is configured to pass through messages on that port to the correct destination. Otherwise they'll go nowhere.
I think you would have to investigate if JMS or Tibco has a mode that allows a client to maintain a connection to the server or poll the server for messages because it will not be able to receive ad hoc messages in the other direction.
In extreme cases (e.g. corporate firewalls & proxies where all ports are offlimits) the client might not even be able to connect to your server on some random port. It might have to open a connection via an HTTP/1.1 pipeline to receive any messages from your server.