I see the open port with netstat, and I see the connection established,
but I don’t get any data. - Local firewall was disabled for testing!
I tried much much more with several possibilities with
jmxremote.access
jmxremote.password
management.properties
But with no success!
Unfortunately ZapCat doesn’t work with Openfire 3.8.1. You get data, but there’s an exception-fault
when you log in in the openfire-backend when using zapcat-Plugin.
If JMX is enabled via the admin console (server properties page),
the JConsole utility can be used at :1099 to connect to
the running Openfire server. The JMX connector may be configured
to require the credentials of an admin user, or the authentication
can be disabled if desired.
Has anyone some ideas or a cookbook to enable and use jmx on openfire?!
If you have enabled JMX via the admin console using the default configuration, you should be able to use the JConsole application to monitor Openfire. At the JConsole “New Connection” dialog, select “Remote Process” and enter “localhost:1099” as the connection string. You will also need to provide the credentials for an Openfire admin user in the username and password fields.
Hope that helps! I still have a TODO item to append these instructions to the setup documentation.
Please also note that the JMX enhancements are brand new and will be included in the upcoming 3.8.2 release. If you would like to try it out now, you will need to grab the latest nightly build to pick up these features.
Thank you for the “new” zabcat-Plugin, I will try it in the next minutes!
ad 2 - JMX:
As I understand, there are two JMX:
Java-JMX
Openfire-JMX (new in 3.8.2)
On my server isn’t a X installed, that is why I cannot connect “localhost” / Process-ID and in all my tests I tried to connect via network. On productive systems I try to avoid installing X.
In our running system, I’m using java-snmp, and the gathered statistical informations were very helpful for optimization and searching resource-lacks.
In our new system, I would like to gather these statistics via java-jmx, because of missed java-snmp.
And I haven’t understood yet, why I don’t get any jmx-data via jconsole - I described before.
Openfire-JMX is a VERY GREAT option for us in the next version!
So now I will do:
a) using the new zapcat plugin now,
b) installing a test-system with 3.8.2 (beta) and X to solve
my problems with jmx in openjdk and
test the new openfire-jmx.
By the way: I think my problems with jmx depends on using openjdk and installing openfire directly and don’t using the openfire.rpm.
I will inform you about my solution / experiences.
I attached now my generic jmx template for openfire via zapcat. It’s running on Zabbix 2.0.6. Perhaps it can help you to make your own. zbx_export_template_zapcat_jmx_generic.xml (133027 Bytes)
I checked all connection-possibilites with my test-system, and that works all fine. And so I googled for some further hints. I never thought that jmx is using 2 ports with one (random) dynamically!
So, my running zapcat-solution now has the great advantage, that one need just one port! And that is easy to ahndle in the firewall.
The access works via zapcat (s.a.) to make the communication easier because of the firewall.
*As you may already know if you have been confronted with this problem, the JMX RMI connector opens two ports: one is for the RMI registry, and it’s the port that you usually supply with the -Dcom.sun.management.jmxremote.port=<port> property. The other port is used to export JMX RMI connection objects. This second port is usually dynamically allocated at random. Indeed you don’t need to know this port number in order to connect to the JMX agent: the only port number you need to know to connect is the RMI registry port number from which to obtain the connection objects. *
Thank you very much to all, who helped me to solve my problems!