|
Replies:
4
-
Last Post:
Dec 2, 2005 1:10 AM
by: mthornton
|
|
|
|
|
|
|
Opening a file with FILE_SHARE_DELETE mode (Only on Windows)
Posted:
Nov 30, 2005 11:26 AM
|
|
|
Hi,
We have an application that imports logs from several 3rd party vendor's applications. Basically what we do is import the logs in real time, i.e we do have a live FileInputstream connection to the log file. Now, when the 3rd party applications that rotate these logs (many of them do when they grow big or scheduled periodically), all unix flavors dont see to have any problem, while the windows does complain that the device or resource is busy and the original application is not allowed to rotate it. When i dug into the native code of windows jvm, i found that the file is not opened in the FILE_SHARE_DELETE mode and only with FILE_SHARE_READ and FILE_SHARE_WRITE modes. When we wrote a separate C++ application the opens a file with FILE_SHARE_DELETE mode, we found that the logs are rotatable.
Now, how can we instruct the JVM to open a file with FILE_SHARE_DELETE mode? Is there any such implementation already or do i have to come up with another class extending the FileInputStream and use a totally different open method where the file is opened with this mode in the native code?
Thanks
Manava
|
|
|
|
|
|
|
Re: Opening a file with FILE_SHARE_DELETE mode (Only on Windows)
Posted:
Nov 30, 2005 4:02 PM
in response to: manavaputra
|
|
|
Currently there is no convenient way to do this and no way to force the Java libraries to specify FILE_SHARE_DELETE when the file is opened. Thanks for mentioning this deficiency and providing a clear explanation of why it is necessary. I've filed RFE 6357433 to cover it which should be visible in the bug database tomorrow.
There are a few possible workarounds, but none of them are really convenient.
1. The 100% pure Java way to do this would be to use a different mechanism for bringing in the log's data which doesn't require the log to be always open. You could use FileInputStream and FileChannel to open and memory-map the file and keep track of your current position in the file as well as a timestamp to know whether the other application deleted and re-created the file since the last time it was opened. You could thereby only open the log for brief periods of time, reading only the new data in the log file each time, or going back to the beginning if the log was recreated.
2. You could create a new implementation of the InputStream abstract class using Windows-specific native code which would implement your desired functionality. This would be pluggable into e.g. BufferedInputStream so that you could continue to reuse other pure-Java code interacting with your InputStream. The advantage of going down this route would be that you would have complete control of the new native code, but the disadvantage is that it wouldn't interact at all with the existing Java libraries' native code, which may or may not be an issue. I probably wouldn't recommend subclassing FileInputStream directly as the ties between the native code and Java code are very tight and it may be difficult to interpose on just the routine you want to change. (This is a larger problem which we are aware of at Sun and which I personally would like to fix in a future release.)
3. You could download the Mustang source code, make the necessary changes to io_util_md.c, rebuild java.dll, and drop your modified java.dll into the rest of the JDK.
The primary issue with making the change in (3) immediately is compatibility; there may be applications relying on the current Windows file locking semantics and there is no way in the current public API to request that this not be done. We'll look into possible public API changes to support this in the next release.
|
|
|
|
|
|
|
|
|
Re: Opening a file with FILE_SHARE_DELETE mode (Only on Windows)
Posted:
Dec 1, 2005 8:19 AM
in response to: kbr
|
|
|
It would be a bad idea to memory map the file as you then lose control over how long the file is prevented from being deleted. Windows won't allow the file to be deleted until the memory map is closed, and the close won't happen until after the mapped byte buffer is collected by the garbage collector.
For this reason memory mapping is almost unusable for many purposes on Windows (and therefore any application intended to run on multiple platforms).
|
|
|
|
|
|
|
|
|
Re: Opening a file with FILE_SHARE_DELETE mode (Only on Windows)
Posted:
Dec 1, 2005 6:24 PM
in response to: mthornton
|
|
|
This is a good point. I have never needed to forcibly close a file memory-mapped using NIO and didn't notice that there is no way to do so.
Do you think using the FILE_SHARE_DELETE flag for the FileInputStream would solve this problem as well? Is your statement about the unusability of memory mapping tied to this kind of problem, or do you have another scenario?
|
|
|
|
|
|
|
|
|
Re: Opening a file with FILE_SHARE_DELETE mode (Only on Windows)
Posted:
Dec 2, 2005 1:02 AM
in response to: kbr
|
|
|
I don't know if FILE_SHARE_DELETE would solve the problem of deleting files which have been memory mapped (the documentation is unclear).
However this is not the only problem that arises from the inability to forcibly close memory mappings. An open mapping also prevents a file being truncated if data beyond the point of truncation is still mapped.
The other main problem is that open but unreachable memory mappings use address space and thus a further mapping request can fail even though there would be sufficient space were all the unreachable mappings to be closed. This problem might be resolvable if there was an interaction between the map method and the garbage collector and mapping cleanup processes. In the event of a mapping failing due to lack of address space the garbage collector would be automatically invoked to see if other mappings could be reclaimed.
Message was edited by: mthornton
|
|
|
|
|
java.net RSS
