if you prefer to get a normal OOM error you may also add -XX:-UseGCOverheadLimit to openfire.vmoptions.
I assume that you use also the embedded database. It stores the tables in memory, also the chat conversations so you’ll soon get an OOM error.
Remove the monitoring plugin (backup and delete monitoring.jar and the monitoring folder in openfire/plugins while Openifre is not running) and set the Xmx value a little bit higher, this should allow you to start Openfire again.
LG
added: You may also want to edit embedded-ed/openfire.properties while Openfire is not running and set “hsqldb.log_size=50”. This will rotate / compact the database logs when they reach 50 MB. Much better than to wait for a 200 MB file to be compacted.
poking around on the server side of things I found that the previous admin had set the windows virtual memory to a static number, and well windows needed more than that. I increased the size and rebooted the server, everything seems to be fine now.
You should monitor the embedded-db directory as there the openfire.script and openfire.log file are stored. openfire.log should be “merged” into openfire.script as soon as it reaches 50 MB. So openfire.script will grow and sooner or later you will get another OOM.
So you need to get rid of the monitoring plugin within HSQLDB. Or you could try something which is not supported:
shutdown Openfire
make a backup of embedded-db/*
edit embedded-db/openfire.script (hopefully your editor can open it) and replace “CREATE MEMORY TABLE n …” to “CREATE CACHED TABLE n …” for n={ofConversation, ofConParticipant, ofMessageArchive, ofRRDs}.
start Openfire
The better solution is to use a remote database (Oracle, PostgreSQL, MySQL, MSSQL, …)