Connecting to a Tibco Queue from a natted ip fails

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?

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) 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

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.