You can clone with
HTTPS or Subversion.
Shaun spotted this issue on snowy. There's a whole bunch of containers with a single file in each.
The excess containers aren't sealed so it's not the size condition that's wrong. On init the Area is supposed to find its first existing open container and continue packing into it:
I guess that must be failing. Perhaps it's the query:
I always assumed that would return the first match. But perhaps if there's multiple rows JDBI returns "null". That would cause the observed behaviour at least.
How it might be getting into that situation of more than one open container in the first place:
Possible fix to make DOSS more robust?
SELECT MIN(container_id) FROM containers WHERE sealed = 0 AND AREA = :area;
Need to think about the implications of the race too. When I wrote LocalBlobStore I was imagining it being called from multiple threads, not multiple instances of LocalBlobStore with a single shared database as Amber's currently doing.
@scoen I think we should move the opening of LocalBlobStore in amber up from the AmberSession level to the AmberDb class so the sessions all share the same blobstore.
Hmm, it also looks like amber's never closing the BlobStore which needs fixing as it will be another file descriptor leak.
Test container bug #76 hypothesis
Hypothesis was disproven.
My hypothesis was disproven by ca5965e. Now I've got no idea what's causing it.
Reading an old container shouldn't switch the current writing contain…
…er. fix #76
Renamed container to currentContainer to reduce the likelihood
of reintroducing this mistake.
@scoen fix for this released as doss 0.23.8.