Re: why org.apache.beam.sdk.util.UnownedInputStream fails on close instead of ignoring it

Yep but makes one other step to work in beam - dont forget you already passed like 10 steps when you end up on coders. My view was that the skip first close was a win-win for beam and users bit technically you are right, users can always do it themselves. Le 1 févr. 2018 07:16, "Lukasz Cwik"

Re: why org.apache.beam.sdk.util.UnownedInputStream fails on close instead of ignoring it

I'm not sure what you mean by it closes the door since as the caller of the library you can create a wrapper filter input stream that ignores close calls effectively overriding what happens in the UnownedInputStream. On Wed, Jan 31, 2018 at 10:08 PM, Romain Manni-Bucau

Re: why org.apache.beam.sdk.util.UnownedInputStream fails on close instead of ignoring it

Le 1 févr. 2018 03:10, "Lukasz Cwik" a écrit : Yes, people will write bad coders which is why this is there. No, I don't think swallowing one close is what we want. In the case where you wants to pass an input/output stream to a library that incorrectly assumes ownership, the

Re: why org.apache.beam.sdk.util.UnownedInputStream fails on close instead of ignoring it

Hmm, here we are the ones owning the call since it is in a coder, no? Do we assume people will badly implement coders? In this particular case we can assume close() will be called by a framework I think. What about swallowing one close() and fail on the second? Romain Manni-Bucau @rmannibucau

Re: why org.apache.beam.sdk.util.UnownedInputStream fails on close instead of ignoring it

Because people write code like: myMethod(InputStream in) { InputStream child = new InputStream(in); child.close(); } InputStream in = new FileInputStream(... path ...); myMethod(in); myMethod(in); An exception will be thrown when the second myMethod call occurs. Unfortunately not everyone

Re: why org.apache.beam.sdk.util.UnownedInputStream fails on close instead of ignoring it

I get the issue but I don't get the last part. Concretely we can support any lib by just removing the exception in the close, no? What would be the issue? No additional wrapper, no lib integration issue. Romain Manni-Bucau @rmannibucau | Blog

Re: why org.apache.beam.sdk.util.UnownedInputStream fails on close instead of ignoring it

Its common in the code base that input and output streams are passed around and the caller is responsible for closing it, not the callee. The UnownedInputStream is to guard against libraries that are poorly behaved and assume they get ownership of the stream when it is given to them. In the code:

why org.apache.beam.sdk.util.UnownedInputStream fails on close instead of ignoring it

Hi guys, All is in the subject ;) Rational is to support any I/O library and not fail when the close is encapsulated. Any blocker to swallow this close call? Romain Manni-Bucau @rmannibucau | Blog | Old Blog