I'm using a third-party commercial library which seems to be leaking file handles (I verified this on Linux using lsof). Eventually the server (Tomcat) starts getting the infamous "Too many open files error", and I have to re-start the JVM.
I've already contacted the vendor. In the meantime, however, I would like to find a workaround for this. I do not have access to their source code. Is there any way, in Java, to clean up file handles without having access to the original File object (or FileWriter, FileOutputStream, etc.)?
a fun way would be to write a dynamic library and use LD_PRELOAD to load it for the java instance you are launching ... this DLL could override the appropriate underlying open(2) system call (or use some other logic) to close existing file descriptors of the process before passing the call to the libc implementation (or the kernel). You need to do some serious accounting and possibly deal with threads; but it can be done. Especially if you take hints from /proc/pid/fd/ for figuring whether or not a close is appropriate for the target fd.
You could, on startup, open a bunch of files and use File*putStream.getFD() to obtain a bunch of java.io.FileDescriptors, then close them, but hold onto the descriptors. Later you might be able to create streams using those stored FileDescriptors and close them.
I have not tested this, so would not be surprised if it did not work on some platforms.
Related
After years of coding with the old File API, I'm finally ready to hop onto the whole Path/Paths train. For the most part, this has gone smoothly, however, I'm stumped on this particular aspect: temporary files.
The documentation on java.nio.Files#createTempFile says:
As with the File.createTempFile methods, this method is only part of a temporary-file facility. Where used as a work files, the resulting file may be opened using the DELETE_ON_CLOSE option so that the file is deleted when the appropriate close method is invoked. Alternatively, a shutdown-hook, or the File.deleteOnExit() mechanism may be used to delete the file automatically.
I don't see where the DELETE_ON_CLOSE option is supposed to be specified. Using a shutdown hook is incredibly inconvenient (unless I'm thinking of it wrong). In an effort to avoid using both Path objects and File objects, I am looking for a solution similar to the File.deleteOnExit() for the Path object, but obviously one that doesn't require using Path.toFile().[...].toPath() sort of calling pattern.
What is the correct way to implement "self-destructing" temporary files using the java.nio.Files API?
You set that option when you write, for example:
Path myTempFile = Files.createTempFile(...);
Files.write(myTempFile, ..., StandardOpenOption.DELETE_ON_CLOSE);
I have an issue in my codebase where we are not properly closing file handles, or probably streams. We eventually get a TooManyOpenFiles exception under very heavy load. Based on the output of lsof, we are pretty sure we know where the leak is (in our logging system), but my question is: how can I write a unit test that checks, when it's complete, that resources have been closed properly? Is there a way to query the JRE to find out how many files are currently open? Can I somehow intercept file operations so I can monitor them?
I suspect I will have to instrument my code in order to manage all the file I/O, count references, and make sure they are getting closed that way, but if anyone knows of a top-down solution akin to those ideas I mentioned above, that would be a huge help!
Since you are talking about Tests, PowerMock http://code.google.com/p/powermock/ might do the trick. It makes it possible to mock static methods and constructors if I am not mistaken. So you could mock/spy on the constructors and on the close methods or what ever you need for freeing the resources.
I try to avoid it in my tests but in the case which you describe it might be worth the hassle.
You can use aspect-oriented programming (AOP) tool like AspectJ to add code to count open/closed files to FileInputStream and FileOutputStream. This is fairly easy to do (details depend on the tool, of course) robust and noninvasive.
Looks like you can watch this via JMX.
Someone posted code here:
http://java-monitor.com/forum/showthread.php?t=130
You'll have to enable JMX in your JVM if you haven't already.
You could write your own "library" for the normal IO classes, FileInputStream, etc. That tracks (in test) what caller opened it, if it's still open, a global list, etc. Have it wrap a "real" FileInputStream.
Then use that everywhere in your code instead of a "normal" FileInputStream et al.
Then at the end of your unit test you assert WrappedFileInputStreams.assertAllWereClosed or what have you.
Another option would be to write your methods so they accept FileinputStream as a parameter somehow, then call them, then assert your parameter comes out "closed now" after the method ends.
Or if you know you'll be on linux, do a system call to lsof and it should not list any files as location '(deleted)'. https://unix.stackexchange.com/a/64737/8337
For some reason on OS X it's not that easy, it doesn't show "(deleted)" but you could still detect if the file is gone by looping over lsof -p ... and checking if each file is actually there on the file system...
All,
I'm working on the design of a cloud-based service that will provide the option to execute some "plugin" code submitted by clients. In order to make this work it is essential that the plugins can't threaten system integrity or have any ability to access the data of other clients.
Ideally I'd like it to be possible for clients to submit a simple jar file (containing a class conforming to some pre-defined interface) which would then be run within a sandbox.
The client code should be allowed to:
Take as much CPU time as it needs on a single thread
Perform any calculations using standard java classes (e.g. java.lang.Math, java.util.Random etc.)
Call any libraries bundled in the jar (but which must be subject to the same restrictions)
But I would specifically need to disallow the following:
Spawning new threads (so that server resource can be fairly managed!)
Any access to the file system / IO / network
Any access to native code
Any access to data in the JVM other than that passed to / created by the client code
Any access to reflection on classes other than those in the .jar sandbox
Any ability to call methods on objects outside the sandbox, other than the standard Java libraries
Is it be possible to achieve this with a custom ClassLoader / SecurityManager setup? Or will I need to start looking for a more sophisticated solution (e.g. launching multiple JVMs?)
Managing resource and limiting resources is not possible in java. You can prevent malicious code to access system resources (disk/network and so) or the JVM itself but:
...
Spawning new threads (so that server resource can be fairly managed!)
If i wanna be malicious I am gonna do all my code in the finalizer thread and just block the VM. Same doing protected void finalize(synchronized(Thread.class) {for(;;) LockSupport.park();}} bye-bye new threads.
Eating all the memory, eating all direct memory and so on.
Accessing zip files in my own jar, and expect 'em getting moved away, so the JVM crashes (due to bug(s) in zlib)
If one purposely wants to deny resources, it is just not a feasible task to try and catch the hacker. You'd need to know what to search for and dynamically check/enhance the classes on run-time to disallow the behavior.
Any ability to call methods on objects outside the sandbox, other than the standard Java libraries
What are the standard libraries? Do you know if/when they must possibly execute some code in a privileged method.
Each customer - separate VM w/ full restrictions, process affinity/priority, incl max memory/stack and so on.
I think everything you want to achieve can be done through a custom SecurityManager. In fact it's pretty simple, you just create a class that extends SecurityManager, implement the two checkPermission(..) methods and in the first iteration just throw an SecurityException for everything that comes in (and log what you just denied). Then you allow specific operations until you find yourself in the situation that it's possible to create useful plugins and let your clients play with it. They will complain. Then you have to judge whether to allow them to do whatever they requested or if you want to stick with your rules. Here the difficult part begins...
I need to do a lot of things with resources on the fly: parsing xsd/xml docs, building and compiling java classes, package them into jars ans wars, persist in DB, deploy them as OSGi, etc.
Most of the libraries/API's, which I use, allow to perform all these intermediate tasks in memory, but there are some "special" libraries operating with java.io.File only. And there's nothing left for me but using real temporary files and directories which is not good in Java EE environment.
I believe there must be a library/solution for in-memory file structure having nodes extending java.io.File (as I see it). Please drop in a link to known/similar libraries. Any comments are welcome.
Thanks!
I do not believe you are going to find what you are looking for. The java.io.File API was not written with the intention of providing a file system abstraction that can be implemented in a variety of ways. While it does expose method for some FS operations (such as delete and mkdir), it doesn't handle the basic read/write I/O. That is left to other classes, such as FileInputStream. This means that from API standpoint, a File object is no more than a path. Nothing is abstracted. You are stuck.
One option is to use a RAM disk. Your program will think its using the disk with java.io.File, but it will really be using main memory.
There is a fine alternative available: https://github.com/google/jimfs
This supports java(7+) in memory filesystem handling and is very easy to use too.
I have a set of files. The set of files is read-only off a NTFS share, thus can have many readers. Each file is updated occasionally by one writer that has write access.
How do I ensure that:
If the write fails, that the previous file is still readable
Readers cannot hold up the single writer
I am using Java and my current solution is for the writer to write to a temporary file, then swap it out with the existing file using File.renameTo(). The problem is on NTFS, renameTo fails if target file already exists, so you have to delete it yourself. But if the writer deletes the target file and then fails (computer crash), I don't have a readable file.
nio's FileLock only work with the same JVM, so it useless to me.
How do I safely update a file with many readers using Java?
According to the JavaDoc:
This file-locking API is intended to
map directly to the native locking
facility of the underlying operating
system. Thus the locks held on a file
should be visible to all programs that
have access to the file, regardless of
the language in which those programs
are written.
I don't know if this is applicable, but if you are running in a pure Vista/Windows Server 2008 solution, I would use TxF (transactional NTFS) and then make sure you open the file handle and perform the file operations by calling the appropriate file APIs through JNI.
If that is not an option, then I think you need to have some sort of service that all clients access which is responsible to coordinate the reading/writing of the file.
On a Unix system, I'd remove the file and then open it for writing. Anybody who had it open for reading would still see the old one, and once they'd all closed it it would vanish from the file system. I don't know if NTFS has similar semantics, although I've heard that it's losely based on BSD's file system so maybe it does.
Something that should always work, no matter what OS etc, is changing your client software.
If this is an option, then you could have a file "settings1.ini" and if you want to change it, you create a file "settings2.ini.wait", then write your stuff to it and then rename it to "settings2.ini" and then delete "settings1.ini".
Your changed client software would simply always check for settings2.ini if it has read settings1.ini last, and vice versa.
This way you have always a working copy.
There might be no need for locking. I am not too familiar with the FS API on Windows, but as NTFS supports both hard links and soft links, AFAIK, you can try this if your setup allows it:
Use a hard or soft link to point to the actual file, and name the file diferently. Let everyone access the file using the link's name.
Write the new file under a different name, in the same folder.
Once it is finished, have the file point to the new file. Optimally, Windows would allow you to create the new link with replacing the existing link in one atomic operation. Then you'd effectively have the link always identify a valid file, either the old or the new one. At worst, you'd have to delete the old one first, then create the link to the new file. In that case, there'd be a short time span in which a program would not be able to locate the file. (Also, Mac OS X offers a "ExchangeObjects" function that allows you to swap two items atomically - maybe Windows offers something similar).
This way, any program that has the old file already opened will continue to access the old one, and you won't get into its way creating the new one. Only if an app then notices the existence of the new version, it could then close the current and open it again, this way getting access to the new version.
I don't know, however, how to create links in Java. Maybe you have to use some native API for that.
I hope this helps anyways.
I have been dealing with something similar recently. If you are running Java 5, perhaps you could consider using NIO file locks in conjunction with a ReentrantReadWriteLock? Make sure all code referencing the FileChannel object ALSO references the ReentrantReadWriteLock. This way the NIO locks it at a per-VM level while the reentrant lock locks it at a per-thread level.
FileLock fileLock = filechannel.lock(position, size, shared);
reentrantReadWriteLock.lock();
// do stuff
fileLock.release();
reentrantReadWriteLock.unlock();
Of course, some exception handling would be required.