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?

thanks.

Are you sure there isn’t an authentication issue?

Regards

Luke,

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.

Hope this helps,
Tate

Luke

What is the Error you are getting in the logs at that moment.

Regards,

they are getting a request timed out error, we are not seeing their traffic at all.

Maybe it’s the firewall?

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.

where is this host/IP cache setting controlled?

thanks again.

AS you suggested, it’s in the DNS “database”.

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.

Does anyone know why the JVM or IS would do that?

Are there sites without DNS?

As a minimum it should be possible to disable it with a config setting.

Dontcha think?

Sonam,

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?

-L

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.

Very good!

Can anyone think of any reason to set this to anything except 0?

Regards

maybe in case all your DNS go down? of course, if all your DNS go down, you probably have LOTS of other problems! =)

Exactly!

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.

that’s why Rob has “Senior” in his membership title!

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.

“Senior” just means I’m a blabber-mouth!

Hi Rob,

By performance, you mean the time it takes to hit the DNS server and get a response?

I could see that if you had a Java service, ( not Flow ) repeatedly contacting a large number of hosts in a relatively short period of time.

Regards

but all Flow services run inside the JVM as well…

my understanding was/is that Flows are, in simple terms, XML that dictates what Java code should run and how it should run. if that is the case, then the cached DNS would be applicable to the Java services that directly use the DNS capabilities of the JVM, and also the Flows that invoke Java code that uses the DNS capabilities of the JVM.

at least, that’s how the salespeople described it.

Mark, the DNS lookup is indeed what I’m referring to.

As Luke points out, and you undoubtedly understand, IS is a Java program, subject to all the JVM niceties and not-so-niceties. Any name resolution done anywhere within the IS run-time (FLOW and Java services) is subject to the name lookup behavior of the JVM and the OS (to really mess with someone’s mind edit their hosts file).

It isn’t necessary to contact a large number of hosts to run into this. If name resolution caching is disabled and one server is contacting another server repeatedly in a short time (e.g. IS publishing a bunch of docs to Broker), the DNS lookups could become statistically significant.

Yep. I meant that the DNS lookup latency seemed small by comparison to the speed of Flow service execution.

I guess for the Broker situation, I’d just leave the setting at 0 and enter the IP address instead of the hostname in the Broker config.

I’d go to some length to be able to avoid an IS restart in response to an external host configuration change.

Luke - Yes, it is most probably the your partner’s JVM at fault here.

You got some good advice from Rob there.

I also remember a related SR from 2 years ago - a partner changed their IP, and instead of doing a fresh DNS lookup, our IS was caching the Java lookup failure (it was an “UnknownHostException” exception or something like that). This may be similar to what your partner was experiencing. At the time, I remember WM recommending a JVM flag to specifically disable JVM caching of DNS lookup failures (as distinct from JVM caching of DNS lookup successes). Sorry, I can’t find the setting and the search functionality of the “Service Request Center” on Advantage is broken.

However Google came up with this snippet at this link:
[url=“http://forum.java.sun.com/thread.jspa?threadID=232008&messageID=1217613”]http://forum.java.sun.com/thread.jspa?threadID=232008&messageID=1217613[/url]

Note that the “sun.net.inetaddr.negative.ttl” property doesn’t seem to work (tested using 1.3.0). However, with 1.4.x Sun introduced the following properties (with their default values shown):

networkaddress.cache.ttl=-1
networkaddress.cache.negative.ttl=10

Finally found the SR. This is what WM support said to me in Feb 2003 when I reported this problem:

> Hello Sonam,
>
> As discussed in our phone conversation, please refer to:
>
> [url=“JDK 19 Documentation - Home”]JDK 19 Documentation - Home
>
> We will need to confirm that this is also the case for JAVA 1.3.
>
> Here’s an example using my IS 4.6 server.bat file:
>
> Original line: set JAVA_RUN=%JAVA_EXE% %JAVA_MEMSET%
>
> Changed to: set JAVA_RUN=%JAVA_EXE% %JAVA_MEMSET%
> -Dnetworkaddress.cache.ttl=0 (the -D tells it you are setting a
property)
>
> Please let me know if this resolves your issue.

I then asked the support person about the negative TTL:

2. Given that the negative (failed) name-lookups are causing the problem; the relevance of using the ‘networkaddress.cache.negative.ttl’ parameter instead of ‘networkaddress.cache.ttl’.

I don’t recall getting a response back about this.

I’d suggest perhaps getting your partner to use perhaps this Java setting:
“-Dnetworkaddress.cache.negative.ttl=0”
It may be easiest to write it off as a once-off.

BTW, to query Advantage “Service Request Center” by keyword, one needs to put “*” wildcards either side of keyword. (i.e.: “some_keyword”).

(Sorry to hog this thread.) Correction: the support person did respond back. Apparently, in JVM 1.3 you will have to turn off all caching - both success and failures, but in JVM 1.4, you can specifically turn off caching of lookup failures.

Take a read of knowledge based 1611599371 on WM Advantage (Advantage knowledge policy forbids me from posting it here).

Using JVM 1.4.2, I found out you can’t just override the settings in java.security such as networkaddress.cache.ttl. Their are posts about overriding a single value in your startup command, but it’s a little trickier than that. The sun documentation talks about overriding java.security variables, but it isn’t clear how to do it until you do some more digging.

Yes, you CAN change your java.security values. If you are using the built-in JVM, it’s a done deal. If you are using a shared JVM, read on.

If you can NOT change your java.security variables (i.e., it’s shared across applications), you’ll need to do the following.

1. Ensure that your shared JVM java.security file has the following variable set to true. ‘security.overridePropertiesFile’
2. Create a file ‘filename’ with the java.security variables to override and their new values. (i.e., networkaddress.cache.ttl=1200)
3. In your startup routine, set this variable in your startup command. “-Djava.security.properties=/DirectoryPath/filename”

To verify these values are overriding, use the Security.getProperty API. You’ll need to import the java.security.* classes.