I have to keep restarting my openfire server about once per week, because the users either cannot get into any chatrooms, or they cannot connect at all. I am using a pretty standard setup with some chatrooms, about 25 users, using LDAP integration and a MySQL database. MySQL and openfire are running on the same system, OpenLDAP is running on a different server. The Openfire server is a virtual machine. I notice each time I have to restart the Openfire service it is using all of the available memory. Just stopping Openfire and starting it up again fixes the problem but I would prefer to not have to do this. Can anyone give me any idea of how to fix this? BTW the only error that I can find is "Exception in thread "Server SR - 431149549" java.lang.OutOfMemoryError: Java heap space" which basically reads as java ran out of memory.
Can you post or pm me the contents of the ofpubsubnode table. I am trying to confirm the root of the problem. If it is a very large list, a sample should suffice, along with some information as to the total number of entries.
I am having the same problem. A couple of years ago I ran openfire with no server lock ups. Does this have soemthing to do with version 3.71?
@ wroot....where is this PEP setting? I do not see it right off in server properties, I see all the other xmpp settings but nothing for PEP.
Will be happy to post any logs if that would help track this issue down.
Thanks! I will grab those logs for you.
What does xmpp.pep do in openfire? All the information I can find is about the memory leak and that disabling fixes it.....however no one seems to say what it does. I will give it a shot since it seems to be the culprit but any info of what it does would be great so I am not blindly pulling the triger.
From what I can tell this is what it does in a nutshell?
Personal eventing provides a way for a Jabber/XMPP user to send updates or "events" to other users, who are typically contacts in the user's roster. An event can be anything that a user wants to make known to other people, such as those described in User Geolocation , User Mood , User Activity , and User Tune . While the XMPP Publish-Subscribe  extension ("pubsub") can be used to broadcast such events associated, the full pubsub protocol is often thought of as complicated and therefore has not been widely implemented.  To make publish-subscribe functionality more accessible (especially to instant messaging and presence applications that conform to XMPP IM ), this document defines a simplified subset of pubsub that can be followed by instant messaging client and server developers to more easily deploy personal eventing services across the Jabber/XMPP network. We label this subset "Personal Eventing Protocol" or PEP."
Is that pretty much how its used in openfire? Thanks in advance for any help.
I also am seeing this behaviour - usually takes about a week. However disabling PEP has *not* solved the issue for us.
What other logs should I be looking in?
Ubuntu server 11 running on ESXi 4
Spark clients across the board
Thanks for any info.
Just another me-too reply. After ~10-14 days, java ends up consuming 99.9% CPU. We've got Openfire running on a CentOS release 6.2 (Final) Hyper-V VM w/ 4GB RAM and a single CPU. Embedded database, Active Directory integration. Search and Kracken IM Gateway 1.1.3b3 are the only plugins installed. We generally have less than 150 active sessions on our busiest days; and there are currently 26 group chat rooms. Restarting the service seems to take longer than simply rebooting the OS. After a clean boot, we'll see java eat away at the CPU for approximately 3-5 minutes, then it backs down to 1-15%. OPENFIRE_OPTS="-Xms256m -Xmx2048m"
Please let me know if there's anything I can do to help resolve this issue.
I have verified that there are no more apparent memory leaks in my setup so it was PEP that was the problem for me. It has been almost a month now and I have not had to restart Openfire where before I had to restart it about once a week.
Me four, I guess.
Found this post after a google search. I run openfire at work, and as a (volunteer) member of the NWSChat system know that openfire is more reliable than my experience.
I have been restarting the process weekly. I've just had a second to look into the problem. I've increased memory available, will start monitoring java memory usage, and disable PEP.
The symptom is that java runs out of memory. I've seen a race condition, but it's probably from java frantically trying to reclaim memory.
just commenting here for the log.