Cause for sleeping threads in Nifi flows

[#1]

Hello,

My custom java processor becomes unresponsive after being idle for a while resulting in or causing subsequent flows to fail. I used the ./nifi.sh dump thread-dump.txt to capture the problem and I've attached the resulting file. thread-dump.txt It appears that the dump shows predominately TIMED_WAITING on java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject, but I'm not sure how to interpret this issue.

This is a continuation of the question asked earlier (https://community.hortonworks.com/questions/79331/debugging-custom-nifi-unresponsive-flows.html#answer-79337), but since I answered as satisfied I'm not sure that it will be monitored.

Thanks,

~Sean

[#2]

Can you provide some more information like what is your flow doing (screenshot/template)? what is your custom processor doing? how do you know it is unresponsive? what version of NiFi are you using? Thanks.

[#3]

I realize my question is too vague to assist based on what I've provided. I'm not sure the "thread-dump.txt" is even capturing anything related to the problem. I know the processor is entering the exception part of the custom code, but I cannot get the inherent getLogger() to produce the error logs. (I've tried a standard System.out.println as well, but I'm not sure where the console output would be written to) I've seen examples where the logger is instantiated via "final ComponentLog logger = getLogger()" and other examples that suggest the getLogger() is inherented from the "AbstractProcessor" thus no instantiation is required. What is further confusing that if I try the above I see an no such method errors on the 'org.apache.nifi.logger.ProcessorLog' which I thought was deprecated.

Our NiFi is running on HDF Version 2.0.1. Thanks of any assistance you can provide.

[#4]

The issue was with the customized bundle utilizing a NiFi 0.5 api where the NiFi running the processor was at 1.0.0.