Should a user configure the stomp gem to connect to a broker over
ssl, when the broker is not configured with ssl, then we leak a
TCPSocket due to the timeout logic. Such a misconfiguration should
be rare but we do see it in the field -
http://tickets.puppetlabs.com/browse/MCO-196
What we see is the underlying TCPSocket is created for the connection
and then passed into an OpenSSL::SSL::SSLSocket, which then starts
the SSL handshake. As ActiveMQ was not expecting an SSL handshake
it simply doesn't respond, and so we block in ssl.connect. Once
the timeout is reached ssl.connect is interrupted, but this leaves
the ssl socket in an indeterminate state, and the TCPSocket is never
cleaned up.
This commit changes the behaviour to check if ssl has a value,
indicating that the TCPSocket did actually connect and then was
wrapped in an OpenSSL::SSL::SSLSocket, and then calls #close on the
OpenSSL::SSL::SSLSocket so we don't leak the TCPSocket.
Should a user configure the stomp gem to connect to a broker over ssl, when the broker is not configured with ssl, then we leak a TCPSocket due to the timeout logic. Such a misconfiguration should be rare but we do see it in the field - http://tickets.puppetlabs.com/browse/MCO-196
What we see is the underlying TCPSocket is created for the connection and then passed into an OpenSSL::SSL::SSLSocket, which then starts the SSL handshake. As ActiveMQ was not expecting an SSL handshake it simply doesn't respond, and so we block in ssl.connect. Once the timeout is reached ssl.connect is interrupted, but this leaves the ssl socket in an indeterminate state, and the TCPSocket is never cleaned up.
This commit changes the behaviour to check if ssl has a value, indicating that the TCPSocket did actually connect and then was wrapped in an OpenSSL::SSL::SSLSocket, and then calls #close on the OpenSSL::SSL::SSLSocket so we don't leak the TCPSocket.