Re: [vfs] LRUFilesCache safe for production use? Google App Engine/Java plug-in
On May 25, 2009, at 7:10 PM, Vince Bonfanti wrote: I'm working on a Google App Engine/Java (GAE/J) plug-in for VFS (it's almost done) and have a few questions: 1. Is the LRUFilesCache safe for production use? GAE/J won't allow using the default SoftRefFilesCache because it doesn't allow background threads. I've found a few really old messages saying things like SoftRefFilesCache is the only implementation suitable for production use and other file cache implementation might cause resouce leaks, etc. To be honest, I've only glanced over these classes. 2. I might be interested in contributing my implementation, either as a 3rd party plug-in or to be included with the standard VFS package, but don't know how to go about this. Is there someone currently in charge of VFS? This is an Apache project. The Apache Commons PMC manages all the Commons projects, but it is up to the committers to collectively make decisions. The normal route of contributing is to create a Jira issue and attach a patch. One of the VFS committers will review it and then comment on it one way or another. However, as this is a completely volunteer organization it is unpredictable how long that might take. If you continue to contribute and participate on this list the community will take notice and at some point might offer commit rights. See http://www.apache.org/foundation/how-it-works.html#meritocracy . Ralph - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
RE: [vfs] LRUFilesCache safe for production use? Google App Engine/Java plug-in
Hi! 1. Is the LRUFilesCache safe for production use? GAE/J won't allow using the default SoftRefFilesCache because it doesn't allow background threads. I 've found a few really old messages saying things like SoftRefFilesCache is the only implementation suitable for production use and other file cache implementation might cause resouce leaks, etc. Yes, these messages are still true. Sad to say that, but I realized that too late and planned to fix this, which is not that easy. Using any thing else than the SoftRefFilesChache will introduce memory leaks as the file-system object will not be discarded. You have to call close() on the filesystem, or even better call close on the DefaultFileSystemManager at all and do not use the VFS.getManager() singleton approach. That will also ensure that each and every resource used by the underlaying libraries are closed then too. Ciao, Mario - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [vfs] LRUFilesCache safe for production use? Google App Engine/Java plug-in
On May 25, 2009, at 11:28 PM, Mario Ivankovits wrote: Hi! 1. Is the LRUFilesCache safe for production use? GAE/J won't allow using the default SoftRefFilesCache because it doesn't allow background threads. I 've found a few really old messages saying things like SoftRefFilesCache is the only implementation suitable for production use and other file cache implementation might cause resouce leaks, etc. Yes, these messages are still true. Sad to say that, but I realized that too late and planned to fix this, which is not that easy. Using any thing else than the SoftRefFilesChache will introduce memory leaks as the file-system object will not be discarded. You have to call close() on the filesystem, or even better call close on the DefaultFileSystemManager at all and do not use the VFS.getManager() singleton approach. That will also ensure that each and every resource used by the underlaying libraries are closed then too. Actually, I commented out the call to filesystemclose in SoftRelFilesCache. While looking at the FileSystem implementation I realized that the way close is implemented is not thread safe and can't be called while the system is running. I believe the fix for this is non-trivial. Ralph - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [vfs] LRUFilesCache safe for production use? Google App Engine/Java plug-in
My code will always run within a servlet, so I can close() the filesystem when the servlet is destroyed. In this case, I should be OK using LRUFilesCache? Thanks, Vince On Tue, May 26, 2009 at 2:28 AM, Mario Ivankovits ma...@ops.co.at wrote: Hi! 1. Is the LRUFilesCache safe for production use? GAE/J won't allow using the default SoftRefFilesCache because it doesn't allow background threads. I 've found a few really old messages saying things like SoftRefFilesCache is the only implementation suitable for production use and other file cache implementation might cause resouce leaks, etc. Yes, these messages are still true. Sad to say that, but I realized that too late and planned to fix this, which is not that easy. Using any thing else than the SoftRefFilesChache will introduce memory leaks as the file-system object will not be discarded. You have to call close() on the filesystem, or even better call close on the DefaultFileSystemManager at all and do not use the VFS.getManager() singleton approach. That will also ensure that each and every resource used by the underlaying libraries are closed then too. Ciao, Mario
RE: [vfs] LRUFilesCache safe for production use? Google App Engine/Java plug-in
Yes, I think so. -Original Message- From: Vince Bonfanti [mailto:vbonfa...@gmail.com] Sent: Tuesday, May 26, 2009 1:14 PM To: Commons Developers List Subject: Re: [vfs] LRUFilesCache safe for production use? Google App Engine/Java plug-in My code will always run within a servlet, so I can close() the filesystem when the servlet is destroyed. In this case, I should be OK using LRUFilesCache? Thanks, Vince On Tue, May 26, 2009 at 2:28 AM, Mario Ivankovits ma...@ops.co.at wrote: Hi! 1. Is the LRUFilesCache safe for production use? GAE/J won't allow using the default SoftRefFilesCache because it doesn't allow background threads. I 've found a few really old messages saying things like SoftRefFilesCache is the only implementation suitable for production use and other file cache implementation might cause resouce leaks, etc. Yes, these messages are still true. Sad to say that, but I realized that too late and planned to fix this, which is not that easy. Using any thing else than the SoftRefFilesChache will introduce memory leaks as the file-system object will not be discarded. You have to call close() on the filesystem, or even better call close on the DefaultFileSystemManager at all and do not use the VFS.getManager() singleton approach. That will also ensure that each and every resource used by the underlaying libraries are closed then too. Ciao, Mario - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
