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
<bernd-2...@eckenfels.net>:
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: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
