commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Suresh Pendap <SURESH.PEN...@oracle.com>
Subject RE: Best practive for invoking VFS.close()
Date Mon, 16 Feb 2009 23:28:53 GMT
Hi!
         So is it true that I have to programmatically create the DefaultFileSystemManager
if I have to close the FileSystemManager instance after every request?

Also can somebody send me the sample code for programmatically creating the DefaultFileSystemManager
and adding the different providers, temporary data store and Replicators etc etc.

Regards
Suresh


-----Original Message-----
From: Mario Ivankovits [mailto:mario@ops.co.at] 
Sent: Monday, February 16, 2009 2:54 PM
To: Commons Users List
Subject: RE: Best practive for invoking VFS.close()

Hi!

> -----Original Message-----
> From: Suresh Pendap [mailto:SURESH.PENDAP@oracle.com]


> Currently we are not invoking the (DefaultFileSystemManager).close ()
> method at all.   I would like to know if it can have any potential Out
> of Memory issues or any other performance related issues.

Under the hood, a SoftRef-cache holds the references to the resolved files. As long as one
of your objects holds a strong refrence to the FileObject it stays in memory. Also, you have
to take care that you call .close() on each and every file object if you do not longer need
them, only then you can be sure that the underlaying transport library has been closed.

Yes, it is tricky to do this right.


> Also would it really impact the performance if we programmatically
> create the DefaultSystemManager upon every request and then close the
> DefaultFileSystemManager instance at the end of the request?
 
This will be the safest way, depending on your throughput you might get a performance. But
why not simply test it on your own? Then you can be sure.

Ciao,
Mario

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org


Mime
View raw message