Support Questions

Find answers, ask questions, and share your expertise
Announcements
Welcome to the upgraded Community! Read this blog to see What’s New!

In a Nifi-workflow some of the processors are not showing start button ?

avatar
Explorer

We have processors in process group but some of them are not showing up the start button.

Here I have attached the screen shot.....

Could someone help on this ?

nifi-error.png

1 ACCEPTED SOLUTION

avatar
Super Guru

When you see the number in the upper-right hand corner, that refers to the fact that even though the processor is "stopped", there are still threads running. You won't be able to edit the configuration or restart it until those threads have stopped (the number and icon will disappear).

View solution in original post

13 REPLIES 13

avatar
Super Guru

When you see the number in the upper-right hand corner, that refers to the fact that even though the processor is "stopped", there are still threads running. You won't be able to edit the configuration or restart it until those threads have stopped (the number and icon will disappear).

avatar
Explorer

Thanks for quick response @Matt Burgess Its not disappearing since long time.

Is there anyway I could kill the threads forcefully and if not Could you let me know what will be the solution to overcome this ?

Thanks

Jasti.

avatar
Super Guru

In NiFi 1.7.0 I believe you can right-click on the processor and choose "Terminate threads". If for some reason that doesn't work I think you have to restart the NiFi instance.

avatar
Mentor

@Veerendra Nath Jasthi

If the ConsumeKafka processor is hanging (showing active threads but not generating any FlowFiles) every time you use it, there is some issue going on in the connection. Getting a NiFi thread dump and inspecting that thread dump for consumekafka should lead you to a thread that is waiting on something.

-

It may be waiting on some authentication issue with the keytab/principal...
It may be hung with "promptForName" keyboard interactive auth which NiFi can't do...

-

The above us typically an issue seen when the ticket expires and has not be renewed.

-

Thanks,

Matt

avatar
Mentor

@Veerendra Nath Jasthi

Most likely your GetFile processor is trying to perform a listing for a very large number of source files? If that is the case, this listing may take a considerable amount of time before FlowFiles even begin to be generated.

-

Stopping a processor only tells the controller to no longer schedule that processor to run. Any currently executing threads will continue to run till completion.

avatar
Expert Contributor

@veerendra

If you are using nifi below 1.7, the best way is to restart nifi

avatar
Explorer

Yeah as you guys said I did restart the instance it worked but If I stop the processor and start again then same issue.

Should I restart nifi Instance every time whenever processor stops and starts since we are dev phase we have to stop and start the processor ?

avatar
Expert Contributor
@Veerendra Nath Jasthi

It should not be the case, what processors you are using and getting the issue?

avatar
Explorer

I am using GetFile processor..

avatar
Expert Contributor

@Veerendra Nath JasthiPossibly, you have a complicated computation (may be regex) running on Getfile, which is taking a lot of time to

complete, also check howmany files it is getting based on your regex, it should be fixed.

avatar
Explorer

No I have been using the plain getFile which is having input as a simple folder and we are not doing any regex on those files.

FYI.... In my entire workflow all processors are behaving the same.

avatar
Expert Contributor
@Veerendra Nath Jasthi

What is the frequency of files and how big are the files in the given path? Also could you please check your JVM heap memory (this is a guess, not solution)?

avatar
Explorer

I've seen the problem you describe with getfile processor when I used it with nifi deployed on Windows OS and the directory I listed had very large number of recursive subdirectories. In source files of nifi 1.3 or 1.4 I noticed there was a code replacing listfiles with DirectoryInputStream methods, but later it was removed

Labels