Rebel flowfile and python scripts.
Hello all,
there is a strange behavior on our NIFI installation.
I wrote a script in python and for some reason and sometimes the flowfile does
not always moves into it, like in this case:
[cid:bc2b4b7b-c4dc-4a6a-bffb-e78f432a897b]
I see that Queued Duration for the above flowfile is 07:53:04.557! What is it
waiting for ?
The executeScript processor is running on each node with concurrent Task set to
1.
In attachment there is the flowfile source code.
Any help is appreciated.
Thanks in advance.
AP
from urlparse import parse_qs, urlparse
def parse ( uri2parse ) :
o = urlparse( uri2parse )
d = parse_qs( o.query )
return ( o.path[1:], d['year'][0], d['month'][0], d['day'][0] )
# get the flow file from the incoming queue
flowfile = session.get()
if flowfile is not None:
source_URI = flowfile.getAttribute( 'source_URI' )
destination_URI = flowfile.getAttribute( 'destination_URI' )
current_time = flowfile.getAttribute( 'current_time' )
# expand the URI into smaller pieces
src_table, src_year, src_month, src_day = parse( source_URI )
dst_table, dst_year, dst_month, dst_day = parse( destination_URI )
flowfile = session.putAllAttributes( flowfile, { 'src_table' : src_table, 'src_year': src_year, 'src_month' :src_month, 'src_day': src_day })
flowfile = session.putAllAttributes( flowfile, { 'dst_table' : dst_table, 'dst_year': dst_year, 'dst_month' :dst_month, 'dst_day': dst_day })
session.transfer( flowfile, REL_SUCCESS )
else:
flowfile = session.create()
session.transer( flowfile, REL_FAILURE )
Sentry & NIFI
Hello all, is there a simple way to connect nifi to sentry using the log appender facility?
Re: Cluster instability due to java.net.SocketTimeoutException: Read timed out
Hello again,
this is the stack trace which is raised on the connection timeout.
2017-02-13 08:02:01,796 WARN [Replicate Request Thread-3]
o.a.n.c.c.h.r.ThreadPoolRequestReplicator Failed to replicate request GET
/nifi-api/flow/status to mid1-a128-3.buongiorn
o.com:8080 due to {}
com.sun.jersey.api.client.ClientHandlerException:
java.net.SocketTimeoutException: Read timed out
at
com.sun.jersey.client.urlconnection.URLConnectionClientHandler.handle(URLConnectionClientHandler.java:155)
~[jersey-client-1.19.jar:1.19]
at com.sun.jersey.api.client.Client.handle(Client.java:652)
~[jersey-client-1.19.jar:1.19]
at
com.sun.jersey.api.client.filter.GZIPContentEncodingFilter.handle(GZIPContentEncodingFilter.java:123)
~[jersey-client-1.19.jar:1.19]
at com.sun.jersey.api.client.WebResource.handle(WebResource.java:682)
~[jersey-client-1.19.jar:1.19]
at
com.sun.jersey.api.client.WebResource.access$200(WebResource.java:74)
~[jersey-client-1.19.jar:1.19]
at
com.sun.jersey.api.client.WebResource$Builder.get(WebResource.java:509)
~[jersey-client-1.19.jar:1.19]
at
org.apache.nifi.cluster.coordination.http.replication.ThreadPoolRequestReplicator.replicateRequest(ThreadPoolRequestReplicator.java:578)
~[nifi-framework-cluster-1.1.1.jar:1.1.1]
at
org.apache.nifi.cluster.coordination.http.replication.ThreadPoolRequestReplicator$NodeHttpRequest.run(ThreadPoolRequestReplicator.java:770)
~[nifi-framework-cluster-1.1.1.jar:1.1.1]
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
[na:1.8.0_101]
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
[na:1.8.0_101]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
[na:1.8.0_101]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
[na:1.8.0_101]
at java.lang.Thread.run(Thread.java:745) [na:1.8.0_101]
Caused by: java.net.SocketTimeoutException: Read timed out
at java.net.SocketInputStream.socketRead0(Native Method) ~[na:1.8.0_101]
at java.net.SocketInputStream.socketRead(SocketInputStream.java:116)
~[na:1.8.0_101]
at java.net.SocketInputStream.read(SocketInputStream.java:170)
~[na:1.8.0_101]
at java.net.SocketInputStream.read(SocketInputStream.java:141)
~[na:1.8.0_101]
at sun.security.ssl.InputRecord.readFully(InputRecord.java:465)
~[na:1.8.0_101]
at sun.security.ssl.InputRecord.read(InputRecord.java:503)
~[na:1.8.0_101]
at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:973)
~[na:1.8.0_101]
at
sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1375)
~[na:1.8.0_101]
at
sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1403)
~[na:1.8.0_101]
at
sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1387)
~[na:1.8.0_101]
at
sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:559)
~[na:1.8.0_101]
at
sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185)
~[na:1.8.0_101]
at
sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1513)
~[na:1.8.0_101]
at
sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1441)
~[na:1.8.0_101]
at
java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:480)
~[na:1.8.0_101]
at
sun.net.www.protocol.https.HttpsURLConnectionImpl.getResponseCode(HttpsURLConnectionImpl.java:338)
~[na:1.8.0_101]
at
com.sun.jersey.client.urlconnection.URLConnectionClientHandler._invoke(URLConnectionClientHandler.java:253)
~[jersey-client-1.19.jar:1.19]
at
com.sun.jersey.client.urlconnection.URLConnectionClientHandler.handle(URLConnectionClientHandler.java:153)
~[jersey-client-1.19.jar:1.19]
... 12 common frames omitted
perhaps it is useful to understand the problem.
From: Alessio Palma <alessio.pa...@docomodigital.com>
Sent: Monday, February 13, 2017 9:31:15 AM
To: NIFI User mailing
Subject: Cluster instability due to java.net.SocketTimeoutException: Read timed
out
Hello all,
sometime the cluster is unstable due to "read time out".
Is here any parameter which I can fine tuning in order to reduce this problem ?
Most timeouts (66%) are coming from
com.sun.jersey.api.client.ClientHandlerException
few (33%) from
o.apache.nifi.controller.FlowController
Thanks in adavance
AP
Cluster instability due to java.net.SocketTimeoutException: Read timed out
Hello all, sometime the cluster is unstable due to "read time out". Is here any parameter which I can fine tuning in order to reduce this problem ? Most timeouts (66%) are coming from com.sun.jersey.api.client.ClientHandlerException few (33%) from o.apache.nifi.controller.FlowController Thanks in adavance AP
Re: ListHDFS ( some suggestions depending on our usage )
Hello Pierre, card has been opened, maybe I'll will send you the patch so it can be added in the next release. I'm working on it in local. From: Pierre Villard <pierre.villard...@gmail.com> Sent: Friday, February 10, 2017 10:21:28 AM To: users@nifi.apache.org Subject: Re: ListHDFS ( some suggestions depending on our usage ) Hi Alessio, It sounds like a valid improvement on the existing processor. Please feel free to file a JIRA. Since the directory path is already allowing expression language it wouldn't be a huge change. - Pierre 2017-02-10 9:58 GMT+01:00 Alessio Palma <alessio.pa...@docomodigital.com<mailto:alessio.pa...@docomodigital.com>>: Hello all, I'm using ListHDFS but... 1) it can start only on a schedule strategy 2) directory path to list is "hard coded" into the processor it self. I wonder if a new version, which can be started using a flowfile, accept the attributes of the incoming flow file as parameters, it is more usable and useful than the current implementation. If you are thinking to GetHDFSEvent: In real world application HDFS super user is not always an option and checking HDFS file ( ListHDFS ) is something which must be subordinated to something. What do you think ? Is a good idea to add this to default nifi processors ?
ListHDFS ( some suggestions depending on our usage )
Hello all, I'm using ListHDFS but... 1) it can start only on a schedule strategy 2) directory path to list is "hard coded" into the processor it self. I wonder if a new version, which can be started using a flowfile, accept the attributes of the incoming flow file as parameters, it is more usable and useful than the current implementation. If you are thinking to GetHDFSEvent: In real world application HDFS super user is not always an option and checking HDFS file ( ListHDFS ) is something which must be subordinated to something. What do you think ? Is a good idea to add this to default nifi processors ?
How to print flow
Hello all, does anybody found a way to print workflow? I.E: tool to convert the flow into another format which is readable by other software with printing support.
Re: keytab file does not exists but actually it does
Hi Pierre, yes my kerberos configuration on the host is fine, I can use kinit to get a ticket and ktutil to create keytabs with no issue. From: Pierre Villard <pierre.villard...@gmail.com> Sent: Thursday, January 19, 2017 12:25:24 PM To: users@nifi.apache.org Subject: Re: keytab file does not exists but actually it does Hello Alessio, Is you krb5.conf correct and correctly referenced in your nifi.properties file? Pierre 2017-01-19 12:20 GMT+01:00 Alessio Palma <alessio.pa...@docomodigital.com<mailto:alessio.pa...@docomodigital.com>>: Hello all, I'm getting a strange error from a controller service ( hive connection pool ), this error says that: Kerberos Keytab validated against 'myfile...' is invalida because File 'myfile...' does not exists. But the keytab file exists and has the correct permission. What is going wrong? How can I debug this issue ?
Re: keytab file does not exists but actually it does
I dropped and create again the same processor and for some unknown reason it worked. Very strange. From: Alessio Palma <alessio.pa...@docomodigital.com> Sent: Thursday, January 19, 2017 12:33:54 PM To: users@nifi.apache.org Subject: Re: keytab file does not exists but actually it does Hi Pierre, yes my kerberos configuration on the host is fine, I can use kinit to get a ticket and ktutil to create keytabs with no issue. From: Pierre Villard <pierre.villard...@gmail.com> Sent: Thursday, January 19, 2017 12:25:24 PM To: users@nifi.apache.org Subject: Re: keytab file does not exists but actually it does Hello Alessio, Is you krb5.conf correct and correctly referenced in your nifi.properties file? Pierre 2017-01-19 12:20 GMT+01:00 Alessio Palma <alessio.pa...@docomodigital.com<mailto:alessio.pa...@docomodigital.com>>: Hello all, I'm getting a strange error from a controller service ( hive connection pool ), this error says that: Kerberos Keytab validated against 'myfile...' is invalida because File 'myfile...' does not exists. But the keytab file exists and has the correct permission. What is going wrong? How can I debug this issue ?
Host disconnected due to different workflow configuration
Hello all, I experienced "host out of the cluster which was no longer able to join", log reports configuration workflow has been changed and it's different from the one running into the cluster. Due to this issue there is not way to join again the cluster. To resolve this I stopped the whole cluster and copied the same configuration to every host. After the restart anything worked well. Is here a good way to prevent flow changes when all the host into the cluster are not connected ?
Re: How do you recover a workflow ?
The point is that I have a workflow but sometimes things go wrong and I need to manually restart it; this action requires: 1) Change some parameters ( UpdateAttribute processor ) 2) Fire a new flowfile which will start again the workflow. Perhaps this is the most obscure point. We are using nifi to execute some old cron jobs and I'm using the GenerateFlowFile ( crontab scheduling strategy ) processor to start the flow. When the workflow did not complete I use another GenerateFlowFile processor to fire a new flowfile which allows me to execute again the flow out of the schedule. All these points can be executed faster if I can insert the value into some kind of form into the screen and can fire a new flowfile clicking some button instead to start/stop ad additional GenerateFlowFile processor. Perhaps I'm doing it in the wrong way. So how do you restart a workflow ? Maybe this feature can help others in the same task. Don't know... I'm just asking. From: Jeff <jtsw...@gmail.com> Sent: Friday, November 11, 2016 2:36:02 AM To: users@nifi.apache.org Subject: Re: How do you recover a workflow ? Hello Alessio, Could you provide some more details about your NiFi flow? One of the triggers I used to manually be able to start processing in my flow was to have a GetFile processor (configured with "Keep Source File" set to false) watching for files in a directory, and when I wanted to test the flow, I would just run the touch command to create a file that the GetFile processor would detect and emit a flowfile for it. Depending on your use case, there might be a better source processor for flowfiles that you can use in your flow. On Thu, Nov 10, 2016 at 6:55 AM Alessio Palma <alessio.pa...@docomodigital.com<mailto:alessio.pa...@docomodigital.com>> wrote: Hello all, what is the best pratice to recover a workflow gone bad ? Currently I use a generateFlowFile processor attached to some entry point, which allows me to restart something. Start then stop and a flowfile is created, but this is not the best option. I really miss the option to put a flowfile using a mouse click. Also some way to display a basic interface where to insert/modify some values used into some updateAttribute process helps a lot. What do you think ? AP
How do you recover a workflow ?
Hello all, what is the best pratice to recover a workflow gone bad ? Currently I use a generateFlowFile processor attached to some entry point, which allows me to restart something. Start then stop and a flowfile is created, but this is not the best option. I really miss the option to put a flowfile using a mouse click. Also some way to display a basic interface where to insert/modify some values used into some updateAttribute process helps a lot. What do you think ? AP
Re: Host disconnected due to different workflow configuration
OK, understood it. It's still a bit fragile. Is there a way to force the adoption of a configuration from a node using the mouse without to stop and start the server ? From: Bryan Bende <bbe...@gmail.com> Sent: Thursday, November 10, 2016 3:19:16 PM To: users@nifi.apache.org Subject: Re: Host disconnected due to different workflow configuration Hello, In general NiFi does its best to prevent changes being made to the flow when one of the cluster nodes is down. For example, if you have a 3 node cluster and only 2 nodes are up, you can't change the flow. When a request comes in to change the flow, lets say you drag a new processor on the graph, this is sent to one of the nodes which then does a two phase-commit with the rest of the nodes in the cluster. The error message you got means that all the nodes responded successfully to the first phase, and on the second phase of the commit, one of the nodes encountered an error. At this point the change was applied to the other nodes, and the node with the error was purposely disconnected from the cluster because it is in an inconsistent state. If possible, can you see what other errors happened in the log of that node before seeing "host out of cluster..."? because the real problem is there was some other issue on that node that caused it to fail. -Bryan On Wed, Nov 9, 2016 at 5:45 AM, Alessio Palma <alessio.pa...@docomodigital.com<mailto:alessio.pa...@docomodigital.com>> wrote: Hello all, I experienced "host out of the cluster which was no longer able to join", log reports configuration workflow has been changed and it's different from the one running into the cluster. Due to this issue there is not way to join again the cluster. To resolve this I stopped the whole cluster and copied the same configuration to every host. After the restart anything worked well. Is here a good way to prevent flow changes when all the host into the cluster are not connected ?
cannot add working users to nifi
Hello I did setup a 3 hosts nifi cluster, I followed the docs ( administration guide ) and now each user I add has no access. Can login but cannot do anything but see the users on the system. Is there an alternative setup procedure I can follow? User I added has been granted with same groups and permission of the initial admin user, but not way to have it working... Can someone help me ?
how to loop workflows
Hello all, is there any way to loop workflow by list or counters? Oozie allows to break the rules of acyclic graphs with some tricks, is the same in NIFI ?
Flow file from a (long) string
Hello, is there a processor which allows to build a flowfile from a string? Basically I have some huge queries and want to add them into the workflow without load them from file or database. AP
Re: start it ONCE
I see on https://issues.apache.org/jira/browse/NIFI-401: priority : Minor Type: Improvement Are we sure about this ? I think this is a priority bug. Is it just me who is facing the problem to start ONE flowfile into the cluster? On 24/10/2016 15:01, Joe Witt wrote: > Alessio, > > We don't presently support cron scheduling for the primary node only > processors. This does come up fairly often and a nice PR/contrib came > in a while ago from the community > https://issues.apache.org/jira/browse/NIFI-401. It is now getting > some good traction so hopefully it will be in an upcoming release. > > Thanks > Joe > > On Mon, Oct 24, 2016 at 6:13 AM, Alessio Palma > <alessio.pa...@buongiorno.com> wrote: >> Hello All, here is a question which is driving me crazy... >> I'm using the PutHiveQL processor to create some tables and view into >> HIVE. This processor need the SQL to execute into a flowfile. >> >> I'm using a GenerateFlowFile to build an empty flowfile which is later >> filled using the ReplaceText processor. >> >> It Works but the cluster has 3 host and I'm getting the same query 3 times. >> >> If I use the "On primany node" scheduling stretegy into the >> GenerateFlowFile, anything works but I'm no longer able to use the CRON >> scheduling option. >> >> So.. There is a way to produce a SINGLE FlowFile into a cluster using a >> "cron scheduling" option ? >> > . >
start it ONCE
Hello All, here is a question which is driving me crazy... I'm using the PutHiveQL processor to create some tables and view into HIVE. This processor need the SQL to execute into a flowfile. I'm using a GenerateFlowFile to build an empty flowfile which is later filled using the ReplaceText processor. It Works but the cluster has 3 host and I'm getting the same query 3 times. If I use the "On primany node" scheduling stretegy into the GenerateFlowFile, anything works but I'm no longer able to use the CRON scheduling option. So.. There is a way to produce a SINGLE FlowFile into a cluster using a "cron scheduling" option ?
Resource directory paths are malformed: docs
Hello all, I rebuild nifi from scratch and after the deploy Jetty won't restartslogs returns this error: at java.lang.reflect.Constructor.newInstance(Constructor.java:423) ~[na:1.8.0_92] at org.apache.nifi.NiFi.(NiFi.java:146) ~[nifi-runtime-1.0.0-SNAPSHOT.jar:1.0.0-SNAPSHOT] at org.apache.nifi.NiFi.main(NiFi.java:243) ~[nifi-runtime-1.0.0-SNAPSHOT.jar:1.0.0-SNAPSHOT] Caused by: java.lang.IllegalStateException: Resource directory paths are malformed: docs at org.apache.nifi.web.server.JettyServer.createDocsWebApp(JettyServer.java:540) ~[nifi-jetty-1.0.0-SNAPSHOT.jar:1.0.0-SNAPSHOT] at org.apache.nifi.web.server.JettyServer.loadWars(JettyServer.java:321) ~[nifi-jetty-1.0.0-SNAPSHOT.jar:1.0.0-SNAPSHOT] at org.apache.nifi.web.server.JettyServer.(JettyServer.java:144) ~[nifi-jetty-1.0.0-SNAPSHOT.jar:1.0.0-SNAPSHOT] any idea where to look / how to fix this ?
Re: Resource directory paths are malformed: docs
Thanks for you time, It has been resolved. Due to a pom.xml misconfiguration the docs folder was not present. bin conf docs <--- this was missing. lib logs release.version storage -> /opt/storage wwwdocs I fixed the pom.xml and anything worked fine. Mumble... I my opinion "Folder not found" works better than "Resource directory paths are malformed" From: Pierre Villard <pierre.villard...@gmail.com> Sent: Thursday, November 17, 2016 6:30:15 PM To: users@nifi.apache.org Subject: Re: Resource directory paths are malformed: docs Hi Alessio, Could you copy/paste the full stack trace? Thanks! Pierre 2016-11-17 17:03 GMT+01:00 Alessio Palma <alessio.pa...@docomodigital.com<mailto:alessio.pa...@docomodigital.com>>: Hello all, I rebuild nifi from scratch and after the deploy Jetty won't restartslogs returns this error: at java.lang.reflect.Constructor.newInstance(Constructor.java:423) ~[na:1.8.0_92] at org.apache.nifi.NiFi.(NiFi.java:146) ~[nifi-runtime-1.0.0-SNAPSHOT.jar:1.0.0-SNAPSHOT] at org.apache.nifi.NiFi.main(NiFi.java:243) ~[nifi-runtime-1.0.0-SNAPSHOT.jar:1.0.0-SNAPSHOT] Caused by: java.lang.IllegalStateException: Resource directory paths are malformed: docs at org.apache.nifi.web.server.JettyServer.createDocsWebApp(JettyServer.java:540) ~[nifi-jetty-1.0.0-SNAPSHOT.jar:1.0.0-SNAPSHOT] at org.apache.nifi.web.server.JettyServer.loadWars(JettyServer.java:321) ~[nifi-jetty-1.0.0-SNAPSHOT.jar:1.0.0-SNAPSHOT] at org.apache.nifi.web.server.JettyServer.(JettyServer.java:144) ~[nifi-jetty-1.0.0-SNAPSHOT.jar:1.0.0-SNAPSHOT] any idea where to look / how to fix this ?
How I put the cluster down.
Hello all, yesterday, for a mistake, basically I executed " ls -R / " using the ListHDFS processor and the whole cluster gone down ( not just a node ). Something like this also happened when I was playing with some DO WHILE / WHILE DO patterns. I have only the nifi logs and they show the heartbeat has been lost. About the CPU LOAD, NETWORK TRAFFIC I have no info. Any pointers about where do I have look for the problem's root ? Today I'm trying to repeat the problems I got with DO/WHILE, nothing bad is happening although CPU LOAD is enough high and NETWORK TRAFFIC increased up to 282 Kb/sec. Of course I can redo the "ls -R /" on production, however I like to avoid it since there are already some ingestion flows running. AP
Re: How I put the cluster down.
Hello Witt, before anything else thanks for your help. Fortunatly I put down only the NIFI cluster, otherwise I was already in vacation :) After I posted this problem I kept to torture staging NIFI and discovered that when CPU LOAD gets very high, nodes loose connection and anything starts going in the bad directory. Also the WEB GUI becomes not responsive, you have no option to stop workflows. You can reproduce this issue starting some workflows composed by 1) GenerateFlowFile ( 1 Kb size, Timer driven, 0 sec run schedule ) 2) ReplaceText ( just to force the use of regexp ) 3) HashContent, ( auto terminate both relationships ) Currently my staging cluster is composed by 2 virtual host configured as: 2 Core cpu ( Intel(R) Xeon(R) CPU E7- 2870 @ 2.40GHz ) 2 GB RAM 18 GB HD The problem raised when the CPU load goes over 8, this basically means when you start 8 of the above WF. I noticed NIFI attempts to reduce the load but this does not works too much and does not avoid the general failure. Here you can see the errors which started to show under stress: https://drive.google.com/drive/folders/0B7NTMIqrCjESN0JURnRtZWp5Tms?usp=sharing The 1st question is: is here a way to keep the load under some critical values? Is there some "how to" which helps me to configure NIFI ? Currently it is using the factory settings and no customization has been performed but LDAP login. AP On 28/10/2016 13:24, Joe Witt wrote: > Alessio > > You have two clusters here potentially. The NiFi cluster and the > Hadoop cluster. Which one went down? > > If NiFi went down I'd suspect memory exhaustion issues because other > resource exhaustion issues like full file system, exhausted file > handles, pegged CPU, etc.. tend not to cause it to restart. If memory > related you'll probably see something in the nifi-app.log. Try going > with a larger heap as can be controlled in conf/bootstrap.conf. > > Thanks > Joe > > On Fri, Oct 28, 2016 at 5:55 AM, Alessio Palma > <alessio.pa...@buongiorno.com> wrote: >> Hello all, >> yesterday, for a mistake, basically I executed " ls -R / " using the >> ListHDFS processor and the whole cluster gone down ( not just a node ). >> >> Something like this also happened when I was playing with some DO WHILE >> / WHILE DO patterns. I have only the nifi logs and they show the >> heartbeat has been lost. About the CPU LOAD, NETWORK TRAFFIC I have no >> info. Any pointers about where do I have look for the problem's root ? >> >> Today I'm trying to repeat the problems I got with DO/WHILE, nothing bad >> is happening although CPU LOAD is enough high and NETWORK TRAFFIC >> increased up to 282 Kb/sec. >> >> Of course I can redo the "ls -R /" on production, however I like to >> avoid it since there are already some ingestion flows running. >> >> AP > . >
Re: nifi 1.1.1 : Unable to empty queues
Yes, instance is clustered and secured ( https ) and it was running nifi 1.0.0. Before nifi 1.1.1 anything was working correctly. I authorized all the nodes with no success. Perhaps I'm doing it in the wrong way... I just added to nodes all the policies. But it still does not work. I checked also the nifi.properties file. Currently I'm not able to empty queue. From: Matt Gilman <matt.c.gil...@gmail.com> Sent: Tuesday, January 10, 2017 3:43:46 PM To: users@nifi.apache.org Subject: Re: nifi 1.1.1 : Unable to empty queues If your instance is clustered, you'll need to authorize the nodes with the data policies as well. Any 'data-plane' endpoint (where data or meta-data is returned or modified) will require the nodes in the request chain to also be approved for access as the data will traverse some of them when the request is replicated. 'Control-plane' endpoints (where data flow configuration is retrieved/modified) are not subject to the additional check. FYI, there was a recent improvement committed the master branch that provides some level of details regarding the insufficient privileges. This should make it into the next release (1.2.0). Matt On Tue, Jan 10, 2017 at 9:36 AM, Alessio Palma <alessio.pa...@docomodigital.com<mailto:alessio.pa...@docomodigital.com>> wrote: Hello all, I'm checking nifi 1.1.1 before moving it to production and something weird is happening when I try to empty a queue. System replies telling I'm unable to perform the desired action due to insufficient permissions. My user has any available rule. What can I check ? Any suggestions? Thanks in advance for your time.
Re: nifi 1.1.1 : Unable to empty queues
Hello Gilman, I found a way to have it working. I give view data and modify data policies to my user too. Nifi 1.0.0 was working without this setting and using nifi-1.1.1 need it. What are the differences between 1.0.0 and 1.1.1 about this point ? From: Matt Gilman <matt.c.gil...@gmail.com> Sent: Tuesday, January 10, 2017 3:43:46 PM To: users@nifi.apache.org Subject: Re: nifi 1.1.1 : Unable to empty queues If your instance is clustered, you'll need to authorize the nodes with the data policies as well. Any 'data-plane' endpoint (where data or meta-data is returned or modified) will require the nodes in the request chain to also be approved for access as the data will traverse some of them when the request is replicated. 'Control-plane' endpoints (where data flow configuration is retrieved/modified) are not subject to the additional check. FYI, there was a recent improvement committed the master branch that provides some level of details regarding the insufficient privileges. This should make it into the next release (1.2.0). Matt On Tue, Jan 10, 2017 at 9:36 AM, Alessio Palma <alessio.pa...@docomodigital.com<mailto:alessio.pa...@docomodigital.com>> wrote: Hello all, I'm checking nifi 1.1.1 before moving it to production and something weird is happening when I try to empty a queue. System replies telling I'm unable to perform the desired action due to insufficient permissions. My user has any available rule. What can I check ? Any suggestions? Thanks in advance for your time.
Re: Cluster is still voting on which Flow is the correct flow for the cluster
Thanks Mark,
U right, authorizations.xml was out of sync.
Now the trick is clear, and when you know the solution everything looks clear,
but is there a way to have a clearer error message into the logs ?
From: Mark Payne <marka...@hotmail.com>
Sent: Thursday, January 12, 2017 3:24:22 PM
To: users@nifi.apache.org
Subject: Re: Cluster is still voting on which Flow is the correct flow for the
cluster
Alessio,
It looks like the flow is the not the same on both nodes. Since you only have
two nodes, NiFi is not able
to come up with a majority of votes. Specifically, it looks like the
conf/authorizations.xml or conf/authorizers.xml or conf/users.xml
file is out-of-sync. You can try copying these from 1 node to the other, or
just deleting them from 1 node and it will inherit
the other node's on startup.
Thanks
-Mark
On Jan 12, 2017, at 8:40 AM, Alessio Palma
<alessio.pa...@docomodigital.com<mailto:alessio.pa...@docomodigital.com>> wrote:
2 host secured custer.
2 zookeeper.
From: Andre <andre-li...@fucs.org<mailto:andre-li...@fucs.org>>
Sent: Thursday, January 12, 2017 2:39:23 PM
To: users@nifi.apache.org<mailto:users@nifi.apache.org>
Subject: Re: Cluster is still voting on which Flow is the correct flow for the
cluster
Alessio,
May I ask you how many zookeeper form your ensemble?
Kind regards
On Fri, Jan 13, 2017 at 12:28 AM, Alessio Palma
<alessio.pa...@docomodigital.com<mailto:alessio.pa...@docomodigital.com>> wrote:
Hello all,
there are 5 minutes of negotiation on the cluster which ends in nothing.
These are the logs after the handshake fails:
host 1
2017-01-12 13:20:36,448 INFO [main] o.a.n.c.c.node.NodeClusterCoordinator
Resetting cluster node statuses from {} to
{mid1-t029nifi-2.buongiorno.com:8080=NodeConnectionStatus[
nodeId=mid1-t029nifi-2.buongiorno.com:8080<http://mid1-t029nifi-2.buongiorno.com:8080/>,
state=DISCONNECTED, Disconnect Code=Not Has Not Yet Connected to Cluster,
Disconnect Reason=Not Has Not Yet Connected to Cluster, u
pdateId=1],
mid1-t029nifi-1.buongiorno.com:8080=NodeConnectionStatus[nodeId=mid1-t029nifi-1.buongiorno.com:8080<http://mid1-t029nifi-1.buongiorno.com:8080/>,
state=CONNECTING, updateId=120]}
2017-01-12 13:20:36,450 ERROR [main] o.a.nifi.controller.StandardFlowService
Failed to load flow from cluster due to:
org.apache.nifi.controller.UninheritableFlowException: Fa
iled to connect node to cluster because local flow is different than cluster
flow.
org.apache.nifi.controller.UninheritableFlowException: Failed to connect node
to cluster because local flow is different than cluster flow.
at
org.apache.nifi.controller.StandardFlowService.loadFromConnectionResponse(StandardFlowService.java:894)
~[nifi-framework-core-1.1.1.jar:1.1.1]
at
org.apache.nifi.controller.StandardFlowService.load(StandardFlowService.java:493)
~[nifi-framework-core-1.1.1.jar:1.1.1]
at org.apache.nifi.web.server.JettyServer.start(JettyServer.java:770)
[nifi-jetty-1.1.1.jar:1.1.1]
at org.apache.nifi.NiFi.(NiFi.java:156)
[nifi-runtime-1.1.1.jar:1.1.1]
at org.apache.nifi.NiFi.main(NiFi.java:262)
[nifi-runtime-1.1.1.jar:1.1.1]
Caused by: org.apache.nifi.controller.UninheritableFlowException: Proposed
Authorizer is not inheritable by the flow controller because of Authorizer
differences: Proposed Aut
horizations do not match current Authorizations
at
org.apache.nifi.controller.StandardFlowSynchronizer.sync(StandardFlowSynchronizer.java:253)
~[nifi-framework-core-1.1.1.jar:1.1.1]
at
org.apache.nifi.controller.FlowController.synchronize(FlowController.java:1461)
~[nifi-framework-core-1.1.1.jar:1.1.1]
at
org.apache.nifi.persistence.StandardXMLFlowConfigurationDAO.load(StandardXMLFlowConfigurationDAO.java:83)
~[nifi-framework-core-1.1.1.jar:1.1.1]
at
org.apache.nifi.controller.StandardFlowService.loadFromBytes(StandardFlowService.java:678)
~[nifi-framework-core-1.1.1.jar:1.1.1]
at
org.apache.nifi.controller.StandardFlowService.loadFromConnectionResponse(StandardFlowService.java:872)
~[nifi-framework-core-1.1.1.jar:1.1.1]
... 4 common frames omitted
Host 2
2017-01-12 13:20:36,900 INFO [main] o.a.n.c.c.node.NodeClusterCoordinator
Resetting cluster node statuses from
{mid1-t029nifi-2.buongiorno.com:8080=NodeConnectionStatus[nodeId=mid1-t029nifi-2.buongiorno.com:8080<http://mid1-t029nifi-2.buongiorno.com:8080/>,
state=CONNECTING, updateId=122],
mid1-t029nifi-1.buongiorno.com:8080=NodeConnectionStatus[nodeId=mid1-t029nifi-1.buongiorno.com:8080<http://mid1-t029nifi-1.buongiorno.com:8080/>,
state=DISCONNECTED, Disconnect Code=Node's Flow did not Match Cluster Flow,
Disconnect Reason=org.apache.nifi.controller.UninheritableFlowException: Failed
to connect node to cluster because local flow is different than cluster flow.,
updateId=1]} t
Re: Cluster is still voting on which Flow is the correct flow for the cluster
Why not.
From: Mark Payne <marka...@hotmail.com>
Sent: Thursday, January 12, 2017 3:59:03 PM
To: users@nifi.apache.org
Subject: Re: Cluster is still voting on which Flow is the correct flow for the
cluster
Alessio,
Certainly, we could clarify the log message. Do you mind filing a JIRA for that?
Thanks
-Mark
On Jan 12, 2017, at 9:34 AM, Alessio Palma
<alessio.pa...@docomodigital.com<mailto:alessio.pa...@docomodigital.com>> wrote:
Thanks Mark,
U right, authorizations.xml was out of sync.
Now the trick is clear, and when you know the solution everything looks clear,
but is there a way to have a clearer error message into the logs ?
From: Mark Payne <marka...@hotmail.com<mailto:marka...@hotmail.com>>
Sent: Thursday, January 12, 2017 3:24:22 PM
To: users@nifi.apache.org<mailto:users@nifi.apache.org>
Subject: Re: Cluster is still voting on which Flow is the correct flow for the
cluster
Alessio,
It looks like the flow is the not the same on both nodes. Since you only have
two nodes, NiFi is not able
to come up with a majority of votes. Specifically, it looks like the
conf/authorizations.xml or conf/authorizers.xml or conf/users.xml
file is out-of-sync. You can try copying these from 1 node to the other, or
just deleting them from 1 node and it will inherit
the other node's on startup.
Thanks
-Mark
On Jan 12, 2017, at 8:40 AM, Alessio Palma
<alessio.pa...@docomodigital.com<mailto:alessio.pa...@docomodigital.com>> wrote:
2 host secured custer.
2 zookeeper.
From: Andre <andre-li...@fucs.org<mailto:andre-li...@fucs.org>>
Sent: Thursday, January 12, 2017 2:39:23 PM
To: users@nifi.apache.org<mailto:users@nifi.apache.org>
Subject: Re: Cluster is still voting on which Flow is the correct flow for the
cluster
Alessio,
May I ask you how many zookeeper form your ensemble?
Kind regards
On Fri, Jan 13, 2017 at 12:28 AM, Alessio Palma
<alessio.pa...@docomodigital.com<mailto:alessio.pa...@docomodigital.com>> wrote:
Hello all,
there are 5 minutes of negotiation on the cluster which ends in nothing.
These are the logs after the handshake fails:
host 1
2017-01-12 13:20:36,448 INFO [main] o.a.n.c.c.node.NodeClusterCoordinator
Resetting cluster node statuses from {} to
{mid1-t029nifi-2.buongiorno.com:8080=NodeConnectionStatus[
nodeId=mid1-t029nifi-2.buongiorno.com:8080<http://mid1-t029nifi-2.buongiorno.com:8080/>,
state=DISCONNECTED, Disconnect Code=Not Has Not Yet Connected to Cluster,
Disconnect Reason=Not Has Not Yet Connected to Cluster, u
pdateId=1],
mid1-t029nifi-1.buongiorno.com:8080=NodeConnectionStatus[nodeId=mid1-t029nifi-1.buongiorno.com:8080<http://mid1-t029nifi-1.buongiorno.com:8080/>,
state=CONNECTING, updateId=120]}
2017-01-12 13:20:36,450 ERROR [main] o.a.nifi.controller.StandardFlowService
Failed to load flow from cluster due to:
org.apache.nifi.controller.UninheritableFlowException: Fa
iled to connect node to cluster because local flow is different than cluster
flow.
org.apache.nifi.controller.UninheritableFlowException: Failed to connect node
to cluster because local flow is different than cluster flow.
at
org.apache.nifi.controller.StandardFlowService.loadFromConnectionResponse(StandardFlowService.java:894)
~[nifi-framework-core-1.1.1.jar:1.1.1]
at
org.apache.nifi.controller.StandardFlowService.load(StandardFlowService.java:493)
~[nifi-framework-core-1.1.1.jar:1.1.1]
at org.apache.nifi.web.server.JettyServer.start(JettyServer.java:770)
[nifi-jetty-1.1.1.jar:1.1.1]
at org.apache.nifi.NiFi.(NiFi.java:156)
[nifi-runtime-1.1.1.jar:1.1.1]
at org.apache.nifi.NiFi.main(NiFi.java:262)
[nifi-runtime-1.1.1.jar:1.1.1]
Caused by: org.apache.nifi.controller.UninheritableFlowException: Proposed
Authorizer is not inheritable by the flow controller because of Authorizer
differences: Proposed Aut
horizations do not match current Authorizations
at
org.apache.nifi.controller.StandardFlowSynchronizer.sync(StandardFlowSynchronizer.java:253)
~[nifi-framework-core-1.1.1.jar:1.1.1]
at
org.apache.nifi.controller.FlowController.synchronize(FlowController.java:1461)
~[nifi-framework-core-1.1.1.jar:1.1.1]
at
org.apache.nifi.persistence.StandardXMLFlowConfigurationDAO.load(StandardXMLFlowConfigurationDAO.java:83)
~[nifi-framework-core-1.1.1.jar:1.1.1]
at
org.apache.nifi.controller.StandardFlowService.loadFromBytes(StandardFlowService.java:678)
~[nifi-framework-core-1.1.1.jar:1.1.1]
at
org.apache.nifi.controller.StandardFlowService.loadFromConnectionResponse(StandardFlowService.java:872)
~[nifi-framework-core-1.1.1.jar:1.1.1]
... 4 common frames omitted
Host 2
2017-01-12 13:20:36,900 INFO [main] o.a.n.c.c.node.NodeClusterCoordinator
Resetting cluster node statuses from
{mid1-t029nifi-2.buongiorno.com:8
Re: Cluster is still voting on which Flow is the correct flow for the cluster
2 host secured custer.
2 zookeeper.
From: Andre <andre-li...@fucs.org>
Sent: Thursday, January 12, 2017 2:39:23 PM
To: users@nifi.apache.org
Subject: Re: Cluster is still voting on which Flow is the correct flow for the
cluster
Alessio,
May I ask you how many zookeeper form your ensemble?
Kind regards
On Fri, Jan 13, 2017 at 12:28 AM, Alessio Palma
<alessio.pa...@docomodigital.com<mailto:alessio.pa...@docomodigital.com>> wrote:
Hello all,
there are 5 minutes of negotiation on the cluster which ends in nothing.
These are the logs after the handshake fails:
host 1
2017-01-12 13:20:36,448 INFO [main] o.a.n.c.c.node.NodeClusterCoordinator
Resetting cluster node statuses from {} to
{mid1-t029nifi-2.buongiorno.com:8080=NodeConnectionStatus[
nodeId=mid1-t029nifi-2.buongiorno.com:8080<http://mid1-t029nifi-2.buongiorno.com:8080>,
state=DISCONNECTED, Disconnect Code=Not Has Not Yet Connected to Cluster,
Disconnect Reason=Not Has Not Yet Connected to Cluster, u
pdateId=1],
mid1-t029nifi-1.buongiorno.com:8080=NodeConnectionStatus[nodeId=mid1-t029nifi-1.buongiorno.com:8080<http://mid1-t029nifi-1.buongiorno.com:8080>,
state=CONNECTING, updateId=120]}
2017-01-12 13:20:36,450 ERROR [main] o.a.nifi.controller.StandardFlowService
Failed to load flow from cluster due to:
org.apache.nifi.controller.UninheritableFlowException: Fa
iled to connect node to cluster because local flow is different than cluster
flow.
org.apache.nifi.controller.UninheritableFlowException: Failed to connect node
to cluster because local flow is different than cluster flow.
at
org.apache.nifi.controller.StandardFlowService.loadFromConnectionResponse(StandardFlowService.java:894)
~[nifi-framework-core-1.1.1.jar:1.1.1]
at
org.apache.nifi.controller.StandardFlowService.load(StandardFlowService.java:493)
~[nifi-framework-core-1.1.1.jar:1.1.1]
at org.apache.nifi.web.server.JettyServer.start(JettyServer.java:770)
[nifi-jetty-1.1.1.jar:1.1.1]
at org.apache.nifi.NiFi.(NiFi.java:156)
[nifi-runtime-1.1.1.jar:1.1.1]
at org.apache.nifi.NiFi.main(NiFi.java:262)
[nifi-runtime-1.1.1.jar:1.1.1]
Caused by: org.apache.nifi.controller.UninheritableFlowException: Proposed
Authorizer is not inheritable by the flow controller because of Authorizer
differences: Proposed Aut
horizations do not match current Authorizations
at
org.apache.nifi.controller.StandardFlowSynchronizer.sync(StandardFlowSynchronizer.java:253)
~[nifi-framework-core-1.1.1.jar:1.1.1]
at
org.apache.nifi.controller.FlowController.synchronize(FlowController.java:1461)
~[nifi-framework-core-1.1.1.jar:1.1.1]
at
org.apache.nifi.persistence.StandardXMLFlowConfigurationDAO.load(StandardXMLFlowConfigurationDAO.java:83)
~[nifi-framework-core-1.1.1.jar:1.1.1]
at
org.apache.nifi.controller.StandardFlowService.loadFromBytes(StandardFlowService.java:678)
~[nifi-framework-core-1.1.1.jar:1.1.1]
at
org.apache.nifi.controller.StandardFlowService.loadFromConnectionResponse(StandardFlowService.java:872)
~[nifi-framework-core-1.1.1.jar:1.1.1]
... 4 common frames omitted
Host 2
2017-01-12 13:20:36,900 INFO [main] o.a.n.c.c.node.NodeClusterCoordinator
Resetting cluster node statuses from
{mid1-t029nifi-2.buongiorno.com:8080=NodeConnectionStatus[nodeId=mid1-t029nifi-2.buongiorno.com:8080<http://mid1-t029nifi-2.buongiorno.com:8080>,
state=CONNECTING, updateId=122],
mid1-t029nifi-1.buongiorno.com:8080=NodeConnectionStatus[nodeId=mid1-t029nifi-1.buongiorno.com:8080<http://mid1-t029nifi-1.buongiorno.com:8080>,
state=DISCONNECTED, Disconnect Code=Node's Flow did not Match Cluster Flow,
Disconnect Reason=org.apache.nifi.controller.UninheritableFlowException: Failed
to connect node to cluster because local flow is different than cluster flow.,
updateId=1]} to
{mid1-t029nifi-2.buongiorno.com:8080=NodeConnectionStatus[nodeId=mid1-t029nifi-2.buongiorno.com:8080<http://mid1-t029nifi-2.buongiorno.com:8080>,
state=CONNECTING, updateId=122],
mid1-t029nifi-1.buongiorno.com:8080=NodeConnectionStatus[nodeId=mid1-t029nifi-1.buongiorno.com:8080<http://mid1-t029nifi-1.buongiorno.com:8080>,
state=DISCONNECTED, Disconnect Code=Node's Flow did not Match Cluster Flow,
Disconnect Reason=org.apache.nifi.controller.UninheritableFlowException: Failed
to connect node to cluster because local flow is different than cluster flow.,
updateId=1]}
2017-01-12 13:20:36,927 INFO [main] o.apache.nifi.controller.FlowController
Successfully synchronized controller with proposed flow
2017-01-12 13:20:37,092 INFO [main] org.wali.MinimalLockingWriteAheadLog
org.wali.MinimalLockingWriteAheadLog@c42ee90 finished recovering records.
Performing Checkpoint to ensure proper state of Partitions before updates
What can I check to solve this ?
5 minutes
Hello all, something into NIFI is timed to 5 minutes: processor statistic error messages How can I change processor statistics to hours and error messages to last days ?
Write-lock processors
Hello all, I wonder if there is a fast way to set processor to write only. It's easy to deleted/move/change them on the workbench and I see no undo option.
