Issue: NiFi and NiFi Registry are unable to import or change version when Processors are configured with CRON Scheduling Strategy.

Associated error message:

During an import or upgrade flow version process, a dialog displays a message indicating that a CRON expression is not a valid time duration or that a time duration is not a valid CRON expression.

Problem:

When updating the flow during an import or change version request, the properties are applied in the incorrect order. Because it is attempting to set the Run Schedule prior to configuring the Scheduling Strategy, when the Scheduling Strategy is changes it may fail to interpret the Run Schedule. This happens because the Processor is currently expecting the Run Schedule to be in a particular format based on its current Scheduling Strategy, but it is given the value that satisfies the new Scheduling Strategy.

This happens during import when the incoming flow is configured with CRON driven scheduling. This is because the default Scheduling Strategy is Timer driven.

This also happens during any flow version changes when the incoming version of the flow changes a Processor Schedule Strategy from CRON driven to Timer driven or vice versa.

Workaround:

To work around this issue, only configure the components in the flow with a Timer driven or Event driven Scheduling Strategy. Using Timer or Event driven scheduling does not exhibit this known issue since Timer driven is the default Scheduling Strategy and Event driven does not attempt to interpret the Run Schedule.

Issue: ReportLineageToAtlas may report wrong Hive database name and Kafka topic cluster name

Problem:

If the “Hive connection URL” of HiveConnectionPool Controller Service has parameters other than a database name, ReportLineageToAtlas may report incorrect database name for the Atlas hive_table entities representing lineage from/to PutHiveQL or SelectHiveQL.

Even if there are more than one hostname:port values defined in “Hive connection URL” of HiveConnectionPool, or “Kafka Brokers” of PublishKafka or ConsumeKafka, ReportLineageToAtlas only uses the first hostname to analyze cluster names.

Workaround: To work around this issue, remove parameters from HiveConnectionPool “Hive connection URL” if possible. E.g. "CJD:hive2://hive host:10000/byname". In order to map a cluster name (other than the default cluster name) from hostnames in “Hive connection URLs” or “Kafka Brokers”, define Regular Expressions which match with the first hostname.

Issue: ReportLineageToAtlas may report wrong Hive database name and Kafka topic cluster name

Problem:

If the “Hive connection URL” of HiveConnectionPool Controller Service has parameters other than a database name, ReportLineageToAtlas may report incorrect database name for the Atlas hive_table entities representing lineage from/to PutHiveQL or SelectHiveQL.

Even if there are more than one hostname:port values defined in “Hive connection URL” of HiveConnectionPool, or “Kafka Brokers” of PublishKafka or ConsumeKafka, ReportLineageToAtlas only uses the first hostname to analyze cluster names.

Workaround: To work around this issue, remove parameters from HiveConnectionPool “Hive connection URL” if possible. E.g. "CJD:hive2://hive host:10000/byname". In order to map a cluster name (other than the default cluster name) from hostnames in “Hive connection URLs” or “Kafka Brokers”, define Regular Expressions which match with the first hostname.

Issue: If the total character count of your node names assigned to services exceeds 255 characters, your upgrade fails.

Workaround: There is no workaround for this issue.

Issue: When using SAM's Aggregator processor, you cannot add nested fields to the Select Key field.

Workaround: To work around this issue, create only top level values for Select Key. You can add as many top level Select Key fields as is needed.

Issue: You may be unable to import some topologies from HDF 3.0.x

Problem: When you have a new HDF 3.1.0 installation, you cannot import topologies created in HDF 3.0.x.

Workaround: To work around this issue, you can upgrade your existing version of HDF to HDF 3.1.0.

Issue: When you have upgraded HDF services on your HDP cluster, the NiFi version number displayed in Ambari does not change from NiFi 1.2.0 to NiFi 1.5.0.

Workaround: After performing the upgrade scenario for HDF services on an HDP cluster as documented in the Ambari Managed HDF Upgrade documentation, disregard the NiFi version displayed in Ambari. NiFi has been successfully upgraded.

Issue: Unable to load native library.

Associated error message: You may encounter an error message similar to one of the following:

Problem: Native libraries can only be loaded into the Java runtime by a single ClassLoader. Once a ClassLoader loads a native library, subsequent attempts to load that same native library by a different ClassLoader will fail. If multiple components in NiFi attempt to load a native library, it will fail to do so and the components may fail to execute if it attempts to use those native libraries. Whether those components fail ultimately depend on the order they are loaded and executed which is not guaranteed by NiFi. This will occur most frequently with components that leverage the native Hadoop library. These components include but are not limited to:

Workaround: This issue is most frequently encountered using an HDFS Processor with a Compression Codec that Hadoop leverages native libraries to implement. In this scenario, the dataflow can be updated to utilize a CompressContent Processor before/after the HDFS Processor to apply the desired compression. The CompressContent does not leverage native libraries and will not be susceptible to this known issue.

Issue: When performing an Ambari managed rolling upgrade, you may encounter an inaccurate warning message indicating that Storm topologies need to be stopped.

Associated error message: Storm topologies need to stop.

Workaround: You may safely ignore this error message. Storm topologies do not need to be stopped before performing a rolling upgrade.

Issue: NiFi/Knox integration does not support HA.

In NiFiHaDispatch, executeRequest is overridden and does not have the try/catch block in DefaultHaDispatch's executeRequest method which is used to catch exceptions and begin the fail over process.

Workaround: There is no workaround for this issue.

Issue: Knox HA failover for NiFi is not supported.

Workaround: There is no workaround for this issue.

Summary: Solr bolt does not run in a Kerberos environment.

Associated error message: The following is an example:

[ERROR] Request to collection hadoop_logs failed due to (401) org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error from server at http:[...] Error 401 Authentication required

Workaround: None at this time.