I am reviewing PR 541 [1] for that bug right now. 

[1] https://github.com/apache/nifi/pull/541

Andy LoPresto
alopresto@apache.org
alopresto.apache@gmail.com
PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69

On Jun 20, 2016, at 1:25 PM, Michael Moser <moser.mw@gmail.com> 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 <mdcoon1@yahoo.com.invalid
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