[
https://issues.apache.org/activemq/browse/AMQ-2571?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rob Davies resolved AMQ-2571.
-----------------------------
Resolution: Fixed
Fix Version/s: 5.4.0
Assignee: Rob Davies
I know this issue was raised on 4.x - but also found on 5.3.0 - but I have not
been able to reproduce after many tries on trunk.
Added a test case - org.apache.activemq.bugs.AMQ2571 by SVN revision 901832
> Sender sometimes, involuntary, autocreates new, consumerless, TempQueue when
> trying to send to removed TempQueue.
> -----------------------------------------------------------------------------------------------------------------
>
> Key: AMQ-2571
> URL: https://issues.apache.org/activemq/browse/AMQ-2571
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
> Affects Versions: 4.1.1
> Environment: Ubuntu 9.10, P4 2.6 GHz HT, 3 GB RAM.
> Reporter: Simon
> Assignee: Rob Davies
> Fix For: 5.4.0
>
> Attachments: TempQueueClosing.java
>
>
> Please see this post for discussion:
> http://old.nabble.com/Problems-with-prefetch-and-TemporaryQueues-td27130529.html
> I've tested this on 4.1.1, and briefly on 5.3.0 with the same result.
> Scenario:
> We have a server and a client. The client posts a message on the servers
> queue in order to subscribe to updates.
> The server takes the reply address from the client and starts sending
> messages to a TempQueue created by the client.
> When the client disconnects without notifying the server the following might
> happen:
> 1. The temporary queue is removed correctly when the client exits and closes
> its connection.
> From here we have three scenarios:
> 2.a The server gets an exception the next time it tries to send a message to
> the TempQueue. This is wanted behaviour. It can then simply drop the
> "subscription".
> 2.b The server isn't notified in time and sends some messages before it gets
> the exception. Due to AutoCreateDestination being enabled one of these
> messages creates a new TempQueue with the same name as the one removed. It is
> of course missing a consumer.
> But since the server gets the exception it will stop posting to the
> TempQueue. However, when the server closes its connection the TempQueue is
> not removed and is left lying around with no consumer.
> 2.c The server recreates the TempQueue in the same way as in 2.b, but here it
> never gets the exception for some reason. The server then has no idea that
> the client left and keeps pilling up messages on the TempQueue until the
> broker object hits its memory limit and everything connected to the broker
> halts.
> I think there are three problems here:
> 1. The exception is not thrown every time.
> 2. When the TempQueue is recreated it is not removed when the server closes
> its connection. Also, the server gets an InvalidDestinationException if I, at
> server side, try to connect a consumer to the TempQueue. I guess this means
> that although the server is the initiator for the auto(re)creation it does
> not become the owner of the TempQueue. But who is then the owner? The broker
> itself?
> 3. Due to AutoCreateDestination being enabled by default for TempQueues,
> every post to a TempQueue could result in unknowingly creating a new
> TempQueue.
> Suggestions
> Settings AutoCreateDestination to false for TempQueues solves all three
> problems.
> So exposing that option in an easily accessible way is important.
> But even then, 1 and 2 should perhaps be examined separately.
> I'll attach a JUnit test case for this. Unfortunately it is not 100% reliable
> in detecting the problem. One has to run it multiple times.
> On my test setup it failed correctly 8 times out of 10 runs. You might be
> able to improve it.
> Best Regards
> Nimos
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
