Sudden Failure

Openfire Openfire Support
1

I have Openfire working reliably for over 2 years, then without notice, sudden failure. Nothing changed on the server, and the server has not been rebooted for 3 years.

This is my openfire-properties file.

#HSQL Database Engine

#Mon Jan 16 08:10:50 HKT 2012

hsqldb.script_format=0

runtime.gc_interval=0

sql.enforce_strict_size=false

hsqldb.cache_size_scale=8

readonly=false

hsqldb.nio_data_file=true

hsqldb.cache_scale=14

version=1.8.0

hsqldb.default_table_type=memory

hsqldb.cache_file_scale=1

hsqldb.log_size=200

modified=yes

hsqldb.cache_version=1.7.0

hsqldb.original_version=1.8.0

hsqldb.compatible_version=1.8.0

Using ht eembedded database, which I can see, loads up into memory, my guess is that this loads into memory, and now out of memory, refuses to allow any more, and as a resault stops working, users who are logged in can continue, but no new logins accepted.

During this time, no purges have been done, so I most likly need to clean up the message logs.

Any tips for this? Should I copy the openfire.script file and remove the " INSERT INTO OFMESSAGEARCHIVE VALUES( " lines so I can get it running again?

or is there a memory switch that will allow it to run and then I can use the in admin tools to clean up the archives?

Also, any document on moving from the embeded to mysql?

Regards

Geoff

2

a) You could increase the Openfire memory (Xmx value) if you server has enough memory and start it.

b) Deleting the “INSERT INTO OFMESSAGEARCHIVE” lines should help if a) is not possible. I assume that you will keep a backup of the openfire.script/log so you could access the conversations again / after MySL migration.

See http://community.igniterealtime.org/docs/DOC-1540 for a migration option.

3

Yes deleting these lines was the way that worked for me, a bit difficult at first, I tried vi, went to the line that started with the ofmessagearchive and pressed dG which is delete to end of file, but it appeared that vi crashed both times I tried it, so instead, I used head -[linenumber] openfire.script1 to a new file and then renamed the file to openfire.script this created the shorter version of the db creation script, and everything worked, all accounts recovered.

It seems bad programming if a system can suddenly stop like this, there should be some code that would detect memory running low and either trunk the archive to a log or stop storing messages.

4

It seems bad programming if a system can suddenly stop like this

That may be true for the plugin. Anyhow one should

  • use one of the recommended databases (and not the embedded one).
  • monitor at least some JVM metrics like memory usage.
5

Considering the embedded database is part of the default installation, it should be the most robust.

and the developer cannot pass responsibility for a systems robustness to the user. The whole point of a solid application is to be as self protective as possible, and a database that uses allocated memory of the JVM and runs out of space is akin to a memory leak.

Anyway, I can turn of login and this should stop it from happening, and possibly convert to use in a MySQL DB would help to repar issues if the same was to happen in the future.

Thanks for the feed back, it was helpful.