java.io.File shouldn't be holding any system handles. it basically holds the path information. note the thread from several months ago about how inefficient this is on network drives when you are checking attributes etc. lots of round trips. the Java team said there weren't going to "fix" (change) this behaviour.
if your code is using a FileInputStream or RandomAccessFile for processing, this should be invalidated when the file system drops out. you can't reopen these without constructing new ones from the File. It's obviously hard to tell where the exact problem lies. Perhaps the error handing and retry isn't working as cleanly as you expect (ie. it's irrelevant that it's a network drive). Perhaps the failing File opens are killing the whole daemon process (or worse). You should conduct some experiments where you make the directory "go away". Renaming your data directory should do the trick. The other possible problem is that it is a problem with the share remount, but not necessarily a problem with Java or your code. ie. after remount (or just before it drops out) the directories are visible but you still can't open the files properly (even if for a short time). i have no reason to think this is the case but it shouldn't be overlooked. ie. why did the share go away in the first place? As I say, you want to make sure your disk polling code is as bullet proof as possible and then go from there. -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
