[
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-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
