[
https://issues.apache.org/activemq/browse/AMQ-2571?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=56946#action_56946
]
Simon edited comment on AMQ-2571 at 1/15/10 9:58 PM:
-----------------------------------------------------
My attempt at writing a JUnit test for this.
I used JUnit 3 as it seemed to be the version used for the ActiveMQ in the
source package.
Unfortunately since this seems to be a timing issue it might not be able to
provoke the problem every time.
So it should be run multiple times to increase the chance of detecting the
problem.
A warning might be in place, when it does succeed in provoking the error it
will leave empty TempQueues lying around in the broker.
Regards
Nimos
was (Author: nimos):
My attempt at writing a JUnit test for this.
I used JUnit 3 as it seemed to be the version used for the ActiveMQ in the
source package.
Unfortunately since this seems to be a timing issue it might not be able to
provoke the problem every time.
So it should be run multiple times to increase the chance of detecting the
problem.
Regards
Nimos
> 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
> 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 exists 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.
> 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.
