After upgrading to 188.8.131.52 or higher when the system check runs I get the following stack dump
In 184.108.40.206 and higher, the system check will go out to java.com and get the current shipping version of java. If the relay can not talk to java.com then this will fail and can take a while to get to the failure point.
Current fix is to allow these servers to hit
or to be on webNetwork 220.127.116.11, or higher, and create a baseline.versions file in the stoneware/config folder. The contents should be the same data at the url above displays. See the following article
for more information on creating the baseline.versions file.
Note: Circumventing the suggested version of Java is done at your own risk, and may open you to security vulnerabilities in those older versions of Java.
edir / NDS health check
Common edir issues and how to do a health check. This information comes from an old Novell article, some specific information may not be valid anymore but the general concepts are. Troubleshooting NDS Problems Editor’s Note: "Technically Speaking" ...
Java Applets not working after new Java version released
Issue Now that Oracle is updating Java on an accelerated basis, they are also forcing users to update by setting a minimum Java version. When your client launches a Java Applet, it is directed to contact the following URL and compare the Java version ...
Clients running Java JRE 8u51, and higher, experience issues with webNetwork's Java Applets
With the release of Java 8u51, all customers MUST be on 18.104.22.168 or higher with proper cipher and protocol allow/deny configuration in place for webNetwork Java applet functionality. As of 8u51, Java is now prohibiting the RC4 cipher suite. If your ...
Time Sync Causing OTP Failure
Issue: The customer is having issues with OTP not working from stand-alone relay servers, such as in the DMZ. Solution: Check the server time on stand-alone relay. It's possible the time is out of sync from the internal server. OTP relies on the ...
TIME_WAITs in Netstat report
ISSUE When I run a netstat, I see most of the connections to our UW server are in TIME_WAIT status. How can I get those to close and open ports for connection again? SOLUTION By default the TCP Timed Wait Delay is 240 seconds. When you find that ...