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 (Created) (JIRA)" <ji...@apache.org> on 2011/11/02 15:37:32 UTC
[jira] [Created] (QPID-3575) connection leak after an attempt to
subscribe to nonexisting queue
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
[jira] [Updated] (QPID-3575) session exceptions do not properly
close connections, causing connections leak
Posted by "Rajith Attapattu (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/QPID-3575?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Rajith Attapattu updated QPID-3575:
-----------------------------------
Fix Version/s: 0.17
> 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
> Labels: exception-handling
> Fix For: 0.17
>
> Attachments: QueueFull.java, TestQpidLeak.java, jira-3575_workaround-patch.patch
>
>
> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
[jira] [Commented] (QPID-3575) session exceptions do not properly
close connections, causing connections leak
Posted by "Keith Wall (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/QPID-3575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13147550#comment-13147550 ]
Keith Wall commented on QPID-3575:
----------------------------------
Alex and I spent some time looking at this issue. We could not find a clean manner to arrange for the client to close the connection without introducing new race conditions and requiring some XA re-work. It seems to us that the correct way to resolve this problem is to address QPID-3289.
> 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
[jira] [Commented] (QPID-3575) connection leak after an attempt to
subscribe to nonexisting queue
Posted by "Pavel Moravec (Commented) (JIRA)" <ji...@apache.org>.
[ 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
[jira] [Issue Comment Edited] (QPID-3575) session exceptions do not
properly close connections, causing connections leak
Posted by "Pavel Moravec (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/QPID-3575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13268213#comment-13268213 ]
Pavel Moravec edited comment on QPID-3575 at 5/4/12 9:15 AM:
-------------------------------------------------------------
A dirty workaround patch that allows (under some further described changes in client's code - see below) proper closure of connection.
>From black-box perspective, patch + client's code changes resolves the issue but I don't recommend the patch content to be put into upstream. As it 1) rather fixes already existing problem than prevents it (moreover doing so by a nasty way, changing privateness of a method) and 2) requires some changes in client's source code.
-------
Code changes in client's application required:
-------
Once a session exception is raised and caught in application code, the session object needs to be re-created as follows:
import org.apache.qpid.client.*; // required to be added due to session closure
..
try {
// do something that can raise a session exception - like sending a message to some full queue
}
catch (javax.jms.JMSException exp) {
..
((AMQSession) session).close(-1,false); // the session needs to be closed in this way; keep in mind this instance of the method (with two parameters) is not in JMS specification neither in usual qpid java client library
session=connection.createSession( .. );
..
}
If all sessions are re-created as above (plus re-creating producers and consumers as well), then:
(*) no session or connection is stuck and no session or connection leak shall occur
(*) the session shall be usable without a problem
(*) the underlying TCP connection is operating all the time properly
(*) other sessions established in parallel on the same connection are unaffected
was (Author: pmoravec):
A dirty workaround patch that allows (under some further described changes in client's code - see below) proper closure of connection.
>From black-box perspective, patch + client's code changes resolves the issue but I don't recommend the patch content to be put into upstream. As it 1) rather fixes already existing problem than prevents it (moreover doing so by a nasty way, changing privateness of a method) and 2) requires some changes in client's source code.
-------
Code changes in client's application required:
-------
Once a session exception is raised and caught in application code, the session object needs to be re-created as follows:
import org.apache.qpid.client.*; // required to be added due to session closure
..
try {
// do something that can raise a session exception - like sending a message to some full queue
}
catch (javax.jms.JMSException exp) {
..
((AMQSession) session).close(-1,false); // the session needs to be closed in this way; keep in mind this instance of the method (with two parameters) is not in JMS specification neither in usual qpid java client library
session=connection.createSession( .. );
..
}
If all sessions are re-created as above (plus re-creating producers and consumers as well), then:
(*) no session or connection is stuck and no session or connection leak shall occur
(*) the session shall be usable without a problem
(*) the underlying TCP connection is operating all the time properly
(*) other sessions established in parallel on the same connection are unaffected
> 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
> Labels: exception-handling
> Attachments: QueueFull.java, TestQpidLeak.java, jira-3575_workaround-patch.patch
>
>
> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
[jira] [Issue Comment Edited] (QPID-3575) session exceptions do not
properly close connections, causing connections leak
Posted by "Pavel Moravec (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/QPID-3575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13268213#comment-13268213 ]
Pavel Moravec edited comment on QPID-3575 at 5/4/12 9:12 AM:
-------------------------------------------------------------
A dirty workaround patch that allows (under some further described changes in client's code - see below) proper closure of connection.
>From black-box perspective, patch + client's code changes resolves the issue but I don't recommend the patch content to be put into upstream. As it 1) rather fixes already existing problem than prevents it (moreover doing so by a nasty way, changing privateness of a method) and 2) requires some changes in client's source code.
-------
Code changes in client's application required:
-------
Once a session exception is raised and caught in application code, the session object needs to be re-created as follows:
import org.apache.qpid.client.*; // required to be added due to session closure
..
try {
// do something that can raise a session exception - like sending a message to some full queue
}
catch (javax.jms.JMSException exp) {
..
((AMQSession) session).close(-1,false); // the session needs to be closed in this way; keep in mind this instance of the method (with two parameters) is not in JMS specification neither in usual qpid java client library
session=connection.createSession( .. );
..
}
If all sessions are re-created as above (plus re-creating producers and consumers as well), then:
(*) no session or connection is stuck and no session or connection leak shall occur
(*) the session shall be usable without a problem
(*) the underlying TCP connection is operating all the time properly
(*) other sessions established in parallel on the same connection are unaffected
was (Author: pmoravec):
A dirty workaround patch that allows (under some further described changes in client's code - see below) proper closure of connection.
>From black-box perspective, patch + client's code changes resolves the issue but I don't recommend the patch content to be put into upstream. As it 1) rather fixes already existing problem than prevents it (moreover doing so by a nasty way, changing privateness of a method) and 2) requires some changes in client's source code.
-------
Code changes in client's application required:
-------
Once a session exception is raised and caught in application code, the session object needs to be re-created as follows:
import org.apache.qpid.client.*; // required to be added due to session closure
..
try {
// do something that can raise a session exception - like sending a message to some full queue
}
catch (javax.jms.JMSException exp) {
..
((AMQSession) session).close(-1,false); // the session needs to be closed in this way; keep in mind this instance of the method (with two parameters) is not in JMS specification neither in usual qpid java client library
session=connection.createSession( .. );
..
}
If all sessions are re-created as above (plus re-creating producers and consumers as well), then:
(*) no session or connection is stuck and no session or connection leak shall occur
(*) the session shall be usable without a problem
(*) the underlying TCP connection is operating all the time properly
(*) other sessions established in parallel on the same connection are unaffected
> 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
> Labels: exception-handling
> Attachments: QueueFull.java, TestQpidLeak.java, jira-3575_workaround-patch.patch
>
>
> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
[jira] [Resolved] (QPID-3575) session exceptions do not properly
close connections, causing connections leak
Posted by "Robbie Gemmell (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/QPID-3575?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Robbie Gemmell resolved QPID-3575.
----------------------------------
Resolution: Fixed
Assignee: Rajith Attapattu
Rajith committed changes to fix this JIRA for 0.18, so assigning and resolving.
> 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
> Assignee: Rajith Attapattu
> Priority: Critical
> Labels: exception-handling
> Fix For: 0.17
>
> Attachments: jira-3575_workaround-patch.patch, 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
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
[jira] [Updated] (QPID-3575) session exceptions do not properly
close connections, causing connections leak
Posted by "Pavel Moravec (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/QPID-3575?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Pavel Moravec updated QPID-3575:
--------------------------------
Attachment: QueueFull.java
Java program for the second replication scenario
> 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.12
> 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
[jira] [Updated] (QPID-3575) session exceptions do not properly
close connections, causing connections leak
Posted by "Keith Wall (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/QPID-3575?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Keith Wall updated QPID-3575:
-----------------------------
Affects Version/s: 0.13
0.10
I've reproduced on release 0-10. I confirm I can see this problem on 0-12 and 0-13.
> 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
[jira] [Assigned] (QPID-3575) session exceptions do not properly
close connections, causing connections leak
Posted by "Keith Wall (Assigned) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/QPID-3575?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Keith Wall reassigned QPID-3575:
--------------------------------
Assignee: (was: Keith Wall)
> 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
[jira] [Issue Comment Edited] (QPID-3575) session exceptions do not
properly close connections, causing connections leak
Posted by "Pavel Moravec (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/QPID-3575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13268213#comment-13268213 ]
Pavel Moravec edited comment on QPID-3575 at 5/4/12 9:18 AM:
-------------------------------------------------------------
A dirty workaround patch that allows (under some further described changes in client's code - see below) proper closure of connection.
>From black-box perspective, patch + client's code changes resolves the issue but I don't recommend the patch content to be put into upstream. As it 1) rather fixes already existing problem than prevents it (moreover doing so by a nasty way, changing privateness of a method) and 2) requires some changes in client's source code.
-------
Code changes in client's application required:
-------
Once a session exception is raised and caught in application code, the session object needs to be re-created as follows:
{quote}
import org.apache.qpid.client.*; // required to be added due to session closure
..
try \{
// do something that can raise a session exception - like sending a message to some full queue
\}
catch (javax.jms.JMSException exp) \{
..
((AMQSession) session).close(-1,false); // the session needs to be closed in this way; keep in mind this instance of the method (with two parameters) is not in JMS specification neither in usual qpid java client library
session=connection.createSession( .. );
..
\}
{quote}
If all sessions are re-created as above (plus re-creating producers and consumers as well), then:
* no session or connection is stuck and no session or connection leak shall occur
* the session shall be usable without a problem
* the underlying TCP connection is operating all the time properly
* other sessions established in parallel on the same connection are unaffected
was (Author: pmoravec):
A dirty workaround patch that allows (under some further described changes in client's code - see below) proper closure of connection.
>From black-box perspective, patch + client's code changes resolves the issue but I don't recommend the patch content to be put into upstream. As it 1) rather fixes already existing problem than prevents it (moreover doing so by a nasty way, changing privateness of a method) and 2) requires some changes in client's source code.
-------
Code changes in client's application required:
-------
Once a session exception is raised and caught in application code, the session object needs to be re-created as follows:
import org.apache.qpid.client.*; // required to be added due to session closure
..
try {
// do something that can raise a session exception - like sending a message to some full queue
}
catch (javax.jms.JMSException exp) {
..
((AMQSession) session).close(-1,false); // the session needs to be closed in this way; keep in mind this instance of the method (with two parameters) is not in JMS specification neither in usual qpid java client library
session=connection.createSession( .. );
..
}
If all sessions are re-created as above (plus re-creating producers and consumers as well), then:
(*) no session or connection is stuck and no session or connection leak shall occur
(*) the session shall be usable without a problem
(*) the underlying TCP connection is operating all the time properly
(*) other sessions established in parallel on the same connection are unaffected
> 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
> Labels: exception-handling
> Attachments: QueueFull.java, TestQpidLeak.java, jira-3575_workaround-patch.patch
>
>
> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
[jira] [Updated] (QPID-3575) session exceptions do not properly
close connections, causing connections leak
Posted by "Pavel Moravec (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/QPID-3575?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Pavel Moravec updated QPID-3575:
--------------------------------
Attachment: jira-3575_workaround-patch.patch
A dirty workaround patch that allows (under some further described changes in client's code - see below) proper closure of connection.
>From black-box perspective, patch + client's code changes resolves the issue but I don't recommend the patch content to be put into upstream. As it 1) rather fixes already existing problem than prevents it (moreover doing so by a nasty way, changing privateness of a method) and 2) requires some changes in client's source code.
-------
Code changes in client's application required:
-------
Once a session exception is raised and caught in application code, the session object needs to be re-created as follows:
import org.apache.qpid.client.*; // required to be added due to session closure
..
try {
// do something that can raise a session exception - like sending a message to some full queue
}
catch (javax.jms.JMSException exp) {
..
((AMQSession) session).close(-1,false); // the session needs to be closed in this way; keep in mind this instance of the method (with two parameters) is not in JMS specification neither in usual qpid java client library
session=connection.createSession( .. );
..
}
If all sessions are re-created as above (plus re-creating producers and consumers as well), then:
(*) no session or connection is stuck and no session or connection leak shall occur
(*) the session shall be usable without a problem
(*) the underlying TCP connection is operating all the time properly
(*) other sessions established in parallel on the same connection are unaffected
> 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
> Labels: exception-handling
> Attachments: QueueFull.java, TestQpidLeak.java, jira-3575_workaround-patch.patch
>
>
> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
[jira] [Issue Comment Edited] (QPID-3575) session exceptions do not
properly close connections, causing connections leak
Posted by "Keith Wall (Issue Comment Edited) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/QPID-3575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13147550#comment-13147550 ]
Keith Wall edited comment on QPID-3575 at 11/10/11 8:29 AM:
------------------------------------------------------------
Alex and I spent some time looking at this issue. We could not find a clean manner to arrange for the client to close the connection without introducing new race conditions and requiring some XA re-work. It seems to us that the correct way to resolve this problem is to address QPID-3234.
was (Author: k-wall):
Alex and I spent some time looking at this issue. We could not find a clean manner to arrange for the client to close the connection without introducing new race conditions and requiring some XA re-work. It seems to us that the correct way to resolve this problem is to address QPID-3289.
> 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
[jira] [Issue Comment Edited] (QPID-3575) session exceptions do not
properly close connections, causing connections leak
Posted by "Pavel Moravec (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/QPID-3575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13268213#comment-13268213 ]
Pavel Moravec edited comment on QPID-3575 at 5/4/12 9:19 AM:
-------------------------------------------------------------
A dirty workaround patch (jira-3575_workaround-patch.patch) that allows (under some further described changes in client's code - see below) proper closure of connection.
>From black-box perspective, patch + client's code changes resolves the issue but I don't recommend the patch content to be put into upstream. As it 1) rather fixes already existing problem than prevents it (moreover doing so by a nasty way, changing privateness of a method) and 2) requires some changes in client's source code.
-------
Code changes in client's application required:
-------
Once a session exception is raised and caught in application code, the session object needs to be re-created as follows:
{quote}
import org.apache.qpid.client.*; // required to be added due to session closure
..
try \{
// do something that can raise a session exception - like sending a message to some full queue
\}
catch (javax.jms.JMSException exp) \{
..
((AMQSession) session).close(-1,false); // the session needs to be closed in this way; keep in mind this instance of the method (with two parameters) is not in JMS specification neither in usual qpid java client library
session=connection.createSession( .. );
..
\}
{quote}
If all sessions are re-created as above (plus re-creating producers and consumers as well), then:
* no session or connection is stuck and no session or connection leak shall occur
* the session shall be usable without a problem
* the underlying TCP connection is operating all the time properly
* other sessions established in parallel on the same connection are unaffected
was (Author: pmoravec):
A dirty workaround patch that allows (under some further described changes in client's code - see below) proper closure of connection.
>From black-box perspective, patch + client's code changes resolves the issue but I don't recommend the patch content to be put into upstream. As it 1) rather fixes already existing problem than prevents it (moreover doing so by a nasty way, changing privateness of a method) and 2) requires some changes in client's source code.
-------
Code changes in client's application required:
-------
Once a session exception is raised and caught in application code, the session object needs to be re-created as follows:
{quote}
import org.apache.qpid.client.*; // required to be added due to session closure
..
try \{
// do something that can raise a session exception - like sending a message to some full queue
\}
catch (javax.jms.JMSException exp) \{
..
((AMQSession) session).close(-1,false); // the session needs to be closed in this way; keep in mind this instance of the method (with two parameters) is not in JMS specification neither in usual qpid java client library
session=connection.createSession( .. );
..
\}
{quote}
If all sessions are re-created as above (plus re-creating producers and consumers as well), then:
* no session or connection is stuck and no session or connection leak shall occur
* the session shall be usable without a problem
* the underlying TCP connection is operating all the time properly
* other sessions established in parallel on the same connection are unaffected
> 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
> Labels: exception-handling
> Attachments: QueueFull.java, TestQpidLeak.java, jira-3575_workaround-patch.patch
>
>
> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
[jira] [Issue Comment Edited] (QPID-3575) session exceptions do not
properly close connections, causing connections leak
Posted by "Pavel Moravec (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/QPID-3575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13268213#comment-13268213 ]
Pavel Moravec edited comment on QPID-3575 at 5/4/12 11:13 AM:
--------------------------------------------------------------
A dirty workaround patch (jira-3575_workaround-patch.patch) that allows (under some further described changes in client's code - see below) proper closure of connection. The patch includes / is based on the patch proposed in https://issues.apache.org/jira/browse/QPID-3234.
>From black-box perspective, patch + client's code changes resolves the issue but I don't recommend the patch content to be put into upstream. As it 1) rather fixes already existing problem than prevents it (moreover doing so by a nasty way, changing privateness of a method) and 2) requires some changes in client's source code.
-------
Code changes in client's application required:
-------
Once a session exception is raised and caught in application code, the session object needs to be re-created as follows:
{quote}
import org.apache.qpid.client.*; // required to be added due to session closure
..
try \{
// do something that can raise a session exception - like sending a message to some full queue
\}
catch (javax.jms.JMSException exp) \{
..
((AMQSession) session).close(-1,false); // the session needs to be closed in this way; keep in mind this instance of the method (with two parameters) is not in JMS specification neither in usual qpid java client library
session=connection.createSession( .. );
..
\}
{quote}
If all sessions are re-created as above (plus re-creating producers and consumers as well), then:
* no session or connection is stuck and no session or connection leak shall occur
* the session shall be usable without a problem
* the underlying TCP connection is operating all the time properly
* other sessions established in parallel on the same connection are unaffected
was (Author: pmoravec):
A dirty workaround patch (jira-3575_workaround-patch.patch) that allows (under some further described changes in client's code - see below) proper closure of connection.
>From black-box perspective, patch + client's code changes resolves the issue but I don't recommend the patch content to be put into upstream. As it 1) rather fixes already existing problem than prevents it (moreover doing so by a nasty way, changing privateness of a method) and 2) requires some changes in client's source code.
-------
Code changes in client's application required:
-------
Once a session exception is raised and caught in application code, the session object needs to be re-created as follows:
{quote}
import org.apache.qpid.client.*; // required to be added due to session closure
..
try \{
// do something that can raise a session exception - like sending a message to some full queue
\}
catch (javax.jms.JMSException exp) \{
..
((AMQSession) session).close(-1,false); // the session needs to be closed in this way; keep in mind this instance of the method (with two parameters) is not in JMS specification neither in usual qpid java client library
session=connection.createSession( .. );
..
\}
{quote}
If all sessions are re-created as above (plus re-creating producers and consumers as well), then:
* no session or connection is stuck and no session or connection leak shall occur
* the session shall be usable without a problem
* the underlying TCP connection is operating all the time properly
* other sessions established in parallel on the same connection are unaffected
> 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
> Labels: exception-handling
> Attachments: QueueFull.java, TestQpidLeak.java, jira-3575_workaround-patch.patch
>
>
> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
[jira] [Assigned] (QPID-3575) session exceptions do not properly
close connections, causing connections leak
Posted by "Keith Wall (Assigned) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/QPID-3575?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Keith Wall reassigned QPID-3575:
--------------------------------
Assignee: Keith Wall
> 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
> Assignee: Keith Wall
> 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
[jira] [Updated] (QPID-3575) connection leak after an attempt to
subscribe to nonexisting queue
Posted by "Pavel Moravec (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/QPID-3575?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Pavel Moravec updated QPID-3575:
--------------------------------
Attachment: TestQpidLeak.java
reproducer program
> 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
[jira] [Commented] (QPID-3575) session exceptions do not properly
close connections, causing connections leak
Posted by "Pavel Moravec (Commented) (JIRA)" <ji...@apache.org>.
[ 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
[jira] [Updated] (QPID-3575) session exceptions do not properly
close connections, causing connections leak
Posted by "Pavel Moravec (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/QPID-3575?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Pavel Moravec updated QPID-3575:
--------------------------------
Priority: Critical (was: Major)
Description:
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.
was:
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.
Affects Version/s: (was: 0.14)
0.12
Summary: session exceptions do not properly close connections, causing connections leak (was: connection leak after an attempt to subscribe to nonexisting queue)
Description of the issue rewritten after playing more around.
> 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.12
> Reporter: Pavel Moravec
> Priority: Critical
> Attachments: 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