Thomas,
I don't know how much help I will be but I will give it a shot.
- What is your database URL?
JDBC url =
jdbc:h2:../data/audit/msgfwd;COMPRESS=TRUE;AUTOCOMMIT=ON;MVCC=TRUE;DB_CLOSE_ON_EXIT=FALSE;MV_STORE=FALSE;AUTO_SERVER=TRUE;AUTO_SERVER_PORT=7799
- Did you use LOG=0 or LOG=1? Did you read the FAQ about it?
I have not modify the default log mode.
- Did the system ever run out of disk space?
No. I have had no indication that it ran out of disk space. My application
monitors disk resources and automatically shuts down if the disk
utilization exceeds 90%. That being said the DB file is about 1.8GB in
size so If at any point H2 duplicates this file temporarily during cleanup
or optimization then I suppose I would have to revisit my answer.
- Could you send the full stack trace of the exception including message
text?
I have posted the entire contents of the trace file. My application was in
its shutdown hook and already 99.9% shutdown at this time just waiting for
H2 to exit.
- Did you use SHUTDOWN DEFRAG or the database setting DEFRAG_ALWAYS with H2
version 1.3.159 or older?
No. I am using the latest version 1.4.182 and the database file was
generated with this version. I do not use either of those two settings
because my database file gets so large that it takes too long to exit with
those two options set.
- How many connections does your application use concurrently?
I use boneCP for a connection pool to simplify connections that are made
from multiple threads. I have boneCP set at 10 connections max, but I
would be surprised if there were more that two connection (per application)
at any one time. I did have two applications running. One is essentially
writing files as text to the database and the other is reading these text
entries. They run independently and one application can be ahead or behind
the other at anytime. The database primary keys are transmitted via a
message queue and the database is used as our data store until the queue
can be worked off.
- Do you use temporary tables?
No. We have two tables and they are created at startup if necessary.
- With which version of H2 was this database created?
You can find it out using:
select * from information_schema.settings where name='CREATE_BUILD'
or have a look in the SQL script created by the recover tool.
The database was deleted and recreated when we upgraded from 1.4.181 to
1.4.182. It was created with the same version that threw the exception
1.4.182
- Did the application run out of memory (once, or multiple times)?
No. We did not experience any memory issues. We just hung during
shutdown. Which has not been unheard of in our tests. But per Noels
suggestion we have changed from writing/reading Clobs to writing/reading
large varchar fields.
- Do you use any settings or special features (for example cache settings,
two phase commit, linked tables)?
No. our goal is simple fast and as small as possible. We store a lot of
data quickly and for short periods of time.
- Do you use any H2-specific system properties?
Only those listed in our URL. We make considerable use of the
AUTO_SERVER=true setting. We rely on it.
- Is the application multi-threaded?
Yes. but the biggest database contentions would be between applications.
Multiple applications read and write to the same table.
- What operating system, file system, and virtual machine
(java -version) do you use?
We have been testing on Solaris 10, sparc UFS, Java 7u45
- How did you start the Java process (java -Xmx... and so on)?
We have some custom command line defines and these -Xmx1G -Xms128m
-XX:MaxPermSize=256m
- Is it (or was it at some point) a networked file system?
No. This database file is only a couple days old.
- How big is the database (file sizes)?
I will verify on Monday. but I have in my notes 1.8GB
- How much heap memory does the Java process have?
Set to max of 1GB ( see java options above )
- Is the database usually closed normally, or is process terminated
forcefully or the computer switched off?
Database is ALWAYS closed normally via a shutdown hook that cleans up all
our application services. We close the H2 database by way of the boneCP
connection pool.
- Is it possible to reproduce this problem using a fresh database
(sometimes, or always)?
I have never seen this exception in our trace file, however, we see startup
contentions between applications every single day multiple times a day.
They usually are handled automattically by boneCP which retries to
connection again after (n) seconds and these subsequent connections usually
succeed. As far as shutdown issues - honestly, we see them often enough
that we have chosen not to use the H2 database in production yet. Are
applications are controlled from a main GUI and they are typically started
and stopped simultaneously. Since we are using the AUTO_SERVER option we
assume these issues have to do with race conditions and/or timing with the
embedded server stopping at the same time the non-embedded connections are
stopping.
As far as reproducible exceptions or corrupting the database. No, I cannot
make bad issues happen on command. We tend to start our applications and
run them for a long time (days), so we do not make a point of starting and
stopping them constantly.
- Are there any other exceptions (maybe in the .trace.db file)?
Could you send them please?
In this case, I have posted the entire contents of the trace file.
- Do you still have any .trace.db files, and if yes could you send them?
I can look for other trace files, however the one for this exception has
been posted in its entirety.
- Could you send the .h2.db file where this exception occurs?
I maybe able to post it to an ftp server on Monday - but I would have to
send you connection details directly not on the forum. I have not been
able to confirm the database file is corrupted yet since I did not run it
again after the exception, but I will take your word for it. Would you be
interested in downloading it from an ftp server?
--
You received this message because you are subscribed to the Google Groups "H2
Database" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/h2-database.
For more options, visit https://groups.google.com/d/optout.
