Openfire 3.7.0 and PEP

It looks to me like the memory leak in PEP is still present in Openfire 3.7.0. Whenever I connect a PEP enabled client that uses the geoloc PEP feature the Openfire server rapidly runs out of memory (within 5 minutes) and dies. Does anyone else experience this problem? thanks

Exactly which client do you use? Would you be willing to submit a heap dump of a VM that’s (almost) out of memory?

It is actually a custom client I wrote. I don’t know many PEP enabled clients. I am trying to get a heap snapshot now that is suitable. thanks.

I do see things related to the timer code in PEPService:

2011.03.08 08:23:33 Internal server error
java.lang.IllegalStateException: Timer already cancelled.
at java.util.Timer.sched(Unknown Source)
at java.util.Timer.schedule(Unknown Source)
at org.jivesoftware.openfire.pep.PEPService.(
at org.jivesoftware.openfire.pep.PEPServiceManager.loadPEPServiceFromDB(PEPService
at org.jivesoftware.openfire.pep.PEPServiceManager.getPEPService(PEPServiceManager .java:78)
at org.jivesoftware.openfire.pep.IQPEPHandler.handleIQ(
at org.jivesoftware.openfire.handler.IQHandler.process(
at org.jivesoftware.openfire.IQRouter.handle(
at org.jivesoftware.openfire.IQRouter.route(
at org.jivesoftware.openfire.spi.PacketRouterImpl.route(
at .java:93)
at org.jivesoftware.openfire.nio.ConnectionHandler.messageReceived(ConnectionHandl

I went to and changed the code on on line 187 from:

// Save or delete published items from the database every 2 minutes

// starting in 2 minutes (default values)

publishedItemTask = new PublishedItemTask(this) {


timer.schedule(publishedItemTask, items_task_timeout, items_task_timeout);


// Save or delete published items from the database every 2 minutes

// starting in 2 minutes (default values)

PublishedItemTask newpublishedItemTask = new PublishedItemTask(this) {



timer.schedule(newpublishedItemTask, items_task_timeout, items_task_timeout);

That seemed to solve both the leak and the exceptions. I don’t know enough about the PEP code to know why this makes a difference.

I managed to get a heap dump when Openfire crashed. What is the best way to submit the hprof file? It is about 1.6gigabyes in size.

Using VisualVM I see there are a lot of org.jivesoftware.openfire.pubsub.PublishedItems objects that looks suspicious. This is a very lightly used server - mostly used for PEP.


The presence of a lot of PublishedItem objects indicates that the real problem is OF-39. If the PEP nodes are begin configured as persistent, then this is almost guarenteed to be the culprit.