We have been running jboss 3.0.x for quite some time without any problems. Switching to 3.2.3 we have a JMS problem. I don't know if there is a configuration file change or if our application is doing something wrong.

The problem is that in {SERVER_HOME}/data/hypersonic, the localDB.data file continuously grows. It never seems to shrink. We send a LOT of Messages to an MDB and the messages are persisted temporarily until handled. That seems to work just fine but the localDB.data keeps growing even when the messages are finished being handled. The file eventually reaches about 2.0 gigs. At that point, JBoss starts throwing lots of exceptions.. example:

The only solution has been to kill the jboss processes, delete the hypersonic directory, and then start again, letting hypersonic create a new empty database.

Is there any way to automatically shrink the database?

We are using the default configuration without any customization other than deploying our application. I can connect to the hypersonic db and verify that there are no records in the JMS_MESSAGES table but the file is still ever growing.OS: Linux 2.4.19 kernelJDK: Blackdown jdk 1.4.1JBoss: 3.2.3

I'll work on something reproducable. In the mean time, I noticed that it doesn't always grow with every message. In fact most of them seem to be processed normally. There doesn't appear to be any other data in the database. ie: select count(*) from JMS_MESSAGES returns 0. The localDB.script file shows pretty much what I'd expect: inserts and deletes for the Message Queue persisted messages and their transactions.

The fact remains however, that the data file is currently 1.6 gigs and yesterday it was 1.5 gigs. I anticipate that Monday or Tuesday I'll have to fix it again.

My localDB.script grows huge, was there ever a way to deal with the evergrowing size of this file without being forced to shutdown the JBoss instance? Can someone point me to some documentation on this, I have bought some JBoss books and docs already? Is there some rolling log like feature that I can use?

"jbossy" wrote:My localDB.script grows huge, was there ever a way to deal with the evergrowing size of this file without being forced to shutdown the JBoss instance? Can someone point me to some documentation on this, I have bought some JBoss books and docs already? Is there some rolling log like feature that I can use?

we found the same problem on our systems. I did some "tests" and found out, that the hypersonic seems to work pretty smooth, even if it has do do a lot of work. (Sent about some 800.000 messages as fast as the server could, followed up by some other 100.000 messages during the following hours.)There war no problem, until I started some other programs to consume up all physical and virtual memory on my linux-box. (started reading a pdf, wrote it to a vector, read it again, put it in the same vector, created a new vector if an OutOfMemoryException came, ... startet this program some times with Xmx and Xms values between 128MB and 512MB).When the box had 1 Gig RAM used and 2 Gig swap, still eyerthing worked fine. I had a load above 20 and CPU-load 100%. From now on, the .data-file startet to grow... I hat about 100 MB in the .script-file, the .data-file was at ~30MB.Now I stopped the memory-consuming programs and kept looking what happend. Well, the .data-file kept growing. Not that fast, but it did not shrink.

Maybe someone can make a more appropriate test-case with this scenario, I also think, that there is no need for such a brutal load. I think it is more important to force the machine to swap.

1. An automatic checkpoint should take place by default when the .log file reaches 200MB. This will reduce the size of the .log file to a minimum but will not reduce the size of the .data file. (In version 1.7.1, the .script file was used for logging, instead of the currently used .log file). However, there was an issue in HSQLDB 1.7.2.4 (which has been resolved in later revisions) with automatic checkpoints.

2. The .data file keeps track of up to 1000 recently deleted rows and uses the empty space for new rows. When more rows are deleted, it abandons the old list. As a result, whenever a very large number of rows are inserted and then deleted, the .data file grows.

3. From 1.7.2.x a new command, CHECKPOINT DEFRAG, is available to reduce the size. This takes the database engine offline for the duration of the operation. Any queries will be queued until the new files have been written out and the old ones deleted. (You need temporary disk space equivalent to the existing file sizes for this operation).

4. You can reduce the amount of memory used by HSQLDB by setting the cache_scale property to a smaller value (needs a restart). The current defaults allow up to 50MB of data to stay in memory. Reducing the cache_scale to 12 will take this down to 12.5 MB.

5. Using operating system swap space for Java programs is very OS and JVM implementation dependent. In the worst case scenario, the garbage collector will continually bring back the swapped-out blocks into memory and slow down the operation of the app server.

6. With extensive improvements made to HSQLDB leading to 1.7.2.11 and 1.7.3.1, the engine is now extremly reliable. I would like some feedback on the usage pattern under heavy load, so that we can allow a larger list of empty disk spaces to be kept and reduce the growth of the .data file.

Further to my last message, I have just uploaded the latest 1.8.0 RC3. Go to http://hsqldb.sf.net home page to download the file. (Note this is a Release Candidate and should be used only for testing)

With this version the size of the .data file for HSQLDB goes up only by a small fraction of the previous versions for each 200MB worth of logged statements.

Also, when the empty spaces in the .data file reach 200MB and the .log file also reaches 200MB and forces an automatic checkpoint, a defrag is automatically performed. So the .data file size will not have more than an average 200MB wasted space and its size will reflect this.

As a result of all this, you should be able to run a production JBossinstance indefinetly without any problems.

Tests will continue with the 1.8.0 Release Candidates. The final release is scheduled for March.

If you test this version, please report your finidings to the HSQLDB user channels via http://hsqldb.sf.net

- HSQLDB is by default compiled to use some java.nio classes. There may be issues with NFS volumes. Also, memory use is higher than without nio. You should recompile HSQLDB with JDK 1.3.x to avoid such cases. Jars previously supplied with JBoss were recompiled in this way.

- In order to benefit from (a) 8 GB maximum database size, and (b) automatic defrag, you need to set the relevant properties of the HSQLDB database when the database is empty. See the HSQLDB docs on these settings.