[
https://issues.apache.org/jira/browse/NIFI-3860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16006449#comment-16006449
]
ASF GitHub Bot commented on NIFI-3860:
--------------------------------------
Github user joewitt commented on the issue:
https://github.com/apache/nifi/pull/1778
-
https://github.com/markap14/nifi/blob/05833e9f13f31697d146c6fa735b506fd6005811/nifi-api/src/main/java/org/apache/nifi/processor/ProcessSession.java#L138
- Must update this line or remove it. Recommend updating to 'The
effective flowfile operated on will be the most recent version of content and
attributes known for this flowfile identity in this session.'
- Recursive read allowance. I think i get where this was going but i think
something isnt quite right with it. If we're going to allow/track multiple
readers then we need to be doing it via a reference counter type logic i
believe.
- It doesn't look like this is quite true still right? It is now more
flexible in that it does allow multiple readers for a given flowfile. So we
need to make sure we're clear about the allowed pattern here which I think is
we can have multiple readers to the flowfile but *not* if we have a writer to
that flowfile. Right?
-
https://github.com/markap14/nifi/blob/05833e9f13f31697d146c6fa735b506fd6005811/nifi-api/src/main/java/org/apache/nifi/processor/ProcessSession.java#L530
-
https://github.com/markap14/nifi/blob/05833e9f13f31697d146c6fa735b506fd6005811/nifi-api/src/main/java/org/apache/nifi/processor/ProcessSession.java#L559
-
https://github.com/markap14/nifi/blob/05833e9f13f31697d146c6fa735b506fd6005811/nifi-api/src/main/java/org/apache/nifi/processor/ProcessSession.java#L582
- Shouldn't this also throw/do the IllegalState protection for active
readers/writers?
-
https://github.com/markap14/nifi/blob/05833e9f13f31697d146c6fa735b506fd6005811/nifi-api/src/main/java/org/apache/nifi/processor/ProcessSession.java#L746
- I checked through other places like the developer guide to see if we need
to call this out but it looks ok. Please make sure to think of anything we
might be missing there. I suspect API docs are sufficient to properly
articulate this now more relaxed contraint in terms of developer flexibility
(but not relaxed in terms of nifi's ability to enforce the critical conditions
are still held).
Anyway - happy to take a look once the above is responded to/addressed as
necessary. I definitely see how this will help developers have a more
flexible/intuitive interaction with the process session while we still hold the
critical aspects firm.
> Consider relaxing the constraint that ProcessSession enforces we give it the
> most recent version of a FlowFile
> --------------------------------------------------------------------------------------------------------------
>
> Key: NIFI-3860
> URL: https://issues.apache.org/jira/browse/NIFI-3860
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Core Framework
> Reporter: Mark Payne
> Assignee: Mark Payne
>
> Currently, when we call methods on ProcessSession to access or modify a
> FlowFile, the ProcessSession will roll itself back and throw a
> FlowFileHandlingException with the message "<FlowFile> is not the most recent
> version of this FlowFile within this session". This was done to ensure that
> Processor developers ensure that they know what they are doing and always
> have the most recent version of a FlowFile. However, this comes with a few
> downsides:
> * It can result in code being complex in error-handling cases when we need to
> ensure that no matter what we hold the most recent version of a FlowFile
> * It's easy to call session.putAttribute and forget to store the most recent
> version of the FlowFile, which gets returned - this is most problematic when
> dealing with a Collection<FlowFile>.
> * We have a method for ProcessSession.read(FlowFile) that returns an
> InputStream. However, we don't have a corresponding write() method. This is
> due to the fact that once we finish writing to the FlowFile, we would have to
> return the most up-to-date version of the FlowFile and there's no way to do
> that if returning an OutputStream.
> We should consider relaxing this constraint and instead just always make use
> of the most recent version of the FlowFile, even if an older version of the
> FlowFile is passed in.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
