You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by "Pavel Moravec (Commented) (JIRA)" <ji...@apache.org> on 2012/01/20 10:18:39 UTC

[jira] [Commented] (QPID-3575) session exceptions do not properly close connections, causing connections leak

    [ https://issues.apache.org/jira/browse/QPID-3575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13189703#comment-13189703 ] 

Pavel Moravec commented on QPID-3575:
-------------------------------------

The patch proposed by Alex in QPID-3234 resolves this JIRA halfly: session object is closed and can be re-created smoothly, but invoking connection.close(); raises exception "Error closing session: org.apache.qpid.AMQException: ch=0 id=0 ExecutionException(errorCode=RESOURCE_LIMIT_EXCEEDED .." and the underlying TCP connection isn't closed.
                
> session exceptions do not properly close connections, causing connections leak
> ------------------------------------------------------------------------------
>
>                 Key: QPID-3575
>                 URL: https://issues.apache.org/jira/browse/QPID-3575
>             Project: Qpid
>          Issue Type: Bug
>          Components: Java Client
>    Affects Versions: 0.10, 0.12, 0.13
>            Reporter: Pavel Moravec
>            Priority: Critical
>         Attachments: QueueFull.java, TestQpidLeak.java
>
>
> Description of problem:
> There is a connection leak as described below.
> A session level exception is designed to close the underlying connection (along with the other sessions). However this is not true as there are at least two scenarios leading in an orphaned connection that can't be further used(*) (along with any session created on it) but it can't be deleted.
> (*) Once an exception is raised, the connection, a session created on it or a producer/consumer created on such a session can't be effectivelly used - any usage ends up in an exception like the connection would be closed.
> ---------------
> First scenario:
> If qpid.declare_queues is set to false and an attempt to subscribe to a non-existing queue is made, an exception is raised and subsequent connection.close() method does not close the TCP connection at all.
> Steps to Reproduce:
> 1. Start a fresh qpid broker with auth=no - make sure no
> "some.unreal.destination" queue is there
> 2. Run attached Java program TestQpidLeak.java
> 3. Do _not_ terminate it when a prompt appears in it
> 4. Run qpid-stat -c in parallel
> Actual results:
> qpid-stat shows 10 connections made by the client and despite connection.close() has been called for each of them.
> Expected results:
> qpid-stat does not show the 10 connections.
> ---------------
> Second scenario:
> Try to send 500 messages into a queue with max-queue-count 10. Again, a session exception is raised, connection is attempted to be closed but with no impact.
> Steps to Reproduce:
> 1. Start a fresh qpid broker with auth=no
> 2. qpid-config add queue testQueue --max-queue-count 10
> 3. Run attached Java program QueueFull.java
> 3. Do _not_ terminate it when a prompt appears in it
> 4. Run qpid-stat -c in parallel
> Actual results:
> qpid-stat shows 1 connection made by the client and despite connection.close() has been called.
> Sometimes (using a slightly different Java program that I can't revoke) the invoking of connection.close() method in finally-block does not terminate.
> Expected results:
> qpid-stat does not show the connection from the client.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org