wrong Vm parameters about visualvm

[jisedlac]

What kind of application are you monitoring using the VisualVM? I assume it's a remote application using JMX connection - please confirm.

Currently when a JMX-connected application terminates, its window has to be closed in VisualVM and the connection node removed & added again or VisualVM has to be restarted in order to connect to the new application. Otherwise you still see data for the old (terminated) process - connection name and pid at the top of the view is gray.

This is a know annoyance and we're going to address it in some of the future VisualVM releases.

[wirowka]

Correct, I confirm.
The problem is that VisualVM connects to all defined Java processes and retrieves the parameters without explicitly opening the JVMs - this is totally misleading! Why you are doing it this way?

[jisedlac]

VisualVM opens the connections for several reasons:

• to check whether the process is alive
• to read process ID
• to read additional process information for resolving customized display name

[wirowka]

All clear, but why VisualVM does some actions without explicitly opening VM? For egzample, in Oracle SQL Developer (just a sample), if you configure serveral DBs, no action will be done during the process startup. You have to explicitly connect to a DB to retrieve parameters and start working with the DB.
Whereas VisualVM during it's boottime connects to processes, gathers startup parameters and keeps them until VisualVM closure - without any user action, why?
User (like we are) expect that when we click "Open" we connect to VM and retrieve the current and up2date parameters, instead we got parameters which were collected during VisualVM boot time (can be serveral hours ago) and the data displayed can be not up2date. This can cause major outage - like in our case. Why it is designed like that? What is the benefit of connecting to VMs and collecting data during boot?

[jisedlac]

VisualVM is designed this way, it's a different tool for different purposes and use cases. Again, when adding a new JMX connection, VisualVM reads these data:

• tries to connect to the process - to verify whether the connection string is correct and there's no networking problem, otherwise you wouldn't realize you made a typo for example
• process ID - will stay up to date, doesn't change
• startup parameters - will stay up to date, don't change

The other data are being collected only after you open the application in VisualVM and are always up to date as well.

As I've described in the first comment, you've been presented obsolete data for the terminated process because you didn't relaunch VisualVM or re/created the JMX connection after restarting the process, which is a known usability annoyance to be addressed yet.