powered by Jive Software

Problems to enable JMX in Openfire 3.8.1

I would like to monitor the openfire continously with zabbix.

Because I will use a 64bit Java i use
Installed Packages
Name : java-1.7.0-openjdk
Arch : x86_64

That is important to know, because openjdk 1.7 doesn’t support java-snmp any more,
like sun/oracle-java or openjdk 1.6 do.
So I MUST use jmx!

Openfire-Environment
Java Version: 1.7.0_19 Oracle Corporation – OpenJDK 64-Bit Server VM
Appserver: jetty/7.x.y-SNAPSHOT
OS / Hardware: Linux / amd64

I tried so much, but nothing let me reach the jmx with jconsole!

First tries: like discribed in http://community.igniterealtime.org/thread/40439

-Djava.net.preferIPv4Stack=true
-Dcom.sun.management.jmxremote
-Dcom.sun.management.jmxremote.port=1099
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.authenticate=false

without any success.

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.

On my Googeling I found:

Add configurable JMX support
http://issues.igniterealtime.org/browse/OF-655

There is written about:

On/Off for JMX support (default: off)
JMX/RMI connector port (default: 1099)
Require Openfire admin credentials to access JMX (default: true)

But how are the names of these parameters? I found them nowhere…
( There’s nothing too: http://community.igniterealtime.org/docs/DOC-1061 )

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?!

Or what do I do wrong?

Thank you for help!

Attached is a beta version of zapcat, which may work with OF 3.8.1
zapcat-openfire-1.3-beta.jar (60734 Bytes)

Hi Holger -

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.

Regards,

Tom

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.

Did you run jconsole on your server (ssh X tunnel, local X server) to avoid any firewall issues or did you run it on your client?

I’m sorry about my silence - i was on a travel

Thank you for your fast and many answers!

ad 1 - Zabcat:

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.

Your zabcat-plugin for openfire, attached, works fine! Thank you!

Now i’m on tuning my zabbix-template…

Now I have configured a zabbix-template for zapcat.

Zapcat needs another handling of the items than normally in newer zabbix-versions:

zabbix templates normally:

jmx[“java.lang:type=ClassLoading”,LoadedClassCount]

zapcat template needs:

jmx[java.lang:type=ClassLoading][LoadedClassCount]

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)

Dear Tom,

now I found the solution of my problem:

https://blogs.oracle.com/jmxetc/entry/connecting_through_firewall_using_jmx

My openfire is placed in a dmz.

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.

Best wishes

Holger

Now it work all fine in Openfire 3.8.2 too!

I enabled the jmx in Openfire itsself with these Parameters:

found in JMXManager in:

http://www.igniterealtime.org/builds/openfire/docs/latest/documentation/javadoc/

xmpp.jmx.enabled

true

xmpp.jmx.port

1099

xmpp.jmx.secure

false

The advantage of included jmx is, that you don’t need -D parameters in the java-call any more.

Some more information you can find here:

http://issues.igniterealtime.org/browse/OF-655?page=com.atlassian.jira.plugin.sy stem.issuetabpanels:all-tabpanel

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!

Holger