Known issues

A summary of known issues for this version of Cloudera Stream Processing.

SMM does not trigger alert immediately when SRM goes down

Problem: If the SRM cluster goes down, SMM might take 15 minutes to send the alert through email or display the alert on the UI.

First set of produced messages are not counted in total messages displayed in SMM

Problem: You might notice minor discrepancy in the ‘BytesIn’, ‘BytesOut’, and ‘MessagesIn’ timeline metrics for the newly created topics and in the 'outMessagesCount’ timeline metric for the producers when the time period is selected all the way up to topic initialisation or usage time. The discrepancy in the metrics may be off by the first minute’s measurement.

The discrepancy happens due to a delay in the initialisation of metrics in the Kafka Brokers and by default the Metric reporter is configured to report the metrics once in a minute to the external systems post topic initialisation or usage.

Workaround: The graphs in the topic and producer profile page, however, reflect the true state of the metrics the way they are recorded.

SRM does not sync re-created source topics until the offsets have caught up with target topic

Problem: Messages written to topics that were deleted and re-created are not replicated until the source topic reaches the same offset as the target topic. For example, if at the time of deletion and re-creation there are a 100 messages on the source and target clusters, new messages will only get replicated once the re-created source topic has 100 messages. This leads to messages being lost.

Workaround: N/A.

SRM may automatically re-create deleted topics

Problem: If auto.create.topics.enable is enabled, deleted topics are automatically recreated on source clusters.

Workaround: Prior to deletion, remove the topic from the topic allowlist (whitelist) with the srm-control tool. This prevents topics from being re-created.

srm-control topics --source [SOURCE_CLUSTER] --target [TARGET_CLUSTER] --remove [TOPIC1][TOPIC2]

SRM cannot replicate Sentry authorization rules from one Kafka cluster to another

Problem:When Sentry contains Kafka authorization policies for any ConsumerGroup resource, SRM cannot replicate authorization rules from one Kafka cluster to another in environments where Sentry is enabled. This is due to a Kafka resource conversion error in Sentry. For more information regarding the underlying Sentry issue, see SENTRY-2535 and the Kafka known issues in CDH Known Issues.

Workaround: Disable authorization policy synchronization in SRM. This can be achieved by setting the sync.topic.acls.enabled property to false.

SMM throws error if Service Monitor is not on CM host

Problem: If the Cloudera Manager Service Monitor and Cloudera Manager Server are deployed on different hosts, SMM is unable to fetch metrics correctly. As a result, historic data for consumer offsets and lag are not displayed, only the latest data is available.

You receive the following error message and cause in the streams-messaging-manager.log:

ERROR
com.hortonworks.smm.kafka.services.clients.ConsumerGroupManagementTask: Error while fetching consumer group information.
Caused by: org.apache.avro.AvroRemoteException: java.net.ConnectException: Connection refused (Connection refused)

Workaround: No workaround.

Cannot read property 'indexOf' thrown when ETELatencyMetrics is disabled

Problem: If latency metrics is disabled and you click the latency tab on the Topic Profile page in the SMM UI, then the following error appears:

Cannot read property ‘indexOf’ of null.

Workaround: Latency metrics should be configured and enabled before you view it on the SMM UI.