powered by Jive Software

Openfire.lobs file size

Our small Openfire + Spark setup with 30 users and embedded db produces this huge openfire.lobs file.

I’ve tried searching for lobs file on the forum but cannot fine any suggestions what is it for and why is it so big comparing to the openfire.script file.

Can anyone shed some light on this matter ?

C:\Program Files (x86)\Openfire\embedded-db>dir

Volume in drive C is System

Volume Serial Number is C4E5-A493

Directory of C:\Program Files (x86)\Openfire\embedded-db

19/04/2017 00:03 .

19/04/2017 00:03 …

19/04/2017 00:35 16 openfire.lck

18/04/2017 22:03 19,970,326,528 openfire.lobs

19/04/2017 12:45 465,552 openfire.log

19/04/2017 00:03 105 openfire.properties

19/04/2017 00:00 56,809,981 openfire.script

19/04/2017 00:02 openfire.tmp

5 File(s) 20,027,602,182 bytes

3 Dir(s) 7,667,118,080 bytes free

No reply after 10 days ? What is the purpose of this forum ?!

This is not a commercial software and there is no official support. Everyone here is volunteer helping the community if possible. I have seen your question, but i have no clue what this file is. Maybe you can stop Openfire and try moving it out and then see if Openfire works correctly (maybe do full backup first).

1 Like

I’m guessing that this file contains binary data of sorts, or perhaps the RRD tool database that’s used in the monitoring plugin. I’m not aware of any problems related to this - keep an eye on the file size, but unless it exponentially starts growing, there’s nothing to worry about.


I’m sorry for sounding rude. I’ve searched for any info about this file format and its only mentioned on Oracle’s website that its just another format of database and that it can hold anything, including multimedia files.

10 days later and the files are still pretty much the same - LOBS file still sitting at 20 Gigabytes while main DB is 59 Megabytes.

C:\Program Files (x86)\Openfire\embedded-db>dir

Volume in drive C is System

Volume Serial Number is C4E5-A493

Directory of C:\Program Files (x86)\Openfire\embedded-db

28/04/2017 00:03 .

28/04/2017 00:03 …

28/04/2017 00:35 16 openfire.lck

18/04/2017 22:03 19,970,326,528 openfire.lobs

28/04/2017 11:13 273,676 openfire.log

28/04/2017 00:03 105 openfire.properties

28/04/2017 00:00 59,324,404 openfire.script

28/04/2017 00:02 openfire.tmp

5 File(s) 20,029,924,729 bytes

3 Dir(s) 23,633,252,352 bytes free

I have Monitoring plugin installed and enabled logging on my test server, which is used very rarely to send a few test messages. In the embedded-db folder i don’t have openfire.lobs, but i do have openfire.log which seems to contain messages. When server is offline it starts with





So it does look like RRD table to save conversations. I have installed Monitoring plugin not so long ago, so maybe lobs was some extension in the past. Mine logs file is at 10 MB with a very rare usage. So i can see how this can grow to gigs on a production server (that’s why we don’t have it enabled on our production server).

Getting back to this, it seems that lobs file is created when adding blobs objects to database, but it should be reused later. Have found a thread that it doesn’t shrink https://stackoverflow.com/questions/23487684/delete-or-shrink-lobs-file-in-a-hsqldb-database
Maybe it is fixed in the latest HSQLDB versions, or maybe we can change how embedded-db is created.

We are using latest 2.4.1 version at the moment. 2.5.0 is only planned at some point in 2019 maybe.

As i haven’t seen this file on my old production server, maybe this started with recent HSQLB versions and only when new database is created.

Filed https://issues.igniterealtime.org/browse/OF-1756

A few more bits from http://hsqldb.org/web/hsqlPerformance.html

HSQLDB is the only SQL open source database that supports a dedicated LOB store. Blobs and clobs can be very large and benefit from a separate store that avoids mixing their data with row data which is not too large. Internal database tables are used for the LOB catalog. Therefore each access to a LOB has the overhead of catalog lookup. This overhead is justified when the stored LOBs are large. HSQLDB supports long VARCHAR and VARBINARY columns that can be used instead of CLOB and BLOB especially when the average lob size is below 32 KB. These types do not have the LOB catalog overhead.

Related ticket on HSQLDB bug tracker https://sourceforge.net/p/hsqldb/feature-requests/343/

Reply from HSQLDB developer:

Check the .script file of the database. Any CREATE TABLE statement in this file that contains CLOB or BLOB will result in the creation of the .lobs file. You need to change the CREATE TABLE statements in your app to use VARCHAR(max_size) and VARBINARY(max_size) instead of the type you are currently using for those CLOB and BLOB columns.

To change an existing database, use

ALTER TABLE thetable ALTER COLUMN lobcolumn SET DATA TYPE VARCHAR(max_size) [or VARBINARY(max_size) ]