Java memory maxed, CPU usage 97 - 99%, Openfire Unresponsive/Slow

I are currently in the process of testing out openfire before placing into production for my company.

I have Openfire 3.5.2 running on a Solaris 10 server, using the embedded hsql database, authenticated to an LDAP server (novel eDir).

For the past two weeks I have only been able to test with a handful of users, and everything went fine. This morning we tried adding in more users and quickly ran into issues. Messages were taking 30+ seconds to travel, no services or chatrooms would be listed under our client’s (exodus) service browser, AIM transport would not connect or disconnect (if already connected)… and so on.

I logged in to the openfire Admin Console to see if anything was glaringly wrong. I launch openfire with java parameters that set 256-1024mb of memory. The memory usage was all the way up over 1000mb (usually it has been sitting at 60mb - 120mb ). prstat on the box showed the java process eating between 97% and 97% CPU usage.

I restarted the openfire server and everything seems normal now, but has anyone else noticed similar issues or could anyone point me int he direction of what may have caused this?


How about the Openfire log files? Do they have anything interesting?



I’d like to point you to JVM Settings and Debugging, you may want to set “-XX:+HeapDumpOnOutOfMemoryError”.

Does it help to remove and re-install the gateway plugin while the server is running?

High CPU usage when the server has no free memory is usually caused by excessive garbage collections, which you may notice if you enable the GC log.


I did skim through the log files… nothing too interesting, but I’m not sure what I’m looking for so that might not be saying much.


I will set this parameter and see how things turn out. I also found a thread discussing a similar (or the same?) problem:

I don’t have access to the plugin that shows packets from individual users, but I did notice, through the statistics monitor, that the packets per minute jumped to over 60,000.

If this problem occurs again soon (it seems it will since the used java memory has been climbing steadily without an increase in active users) I will remove and re-install the gateway plugin to what happens.


this thread is really very similar, so you may want to download pre-3.6.0 from - there the problem should be fixed. As you are still evaluating it should be fine to use there pre-3.6.0.


Since we are not (yet…) taking advantage of the server to server features, I went ahead and just turned them off and have not had the issue reoccur yet. I am still, however, running 3.5.2 to keep our test environment steady (we are looking to deploy this pretty soon so I didn’t want to complicate things by having something labeled as pre-… management gets nervous ).

3.6.0 Alpha does seem to fix the problem but now the Gateway plugin seem not to work if ANY of the transports are enabled the plugin does not start and the ‘Gateways’ option is missing from the admin console.

this error seems to be thrown quite alot when enabling any of the transports

2008.07.22 16:36:25 Method execution failed:java.lang.NoSuchMethodError:

org.jivesoftware.openfire.vcard.VCardManager.addListener(Lorg/jiv esoftware/openfire/vcard/VCardListener;)Vat org.jivesoftware.openfire.gateway.BaseTransport.start(< span class=“hilite”>at org.jivesoftware.openfire.gateway.protocols.irc.IRCTransport.start(IRCTransport .java:134)at org.jivesoftware.openfire.component.InternalComponentManager.addComponent(Inter org.jivesoftware.openfire.gateway.TransportInstance.startInstance(TransportInst org.jivesoftware.openfire.gateway.TransportInstance.enable(TransportInstance.ja va:100)at org.jivesoftware.openfire.gateway.GatewayPlugin.enableService(GatewayPlugin.jav a:161)at org.jivesoftware.openfire.gateway.web.ConfigManager.toggleTransport(ConfigManag


so it looks like the vCardProvider or Manager was changed again. So one does need to wait for the official beta release containing plugins or one does need to compile/build the gateway plugin along with Openfire.