commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Smiley (JIRA)" <j...@apache.org>
Subject [jira] Commented: (IO-71) [io] PipedUtils
Date Mon, 11 Feb 2008 19:34:08 GMT

    [ https://issues.apache.org/jira/browse/IO-71?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12567767#action_12567767
] 

David Smiley commented on IO-71:
--------------------------------

Perhaps a pair of parallel classes would work out okay.  But I suspect that the client code
would be more involved than you see in my test code.

I wasn't looking for a generic filtering mechanism... I just had to work with an existing
OutputStream that I wanted to be inverted to an InputStream -- that's it.  I can't change
GZipOutputStream so I had to work with that in some way.  If I had to start from scratch if
GZOS didn't exist then I would of ended up with something quite different so that I wouldn't
leave myself  needing to solve a problem with JDK's pipes.

The 2nd thread is an unfortunate necessity.  Observe that the docs for the piped streams in
the JDK require it.  It's not a requirement you can simply refactor away, it's a fundamental
issue of the directionality of the streams.  The underlying reason is that the caller of OutputStream.write
doesn't really have any way of ensuring that the  OutputStream implementation only write <=
X bytes.  If for example the outputstream is deflating some data then it's going to write
more then the amount of data in the arguments to the write method.  You have no way of controlling
just how much, so you'd have to buffer it.  But the problem with buffering it in this situation
is that it's unbounded since there is no way to generically limit how much buffer the write()
method is going to actually write to its delegate.  Perhaps it is true that in practice, that
amount isn't big (particularly if you can ensure that the OutputStream isn't doing much buffering
any way) but that could lead to some fragility since either you max it and an application
could theoretically spontaneously break given a particular data stream, OR, if it's unbounded
then it's theoretically possible the buffer will need to be bigger than you're willing/able
to accept.  You don't really have any control of this, unfortunately. 

In hind-site looking at the JDK's IO streams architecture, I think an alternative API could
of been developed to avoid this situation.  But the current one is the one we have to live
with.

> [io] PipedUtils
> ---------------
>
>                 Key: IO-71
>                 URL: https://issues.apache.org/jira/browse/IO-71
>             Project: Commons IO
>          Issue Type: Improvement
>          Components: Utilities
>         Environment: Operating System: All
> Platform: All
>            Reporter: David Smiley
>            Priority: Minor
>             Fix For: 2.x
>
>         Attachments: PipedUtils.zip
>
>
> I developed some nifty code that takes an OutputStream and sort  of  reverses it as if
it were an 
> InputStream.  Error passing and  handling  close is dealt with.  It needs another thread
to do the  work 
> which  runs in parallel.  It uses Piped streams.  I created  this because I  had to conform

> GZIPOutputStream to my framework  which demanded an  InputStream.
> See URL to source.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message