nifi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Koji Kawamura <>
Subject Re: SSLHandshake Exception from Site-to-Site
Date Thu, 07 Mar 2019 01:44:15 GMT
Hi Nadeem,

This property is used for how S2S server introduces itself to S2S
clients for further network communication.
For example, let's say if the server has 2 ip addresses, private and
public, and the public ip is bounded to a fqdn. hostnames for the
server would be:
- private:
- public:
In that case, the property should be set as

I don't have much experience with Kubernetes (K8s), but usually some
naming and port mapping configurations should be used in order to
expose such public API endpoint in an environment like K8s or
Or use service name to make communication between containers successful.

Furthermore, if you need to expose your NiFi S2S running on K8s so
that S2S client running outside of the K8s cluster can communicate,
then I think you will need to deploy a load-balancer.

> [Site-to-Site Worker Thread-235] o.a.nifi.remote.SocketRemoteSiteListener
> org.apache.nifi.remote.SocketRemoteSiteListener$1$1@74dd1923 Connection URL
> is nifi://*

This log is written by S2S worker thread, that is working at the S2S
server accepting incoming connections.
The Connection URL here represents the associated peer, which is a S2S
client connecting to the server.
That's why it shows internal hostname and random port.


On Thu, Mar 7, 2019 at 12:14 AM Mohammed Nadeem <> wrote:
> Thank you so much Koji for replying,
> This issue of SSL Handshake we see is for a single node cluster instance,
> where our NiFi application has been deployed in Kubernetes container, Here
> is the below configuration we did for site-to-site in file
> for a single cluster node.
> # Site to Site properties
> nifi.remote.input.socket.port=9443
> nifi.remote.input.http.enabled=false
> I was trying to understand how site-to-site works internally by going
> through source code and also debugging parallel to how it does
> communication. I found couple of observations from my analysis
> 1. First off, I believe when you give same hostname as nifi application
> running in a container for site-to-site in for single
> cluster node, the internal site-to-site java code doesn't get the hostname
> of the self node when asked for cluster nodes information (NodeInFormant),
> instead it gives some other private ip hostname. In the logs we see -* DEBUG
> [Site-to-Site Worker Thread-235] o.a.nifi.remote.SocketRemoteSiteListener
> org.apache.nifi.remote.SocketRemoteSiteListener$1$1@74dd1923 Connection URL
> is nifi://*
> From above debug log, I see the internal java code is not recognizing that
> its a docker container instead its trying to connect with unknown hostname
> name with random port. I believe due to incapable of recognizing its a
> container instead returning some kubernetes node ip address, its throwing
> the ssl handshake error
> Interesting thing is, When the port 'nifi.remote.input.socket.port' (9443)
> was reachable at a container level, we see the above SSLHandshake error with
> site-to-site worker thread trying to hit different hostname from the point-1
> I mentioned above, when we blocked this port from the container, the
> SSLHandshake error went away, we no longer see when blocking the port from
> 'nifi.remote.input.socket.port' in properties. I'm not sure if this make
> sense but I want to understand how site-to-site works internally in detail.
> If above of my observations are incorrect or something needs to be done,
> please help me in understanding. Please Bryan, Pierre, Marks, Koji or any
> NiFi experts pleas help me understanding this. I have gone through almost
> all blogs and etc.
> Please suggest the solution,
> Thanks,
> Nadeem
> --
> Sent from:

View raw message