[rabbitmq-discuss] Socket leak in java client library

[Iain Hull]

Sorry I forgot to mention that this bug can cause java clients which
retry connections in the background to run out of open files/handles and
crash the JVM.

 

From: rabbitmq-discuss-bounces at lists.rabbitmq.com
[mailto:rabbitmq-discuss-bounces at lists.rabbitmq.com] On Behalf Of Iain
Hull
Sent: 28 November 2011 12:26
To: rabbitmq-discuss at lists.rabbitmq.com
Subject: [rabbitmq-discuss] Socket leak in java client library

 

Hi,

 

I have discovered a socket leak in the java client library when you try
to connect to a non-existent host.  I discovered this in version 2.5.1
but it also affects all versions after this.  

 

The problem occurs when
com.rabbitmq.client.ConnectionFactory.newConnection() is called with a
bad hostname. In this case
com.rabbitmq.client.ConnectionFactory.createFrameHandler(Address)
creates a socket that is never returned or closed because of an
IOException.

 

I have attached a simple java file, SocketLeak.java, file that
reproduces the problem, simply run it and monitor the number of open
files (or handles on windows).

 

I have applied a fix for this and tested it on version 2.5.1 and to the
latest from the default branch in the hg repo.  The patch is attached,
SocketLeakFix.diff.  All the client tests pass, however there are
currently 3 functional tests failing for me on the default branch both
with and without my changes.

 

There appears to be a similar leak in
com.rabbitmq.client.ConnectionFactory.newConnection(Address[]) where
connections are created and never returned or closed when an IOException
occurs, however I have not been able to reproduce a leak in this code,
but have attached a speculative fix anyway.

 

I understand that you do not have a public bug tracker that I can use to
monitor this issue, but can you give me a bug number to track?

 

Regards,

Iain.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20111128/dfb8d779/attachment.htm>