[
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: [email protected]
For additional commands, e-mail: [email protected]
