Joe, All seems correct to me. Great analysis - that is not an easy piece of code to follow!
On the OutputStreams, it is wrapped in a DisableOnCloseOutputStream. The input may instead he wrapped in a NonCloseableInputStream, but it should use a DisableOnCloseInputStream instead. This is definitely a bug. Sent from my iPhone > On Mar 5, 2015, at 10:42 PM, Joe Witt <[email protected]> wrote: > > Brian, > > Mark has the most up to date mental model for the ProcessSession so he > might need to completely refute or modify what i say here. But...the > intent as the API was designed was that one would not do this nor > should they be able to as you, in my opinion, correctly assumed. > > The point of the callback is to enforce important conditions and state > of the process session. Doing what you have there means that it could > become 'unclear' which input stream you're reading (to you as the > developer) if there are also operations being done which modify the > flow file. > > The reason you're able to do that is that we're actually blocking the > close of the root input stream. But we have two other streams which > wrapped that which we did close (LimitedInputStream and > ByteCountingInputStream) which are how we ensure you only read up to > the amount of bytes appropriate for a given flowfile and so that the > framework can track actual number of bytes read. However, even though > those have been closed we're not doing anything to block them from > still being used (that I *think* is a bug). > > I also notice that ProcessSession.read(...) javadocs indicate an > IllegalStateException should throw an IllegalStateException should be > thrown if this method is being called from within a callback of > another method in this session for the given flow file. But I don't > see that this would occur. I am guessing this constraint was relaxed > when the closeability/timing of close was adjusted. We should clarify > this and fix the API description or enforce it. > > Mark can you elaborate, correct, advise? > > Thanks > Joe > > >> On Thu, Mar 5, 2015 at 9:58 PM, Bryan Bende <[email protected]> wrote: >> Is it generally a bad idea to read from a FlowFile InputStream outside of >> the session.read() /InputStreamCallback? >> >> For example, if you did something like the following: >> >> final ObjectHolder<InputStream> inputStreamHolder = new >> ObjectHolder<>(null); >> >> session.read(flowFile, new InputStreamCallback() { >> @Override >> public void process(InputStream in) throws IOException { >> inputStreamHolder.set(in); >> } >> }); >> >> // read from inputStreamHolder.get() >> >> I was expecting that this wouldn't work, but it appears that it does so I >> am wondering if there are any negative ramifications of doing this. >> >> -Bryan
