Hello @thoufeeq1218, We understand that you have configured spark.blockManager.driver.port and spark.blockManager.port, but Spark may still attempt to use random ports due to the following reasons: - Why is Spark using random ports? Spark uses additional ports beyond BlockManager for communication between the driver and executors. The random port seen (59698) is from the ephemeral port range (1024–65535) and could be assigned due to: spark.driver.port (default: random) spark.executor.port (default: random) - How to restrict Spark to specific ports? Explicitly set spark.driver.port to ensure the driver listens on a fixed port: --conf spark.driver.port=21800 Ensure spark.blockManager.port is available If 21700 is occupied, Spark will fall back to a random port. - Understanding spark.port.maxRetries If spark.port.maxRetries > 0 (default: 16), Spark will try additional ports within the ephemeral range. If spark.port.maxRetries = 0, Spark will fail immediately if the specified port is unavailable. - Executors and Dynamic Ports Executors start/stop dynamically and may request random ports. If you must prevent Spark from using random ephemeral ports, use the following settings: --conf spark.driver.port=21800 --conf spark.blockManager.driver.port=21750 --conf spark.blockManager.port=21700 --conf spark.executor.port=21810 --conf spark.port.maxRetries=0 These settings can be applied at the job level or in the Spark configuration file. Note: If a port is already used by a running job, a new job may fail due to a port conflict. If you found this response assisted with your query, please take a moment to log in and click on KUDOS 🙂 & ”Accept as Solution" below this post. Thank you. ... View more

Hello @Israr , You should verify that both Kafka and Kafka Connect are running and in a healthy state. Thank you.    ... View more

Hello @BrianChan, We should check the consumer offset topic (__consumer_offsets) health using the Kafka describe command in such issues.  And check min.insync.replicas setting of this topic in describe command output. It should be less than or qual to topic ISR. For example: If the topic has replication factor 3 then min ISR should be 2 or 1 for failover.  If you found this response assisted with your query, please take a moment to log in and click on KUDOS 🙂 & ”Accept as Solution" below this post. Thank you. ... View more

Hello @hegdemahendra, 1) Please refer to the following article to connect Kafka from Nifi:  https://community.cloudera.com/t5/Community-Articles/Integrating-Apache-NiFi-and-Apache-Kafka/ta-p/247433 2) Also, to isolate the issue you can try to connect Kafka from the same settings from nifi node using the Kafka command Please let us know if you still have any questions regarding the same or facing any issues. We will be happy to assist you with it.  If you found this response assisted with your query, please take a moment to log in and click on KUDOS 🙂 & ”Accept as Solution" below this post. Thank you. ... View more

Hello @StanislavJ , The Linux kernel parameter, vm.swappiness, is a value from 0-100 that controls the swapping of application data (as anonymous pages) from physical memory to virtual memory on disk. The higher the value, the more aggressively inactive processes are swapped out from physical memory. The lower the value, the less they are swapped, forcing filesystem buffers to be emptied. On most systems, vm.swappiness is set to 60 by default. This is not suitable for Hadoop clusters because processes are sometimes swapped even when enough memory is available. This can cause lengthy garbage collection pauses for important system daemons, affecting stability and performance. Cloudera recommends that you set vm.swappiness to a value between 1 and 10, preferably 1, for minimum swapping on systems where the RHEL kernel is 2.6.32-642.el6 or higher. To view your current setting for vm.swappiness, run: #cat /proc/sys/vm/swappiness To set vm.swappiness to 1, run: #sudo sysctl -w vm.swappiness=1 Also, To give an overview, swapping alerts are generated in Cloudera Manager when host swapping or role process swap usage exceeds a defined threshold. The warning threshold of "500 MiB" will mean that any swap usage beyond this on a given host will generate an alert and critical if set to any would generate an alert even if a small amount of swapping occurs. The swap memory usage threshold value can be set at the "host" level or at the "process/service" level. >> To set the threshold at the process level settings can be done as follows: From CM UI >> Clusters >> yarn >> Configuration >> search for "Process Swap Memory Thresholds" >> (For resource manager) Warning and Critical >> Select Specify >> Specify value here (You can set the values in Bytes/KB/MB/GB) >> Save changes You can increase the value and then further suggest you monitor the cluster for the swap usage and adjust the values accordingly. If you found this response assisted with your query, please take a moment to log in and click on KUDOS 🙂 & ”Accept as Solution" below this post. Thank you, Babasaheb Jagtap ... View more