VisualVM failing to find plugins/updates? Solving the 503 error with an updated URL

jvisual下载插件的官方网站已关闭的问题

原文地址
Have you tried to update or simply see the available plugins for VisualVM (the Java monitoring tool built into the JDK), and found that it fails to respond right away (the progress bar will show “checking”) and then it reports:
Unable to connect to the Java VisualVM Plugins Center because of Server returned HTTP response code: 503 for URL: http://www.oracle.com/splash/java.net/maintenance/index.html
There is a solution.

TLDR: the quick answer is to change the URL used by the tool (Tools>Plugins>Settings) to use a new URL, such as https://visualvm.github.io/uc/8u131/updates.xml.gz.

For those who’d appreciate more detail, read on.

How does one check for such updates, and “why is it working for me? but failing for others?”
So to be clear, I’m talking about how in VisualVM (more about the tool at the bottom here, for those unfamiliar with it), when you go to its Tools>Plugins menu, such as to use the “available plugins” or “updates>check for updates” tabs, you find that you get the error:

visualvm update failure

If you’re using anything but a very recent JDK, you will probably get this problem. (I find that this is NOT a problem on the latest, 1.8.0_131 as I write. But it WAS a problem for a slightly older 1.8.0_73 edition I have, and of course for 1.7 editions.)

(And to be clear, this failure to reach the update server is NOT the OTHER problem which some may have, where calls to the update server fail because you don’t have internet access from the machine you’re running it on. For that problem, you need to modify the “proxy configuration” button shown on that error page.)

The issue: java.net is closed
The problem is that the URL used by the tool to obtain the feed of available plugins and updates no longer works.

If you look at the “Settings” tab (in the same Tools>Plugins UI), you will see that the default URL (if failing) refers to visualvm.java.net, such as: https://visualvm.java.net/uc/8u40/updates.xml.gz

And if you were to visit that page in a browser, you would find that you are redirected to the very oracle.com URL shown in the error above. And in your browser you can see that it goes on to report (via html) that “We’re sorry, the java.net site is closed” (which had been announced some time ago).

Of course, the problem is that visualvm wanted to receive a downloaded gz file, and it didn’t know what to do with the HTML on this page , and thus our error above.

And while the page does point out various URLs to help people find whatever they were looking for, sadly, it doesn’t help us (who have the problem above) with any specific solution.

The solution: tell visualvm to use a newer url
Fortunately, the newer JDKs do have the proper URL embedded within the settings page, and that helps get us on the right track (if we’re using an older jdk).

To get things working, you just need to tell the tool to use a working url. The one for the current latest JDK is: https://visualvm.github.io/uc/8u131/updates.xml.gz. If you’re wondering if that is the “right URL” for your version of the JDK, I’ll have more on that in a moment.

To change your VisualVM UI to use that new update center URL, you want to go to its Tools>Plugins menu, and then to that UI’s “Settings” tab. There you could either add a new “update center” (a new URL), or you could edit the existing one. (Note that you can disable the old one, and enable the new one, if you are reluctant to change or remove the old one for now.)

visualvm update fix

