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

Reply via email to