commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bernd Eckenfels" <bernd-2...@eckenfels.net>
Subject [VFS] Multiple OutputStreams spec vs. DefaultFileContent implementation
Date Thu, 08 Aug 2013 16:12:40 GMT
Hello,

I was trying to understand the concurrency semantics of VFS2, and I found  
some comments which contradict each other and all of them also contradict  
the implementation:

The current implementation allows multiple input streams and multiple  
random access and a single outputstream PER THREAD. The close() will close  
all of them (for the current thread).

DefaultFileContent.java

#401: getInputStream -> no limit on number of opens, all independent,  
track by threadlocal, wraps FileObject.getInputStream with  
FileContentInputStream

#430: getRandomAccessContent -> no limit on number of opens, all  
independent(?), track by threadlocal, wraps  
FileObject.getRandomAccessContent in FileRandomAccessContent

#468: getOutputStream -> allows only one open per thread, track by  
threadlocal, wraps FileObject.getOutputStream in FileContentOutputStream

#495: close() -> closes all (up until first exception!) streams tracked in  
thread local (only). Discards the not-closes streams in thread local in  
all cases (why?)

#584: isOpen() -> returns true if any of the tracked streams in current  
thread are still open

#596: isOpenGlobal() -> returns true if any of the threads have still  
tracked streams open - not in Interface

While I can understand why the clone is limited to the single thread, I am  
not particular clear on the restriction for a single output stream but  
multiple random access. I can understand that multiple output streams do  
cause problems, but only/even more so with multiple threads. So the  
current limit for one OS/thread seems aribitrary.

Actually having a real atomic append only semantic (for multiple writers  
in same of different thread) would be very helpfull for OS. (if I write x  
bytes in a single write() operation they will always land in a atomic  
chunk after the last write of somebody else). Some providers might not be  
able to provide it at all or not across multiple JVMs -> possibility for  
capabulities?


And here are the incomplete/contradicting specifications:


FileContent.java:

#38  * A file may have multiple InputStreams open at the same time.

#149 * <p>There may only be a single input or output stream open for the
      * file at any time.
     InputStream getInputStream() throws FileSystemException;

#167 * <p>There may only be a single input or output stream open for the
      * file at any time.
     OutputStream getOutputStream() throws FileSystemException;

#186 * <p>There may only be a single input or output stream open for the
      * file at any time.
     RandomAccessContent getRandomAccessContent(final RandomAccessMode  
mode) throws FileSystemException;

#203 * <p>There may only be a single input or output stream open for the
      * file at any time.
     OutputStream getOutputStream(boolean bAppend) throws  
FileSystemException;

#217
      * Closes all resources used by the content, including any open stream.
      * Commits pending changes to the file.
      * <p/>
      * <p>This method is a hint to the implementation that it can release
      * resources.  This object can continue to be used after calling this
      * method.
      */
     void close() throws FileSystemException;

I would suggest you change the specification to eighter describe the  
default implementation or to make it clear
that it is implementation specific (and to what degree and depending on  
which capabilities)

If the concurrency semantic depends on the FileContent Implementation,  
then I would say:

  * The decision if you can have multiple open OutputStream or  
RandomAccessContent handles depends
  * on the actual implementation for the FileContent interface. This also  
influences isOpen() and close() methods.
  * For the default behavor see DefaultFileContent. You can always request  
multiple independend InputStreams in
  * the same or different threads.

(isOpenGlobal() is not in the interface only in the DefaultFileContent).

If you agree something needs to be changed, I am happy to open a JIRA  
ISsue.

Gruss
Bernd
-- 
http://bernd.eckenfels.net

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


Mime
View raw message