Andrew, I agree with Mark that these things would be better captured as Processor properties than as a ControllerService. I'll also try and elaborate on his comment "the tradeoff is more art than science" with my own thinking on the subject.
Generally I think ControllerServices are useful when you want to put "stuff" in one place. For the ControllerServices contained in Apache Nifi, this "stuff" usually takes one of three forms. 1) You have several properties that all go together and get used in tons of places. SSLContextService is a great example of this. There are 6 properties that are required to configure an SSL Context. Rather than make every processor that wants to use SSL define these 6 properties, you put it in a controller service, configure it there(once), and let the processors refer to the service/SSLContext via one configuration parameter. This makes both Processor developers and NiFi users life simpler. 2) You have a large dataset you want to load into memory that would be used in several places. Lets say you are writing some kind of enrichment processor, where you have a huge table of key/value pairs. Putting these key/value pairs in one controller service lets them be loaded once and used by many processors. 3) You have state you want to share across multiple processors. Examples of this are the DistributedMapCache, and the HttpContextMap . DistributedMapCache lets you put arbitrary key/value pairs in one processor and reference them in another. HttpContextMap lets you store an HTTPContextRequest and Response in one part of the flow(when you are reading the request), and get them later on(when you are populating the response). Hope this clarifies when to use a ControllerService. Dan Bress Software Engineer ONYX Consulting Services ________________________________________ From: Mark Payne <[email protected]> Sent: Friday, June 5, 2015 3:10 PM To: [email protected] Subject: RE: Controller Service vs Processor Properties Andrew, That tradeoff is more art than science. Personally, I would go with adding them as optional properties. Thanks -Mark ---------------------------------------- > Date: Fri, 5 Jun 2015 14:52:56 -0400 > From: [email protected] > To: [email protected] > Subject: Re: Controller Service vs Processor Properties > > I also just noticed this ticket that is related: > > https://issues.apache.org/jira/browse/NIFI-332 > > If the service is the way to go I can adapt that processor as well. > > On 06/05/2015 02:23 PM, Andrew Hulbert wrote: >> Hi, >> >> I was attempted to add web proxy support to the GetHttp and PostHttp >> processors. Do you think its best to add a ControllerService similar >> to the SSLContextService or just make two properties on each processor >> named "proxyHost" and "proxyPort" >> >> Here's the controller service version I was thinking about but it >> seems like overkill...not sure what the bar was for services. >> >> https://github.com/jahhulbert-ccri/incubator-nifi/tree/http_proxy >> >> It's also going to be super-fun to test proxy support. >> >> Thanks, >> >> Andrew >
