we’re trying to receive an HTTPS post from a trading partner that uses webMethods sans TN. we DO HAVE TN, so we are having them do their HTTPS post to our invoke/wm.tn/receive URL.
each of us have a test server and a production server. here are the results of our efforts:
their test TO our test : successful
their test TO our prod : successful
their prod TO our test : successful
their prod TO our prod : failed
in addition, they are able to pull up a browser window on their production machine, punch in the HTTPS URL to our production TN, and that connects succssfully.
we’re trying to determine on which side the error exists which is causing the failure. the fact that they are able to hit our production URL from a browser on their production machine suggests that it is something on their side. but they are already doing HTTPS from that production WM IS to many other partners, which suggests that it is something on our end.
so are there special things to check on a WM IS posting to TN? any common issues people have experienced?
It’s all about the certs. Setting up SSL requires making sure each side has certificates configured. It sounds like your configuration is mostly right–you’ll just have to identify the difference.
–If their side is getting the error “server cert rejected by chain verifier,” double check that they trust the server’s CA/intermediate CA
–If they can’t get through and you see nothing on your side, check the client cert setup on your prod server, including the user mapping. You are rejecting the cert they are presenting.
–If they see “access denied” and you see a session created for them, check the user mapping and make sure it is a TNPartner.
It’s been a while since I’ve used TN, but this aspect should be pure IS security.
we found out what the problem was and fixed it, but couldn’t figure out what caused the problem.
their WM server was caching an old IP address. we had them going to a URL that used a host name. in the past, that host name had resolved to a certain IP address. that IP address didn’t work from our standpoint, so we had to change the DNS and have the host point to a different IP address. when we did that, that’s when they were able to start hitting the URL from a browser. but apparently their WM IS had cached the host and was using the old IP address, and so it wasn’t getting a connection at all.
In addition, sometimes the JVM will cache the lookup. We ran into this a few times on some older Solaris JVMs. In that case, the solution was restarting the IS.
Tate is right. The DNS is probably OK. I’ve seen the JVM (or WM IS?) incorrectly cache lookup failures and connection denied failures, especially with TN automatic redeliveries. In our case, stopping and starting the delivery from the TN console fixed the problem.
the cache would have happened on THEIR end, and they don’t have TN, so it must be something in the IS. thanks to everyone for all the previous suggestions. has anyone found any setting for this? should it be submitted as a bug or a feature request?
Its Java’s InetAddress class caching IP addresses for given hostnames (after a successful lookup). All JVMs by default are set to cache all successful DNS lookups forever.
Attached is the network properties for the JVM settings.
“networkaddress.cache.ttl” has a default value of -1 which is “cache forever”.
We can change this by modifying your server.[bat|sh] file and adding the flag while starting the JVM
“-Dnetworkaddress.cache.ttl=#”.
So now only a restart of the Integration Server (thereby restarting the JVM) will remove java’s DNS cache.
It’s mostly harmless (except for the memory-leak behavior of the default setting) until you run into a situation like the one described here. Then you have to play “find the system of record” for hostname resolution. This is bad enough with business data. Who needs it at the platform level?
One reason to cache hostname/IP resolution is for performance. Name resolution adds time. Performing name resolution a bunch of times adds a bunch of (unnecessary) time–particularly when the resolution 99 times out of 100 will return the same IP. If the JVM/OS is always trying to resolve the address, overall performance will be less than what it could be. If performance isn’t an issue, then disabling caching may make sense.
Another reason to disable caching, or at least reduce the ttl value, is for load balancing. Products such as 3DNS perform load balancing by returning a different IP during name lookup, so caching the IP can defeat the load balancing scheme.
Another item to be aware of is that different JVMs use different switches for controlling name resolution TTL, though it may be standardized by now. It would be prudent to double-check the name of the switch to use for a specific JVM.
