Github user mattyb149 commented on a diff in the pull request:

    https://github.com/apache/nifi/pull/2443#discussion_r164563821
  
    --- Diff: 
nifi-nar-bundles/nifi-mongodb-bundle/nifi-mongodb-processors/src/main/java/org/apache/nifi/processors/mongodb/GetMongo.java
 ---
    @@ -302,15 +348,19 @@ public void process(OutputStream out) throws 
IOException {
                         }
                     }
     
    -                session.commit();
    +                if (input != null) {
    +                    session.transfer(input, REL_ORIGINAL);
    --- End diff --
    
    If you set Query Location to Query Parameter, but there are input flow 
files, then the "original" relationship might be a bit confusing. If I schedule 
GetMongo to run once a second, and upstream it is generating flow files once 
every 2 seconds, then if using Query Parameter, the first GetMongo will not 
output along the "original" relationship, but the second one will, causing 
twice as many success FlowFiles as originals. This is in line with the 
documented behavior, but it seems a bit awkward to me, what do you think?
    
    An alternative is to not run if there is an incoming connection but no flow 
file, basically the processor behaves in an event-driven fashion if there is an 
incoming connection, or a timer-driven fashion if there is no incoming 
(non-loop) connection. ExecuteSQL has this code at the beginning of onTrigger():
    ```
    FlowFile fileToProcess = null;
    if (context.hasIncomingConnection()) {
         fileToProcess = session.get();
         // If we have no FlowFile, and all incoming connections are self-loops 
then we can continue on.
         // However, if we have no FlowFile and we have connections coming from 
other Processors, then
         // we know that we should run only if we have a FlowFile.
         if (fileToProcess == null && context.hasNonLoopConnection()) {
              return;
         }
     }
    ```
    You could do other runtime checking (unfortunately, connections are not 
currently known to the `ValidationContext` or `ProcessorInitializationContext` 
so must be done in onTrigger) such as making sure that if there is an incoming 
connection, then the Query Location must be Body, if that's the kind of 
behavior you want. Thoughts?



---

Reply via email to