Support Questions

Find answers, ask questions, and share your expertise
Announcements
Celebrating as our community reaches 100,000 members! Thank you!

Meet Failed to replicate request GET /nifi-api/flow/current-user with SSL NIFI and no SSL LDAP

avatar
Expert Contributor

Hello,

My new CDF cluster include 3 nifi nodes. I enable SSL in nifi . but there is not SSL on LDAP. I don't what is the reason got the error:  

2019-11-01 13:42:28,489 WARN org.apache.nifi.cluster.coordination.http.replication.ThreadPoolRequestReplicator: Failed to replicate request GET /nifi-api/flow/current-user to xx-cmf02.beta1.nn/10.202.252.92:8080 due to java.net.ConnectException: Failed to connect to xx-cmf02.beta1.nn/10.202.252.92:8080
        at okhttp3.internal.connection.RealConnection.connectSocket(RealConnection.java:242)
        at okhttp3.internal.connection.RealConnection.connect(RealConnection.java:160)
......
Caused by: java.net.ConnectException: Connection refused (Connection refused)
        at java.net.PlainSocketImpl.socketConnect(Native Method)

The behavior is very strange that one node access else node 8080 port but i did not to config it.

So, what did i miss it?

Thank you for your advice first.

Paul

1 ACCEPTED SOLUTION

avatar
Super Mentor

@Paul Yang 

 

NiFi stores information about the nodes that were connected to the cluster in its local state directory on each node.  Prior to securing your NiFi cluster, all your nodes were running unsecure on port 8080 and that information was retained in local state.  After securing your NiFi, you node were now identified using the same hostnames, but different secure port.  So Now your cluster is expecting to see 8080 and new secure port nodes in the cluster.  

The easiest way to resolve this issue is to simply stop your NiFi nodes, remove the NiFi local state directory contents on each of your node, and then start your nodes.   

Now if this is not a new installation and you are concerned about losing locally stored NiFi component state (like listFile stores state in what was already listed), then you can get around this issue by changing the configured cluster protocol port (found in the nifi.properties file) to a different unused port on your servers.  You will then be able to access the UI were you will see your new nodes plus the unexpected ones on the old ports which you can manually remove from the "cluster" UI accessible from the NiFi Global menu in the upper right corner.

 

This is a known issue which is being addressed.  But it only happens when you change ports (which commonly only happens when you are switching from unsecure to secure.

 

Hope this helps,

Matt

View solution in original post

2 REPLIES 2

avatar
Super Mentor

@Paul Yang 

 

NiFi stores information about the nodes that were connected to the cluster in its local state directory on each node.  Prior to securing your NiFi cluster, all your nodes were running unsecure on port 8080 and that information was retained in local state.  After securing your NiFi, you node were now identified using the same hostnames, but different secure port.  So Now your cluster is expecting to see 8080 and new secure port nodes in the cluster.  

The easiest way to resolve this issue is to simply stop your NiFi nodes, remove the NiFi local state directory contents on each of your node, and then start your nodes.   

Now if this is not a new installation and you are concerned about losing locally stored NiFi component state (like listFile stores state in what was already listed), then you can get around this issue by changing the configured cluster protocol port (found in the nifi.properties file) to a different unused port on your servers.  You will then be able to access the UI were you will see your new nodes plus the unexpected ones on the old ports which you can manually remove from the "cluster" UI accessible from the NiFi Global menu in the upper right corner.

 

This is a known issue which is being addressed.  But it only happens when you change ports (which commonly only happens when you are switching from unsecure to secure.

 

Hope this helps,

Matt

avatar
Expert Contributor

@Matt

Thanks,

I solved this issue when i follow your point.

Paul