Note how this “new url” is instead located at the new home for visualvm: visualvm.github.io. (And of course, you could download an updated version of visualvm entirely here, at https://visualvm.github.io/download.html. Again, more on the tool, in general, at the bottom here.)

I am surprised that this site, which has a link for information about the plugin download center as https://visualvm.github.io/pluginscenters.html, does not discuss this issue of needing to change the URL in older versions of visualvm as found in older JDKs. Perhaps at some point they will add that, and if so I hope to update this comment.

Indeed, I looked around the web to find anyone talking about this matter (the need to change the URL, to fix this error), and I’d not found anyone discussing it, which is why I wrote this.

A curiosity about that “new url”
Before you just take the URL I offered (https://visualvm.github.io/uc/8u131/updates.xml.gz) and plunk it into the VisualVM UI, do take note that the JDK version is embedded in that URL, so it will surely change over time. While it is the “right url” to use today, I can’t say what it should be in the future, if you may be coming across this post a year later, for instance.

But by the same token, don’t presume that if you are on an OLDER JDK than 1.8.0_131 you should NOT be using this new URL. The thing is, first, I’ll note that it was my 1.8.0_73 JDK version which showed the reference to that failing URL I mentioned above, the one using 8u40 in the URL. So you see that the version numbers (in the JDK vs the URL) don’t often match. Indeed, I found that even on a JDK 1.7.0_79 (which had been installed and unchanged since 2015) it did ALSO have that same 8u40 value in its URL.

And for any who may wonder, I can also confirm that changing this “now-working” url to try to refer to 8u40 instead does in fact fail, so the answer is not to “just change it to match your JDK version”.

I suspect that they only change the value when there is some perceived need for it to be different for that given JDK.

Anyway, perhaps someone closely involved in the visualvm project (or just more knowledgeable than me) can help us know if/when/why the download URL changes.

And in the meantime, you could always look at the current visualvm.github.io site to obtain the latest version of the tool and see what value it has. (You can install that in its own directory, in addition to whatever JDK you’re using in another folder. They are completely separate apps. But you could bring the settings from the new one into the old one, it seems.)

More about VisualVM
I realize that some of my readers may be wondering, “so what’s this VisualVM tool you’re talking about?”

VisualVM is a tool that has come built-into the JDK for some years, back to 1.6.0_07. It’s found in /the bin folder of your jdk, as jvisualvm.exe (on Windows, or more specifically C:\Program Files\Java\jdk[yourversion]\bin).

It lets you watch some rudimentary information about some running Java process, such as the current heap and permgen/metaspace use, CPU use (in the JVM, and for GCs specifically), the current count of classes, how long the JVM has been up. It also lets you attempt a garbage collection, as well as take a heap dump (and you can then analyze and search the heap dump, do comparisons of one heap dump to another, and more).

It also lets you watch threads, but it’s hard to easily connect a thread to a running web request (for java application servers, whether traditional ones like Tomcat, jBoss, and such, or Java-based CFML engines like ColdFusion, Lucee, BlueDragon, or others.)

Indeed, for my regular readers familiar with CF monitoring tools, I will note that there’s much that VisualVM can’t do, which is why I favor other tools first. It has no insight into things like running requests (or their history) and running queries (or their history), which is a staple of tools like the CF Enterprise Server Monitor, FusionReactor, and SeeFusion, all of which I’ve written about before (see the categories for them here). VisualVM doesn’t even let you see non-heap memory spaces like codecache or compressed class space, as FusionReactor does it, not does it let you see a count of GCs, their duration, or how much memory they released, as FR does.

But check out the "sampler’ tab in VisualVM for its available “cpu” and “memory” profiling tools. (FusionReactor Ultimate and SeeFusion also offer CPU profiling, and FusionReactor Ultimate will soon offer Memory profiling.)

This is not the place to compare VisualVM to such tools, but I’m just saying that there’s a place for each, and each does things the other may not.

For more about VisualVM, see the JDK docs on it such as these for it as of Java 8, or again see the more modern visualvm.github.io site.

And do check out the available plugins, to extend VisualVM to do still more than it does out of the box.

Bonus topic: Setting up your Java/CFML engine, when run as a Service, to use with VisualVM
Finally, for any who may try to use the tool for the first time with CFML engines or Java app servers, note that if you have started your app server or CFML engine from the command line, then VisualVM will readily find it if you start while logged in as the same user that started those. But if you want to use it to watch a CFML engine or app server which is running as a Windows service, that is just a bit more challenging. The easiest thing to do is add some JVM startup arguments to expose JXM “remotely”, so it can be seen by VisualVM (as it runs “remotely”, even on the same machine, from the JVM as it’s running as a service):

-Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=1099 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false
You would put these in the JVM startup args for CF/your server, but getting into the details of that is beyond the scope of this post.

Then after restarting CF, you should be able to launch visualvm as found in your already-installed JDK, in its bin folder. (Note that you do NOT need to have pointed CF at a JDK to use this. It works with the JRE that comes with CF.)

And to add the instance to VisualVM to view it, in the tool’s navigation tree, right-click “Local” and choose “add a jmx connection”, adding our chosen port (1099, in my example) to the URL shown.

There’s much more that can be said about the tool and these args, and it’s beyond the scope of this post to get into that. I will note that the port used, in this case 1099, is a non-standard port so that your firewall should prevent it being exposed “remotely”, as in off the server. Again, this is about the java monitoring tool (in our case VisualVM) being “remote” from the JVM to be monitored…even though it’s on the same machine.

Anyway, you can find more on these args in any of many Java resources. And there have been various blog posts in the CF community over the years about using such tools and jvm args. One of the more complete ones is from Bilal Soylu, CF: Java: Using free VisualVM tool to monitor running ColdFusion Servers (and though from 2010, it’s still all accurate today), with screenshots and more on both the tool and those JMX args above.

Hope the tip to update the VisualVM Plugin Center URL was helpful for you.

替换URL之后还是不能访问

需要将https改为http之后setting设置成功，但是到下载插件的时候依然会失败，因为install插件时URL是不能修改的，所以没找到解决方案

使用JDK8，完美

前面说了JDK8以前版本的jvisualvm中setting的URL失效原因以及修改为可访问的URL之后，依然失败
但是使用JDK8之后，直接打开jvisualvm下载插件，不会出现任何问题，这就是时间的力量，因为JDK8的URL是没有问题的，而且我觉得JDK8中的jvisualvm应该是有修改的（我懒得去比较，谁有兴趣可以打开对比，都是shell脚本）