powered by Jive Software

Java consumes too much memory

Hi Nicolyn,

the file name must be openfired.vmoptions without .txt. You need to restart Openfire to read the new settings. The JVM does not allow to alter the max memory (-Xmx) setting during runtime.

As fas as I know one needs to run SQL statements to delete archived messages. Are you using the embedded database or an external one?


I think I got it to work as Openfire is not crashing anymore. The only

thing is that the archive is not working. The message is saying that the

Conversation was not archived. I’m using the embedded dbase. Where or how

do I execute the SQL statements?? I just came across it in a msg that was

previously posted…It’s shown below.

DELETE ofMessageArchive.*

FROM ofMessageArchive, ofConversation

WHERE ofMessageArchive.conversationID = ofConversation.conversationID

AND ofConversation.startDate <= 1192224791872;

DELETE ofConParticipant.*

FROM ofConParticipant, ofConversation

WHERE ofConParticipant.conversationID = ofConversation.conversationID

AND ofConversation.startDate <= 1192224791872;

DELETE ofConversation.*

FROM ofConversation

WHERE ofConversation.startDate <= 1192224791872;


Nicolyn C. Parks

Business Systems Support

IT Department

Belize City, Belize

Phone: 011-501-222-4757 ext. 274

Fax: 011-501-222-4759


The information contained in this message and any attachments are intended

solely for the use of the individual or entity to whom they are addressed.

It may contain privileged or confidential information. If you are not the

intended recipient you must not copy, distribute or take any action in

reliance on it. If you have received this e-mail in error please notify the

sender and delete the email. Thank You.

Hi Nicolyn,

you should open a new thread for new questions as this has usually little to do with memory. But in your case it has a lot to do with it. The embedded database uses “MEMORY TABLES”, this means: “Memory tables are the default type when the CREATE TABLE command is used. Their data is held entirely in memory but any change to their structure or contents is written to the <dbname>.script file. The script file is read the next time the database is opened, and the MEMORY tables are recreated with all their contents.” (ref: http://hsqldb.org/doc/guide/ch01.html)

As more log messages you store there the more memory Openfire will consume. So it’s a bad idea to use the monitoring plugin with the embedded database.

To edit the database you need to stop Openfire. Make a backup of the embedded-db folder. Then you can use the bin/extra/embedded-db-viewer.sh or .cmd script to access the database via SQL.

You can also use vi or notepad to open the embedded-db/openfire.script and embedded-db/openfire.log files and delete there random SQL INSERT statements.

If you like the risk you can change the three table from MEMORY to CACHED tables. Anyhow you can no longer edit content of CACHED tables with vi / notepad.


I have no headdump yet but i create a stack with jstack and a seperate file with a reduced stack with only the threads who use more cpu time. Maybe calling looping threads?

I alsa include the script wich i create the both stacks… not perfekt but it works I think :wink:


get_threads (751 Bytes)
openfire_loopingthreads.txt (22715 Bytes)
openfire_stack.txt (109473 Bytes)