powered by Jive Software

Cache management of Groups

We’re seeing some unexpected behavior with the cache management of groups.

We’re using Openfire 3.6.4. We’re populating groups into the Openfire system using the available ad-hoc command to add a group (http://jabber.org/protocol/admin#add-group), using a Java Smack client to send the ad-hoc commands to the Openfire server.

When the group cache on the Openfire server gets close to capacity (nearing 95% full), the remote command starts to fail, usually with client stack traces something like this:

No response from server on status set.:

at org.jivesoftware.smackx.commands.RemoteCommand.executeAction(RemoteCommand.java :155)

We haven’t observed any exceptions in the Openfire server logs we can directly relate to this failure. Looking at the client Smack code, it appears this error can happen when a timeout occurs.

As a workaround, we are experimenting with increasing the group cache size from its default value of 1 megabyte, or with setting the cache to unlimited. We are also adding some retry logic to our client using the Smack library.

When we watch the cache behavior using the Cache Summary page in the Openfire console, it appears the group cache take a long time to release the cached information. The cache will stay near a full level for a long time, even though it appears the default value for “cache.group.maxLifetime” is only 15 minutes. Does Openfire repopulate the group cache whenever a new group is added?

Are there any known issues with cache management in Openfire, or something specific to the cache management of groups? Are there better ways to populate the Openfire groups from an external application?

Thanks for any information.

We inspected the code in the AddGroup.java class in the org.jivesoftware.openfire.commands.admin.group package, and discovered that every time an ad-hoc command was sent to create a group, the entire list of groups already created was sent back to the Smack client. You can see this in the following lines of code:

    for (Group group : GroupManager.getInstance().getGroups()) {
        field.addOption(group.getName(), group.getName());

We verified this was actually happening by using the debug option in Smack to see the XML sent back to the client. We had 4500 groups in one environment, so the resulting XML payload had become quite large.

As a workaround, we are creating a new ad-hoc command for internal use to create groups that avoids sending back the entire group list to the client.