Thanks. So the weird thing on my system is that the import is not only proceeding, it's succeeding, so there is a document in the index when it turns around and queries for id:1, so the test as-is fails for me.
If I tell it to do a delta import rather than a full import, the test succeeds - no document is indexed. If I tell it to do a delta import, check for no documents, then do a full import and check for 1 document, the second part fails - the full import did not index anything.
None of my test runs show the following exception in checkWritablePersistFile. On systems where the test passes, is it thrown?
throw new DataImportHandlerException(SEVERE, persistFile.getAbsolutePath() +
" is not writable. Delta imports are supported by data config but will not work.");
There's nothing particularly unusual about this setup. It's 64-bit CentOS 6, ext4 over LVM on a Dell server with hardware RAID1, running Oracle Java 1.6.0_27. Java was installed using the method on this page, with the nosrc rpm specific to version _27, not the _26 one on the page:
My best guess (on the unmodified test) is that when checkWritablePersistFile (called from doFullImport) runs the isWritable() check, it is being told that the file is writable, so the full import proceeds. I can't see any reason for the check to work correctly on delta import but not work on full import.
My first thought is thread locking/timing problems in the test code, but I don't know how to look for that, and I know the build.xml for DIH tests is configured to not run tests in parallel. Second thought if that's not the problem is that it is a bug in the OS, Java, or the OS/Java combination. It fails on CentOS5/1.6.0_26 on NFS and ext3. It fails on CentOS6/1.6.0_27 on NFS and ext4. It fails on Debian6/1.6.0_26 on ext4. Due to ongoing work that can't be interrupted to remake the platform, I can't easily try any other combinations.