You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@commons.apache.org by Suresh Pendap <SU...@oracle.com> on 2009/02/16 22:35:57 UTC
Best practive for invoking VFS.close()
Hi,
We are using VFS in order to transfer files using FTP, SFtp providers. We are using the singleton instance of the FileSystemManager by invoking VFS.getManager ().
All the file transfers are done by a daemon process upon user's request. Currently we are not invoking (DefaultFileSystemManager).close () method after the end of each request.
I have noticed that if I invoke the close() after the end of the request, the next request fails as the default single instance of FileSystemManager is already closed by the previous request.
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. I have read in the "Using APi" wiki page that it cleans the resources and closes all the files used by the FileSystemManager.
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?
Regards
Suresh
RE: Best practive for invoking VFS.close()
Posted by Suresh Pendap <SU...@oracle.com>.
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
RE: Best practive for invoking VFS.close()
Posted by Mario Ivankovits <ma...@ops.co.at>.
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