qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pavel Moravec (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (QPID-3575) connection leak after an attempt to subscribe to nonexisting queue
Date Wed, 02 Nov 2011 15:47:32 GMT

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

Pavel Moravec commented on QPID-3575:

Root cause of the bug:

1) Due to the nonexisting queue disallowed to be created, exception
"javax.jms.JMSException: Error registering consumer:
org.apache.qpid.AMQException .. Bind failed. No such queue: .." is thrown and
managed in AMQSession_0_10::setCurrentException and
AMQConnection::exceptionReceived is called.

2) hardError called to the cause returns true, causing 
closer = (!_closed.getAndSet(true)) || closer;
is called. This has two consequences: a) _closed is set to true and b)
closeAllSessions is called later on.

3) Both a) and b) (even independently) sets _closed to true at the end.

4) When connection.close() method is called, close(List<AMQSession> sessions,
long timeout) method evaluates the main if-statement to false end directly
finishes. While we need doClose(sessions, timeout); to be called.

QPID-3289 and  QPID-3234 refer to the core problem of session exceptions (which are soft
errors as per the spec) are still treated as hard errors.
> connection leak after an attempt to subscribe to nonexisting queue
> ------------------------------------------------------------------
>                 Key: QPID-3575
>                 URL: https://issues.apache.org/jira/browse/QPID-3575
>             Project: Qpid
>          Issue Type: Bug
>          Components: Java Client
>    Affects Versions: 0.14
>            Reporter: Pavel Moravec
>         Attachments: TestQpidLeak.java
> Description of problem:
> If qpid.declare_queues is set to false and an attempt to subscribe to a non-existing
queue is made, connection.close() method does not close the TCP connection. This causes a
TCP connection leak for case when heartbeats are set.
> How reproducible:
> 100%
> 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
> 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.

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

View raw message