You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@qpid.apache.org by Fraser Adams <fr...@blueyonder.co.uk> on 2011/12/11 13:05:01 UTC

A JMS Connection failing with asynchronous exception doesn't seem to close cleanly.

I've just noticed some odd behaviour when a connection got closed on 
exception with JMS (Qpid 0.12 using C++ broker).

In my test I've got an ExceptionListener registered and I deliberately 
send a big payload in order to get resource-limit-exceeded.

The client log says:

IoReceiver - localhost/127.0.0.1:5672 2011-12-11 11:39:29,557 INFO 
[apache.qpid.client.AMQConnection] Closing AMQConnection due to 
:org.apache.qpid.AMQException: ch=1 id=4 
ExecutionException(errorCode=RESOURCE_LIMIT_EXCEEDED, commandId=11, 
classCode=0, commandCode=0, fieldIndex=0, 
description=resource-limit-exceeded: resource-limit-exceeded: Policy 
exceeded on TempQueuee8e2ed69-63ce-41bd-9459-28cb17d1d629, policy: size: 
max=104857600, current=0; count: unlimited; type=reject 
(qpid/broker/QueuePolicy.cpp:87), errorInfo={}) [error code 506: 
resource error]
JMSException 506 caught: BigPayloadAgentTest failed
IoReceiver - localhost/127.0.0.1:5672 2011-12-11 11:39:29,557 INFO 
[apache.qpid.client.BasicMessageConsumer] Closing consumer:1[1625215216]
IoReceiver - localhost/127.0.0.1:5672 2011-12-11 11:39:29,557 INFO 
[apache.qpid.client.BasicMessageConsumer] Closing consumer:2[1147629119]
Dispatcher-Channel-0 2011-12-11 11:39:29,557 INFO 
[qpid.client.AMQSession.Dispatcher] Dispatcher-Channel-0 thread 
terminating for channel 0:org.apache.qpid.client.AMQSession_0_10@a383118

So *in theory* the connection should be closed, but in practice it 
doesn't seem to be.

Checking with qpid-printevents shows that there is no clientDisconnect 
Event and checking with qpid-config shows that exclusive queues bound to 
the connection remain.

There seems to be no clean way to properly close a connection in this 
state (I've tried explicitly closing it and even closing the underlying 
Session and MessageProducers/MessageConsumers using the connection).

The clientDisconnect Event only occurs when I actually terminate the client.

This behaviour seems wrong to me and results in a potential resource 
leak, unless I'm missing something it looks like something isn't getting 
correctly tidied up when this exception occurs which results in the 
underlying socket connection remaining.

Does anyone know of a workaround? I actually wanted to handle this in my 
ExceptionListener and re-establish connections.

Cheers,
Frase







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


Re: A JMS Connection failing with asynchronous exception doesn't seem to close cleanly.

Posted by Pavel Moravec <pm...@redhat.com>.
Hi Frase,
the bug is already tracked under https://issues.apache.org/jira/browse/QPID-3575. In fact, there are two somehow joined issues:

1) the session and connection leak problem itself, where a session becomes into detached state but cant be used further any way.
2) any exception raised on a session leads to the session and connection "closure", though many exceptions do not need to end up in connection closure. That is raised as https://issues.apache.org/jira/browse/QPID-3289 / https://issues.apache.org/jira/browse/QPID-3234.

Currently I am not aware of a workaround.

Kind regards,
Pavel


----- Original Message -----
> From: "Fraser Adams" <fr...@blueyonder.co.uk>
> To: users@qpid.apache.org
> Sent: Sunday, December 11, 2011 1:05:01 PM
> Subject: A JMS Connection failing with asynchronous exception doesn't seem to close cleanly.
> 
> I've just noticed some odd behaviour when a connection got closed on
> exception with JMS (Qpid 0.12 using C++ broker).
> 
> In my test I've got an ExceptionListener registered and I
> deliberately
> send a big payload in order to get resource-limit-exceeded.
> 
> The client log says:
> 
> IoReceiver - localhost/127.0.0.1:5672 2011-12-11 11:39:29,557 INFO
> [apache.qpid.client.AMQConnection] Closing AMQConnection due to
> :org.apache.qpid.AMQException: ch=1 id=4
> ExecutionException(errorCode=RESOURCE_LIMIT_EXCEEDED, commandId=11,
> classCode=0, commandCode=0, fieldIndex=0,
> description=resource-limit-exceeded: resource-limit-exceeded: Policy
> exceeded on TempQueuee8e2ed69-63ce-41bd-9459-28cb17d1d629, policy:
> size:
> max=104857600, current=0; count: unlimited; type=reject
> (qpid/broker/QueuePolicy.cpp:87), errorInfo={}) [error code 506:
> resource error]
> JMSException 506 caught: BigPayloadAgentTest failed
> IoReceiver - localhost/127.0.0.1:5672 2011-12-11 11:39:29,557 INFO
> [apache.qpid.client.BasicMessageConsumer] Closing
> consumer:1[1625215216]
> IoReceiver - localhost/127.0.0.1:5672 2011-12-11 11:39:29,557 INFO
> [apache.qpid.client.BasicMessageConsumer] Closing
> consumer:2[1147629119]
> Dispatcher-Channel-0 2011-12-11 11:39:29,557 INFO
> [qpid.client.AMQSession.Dispatcher] Dispatcher-Channel-0 thread
> terminating for channel
> 0:org.apache.qpid.client.AMQSession_0_10@a383118
> 
> So *in theory* the connection should be closed, but in practice it
> doesn't seem to be.
> 
> Checking with qpid-printevents shows that there is no
> clientDisconnect
> Event and checking with qpid-config shows that exclusive queues bound
> to
> the connection remain.
> 
> There seems to be no clean way to properly close a connection in this
> state (I've tried explicitly closing it and even closing the
> underlying
> Session and MessageProducers/MessageConsumers using the connection).
> 
> The clientDisconnect Event only occurs when I actually terminate the
> client.
> 
> This behaviour seems wrong to me and results in a potential resource
> leak, unless I'm missing something it looks like something isn't
> getting
> correctly tidied up when this exception occurs which results in the
> underlying socket connection remaining.
> 
> Does anyone know of a workaround? I actually wanted to handle this in
> my
> ExceptionListener and re-establish connections.
> 
> Cheers,
> Frase
> 
> 
> 
> 
> 
> 
> 
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project:      http://qpid.apache.org
> Use/Interact: mailto:users-subscribe@qpid.apache.org
> 
> 

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