The stack should help a lot. Also could you include whether
the log disk was full or not?
It is expected that Derby may not be able to restart if there is
any recovery work to do and there is not disk space available. Though
a null pointer error from the server would be incorrect. On restart
recovery Derby may have to write compensation log records to the log,
and Derby does not "reserve" space for future possible log records
(though we do currently preallocate a log file at a time so there
usually is some space available). When enough space is freed up
by the client the database should boot fine.
Note also that this case is often hard to debug using the derby.log
as often writes to it fail because it is on the same disk with no
disk space available.
Also historically the decision to not reserve log space came when we
did not preallocate any log space. We could put logic in to try to
guarantee empty space for the maximum possible recovery space needed
after a crash which might help a small number of applications, the
others are just going to crash soon when they need space for their
regular data tables on the full disk. My opinion would be to do what
it takes to get a reasonable error message to the client, but not
worry too much about being able to boot on a 100% full disk (but it
is important to be able to boot once space is available - also with
derby the client has the choice of freeing space on the db disk or
just copying the whole database/logs to another disk with more space).
We used to test this by using a floppy and filling it up, and then
making sure by hand that database would recover after freeing space and
booting. It
is likely it has not been tested with log on separate device and
it also could be a regression as there is not automated test for
this.
Øystein Grøvlen (JIRA) wrote:
Unable to restart after disk is full
------------------------------------
Key: DERBY-555
URL: http://issues.apache.org/jira/browse/DERBY-555
Project: Derby
Type: Bug
Components: Store
Versions: 10.2.0.0
Environment: Sun Sparc Solaris, 1.4 JDK, Derby Client/Server
Reporter: Øystein Grøvlen
Assigned to: Øystein Grøvlen
Priority: Critical
1. Inserted data into the database until the disk was full. (5 clients
inserting into 5 different tables in parallel.)
2. Shut down the server
3. Start the database again without freeing any disk space.
When I try to start the database again, I get Null-pointer-exception, regardless of how I connect (have tried embedded, client server, ij, jdbc applications). I have not tried to free some space on the disk before starting.
The call stack is not available right now (the computer I used had to be shut
down due to problems with our cooling system), but the exception comes from the
following line in RawStore.java:
properties.put(Attribute.LOG_DEVICE, logFactory.getCanonicalLogPath());
getCanonicalLogPath() returns null which results in a NPE in the hash table.
A quick debug before the computer was stopped, showed that the logFactory was
an instance of org.apache.derby.impl.store.raw.log.ReadOnly which always
returns null in its getCanonicalLogPath().
I suspect this may be related to the fact that I ran with the log in a
non-default location.
