[VFS] Multiple OutputStreams spec vs. DefaultFileContent implementation

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

[VFS] Multiple OutputStreams spec vs. DefaultFileContent implementation

Bernd Eckenfels-2
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VFS] Multiple OutputStreams spec vs. DefaultFileContent implementation

Bernd Eckenfels
Hello,

there are some more places where some semantic for input/output streams is  
described (and I think it does not match the implementation)

org.apache.commons.vfs2.provider.http.HttpFileObject.doGetInputStream():127
      * <p>It is guaranteed that there are no open output streams for this  
file
      * when this method is called.

org.apache.commons.vfs2.provider.tar.TarFileObject.doGetInputStream():161
org.apache.commons.vfs2.provider.zip.ZipFileObject.doGetInputStream():158
org.apache.commons.vfs2.provider.AbstractFileObject.doGetInputStream():435
org.apache.commons.vfs2.provider.AbstractFileObject.doGetRandomAccessContent(RandomAccessMode):448
      * The input stream
      * returned by this method is guaranteed to be closed before this
      * method is called again.

org.apache.commons.vfs2.provider.AbstractFileObject.doGetOutputStream(boolean):473
      * <p>It is guaranteed that there are no open stream (input or output)  
for
      * this file when this method is called.

Greetings
Bernd


Am 08.08.2013, 18:12 Uhr, schrieb Bernd Eckenfels  
<[hidden email]>:

> 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://www.zusammenkunft.net

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]