HTTPS from wm IS to wm TN

, ,
21

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.

22

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.

23

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.

:sunglasses:

24

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

25

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:

  1. 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”).

26

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

27

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.