Indeed this sounds like https://issues.apache.org/jira/browse/NIFI-2032. The PR for it has been out https://github.com/apache/nifi/pull/541 so if you get a chance to try it please let us know. Hopefully it will be merged soon.
Cheers Oleg On Jun 20, 2016, at 4:25 PM, Michael Moser <[email protected]<mailto:[email protected]>> wrote: Michael, You may be encountering the bug NIFI-2032 [1] which exists in NiFi 0.6.1. [1] - https://issues.apache.org/jira/browse/NIFI-2032 -- Mike On Mon, Jun 20, 2016 at 12:20 PM, Michael D. Coon <[email protected]<mailto:[email protected]> wrote: All, Before I get too deep in submitting Jira tickets, etc. I'm wondering if this is expected behavior. I'm using NiFi 0.6.1. I have a ControllerService that I reference as a service property on my Processor. The Processor, in turn, uses the ControllerService's internal configuration state to determine Processor output relationships. But, it appears that at NiFi startup, I'm given the ControllerService before it is actually enabled. When I try to invoke the methods to get the ControllerService's state, it fails (because it's not enabled). Two problems I found: 1) Logging the invocation exception for calling a disabled ControllerService is being suppressed in this case, which caused this to take me a full day to track down2) Why would I ever be given a service to use without it being fully enabled? I thought I would just block in my Processor's onPropertyModified method until the ControllerService was enabled; but it looks like the thread that's actually enabling the service is calling my Processor's onPropertyModified method and the ControllerService is never enabled until my Processor's onPropertyModified method is done. Is this expected behavior? If so, can someone please explain the assumptions around sending non-enabled ControllerServices to my Processor? Mike
