Re: Retry logic for rest api - NIFI
Thanks Matt. I got it. We implemented a similar approach to retry in database failures. I will try that now. On Thu, Jul 30, 2020 at 3:31 PM Matt Burgess wrote: > Asmath, > > InvokeHttp routes the original flowfile to a number of different > relationships based on things like the status code. For example if > you're looking for a 2xx code but want to retry on that for some > reason, you'd use the "Original" relationship. If you want a retryable > code (5xx) you can use the "Retry" relationship, and so on. If you > need a specific code, you can use RouteOnAttribute to match the > "invokehttp.status.code" attribute to the code(s) you want, and all > that match can be sent back to the original InvokeHttp processor. > > That's a simpler pattern but they can get more complex. For example > you can start the flowfile with an attribute "retries" set to 5, and > before you send the flow file back to InvokeHttp, you'd decrement the > counter with UpdateAttribute and then perhaps drop the flowfile or > send it to some other mechanism after retries becomes zero. Also you > could put a delay in the flow so you're not retrying the same thing as > fast as possible (that could constitute a Denial-Of-Service attack on > the HTTP endpoint you're trying to reach). I can't remember which > relationships from InvokeHttp penalize the flowfile, so there's a > chance that the processor will handle the delay for you (see the > User's Guide section on penalized flowfiles). > > Regards, > Matt > > On Thu, Jul 30, 2020 at 3:38 PM KhajaAsmath Mohammed > wrote: > > > > can you please let me know how to use this in NIFI. > > > > On Thu, Jul 30, 2020 at 11:19 AM Otto Fowler > wrote: > >> > >> nipyapi does something like that: > https://github.com/Chaffelson/nipyapi/blob/164351ee2d92f8c4a75989310662bbad0f7bafc4/nipyapi/utils.py#L210 > >> > >> > >> > >> > >> On July 30, 2020 at 11:22:29, KhajaAsmath Mohammed ( > mdkhajaasm...@gmail.com) wrote: > >> > >> Hi, > >> > >> I am looking for some information on how to do retry logic on restapi > until we get specific status code. Please let me know if you have any > approach/templates for this > >> > >> Thanks, > >> Asmath >
Re: Retry logic for rest api - NIFI
Asmath, InvokeHttp routes the original flowfile to a number of different relationships based on things like the status code. For example if you're looking for a 2xx code but want to retry on that for some reason, you'd use the "Original" relationship. If you want a retryable code (5xx) you can use the "Retry" relationship, and so on. If you need a specific code, you can use RouteOnAttribute to match the "invokehttp.status.code" attribute to the code(s) you want, and all that match can be sent back to the original InvokeHttp processor. That's a simpler pattern but they can get more complex. For example you can start the flowfile with an attribute "retries" set to 5, and before you send the flow file back to InvokeHttp, you'd decrement the counter with UpdateAttribute and then perhaps drop the flowfile or send it to some other mechanism after retries becomes zero. Also you could put a delay in the flow so you're not retrying the same thing as fast as possible (that could constitute a Denial-Of-Service attack on the HTTP endpoint you're trying to reach). I can't remember which relationships from InvokeHttp penalize the flowfile, so there's a chance that the processor will handle the delay for you (see the User's Guide section on penalized flowfiles). Regards, Matt On Thu, Jul 30, 2020 at 3:38 PM KhajaAsmath Mohammed wrote: > > can you please let me know how to use this in NIFI. > > On Thu, Jul 30, 2020 at 11:19 AM Otto Fowler wrote: >> >> nipyapi does something like that: >> https://github.com/Chaffelson/nipyapi/blob/164351ee2d92f8c4a75989310662bbad0f7bafc4/nipyapi/utils.py#L210 >> >> >> >> >> On July 30, 2020 at 11:22:29, KhajaAsmath Mohammed (mdkhajaasm...@gmail.com) >> wrote: >> >> Hi, >> >> I am looking for some information on how to do retry logic on restapi until >> we get specific status code. Please let me know if you have any >> approach/templates for this >> >> Thanks, >> Asmath
Re: Nifi 1.8 to 1.11.4 migration issue
Thanks Mark for the update. Could you please the jira request number on which this issue is fixed. Regards, Sanjeet On Fri, 31 Jul 2020, 12:51 am Mark Payne, wrote: > OK, I suspect you’re probably hitting an issue that was introduced in > 1.11.x related to fingerprint handling. A change was made to improve how > some things were handled in the flow fingerprinting logic but resulted in > very poor performance in some particular cases. I.e., some flows will load > quickly while others load very slowly. The good news is that this has since > been fixed, though the fix hasn’t yet been released. I would expect the > next release to come pretty soon, though. > > Thanks > -Mark > > On Jul 30, 2020, at 3:15 PM, sanjeet rath wrote: > > Hi Mark, > Thanks for responding. > Sorry, i can't share the log, Due to our company policy. > its keeping printing this 2 warning in nifi-app.log once the server is up > this warning is gone. > 1-> O.apache.nifi.controler.flocontroler failed to send heart beat due to > ; org.apache.nifi.cluster.protocol.protocalException: Failed marshalling > 'HEARTBEAT" protocol message due to javax.net.sslException:Read timed out. > 2-> o.a.nifi.fingerprint.FingerprintFactory unable to get the > controller service of type org.apache.nifi.processor.aws.s3.puts3object;it > is default properties will be fingerprinted instead of being ignored > > Thanks Boris for the response, but i am not that issue, facing node > disconnection issue. > > > > On Fri, Jul 31, 2020 at 12:18 AM Mark Payne wrote: > >> Sanjeet, >> >> I’d recommend grabbing a thread dump while NiFi is starting up (after >> it’s been going for 3 minutes or so) and providing that to understand why >> it’s taking 30 minutes to startup. Specifically, the “main” thread will be >> of interest. >> >> Thanks >> -Mark >> >> >> On Jul 30, 2020, at 2:04 PM, sanjeet rath wrote: >> >> Hi , >> yes i am using external zookeeper 3.5 version.I have already followed all >> the document you have share . >> Now i am seeing after waiting around 30 mins the node gets >> connected after that there is no node disconnection issue. >> when i restarted , again it is taking 30 min for node connection to >> cluster. >> >> not able to figure out where is the issue. >> and same below warning also comes. >> O.apache.nifi.controler.flocontroler failed to send heart beat due to ; >> org.apache.nifi.cluster.protocol.protocalException: Failed marshalling >> 'HEARTBEAT" protocol message due to javax.net.sslException:Read timed out. >> >> On Thu, Jul 30, 2020 at 8:01 PM Nathan Gough wrote: >> >>> Hi Sanjeet, >>> >>> One thing to do is make sure you're using at least Zookeeper 3.5.5: >>> >>> Migrating from 1.x.x to 1.10.0 - The RPM creation mechanism appears broken for both Java 8 and Java 11 binaries if you wanted to build those yourself. Should be resolved in a later release. - We've removed the following nars from the default convenience binary. These include kite-nar, kafka-0-8-nar, flume-nar, media-nar, druid-controller-service-api-nar, druid-nar, other-graph-services-nar. You can still get them from the various artifact repositories and use them in your flows but we cannot bundle them due to space limitations by default. - The "Auto-Create Partitions" property was removed from the PutHive3Streaming processor, causing existing instances of this processor to become invalid. The property would appear as a unsupported user-defined property and must be removed to return the processor to a valid state. - The Zookeeper dependency that NiFi uses for state management and cluster elections was upgraded to v3.5.5. From v3.5.x onwards, *Zookeeper changed the zookeeper.properties file format and as a result NiFi users using an existing embedded zookeeper will need to adjust their existing zookeeper.properties file accordingly*. More details here: https://zookeeper.apache.org/doc/r3.5.3-beta/zookeeperReconfig.html#sc_reconfig_clientport . For new deployments of the 1.10.0 release onwards, NiFi will be packaged with an updated template zookeeper.properties file. To update an existing zookeeper.properties file however, edit the conf/zookeeper.properties file: 1. Remove the clientPort=2181 line (or whatever your port number may be) 2. Add the client port to the end of the server string eg: server.1=localhost:2888:3888;2181 >>> You may also need to ensure your server certificates contain a DNS >>> entry in the Subject Alternative Name (SAN) for their respective hosts. >>> >>> On Thu, Jul 30, 2020 at 10:17 AM sanjeet rath >>> wrote: >>> Hi, The error is, O.apache.nifi.controler.flocontroler failed to send heart beat due to ;
Re: Retry logic for rest api - NIFI
can you please let me know how to use this in NIFI. On Thu, Jul 30, 2020 at 11:19 AM Otto Fowler wrote: > nipyapi does something like that: > https://github.com/Chaffelson/nipyapi/blob/164351ee2d92f8c4a75989310662bbad0f7bafc4/nipyapi/utils.py#L210 > > > > > On July 30, 2020 at 11:22:29, KhajaAsmath Mohammed ( > mdkhajaasm...@gmail.com) wrote: > > Hi, > > I am looking for some information on how to do retry logic on > restapi until we get specific status code. Please let me know if you have > any approach/templates for this > > Thanks, > Asmath > >
Re: Nifi 1.8 to 1.11.4 migration issue
OK, I suspect you’re probably hitting an issue that was introduced in 1.11.x related to fingerprint handling. A change was made to improve how some things were handled in the flow fingerprinting logic but resulted in very poor performance in some particular cases. I.e., some flows will load quickly while others load very slowly. The good news is that this has since been fixed, though the fix hasn’t yet been released. I would expect the next release to come pretty soon, though. Thanks -Mark On Jul 30, 2020, at 3:15 PM, sanjeet rath mailto:rath.sanj...@gmail.com>> wrote: Hi Mark, Thanks for responding. Sorry, i can't share the log, Due to our company policy. its keeping printing this 2 warning in nifi-app.log once the server is up this warning is gone. 1-> O.apache.nifi.controler.flocontroler failed to send heart beat due to ; org.apache.nifi.cluster.protocol.protocalException: Failed marshalling 'HEARTBEAT" protocol message due to javax.net.sslException:Read timed out. 2-> o.a.nifi.fingerprint.FingerprintFactory unable to get the controller service of type org.apache.nifi.processor.aws.s3.puts3object;it is default properties will be fingerprinted instead of being ignored Thanks Boris for the response, but i am not that issue, facing node disconnection issue. On Fri, Jul 31, 2020 at 12:18 AM Mark Payne mailto:marka...@hotmail.com>> wrote: Sanjeet, I’d recommend grabbing a thread dump while NiFi is starting up (after it’s been going for 3 minutes or so) and providing that to understand why it’s taking 30 minutes to startup. Specifically, the “main” thread will be of interest. Thanks -Mark On Jul 30, 2020, at 2:04 PM, sanjeet rath mailto:rath.sanj...@gmail.com>> wrote: Hi , yes i am using external zookeeper 3.5 version.I have already followed all the document you have share . Now i am seeing after waiting around 30 mins the node gets connected after that there is no node disconnection issue. when i restarted , again it is taking 30 min for node connection to cluster. not able to figure out where is the issue. and same below warning also comes. O.apache.nifi.controler.flocontroler failed to send heart beat due to ; org.apache.nifi.cluster.protocol.protocalException: Failed marshalling 'HEARTBEAT" protocol message due to javax.net.sslException:Read timed out. On Thu, Jul 30, 2020 at 8:01 PM Nathan Gough mailto:thena...@gmail.com>> wrote: Hi Sanjeet, One thing to do is make sure you're using at least Zookeeper 3.5.5: Migrating from 1.x.x to 1.10.0 * The RPM creation mechanism appears broken for both Java 8 and Java 11 binaries if you wanted to build those yourself. Should be resolved in a later release. * We've removed the following nars from the default convenience binary. These include kite-nar, kafka-0-8-nar, flume-nar, media-nar, druid-controller-service-api-nar, druid-nar, other-graph-services-nar. You can still get them from the various artifact repositories and use them in your flows but we cannot bundle them due to space limitations by default. * The "Auto-Create Partitions" property was removed from the PutHive3Streaming processor, causing existing instances of this processor to become invalid. The property would appear as a unsupported user-defined property and must be removed to return the processor to a valid state. * The Zookeeper dependency that NiFi uses for state management and cluster elections was upgraded to v3.5.5. From v3.5.x onwards, Zookeeper changed the zookeeper.properties file format and as a result NiFi users using an existing embedded zookeeper will need to adjust their existing zookeeper.properties file accordingly. More details here: https://zookeeper.apache.org/doc/r3.5.3-beta/zookeeperReconfig.html#sc_reconfig_clientport. For new deployments of the 1.10.0 release onwards, NiFi will be packaged with an updated template zookeeper.properties file. To update an existing zookeeper.properties file however, edit the conf/zookeeper.properties file: * Remove the clientPort=2181 line (or whatever your port number may be) * Add the client port to the end of the server string eg: server.1=localhost:2888:3888;2181 You may also need to ensure your server certificates contain a DNS entry in the Subject Alternative Name (SAN) for their respective hosts. On Thu, Jul 30, 2020 at 10:17 AM sanjeet rath mailto:rath.sanj...@gmail.com>> wrote: Hi, The error is, O.apache.nifi.controler.flocontroler failed to send heart beat due to ; org.apache.nifi.cluster.protocol.protocalException: Failed marshalling 'HEARTBEAT" protocol message due to javax.net.sslException:Read timed out. Before migration there was no issue in cluster and ckuster are connected. Just bought flow.xml.gz ,user.xml & authorization.xml from other 1.8 server. Thanks & Regards Sanjeet On Thu, 30 Jul 2020, 7:37 pm sanjeet rath, mailto:rath.sanj...@gmail.com>> wrote: nifi-app.log file , i am getting constant error.
Re: Nifi 1.8 to 1.11.4 migration issue
Hi Mark, Thanks for responding. Sorry, i can't share the log, Due to our company policy. its keeping printing this 2 warning in nifi-app.log once the server is up this warning is gone. 1-> O.apache.nifi.controler.flocontroler failed to send heart beat due to ; org.apache.nifi.cluster.protocol.protocalException: Failed marshalling 'HEARTBEAT" protocol message due to javax.net.sslException:Read timed out. 2-> o.a.nifi.fingerprint.FingerprintFactory unable to get the controller service of type org.apache.nifi.processor.aws.s3.puts3object;it is default properties will be fingerprinted instead of being ignored Thanks Boris for the response, but i am not that issue, facing node disconnection issue. On Fri, Jul 31, 2020 at 12:18 AM Mark Payne wrote: > Sanjeet, > > I’d recommend grabbing a thread dump while NiFi is starting up (after it’s > been going for 3 minutes or so) and providing that to understand why it’s > taking 30 minutes to startup. Specifically, the “main” thread will be of > interest. > > Thanks > -Mark > > > On Jul 30, 2020, at 2:04 PM, sanjeet rath wrote: > > Hi , > yes i am using external zookeeper 3.5 version.I have already followed all > the document you have share . > Now i am seeing after waiting around 30 mins the node gets connected after > that there is no node disconnection issue. > when i restarted , again it is taking 30 min for node connection to > cluster. > > not able to figure out where is the issue. > and same below warning also comes. > O.apache.nifi.controler.flocontroler failed to send heart beat due to ; > org.apache.nifi.cluster.protocol.protocalException: Failed marshalling > 'HEARTBEAT" protocol message due to javax.net.sslException:Read timed out. > > On Thu, Jul 30, 2020 at 8:01 PM Nathan Gough wrote: > >> Hi Sanjeet, >> >> One thing to do is make sure you're using at least Zookeeper 3.5.5: >> >> Migrating from 1.x.x to 1.10.0 >>> >>>- The RPM creation mechanism appears broken for both Java 8 and Java >>>11 binaries if you wanted to build those yourself. Should be resolved >>> in a >>>later release. >>>- We've removed the following nars from the default convenience >>>binary. These include kite-nar, kafka-0-8-nar, flume-nar, media-nar, >>>druid-controller-service-api-nar, druid-nar, other-graph-services-nar. >>> You >>>can still get them from the various artifact repositories and use them in >>>your flows but we cannot bundle them due to space limitations by default. >>>- The "Auto-Create Partitions" property was removed from the >>>PutHive3Streaming processor, causing existing instances of this processor >>>to become invalid. The property would appear as a unsupported >>> user-defined >>>property and must be removed to return the processor to a valid state. >>>- The Zookeeper dependency that NiFi uses for state management and >>>cluster elections was upgraded to v3.5.5. From v3.5.x onwards, *Zookeeper >>>changed the zookeeper.properties file format and as a result NiFi users >>>using an existing embedded zookeeper will need to adjust their existing >>>zookeeper.properties file accordingly*. More details here: >>> >>> https://zookeeper.apache.org/doc/r3.5.3-beta/zookeeperReconfig.html#sc_reconfig_clientport >>>. >>>For new deployments of the 1.10.0 release onwards, NiFi will be >>>packaged with an updated template zookeeper.properties file. >>>To update an existing zookeeper.properties file however, edit the >>>conf/zookeeper.properties file: >>> 1. Remove the clientPort=2181 line (or whatever your port number >>> may be) >>> 2. Add the client port to the end of the server string eg: >>> server.1=localhost:2888:3888;2181 >>> >>> >> You may also need to ensure your server certificates contain a DNS entry >> in the Subject Alternative Name (SAN) for their respective hosts. >> >> On Thu, Jul 30, 2020 at 10:17 AM sanjeet rath >> wrote: >> >>> Hi, >>> >>> The error is, >>> >>> O.apache.nifi.controler.flocontroler failed to send heart beat due to ; >>> org.apache.nifi.cluster.protocol.protocalException: Failed marshalling >>> 'HEARTBEAT" protocol message due to javax.net.sslException:Read timed out. >>> >>> Before migration there was no issue in cluster and ckuster are connected. >>> Just bought flow.xml.gz ,user.xml & authorization.xml from other 1.8 >>> server. >>> >>> Thanks & Regards >>> Sanjeet >>> >>> >>> On Thu, 30 Jul 2020, 7:37 pm sanjeet rath, >>> wrote: >>> nifi-app.log file , i am getting constant error. Apache.nifi.controler.FlowControler Failed to send heart beat due to org.apache.nifi.protocal.protocolException On Thu, 30 Jul 2020, 6:54 pm Mark Payne, wrote: > Sanjeet, > > What error are you receiving? > > Sent from my iPhone > > On Jul 30, 2020, at 9:21 AM, sanjeet rath > wrote: > > > Hi Team, > > Any help on my trailed mail query will be
Re: Nifi 1.8 to 1.11.4 migration issue
Sanjeet, I’d recommend grabbing a thread dump while NiFi is starting up (after it’s been going for 3 minutes or so) and providing that to understand why it’s taking 30 minutes to startup. Specifically, the “main” thread will be of interest. Thanks -Mark On Jul 30, 2020, at 2:04 PM, sanjeet rath mailto:rath.sanj...@gmail.com>> wrote: Hi , yes i am using external zookeeper 3.5 version.I have already followed all the document you have share . Now i am seeing after waiting around 30 mins the node gets connected after that there is no node disconnection issue. when i restarted , again it is taking 30 min for node connection to cluster. not able to figure out where is the issue. and same below warning also comes. O.apache.nifi.controler.flocontroler failed to send heart beat due to ; org.apache.nifi.cluster.protocol.protocalException: Failed marshalling 'HEARTBEAT" protocol message due to javax.net.sslException:Read timed out. On Thu, Jul 30, 2020 at 8:01 PM Nathan Gough mailto:thena...@gmail.com>> wrote: Hi Sanjeet, One thing to do is make sure you're using at least Zookeeper 3.5.5: Migrating from 1.x.x to 1.10.0 * The RPM creation mechanism appears broken for both Java 8 and Java 11 binaries if you wanted to build those yourself. Should be resolved in a later release. * We've removed the following nars from the default convenience binary. These include kite-nar, kafka-0-8-nar, flume-nar, media-nar, druid-controller-service-api-nar, druid-nar, other-graph-services-nar. You can still get them from the various artifact repositories and use them in your flows but we cannot bundle them due to space limitations by default. * The "Auto-Create Partitions" property was removed from the PutHive3Streaming processor, causing existing instances of this processor to become invalid. The property would appear as a unsupported user-defined property and must be removed to return the processor to a valid state. * The Zookeeper dependency that NiFi uses for state management and cluster elections was upgraded to v3.5.5. From v3.5.x onwards, Zookeeper changed the zookeeper.properties file format and as a result NiFi users using an existing embedded zookeeper will need to adjust their existing zookeeper.properties file accordingly. More details here: https://zookeeper.apache.org/doc/r3.5.3-beta/zookeeperReconfig.html#sc_reconfig_clientport. For new deployments of the 1.10.0 release onwards, NiFi will be packaged with an updated template zookeeper.properties file. To update an existing zookeeper.properties file however, edit the conf/zookeeper.properties file: * Remove the clientPort=2181 line (or whatever your port number may be) * Add the client port to the end of the server string eg: server.1=localhost:2888:3888;2181 You may also need to ensure your server certificates contain a DNS entry in the Subject Alternative Name (SAN) for their respective hosts. On Thu, Jul 30, 2020 at 10:17 AM sanjeet rath mailto:rath.sanj...@gmail.com>> wrote: Hi, The error is, O.apache.nifi.controler.flocontroler failed to send heart beat due to ; org.apache.nifi.cluster.protocol.protocalException: Failed marshalling 'HEARTBEAT" protocol message due to javax.net.sslException:Read timed out. Before migration there was no issue in cluster and ckuster are connected. Just bought flow.xml.gz ,user.xml & authorization.xml from other 1.8 server. Thanks & Regards Sanjeet On Thu, 30 Jul 2020, 7:37 pm sanjeet rath, mailto:rath.sanj...@gmail.com>> wrote: nifi-app.log file , i am getting constant error. Apache.nifi.controler.FlowControler Failed to send heart beat due to org.apache.nifi.protocal.protocolException On Thu, 30 Jul 2020, 6:54 pm Mark Payne, mailto:marka...@hotmail.com>> wrote: Sanjeet, What error are you receiving? Sent from my iPhone On Jul 30, 2020, at 9:21 AM, sanjeet rath mailto:rath.sanj...@gmail.com>> wrote: Hi Team, Any help on my trailed mail query will be highly appreciated.still i am strgling yo fix yhe issue. In nifi-app.log file , i am getting constant error. Apache.nifi.controler.FlowControler Failed to send heart beat due to org.apache.nifi.protocal.protocolEcslception. Thanks & Regards, Sanjeet On Tue, 28 Jul 2020, 10:21 pm sanjeet rath, mailto:rath.sanj...@gmail.com>> wrote: Hi Team, I am facing a wired issue while doing migration from 1.8 to 1.11.4 I am bringing flow.xml.gz,user.xml,authorization.xml from a nifi cluster(1.8 version) to a newly created 1.11.4 version cluster. When i am starting the 1.11.4 cluster with this new files, i am getting node disconnected error (this node is not conncted to cluster pop up ) However with only users.xml, authrization.xml from 1.8 and default 1.11.4 flow.xml.gz. i am getting no error all 3 nodes are getting conncted in the new cluster. Infact when i am bringing another 1.8 env's flow.xml.gz files it working fine. So specific for this flow.xml.gz file only my nodes are getting
Re: Nifi 1.8 to 1.11.4 migration issue
Sanjeet, just a heads up as we were in the same boat. We decided to hold off the upgrade because of a critical issue in 1.11.4. not sure if it applies to your environment but we decided to wait for 1.12 more details here https://issues.apache.org/jira/browse/NIFI-7460 On Thu, Jul 30, 2020 at 2:04 PM sanjeet rath wrote: > Hi , > yes i am using external zookeeper 3.5 version.I have already followed all > the document you have share . > Now i am seeing after waiting around 30 mins the node gets connected after > that there is no node disconnection issue. > when i restarted , again it is taking 30 min for node connection to > cluster. > > not able to figure out where is the issue. > and same below warning also comes. > O.apache.nifi.controler.flocontroler failed to send heart beat due to ; > org.apache.nifi.cluster.protocol.protocalException: Failed marshalling > 'HEARTBEAT" protocol message due to javax.net.sslException:Read timed out. > > On Thu, Jul 30, 2020 at 8:01 PM Nathan Gough wrote: > >> Hi Sanjeet, >> >> One thing to do is make sure you're using at least Zookeeper 3.5.5: >> >> Migrating from 1.x.x to 1.10.0 >>> >>>- The RPM creation mechanism appears broken for both Java 8 and Java >>>11 binaries if you wanted to build those yourself. Should be resolved >>> in a >>>later release. >>>- We've removed the following nars from the default convenience >>>binary. These include kite-nar, kafka-0-8-nar, flume-nar, media-nar, >>>druid-controller-service-api-nar, druid-nar, other-graph-services-nar. >>> You >>>can still get them from the various artifact repositories and use them in >>>your flows but we cannot bundle them due to space limitations by default. >>>- The "Auto-Create Partitions" property was removed from the >>>PutHive3Streaming processor, causing existing instances of this processor >>>to become invalid. The property would appear as a unsupported >>> user-defined >>>property and must be removed to return the processor to a valid state. >>>- The Zookeeper dependency that NiFi uses for state management and >>>cluster elections was upgraded to v3.5.5. From v3.5.x onwards, *Zookeeper >>>changed the zookeeper.properties file format and as a result NiFi users >>>using an existing embedded zookeeper will need to adjust their existing >>>zookeeper.properties file accordingly*. More details here: >>> >>> https://zookeeper.apache.org/doc/r3.5.3-beta/zookeeperReconfig.html#sc_reconfig_clientport >>>. >>>For new deployments of the 1.10.0 release onwards, NiFi will be >>>packaged with an updated template zookeeper.properties file. >>>To update an existing zookeeper.properties file however, edit the >>>conf/zookeeper.properties file: >>> 1. Remove the clientPort=2181 line (or whatever your port number >>> may be) >>> 2. Add the client port to the end of the server string eg: >>> server.1=localhost:2888:3888;2181 >>> >>> >> You may also need to ensure your server certificates contain a DNS entry >> in the Subject Alternative Name (SAN) for their respective hosts. >> >> On Thu, Jul 30, 2020 at 10:17 AM sanjeet rath >> wrote: >> >>> Hi, >>> >>> The error is, >>> >>> O.apache.nifi.controler.flocontroler failed to send heart beat due to ; >>> org.apache.nifi.cluster.protocol.protocalException: Failed marshalling >>> 'HEARTBEAT" protocol message due to javax.net.sslException:Read timed out. >>> >>> Before migration there was no issue in cluster and ckuster are connected. >>> Just bought flow.xml.gz ,user.xml & authorization.xml from other 1.8 >>> server. >>> >>> Thanks & Regards >>> Sanjeet >>> >>> >>> On Thu, 30 Jul 2020, 7:37 pm sanjeet rath, >>> wrote: >>> nifi-app.log file , i am getting constant error. Apache.nifi.controler.FlowControler Failed to send heart beat due to org.apache.nifi.protocal.protocolException On Thu, 30 Jul 2020, 6:54 pm Mark Payne, wrote: > Sanjeet, > > What error are you receiving? > > Sent from my iPhone > > On Jul 30, 2020, at 9:21 AM, sanjeet rath > wrote: > > > Hi Team, > > Any help on my trailed mail query will be highly appreciated.still i > am strgling yo fix yhe issue. > > In nifi-app.log file , i am getting constant error. > > Apache.nifi.controler.FlowControler Failed to send heart beat due to > org.apache.nifi.protocal.protocolEcslception. > > Thanks & Regards, > Sanjeet > > On Tue, 28 Jul 2020, 10:21 pm sanjeet rath, > wrote: > >> Hi Team, >> >> I am facing a wired issue while doing migration from 1.8 to 1.11.4 >> I am bringing flow.xml.gz,user.xml,authorization.xml from a nifi >> cluster(1.8 version) to a newly created 1.11.4 version cluster. >> >> When i am starting the 1.11.4 cluster with this new files, i am >> getting node disconnected error (this node is not conncted
Re: Nifi 1.8 to 1.11.4 migration issue
Hi , yes i am using external zookeeper 3.5 version.I have already followed all the document you have share . Now i am seeing after waiting around 30 mins the node gets connected after that there is no node disconnection issue. when i restarted , again it is taking 30 min for node connection to cluster. not able to figure out where is the issue. and same below warning also comes. O.apache.nifi.controler.flocontroler failed to send heart beat due to ; org.apache.nifi.cluster.protocol.protocalException: Failed marshalling 'HEARTBEAT" protocol message due to javax.net.sslException:Read timed out. On Thu, Jul 30, 2020 at 8:01 PM Nathan Gough wrote: > Hi Sanjeet, > > One thing to do is make sure you're using at least Zookeeper 3.5.5: > > Migrating from 1.x.x to 1.10.0 >> >>- The RPM creation mechanism appears broken for both Java 8 and Java >>11 binaries if you wanted to build those yourself. Should be resolved in >> a >>later release. >>- We've removed the following nars from the default convenience >>binary. These include kite-nar, kafka-0-8-nar, flume-nar, media-nar, >>druid-controller-service-api-nar, druid-nar, other-graph-services-nar. >> You >>can still get them from the various artifact repositories and use them in >>your flows but we cannot bundle them due to space limitations by default. >>- The "Auto-Create Partitions" property was removed from the >>PutHive3Streaming processor, causing existing instances of this processor >>to become invalid. The property would appear as a unsupported user-defined >>property and must be removed to return the processor to a valid state. >>- The Zookeeper dependency that NiFi uses for state management and >>cluster elections was upgraded to v3.5.5. From v3.5.x onwards, *Zookeeper >>changed the zookeeper.properties file format and as a result NiFi users >>using an existing embedded zookeeper will need to adjust their existing >>zookeeper.properties file accordingly*. More details here: >> >> https://zookeeper.apache.org/doc/r3.5.3-beta/zookeeperReconfig.html#sc_reconfig_clientport >>. >>For new deployments of the 1.10.0 release onwards, NiFi will be >>packaged with an updated template zookeeper.properties file. >>To update an existing zookeeper.properties file however, edit the >>conf/zookeeper.properties file: >> 1. Remove the clientPort=2181 line (or whatever your port number >> may be) >> 2. Add the client port to the end of the server string eg: >> server.1=localhost:2888:3888;2181 >> >> > You may also need to ensure your server certificates contain a DNS entry > in the Subject Alternative Name (SAN) for their respective hosts. > > On Thu, Jul 30, 2020 at 10:17 AM sanjeet rath > wrote: > >> Hi, >> >> The error is, >> >> O.apache.nifi.controler.flocontroler failed to send heart beat due to ; >> org.apache.nifi.cluster.protocol.protocalException: Failed marshalling >> 'HEARTBEAT" protocol message due to javax.net.sslException:Read timed out. >> >> Before migration there was no issue in cluster and ckuster are connected. >> Just bought flow.xml.gz ,user.xml & authorization.xml from other 1.8 >> server. >> >> Thanks & Regards >> Sanjeet >> >> >> On Thu, 30 Jul 2020, 7:37 pm sanjeet rath, >> wrote: >> >>> nifi-app.log file , i am getting constant error. >>> >>> Apache.nifi.controler.FlowControler Failed to send heart beat due to >>> org.apache.nifi.protocal.protocolException >>> >>> On Thu, 30 Jul 2020, 6:54 pm Mark Payne, wrote: >>> Sanjeet, What error are you receiving? Sent from my iPhone On Jul 30, 2020, at 9:21 AM, sanjeet rath wrote: Hi Team, Any help on my trailed mail query will be highly appreciated.still i am strgling yo fix yhe issue. In nifi-app.log file , i am getting constant error. Apache.nifi.controler.FlowControler Failed to send heart beat due to org.apache.nifi.protocal.protocolEcslception. Thanks & Regards, Sanjeet On Tue, 28 Jul 2020, 10:21 pm sanjeet rath, wrote: > Hi Team, > > I am facing a wired issue while doing migration from 1.8 to 1.11.4 > I am bringing flow.xml.gz,user.xml,authorization.xml from a nifi > cluster(1.8 version) to a newly created 1.11.4 version cluster. > > When i am starting the 1.11.4 cluster with this new files, i am > getting node disconnected error (this node is not conncted to cluster pop > up ) > > However with only users.xml, authrization.xml from 1.8 and default > 1.11.4 flow.xml.gz. i am getting no error all 3 nodes are getting conncted > in the new cluster. > Infact when i am bringing another 1.8 env's flow.xml.gz files it > working fine. > > So specific for this flow.xml.gz file only my nodes are getting > disconncted. > > It will really helpfull if you can help where i need to
Re: mergeContent not working
https://imgur.com/aCzkWfu On 2020/07/30 17:32:47, nayan sharma wrote: > Hi Users, > I am using mergeContent for emitting flow files when size will be greater > than 1 Gb. It is scheduled to run/check for files every 30sec. MergeContent > has following configuration >https://imgur.com/undefined > but it doesn't wait for anything. It emits files as soon as it wakes. It is > creating files in mbs. > Any ideas what configuration i should do to make it work. > > Thanks, > Nayan > > >
mergeContent not working
Hi Users, I am using mergeContent for emitting flow files when size will be greater than 1 Gb. It is scheduled to run/check for files every 30sec. MergeContent has following configuration https://imgur.com/undefined but it doesn't wait for anything. It emits files as soon as it wakes. It is creating files in mbs. Any ideas what configuration i should do to make it work. Thanks, Nayan
Re: Retry logic for rest api - NIFI
nipyapi does something like that: https://github.com/Chaffelson/nipyapi/blob/164351ee2d92f8c4a75989310662bbad0f7bafc4/nipyapi/utils.py#L210 On July 30, 2020 at 11:22:29, KhajaAsmath Mohammed (mdkhajaasm...@gmail.com) wrote: Hi, I am looking for some information on how to do retry logic on restapi until we get specific status code. Please let me know if you have any approach/templates for this Thanks, Asmath
Re: Nifi security of local filesystem and hdfs in multitenant hdfs use cases
in short this case has been really deeply considered and it is a very common usage pattern. We offer a set of policies/controls that let it be well restricted and locked down. But if a user is given too many accesses then yes they can be malicious. Thanks On Thu, Jul 30, 2020 at 9:13 AM Andy LoPresto wrote: > If your concern is the malicious insider using FetchHDFS to read the > keytab as data from the filesystem, the *HDFS processors are marked as > Restricted and require an additional explicit permission to be granted for > users to configure them. At a file system interaction level, the NiFi Java > processes are running as a single OS user, so all of the keytabs will need > to be readable by that OS user, and the OS can’t detect which Java process > is acting as which application user. > > > Andy LoPresto > alopre...@apache.org > *alopresto.apa...@gmail.com * > He/Him > PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69 > > On Jul 30, 2020, at 8:10 AM, Mark Payne wrote: > > Olivier, > > As Joe mentioned, it may help to further explain the exact scenario that > you are concerned about. > > But what I *think* you are concerned about is the following scenario: > - You have several different users developing flows in NiFi. > - You want the ability to give User A (and only User A) access to Keytab A > by creating a KeytabCredentialsService and giving User A READ Access to it. > - You want the ability to give User B (and only User B) access to Keytab B > by creating a KeytabCredentialsService and giving User B READ Access to it. > - If you do the above, but User A happens to know that Keytab B is stored > at /etc/keytabs/keytab-b, then all User A has to do is configure PutHDFS’s > Keytab property to “/etc/keytabs/keytab-b” instead of using the > KeytabCredentialsService. Then User A has access to User B’s keytab. > > Is that the scenario that you are concerned about? > > If yes, then the answer is to set the NIFI_ALLOW_EXPLICIT_KEYTAB > Environment Variable to a value of “false”. If you do that, then PutHDFS > and related processors that allow for either a KeytabCredentialsService or > an explicit keytab will become invalid (and therefore not runnable) if an > explicit keytab is used. This prevents User A from using Keytab A or Keytab > B directly and instead forces them to use no Keytab (which presumably will > result in authorization failure) or using the KeytabCrdentialsService, > which you can control READ access to. > > Does this help? > > Thanks > -Mark > > On Jul 30, 2020, at 10:09 AM, Joe Witt wrote: > > Hello > > Can you more fully explain the scenario you have in mind and what an > intentionally malicious user might do? > > Thanks > > On Thu, Jul 30, 2020 at 6:54 AM oliver twix > wrote: > >> Hello, >> Getting deeper on using nifi in multitenant use cases, I am facing a >> security question: our nifi users must be able to interact with hdfs not >> sharing their credentials (keytabs). >> >> From what understood, keytabCredentialsService enable a way to give a >> policy based control over keytabs access. >> Where I miss something is that for a user to use an hdfs processor, it >> requires read/write filesystem permissions. In this context, any hdfs user >> is able to read the keytabs of any other users. So in my understanding, it >> breaks the initial objective of keytabCredentialsService to control keytabs >> accesses. >> >> Am I missing something ? Do you have a mean to avoid giving access to all >> keytabs stored on local filesystem? >> >> Olivier >> >> >> > >
Re: Nifi security of local filesystem and hdfs in multitenant hdfs use cases
Olivier, As Joe mentioned, it may help to further explain the exact scenario that you are concerned about. But what I *think* you are concerned about is the following scenario: - You have several different users developing flows in NiFi. - You want the ability to give User A (and only User A) access to Keytab A by creating a KeytabCredentialsService and giving User A READ Access to it. - You want the ability to give User B (and only User B) access to Keytab B by creating a KeytabCredentialsService and giving User B READ Access to it. - If you do the above, but User A happens to know that Keytab B is stored at /etc/keytabs/keytab-b, then all User A has to do is configure PutHDFS’s Keytab property to “/etc/keytabs/keytab-b” instead of using the KeytabCredentialsService. Then User A has access to User B’s keytab. Is that the scenario that you are concerned about? If yes, then the answer is to set the NIFI_ALLOW_EXPLICIT_KEYTAB Environment Variable to a value of “false”. If you do that, then PutHDFS and related processors that allow for either a KeytabCredentialsService or an explicit keytab will become invalid (and therefore not runnable) if an explicit keytab is used. This prevents User A from using Keytab A or Keytab B directly and instead forces them to use no Keytab (which presumably will result in authorization failure) or using the KeytabCrdentialsService, which you can control READ access to. Does this help? Thanks -Mark On Jul 30, 2020, at 10:09 AM, Joe Witt mailto:joe.w...@gmail.com>> wrote: Hello Can you more fully explain the scenario you have in mind and what an intentionally malicious user might do? Thanks On Thu, Jul 30, 2020 at 6:54 AM oliver twix mailto:olivertwix.pe...@gmail.com>> wrote: Hello, Getting deeper on using nifi in multitenant use cases, I am facing a security question: our nifi users must be able to interact with hdfs not sharing their credentials (keytabs). From what understood, keytabCredentialsService enable a way to give a policy based control over keytabs access. Where I miss something is that for a user to use an hdfs processor, it requires read/write filesystem permissions. In this context, any hdfs user is able to read the keytabs of any other users. So in my understanding, it breaks the initial objective of keytabCredentialsService to control keytabs accesses. Am I missing something ? Do you have a mean to avoid giving access to all keytabs stored on local filesystem? Olivier
Re: Nifi 1.8 to 1.11.4 migration issue
Hi Sanjeet, One thing to do is make sure you're using at least Zookeeper 3.5.5: Migrating from 1.x.x to 1.10.0 > >- The RPM creation mechanism appears broken for both Java 8 and Java >11 binaries if you wanted to build those yourself. Should be resolved in a >later release. >- We've removed the following nars from the default convenience >binary. These include kite-nar, kafka-0-8-nar, flume-nar, media-nar, >druid-controller-service-api-nar, druid-nar, other-graph-services-nar. You >can still get them from the various artifact repositories and use them in >your flows but we cannot bundle them due to space limitations by default. >- The "Auto-Create Partitions" property was removed from the >PutHive3Streaming processor, causing existing instances of this processor >to become invalid. The property would appear as a unsupported user-defined >property and must be removed to return the processor to a valid state. >- The Zookeeper dependency that NiFi uses for state management and >cluster elections was upgraded to v3.5.5. From v3.5.x onwards, *Zookeeper >changed the zookeeper.properties file format and as a result NiFi users >using an existing embedded zookeeper will need to adjust their existing >zookeeper.properties file accordingly*. More details here: > > https://zookeeper.apache.org/doc/r3.5.3-beta/zookeeperReconfig.html#sc_reconfig_clientport >. >For new deployments of the 1.10.0 release onwards, NiFi will be >packaged with an updated template zookeeper.properties file. >To update an existing zookeeper.properties file however, edit the >conf/zookeeper.properties file: > 1. Remove the clientPort=2181 line (or whatever your port number > may be) > 2. Add the client port to the end of the server string eg: > server.1=localhost:2888:3888;2181 > > You may also need to ensure your server certificates contain a DNS entry in the Subject Alternative Name (SAN) for their respective hosts. On Thu, Jul 30, 2020 at 10:17 AM sanjeet rath wrote: > Hi, > > The error is, > > O.apache.nifi.controler.flocontroler failed to send heart beat due to ; > org.apache.nifi.cluster.protocol.protocalException: Failed marshalling > 'HEARTBEAT" protocol message due to javax.net.sslException:Read timed out. > > Before migration there was no issue in cluster and ckuster are connected. > Just bought flow.xml.gz ,user.xml & authorization.xml from other 1.8 > server. > > Thanks & Regards > Sanjeet > > > On Thu, 30 Jul 2020, 7:37 pm sanjeet rath, wrote: > >> nifi-app.log file , i am getting constant error. >> >> Apache.nifi.controler.FlowControler Failed to send heart beat due to >> org.apache.nifi.protocal.protocolException >> >> On Thu, 30 Jul 2020, 6:54 pm Mark Payne, wrote: >> >>> Sanjeet, >>> >>> What error are you receiving? >>> >>> Sent from my iPhone >>> >>> On Jul 30, 2020, at 9:21 AM, sanjeet rath >>> wrote: >>> >>> >>> Hi Team, >>> >>> Any help on my trailed mail query will be highly appreciated.still i am >>> strgling yo fix yhe issue. >>> >>> In nifi-app.log file , i am getting constant error. >>> >>> Apache.nifi.controler.FlowControler Failed to send heart beat due to >>> org.apache.nifi.protocal.protocolEcslception. >>> >>> Thanks & Regards, >>> Sanjeet >>> >>> On Tue, 28 Jul 2020, 10:21 pm sanjeet rath, >>> wrote: >>> Hi Team, I am facing a wired issue while doing migration from 1.8 to 1.11.4 I am bringing flow.xml.gz,user.xml,authorization.xml from a nifi cluster(1.8 version) to a newly created 1.11.4 version cluster. When i am starting the 1.11.4 cluster with this new files, i am getting node disconnected error (this node is not conncted to cluster pop up ) However with only users.xml, authrization.xml from 1.8 and default 1.11.4 flow.xml.gz. i am getting no error all 3 nodes are getting conncted in the new cluster. Infact when i am bringing another 1.8 env's flow.xml.gz files it working fine. So specific for this flow.xml.gz file only my nodes are getting disconncted. It will really helpfull if you can help where i need to check to resolve this issue. I am using external zookeeper 3.5 version Thanks in advance, Sanjeet
Re: Nifi 1.8 to 1.11.4 migration issue
Hi, The error is, O.apache.nifi.controler.flocontroler failed to send heart beat due to ; org.apache.nifi.cluster.protocol.protocalException: Failed marshalling 'HEARTBEAT" protocol message due to javax.net.sslException:Read timed out. Before migration there was no issue in cluster and ckuster are connected. Just bought flow.xml.gz ,user.xml & authorization.xml from other 1.8 server. Thanks & Regards Sanjeet On Thu, 30 Jul 2020, 7:37 pm sanjeet rath, wrote: > nifi-app.log file , i am getting constant error. > > Apache.nifi.controler.FlowControler Failed to send heart beat due to > org.apache.nifi.protocal.protocolException > > On Thu, 30 Jul 2020, 6:54 pm Mark Payne, wrote: > >> Sanjeet, >> >> What error are you receiving? >> >> Sent from my iPhone >> >> On Jul 30, 2020, at 9:21 AM, sanjeet rath wrote: >> >> >> Hi Team, >> >> Any help on my trailed mail query will be highly appreciated.still i am >> strgling yo fix yhe issue. >> >> In nifi-app.log file , i am getting constant error. >> >> Apache.nifi.controler.FlowControler Failed to send heart beat due to >> org.apache.nifi.protocal.protocolEcslception. >> >> Thanks & Regards, >> Sanjeet >> >> On Tue, 28 Jul 2020, 10:21 pm sanjeet rath, >> wrote: >> >>> Hi Team, >>> >>> I am facing a wired issue while doing migration from 1.8 to 1.11.4 >>> I am bringing flow.xml.gz,user.xml,authorization.xml from a nifi >>> cluster(1.8 version) to a newly created 1.11.4 version cluster. >>> >>> When i am starting the 1.11.4 cluster with this new files, i am getting >>> node disconnected error (this node is not conncted to cluster pop up ) >>> >>> However with only users.xml, authrization.xml from 1.8 and default >>> 1.11.4 flow.xml.gz. i am getting no error all 3 nodes are getting conncted >>> in the new cluster. >>> Infact when i am bringing another 1.8 env's flow.xml.gz files it working >>> fine. >>> >>> So specific for this flow.xml.gz file only my nodes are getting >>> disconncted. >>> >>> It will really helpfull if you can help where i need to check to >>> resolve this issue. >>> >>> I am using external zookeeper 3.5 version >>> >>> Thanks in advance, >>> Sanjeet >>> >>>
Re: Nifi 1.8 to 1.11.4 migration issue
nifi-app.log file , i am getting constant error. Apache.nifi.controler.FlowControler Failed to send heart beat due to org.apache.nifi.protocal.protocolException On Thu, 30 Jul 2020, 6:54 pm Mark Payne, wrote: > Sanjeet, > > What error are you receiving? > > Sent from my iPhone > > On Jul 30, 2020, at 9:21 AM, sanjeet rath wrote: > > > Hi Team, > > Any help on my trailed mail query will be highly appreciated.still i am > strgling yo fix yhe issue. > > In nifi-app.log file , i am getting constant error. > > Apache.nifi.controler.FlowControler Failed to send heart beat due to > org.apache.nifi.protocal.protocolEcslception. > > Thanks & Regards, > Sanjeet > > On Tue, 28 Jul 2020, 10:21 pm sanjeet rath, > wrote: > >> Hi Team, >> >> I am facing a wired issue while doing migration from 1.8 to 1.11.4 >> I am bringing flow.xml.gz,user.xml,authorization.xml from a nifi >> cluster(1.8 version) to a newly created 1.11.4 version cluster. >> >> When i am starting the 1.11.4 cluster with this new files, i am getting >> node disconnected error (this node is not conncted to cluster pop up ) >> >> However with only users.xml, authrization.xml from 1.8 and default 1.11.4 >> flow.xml.gz. i am getting no error all 3 nodes are getting conncted in the >> new cluster. >> Infact when i am bringing another 1.8 env's flow.xml.gz files it working >> fine. >> >> So specific for this flow.xml.gz file only my nodes are getting >> disconncted. >> >> It will really helpfull if you can help where i need to check to >> resolve this issue. >> >> I am using external zookeeper 3.5 version >> >> Thanks in advance, >> Sanjeet >> >>
Nifi security of local filesystem and hdfs in multitenant hdfs use cases
Hello, Getting deeper on using nifi in multitenant use cases, I am facing a security question: our nifi users must be able to interact with hdfs not sharing their credentials (keytabs). >From what understood, keytabCredentialsService enable a way to give a policy based control over keytabs access. Where I miss something is that for a user to use an hdfs processor, it requires read/write filesystem permissions. In this context, any hdfs user is able to read the keytabs of any other users. So in my understanding, it breaks the initial objective of keytabCredentialsService to control keytabs accesses. Am I missing something ? Do you have a mean to avoid giving access to all keytabs stored on local filesystem? Olivier
Re: Nifi 1.8 to 1.11.4 migration issue
Sanjeet, What error are you receiving? Sent from my iPhone On Jul 30, 2020, at 9:21 AM, sanjeet rath wrote: Hi Team, Any help on my trailed mail query will be highly appreciated.still i am strgling yo fix yhe issue. In nifi-app.log file , i am getting constant error. Apache.nifi.controler.FlowControler Failed to send heart beat due to org.apache.nifi.protocal.protocolEcslception. Thanks & Regards, Sanjeet On Tue, 28 Jul 2020, 10:21 pm sanjeet rath, mailto:rath.sanj...@gmail.com>> wrote: Hi Team, I am facing a wired issue while doing migration from 1.8 to 1.11.4 I am bringing flow.xml.gz,user.xml,authorization.xml from a nifi cluster(1.8 version) to a newly created 1.11.4 version cluster. When i am starting the 1.11.4 cluster with this new files, i am getting node disconnected error (this node is not conncted to cluster pop up ) However with only users.xml, authrization.xml from 1.8 and default 1.11.4 flow.xml.gz. i am getting no error all 3 nodes are getting conncted in the new cluster. Infact when i am bringing another 1.8 env's flow.xml.gz files it working fine. So specific for this flow.xml.gz file only my nodes are getting disconncted. It will really helpfull if you can help where i need to check to resolve this issue. I am using external zookeeper 3.5 version Thanks in advance, Sanjeet
Re: Nifi 1.8 to 1.11.4 migration issue
Hi Team, Any help on my trailed mail query will be highly appreciated.still i am strgling yo fix yhe issue. In nifi-app.log file , i am getting constant error. Apache.nifi.controler.FlowControler Failed to send heart beat due to org.apache.nifi.protocal.protocolEcslception. Thanks & Regards, Sanjeet On Tue, 28 Jul 2020, 10:21 pm sanjeet rath, wrote: > Hi Team, > > I am facing a wired issue while doing migration from 1.8 to 1.11.4 > I am bringing flow.xml.gz,user.xml,authorization.xml from a nifi > cluster(1.8 version) to a newly created 1.11.4 version cluster. > > When i am starting the 1.11.4 cluster with this new files, i am getting > node disconnected error (this node is not conncted to cluster pop up ) > > However with only users.xml, authrization.xml from 1.8 and default 1.11.4 > flow.xml.gz. i am getting no error all 3 nodes are getting conncted in the > new cluster. > Infact when i am bringing another 1.8 env's flow.xml.gz files it working > fine. > > So specific for this flow.xml.gz file only my nodes are getting > disconncted. > > It will really helpfull if you can help where i need to check to > resolve this issue. > > I am using external zookeeper 3.5 version > > Thanks in advance, > Sanjeet > >
