Currently, the IBM i Java Development Kit/Portable Application Solutions Environment products attempt to use IPv6 even if an IPv6 TCP Interface is not defined or usable on the IBM i server. As a result, Java TCP/IP Host Resolution Performance Issues are fairly common due to lengthy IPv6 DNS lookups. The current workaround is to implement the following JVM properties to disable the use of IPv6.
java.net.preferIPv4Stack=true
java.net.preferIPv6Addresses=false
A better solution would be to check and see if IPv6 is usable on the IBM i. If an IPv6 interface cannot be found or IPv6 is not usable, skip IPv6 and go straight to IPv4. Recommendation is to pass the AI_ADDRCONFIG flag on GETADDRINFO to prevent IPv6 DNS lookups on machines that only have IPv4 interfaces.
Use Case: System: Any Java Application (WebSphere Application Server included) running on the IBM i OS making a TCP/IP connection.
Actor: Users interacting with the application or waiting on results from the application.
Scenario: A client accesses a WAS online shopping web application, adds items to their shopping cart, and then begins the checkout process. Part of this process contains a TCP/IP connection to a Credit Card company when submitting the order. This Credit Card transaction takes well over 30 seconds to process. The javastack of the JVM thread processing this Credit Card transaction shows "java/net/Inet6AddressImpl.lookupAllHostAddr". The credit card transaction takes over 30 seconds to process because there are performance delays with the IPv6 DNS lookup process. The client does not have IPv6 TCP Interfaces defined nor uses IPv6 on a day-to-day basis. This performance delay significantly impacts the client's business and its ability to process credit card transactions in a timely manner. Resulting in timed out transactions or very slow order processing.
The client has to spend unnecessary time debugging this issue, creating a PMR with IBM, etc. to get IPv6 disabled for the JVM to resolve the issue.
The current solution is to implement these JVM properties and restart the JVM, but the client has already been significantly affected by this issue.
java.net.preferIPv4Stack=true
java.net.preferIPv6Addresses=false
Lastly, using the JVM properties will disable the use of IPv6 completely. Say a client implements these properties and then a few years later they implement IPv6 TCP Interfaces on their IBM i. The client forgets they set these JVM properties a few years back and now IPv6 no longer works with the IBM i JDK. The client has to spend unnecessary time debugging this issue, creating a PMR with IBM, etc. to get IPv6 working with the IBM i JDK again. This could all be avoided by updating the IBM i JDK/PASE products to use IPv6 only if IPv6 TCP Interfaces (other than loopback) exist and IPv6 is usable on the IBM i OS.
Java 7.0 Java 7.1 Java 8.0 all contains the code change. AI_ADDRCONFIG flag is passed to getaddrinfo by default.
To skip query for AAAA records and an IPv6 local host table lookup, make sure the node does not have IPv6 source address configured. The loopback address is not considered as a valid configured source address.
Please apply corresponding PTF groups to get the change.
i 7.1 SF99572 --> level 11
i 7.2 SF99716 --> level 19
i 7.3 SF99725 --> level 34
https://www.ibm.com/developerworks/community/wikis/home?lang=en#!/wiki/IBM%20i%20Technology%20Updates/page/PTF%20groups%20and%20latest%20SR%2C%20FP
The CAAC has reviewed this requirement and recommends that IBM view this as a medium priority requirement that should be addressed. Although there is a work-around, it is clumsy.
Background: The COMMON Americas Advisory Council (CAAC) members have a broad range of experience in working with small and medium-sized IBM i customers. CAAC has a key role in working with IBM i development to help assess the value and impact of individual RFEs on the broader IBM i community, and has therefore reviewed your RFE.
For more information about CAAC, see www.common.org/caac
For more details about CAAC's role with RFEs, see http://www.ibmsystemsmag.com/Blogs/i-Can/May-2017/COMMON-Americas-Advisory-Council-%28CAAC%29-and-RFEs/
Nancy Uthke-Schmucki - CAAC Program Manager