powered by Jive Software

Openfire 3.7.0 and PEP


#1

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


#2

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


#3

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.(PEPService.java:192)
at org.jivesoftware.openfire.pep.PEPServiceManager.loadPEPServiceFromDB(PEPService Manager.java:147)
at org.jivesoftware.openfire.pep.PEPServiceManager.getPEPService(PEPServiceManager .java:78)
at org.jivesoftware.openfire.pep.IQPEPHandler.handleIQ(IQPEPHandler.java:403)
at org.jivesoftware.openfire.handler.IQHandler.process(IQHandler.java:65)
at org.jivesoftware.openfire.IQRouter.handle(IQRouter.java:372)
at org.jivesoftware.openfire.IQRouter.route(IQRouter.java:121)
at org.jivesoftware.openfire.spi.PacketRouterImpl.route(PacketRouterImpl.java:76)
at org.jivesoftware.openfire.net.StanzaHandler.processIQ(StanzaHandler.java:337)
at org.jivesoftware.openfire.net.ClientStanzaHandler.processIQ(ClientStanzaHandler .java:93)
at org.jivesoftware.openfire.net.StanzaHandler.process(StanzaHandler.java:302)
at org.jivesoftware.openfire.net.StanzaHandler.process(StanzaHandler.java:194)
at org.jivesoftware.openfire.nio.ConnectionHandler.messageReceived(ConnectionHandl er.java:169)


#4

I went to PEPService.java 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);

to:

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

// starting in 2 minutes (default values)

PublishedItemTask newpublishedItemTask = new PublishedItemTask(this) {

};

setPublishedItemTask(newpublishedItemTask);

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.


#5

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.

Thanks!


#6

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.