[
https://issues.apache.org/activemq/browse/AMQ-2571?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simon updated AMQ-2571:
-----------------------
Description:
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
was:
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. 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
> 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 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.
