anchor.diff:  and then run the `@OnUnscheduled` and finally `@OnStopped` methods.
   
   If it is desirable to run several iterations of the `onTrigger` method before the other `@OnUnscheduled` and
  -`@OnStopped` life-cycle events are triggered, the `run(int)` method can be used to specify now many iterations
  +`@OnStopped` life-cycle events are triggered, the `run(int)` method can be used to specify how many iterations
   of `onTrigger` should be called.
   
   There are times when we want to trigger the Processor to run but not trigger the `@OnUnscheduled` and `@OnStopped`
  
positive.code: 
  When creating a Processor, the developer is able to provide hints to the framework about how to utilize the Processor most
  effectively. This is done by applying annotations to the Processor's class. The annotations that can be applied to a
  Processor exist in three sub-packages of `org.apache.nifi.annotations`. Those in the `documentation` sub-package are used
  to provide documentation to the user. Those in the `lifecycle` sub-package instruct the framework which methods should
  be called on the Processor in order to respond to the appropriate life-cycle events. Those in the `behavior` package
  help the framework understand how to interact with the Processor in terms of scheduling and general behavior.
  
  The following annotations from the `org.apache.nifi.annotations.behavior` package can be used to modify how the framework
  will handle your Processor:
  
  	- `EventDriven`: Instructs the framework that the Processor can be scheduled using the Event-Driven scheduling
  		strategy. This strategy is still experimental at this point, but can result in reduced resource utilization
  		on dataflows that do not handle extremely high data rates.
  
  	- `SideEffectFree`: Indicates that the Processor does not have any side effects external to NiFi. As a result, the
  		framework is free to invoke the Processor many times with the same input without causing any unexpected
  		results to occur. This implies idempotent behavior. This can be used by the framework to improve efficiency by
  		performing actions such as transferring a ProcessSession from one Processor to another, such that if
  		a problem occurs many Processors' actions can be rolled back and performed again.
  
  	- `SupportsBatching`: This annotation indicates that it is okay for the framework to batch together multiple
  		ProcessSession commits into a single commit. If this annotation is present, the user will be able to choose
  		whether they prefer high throughput or lower latency in the Processor's Scheduling tab. This annotation should
  		be applied to most Processors, but it comes with a caveat: if the Processor calls `ProcessSession.commit`,
  		there is no guarantee that the data has been safely stored in NiFi's Content, FlowFile, and Provenance Repositories.
  		As a result, it is not appropriate for those Processors that receive data from an external source, commit the session,
  		and then delete the remote data or confirm a transaction with a remote resource.
  
  	- `TriggerSerially`: When this annotation is present, the framework will not allow the user to schedule more than one
  		concurrent thread to execute the `onTrigger` method at a time. Instead, the number of thread ("Concurrent Tasks")
  		will always be set to `1`. This does *not*, however, mean that the Processor does not have to be thread-safe,
  		as the thread that is executing `onTrigger` may change between invocations.
  
      - `PrimaryNodeOnly`: Apache NiFi, when clustered, offers two modes of execution for Processors: "Primary Node" and
          "All Nodes". Although running in all the nodes offers better parallelism, some Processors are known to cause unintended
  
negative.code: 
  [[relationship]]
  ==== Relationship
  Relationships define the routes to which a FlowFile may be transferred
  from a Processor. Relationships
  are created by instantiating an instance of the `Relationship.Builder`
  class, calling the appropriate methods
  