Hi @Timothy Spann Thanks for the immediate response. I will be describing in details the issue I am facing. Currently i have setup a Nifi cluster of 4 nodes, this results in all Nifi Processors running in any of the node in a non-deterministic manner. At the start when EMQTT servers have been subscribed using ConsumeMQTT processor using a particular client Id, this results in EMQTT broker node maintaining this client id (consumer1) connecting from node1 (lets assume). After some time, the same processor switches to node2, this leads to EMQTT broker again registering client id (consumer1) connecting from node2. This leads EMQTT to kick out both the clients as they have conflicting information (node1 and node2 having the same client Id) We tried to solve this by setting the processor to run only on Primary Node, this solves the problem for some time until the Primary Nodes switches to a different node, Post which again the conflict issue starts occurring. We are looking for a solution where the ConsumeMQTT processor would dynamically generate the client id every time on a new connection, this would solve the issue of conflicting clients Ids. (for this we were to set the client id to 'empty string', which we assumed ConsumeMQTT would generate dynamically) Please suggest if we can do any alternative approach for this problem. Although forking the ConsumeMQTT process and making a custom version of it would solve the problem, but we were looking for a solution from the Apache Nifi Product wise. I have attached the connection error we are receiving from the EMQTT. Technically speaking, although it says there is connection error, it is able to connect randomly, but it drastically replicates the messages when in a Nifi Cluster mode. (e.g. We published 10 messages, we got around 60 messages at the consumer). When we changed it to a Nifi Standalone mode ( for the same 10 messages, we got 10 messages at the consumer). ... View more