A
Andrew Rollings
Hi...
I'm having a few problems with the close method of the FileChannel class in
Sun java 1.4.2 (latest as of this date) on Windows.
The code I've written seems to perform as expected on both MacOsX and linux,
so I'm wondering if anyone has come across similar circumstances, and has
found a workaround.
Or alternatively, just tell me what I'm doing that's dumb.
I have a class that maintains a TreeMap of FileChannels. At a certain point
in the class execution, I iterate through the map, and close out all of the
channels, and then attempt to delete the underlying file.
The code to this this is as follows:
-- begin excerpt
Iterator iter = m_FileChannelMap.keySet().iterator();
java.util.Vector keysToRemove = new java.util.Vector();
while ( iter.hasNext() )
{
Long lKey = ( Long ) iter.next();
if (lKey.longValue() < 0)
{
// get the channel and close it
FileChannel fc = (FileChannel)m_FileChannelMap.get(lKey);
fc.truncate(0);
fc.force(true);
fc.close();
// okay - file channel should be closed... we can delete the
// file it represents...
String strFilename = m_strFileroot +
this.getSegmentName(lKey.longValue());
if (!strFilename.endsWith(".T")) throw new IOException("Invalid
segment");
java.io.File fSegment = new File(strFilename);
if (false == fSegment.delete())
{
throw new IOException("Cannot close .T segment:" +
strFilename );
}
}
}
-- end excerpt
The problem is, that the IOException is *always* thrown. It seems that
FileChannel.close() does not immediately close the channel. I'm wondering if
this is anything to do with the fact that I'm maintaining a reference to the
FileChannel object in the TreeMap, but I don't see why that should be the
case. Anyway, this code works perfectly on Mac and Linux, but appears to
barf out on Windows.
Can anyone tell me what's wrong with the code? Failing that can anyone
suggest an alternate method that will work?
(And as an aside, is it safe to remove an item from the map while I'm
iterating through it? I don't currently do that, but I may want to at some
point.)
Thanks for reading.
Andrew
I'm having a few problems with the close method of the FileChannel class in
Sun java 1.4.2 (latest as of this date) on Windows.
The code I've written seems to perform as expected on both MacOsX and linux,
so I'm wondering if anyone has come across similar circumstances, and has
found a workaround.
Or alternatively, just tell me what I'm doing that's dumb.
I have a class that maintains a TreeMap of FileChannels. At a certain point
in the class execution, I iterate through the map, and close out all of the
channels, and then attempt to delete the underlying file.
The code to this this is as follows:
-- begin excerpt
Iterator iter = m_FileChannelMap.keySet().iterator();
java.util.Vector keysToRemove = new java.util.Vector();
while ( iter.hasNext() )
{
Long lKey = ( Long ) iter.next();
if (lKey.longValue() < 0)
{
// get the channel and close it
FileChannel fc = (FileChannel)m_FileChannelMap.get(lKey);
fc.truncate(0);
fc.force(true);
fc.close();
// okay - file channel should be closed... we can delete the
// file it represents...
String strFilename = m_strFileroot +
this.getSegmentName(lKey.longValue());
if (!strFilename.endsWith(".T")) throw new IOException("Invalid
segment");
java.io.File fSegment = new File(strFilename);
if (false == fSegment.delete())
{
throw new IOException("Cannot close .T segment:" +
strFilename );
}
}
}
-- end excerpt
The problem is, that the IOException is *always* thrown. It seems that
FileChannel.close() does not immediately close the channel. I'm wondering if
this is anything to do with the fact that I'm maintaining a reference to the
FileChannel object in the TreeMap, but I don't see why that should be the
case. Anyway, this code works perfectly on Mac and Linux, but appears to
barf out on Windows.
Can anyone tell me what's wrong with the code? Failing that can anyone
suggest an alternate method that will work?
(And as an aside, is it safe to remove an item from the map while I'm
iterating through it? I don't currently do that, but I may want to at some
point.)
Thanks for reading.
Andrew