Tja, wie das so ist, kaum hat man aufgegeben, kommt der entscheidende Einfall. Da der Cleaner offenbar durch eine IOException wegen Zugriffsverletzung bei Zugriff auf einen gesperrten Dateibereich abstürzt, und das in einem Thread bzw. einer Java-Sphäre irgendwo dort passiert, wo man als armseliges Java-Coder-Würstchen nicht mal im Traum hingelangt, hilft es, diesen potentiell illegalen Zugriff vorzuverlegen, indem man nach der letzten Schreiboperation in einen freizugebenden Bereich erstmal
MappedByteBuffer.force() aufruft.
Wie in vorangegangen Posts bereits erwähnt, ist das diese Methode, die IOExceptions wirft, obwohl sie das laut Spezifikation gar nicht darf. Der Trick ist nun, dem Java Compiler klar zu machen, dass da tatsächlich Exceptions fliegen, diese dann abzufangen, zu ignorieren, und so lange in einer Endlosschleife via
force() die Daten reinzuwürgen, bis keine Exception mehr fliegt.
Damit euch genauso schlecht wird wie mir, hier noch ein paar Happen Code:
Code: Alles auswählen
// MappedByteBuffer.force() in eigene Methode verpacken, die deren fehlerhafte Exceptionspezifikation um IOException ergänzt
static void throwingForce(MappedByteBuffer buffer) throws IOException
{
buffer.force();
}
static void forceDownAllTheWayDown(MappedByteBuffer buffer)
{
boolean success = false;
while(!success)
{
try
{
throwingForce(buffer);
success = true;
}
catch(IOException e) { }
}
}
Randbemerkung: Die ID-Verteilung in den Open-Street-Map-Daten steht einem Zufallsgenerator leider nur in wenig nach, weswegen ich nun zwar eine lauffähige Lösung habe, deren Performance mit dem Konzept der Riesen-"Hash"-Map auf der Festplatte aber so unterirdisch ist, dass dieser grauenhafte Code wohl doch keinen Einzug in das Endprodukt finden wird.