Truncating a dynamically created volume results in corrupted journal

[John M Bradley]

If you dynamically load a volume, truncate it (without adding any trees), and then close it, the next time the database is initialized a fatal exception is thrown:

[JOURNAL_COPIER] WARNING Missing volume truncated referenced at journal address 364
[main] WARNING Missing volume truncated referenced at journal address 17,004 (6 similar occurrences in 0 seconds)
Exception in thread "main" com.persistit.exception.InvalidPageAddressException: Page 1 out of bounds [0-1]
 at com.persistit.VolumeStorageV2.readPage(VolumeStorageV2.java:426)
 at com.persistit.Buffer.load(Buffer.java:456)
 at com.persistit.BufferPool.get(BufferPool.java:780)
 at com.persistit.Tree.setRootPageAddress(Tree.java:203)
 at com.persistit.VolumeStructure.init(VolumeStructure.java:70)
 at com.persistit.VolumeStorageV2.open(VolumeStorageV2.java:217)
 at com.persistit.Volume.open(Volume.java:442)
 at com.persistit.Persistit.loadVolume(Persistit.java:1066)
 at Truncate.main(Truncate.java:30)

[Peter Beaman (pbeaman)]

Marked this medium because there are probably workaround solutions to avoid having to truncate a non-temporary volume. For example, and application could simply delete all the trees in the volume.

More fundamentally, we need to incorporate management of Tree and Volume instances into the transaction protocol and deal with issues such as transaction A needing to read an old copy of the volume while Transaction B is truncating it. A design for these improvements is underway.