set the auto-delete to true for broker queues created to support non-… #35
Conversation
…durable topics with autogenerated names Broker queues defined for Topic consumers of non-durable Topics are assigned auto-generated names that are not visible to JMS clients. These broker queues are inherently transient and were previously (correctly) unbounded when the connection to the broker was closed. However, because these broker queues are created per consumer, the broker would effectively leak these until the connection was closed. This change flags such broker queues with the auto-delete flag, enabling the broker to expunge them once the last consumer is closed.
|
@AlexShvedoff Thanks! I was planning to release this in JMS Client 2.0.0, which requires Java 8 or more. Would that work for you? |
|
Hello, actually I need it, but for now I'm stuck to Java 7. |
|
@claudiobosticco OK, I'll release this in 1.8.0, along with a Java client update. |
|
Thanks @acogoluegnes! |
WIP. Doing this by default makes the CTS fail. References #35
|
@AlexShvedoff @claudiobosticco I had to add this as an opt-in, using it as is would make the JMS Compliance Test Suite fail. You'll have to set |
|
I may be misreading how this is structured, but this seems like the JMS compliance test suite may need an update instead. I the case of JMS topic consumers, the use of RMQ broker queues is incidental to how RMQ works. These are transient "queues" as evidenced by the fact that they have a randomly generated name. Waiting for a connection close to clear them does mean that in some long-running cases it may literally be years before they go away. And there's no way for a JMS client app to clear them manually because the name of the queue is not something that can be gleaned by calling any API. This all said - you're the expert, and I can be totally misreading how this should work. Ultimately, as long as there is a flag for people to avoid the leak with long-running connections, we have a solution. |
|
I got your point, I prefer the flag solution right now as we haven't seen anyone complaining for years. We'll make the cleaning the default behavior if it becomes a blocking problem for a majority of users. We released the RC BTW, you can give it a try. Thanks again for reporting this and providing a PR! |
|
Makes sense. One other thing: it looks like we need plumbing for this new property in RMQObjectProperty otherwise there's no way to plumb this from the JNDI config all the way to where we need it. Sigh. |
|
Feel free to look into a PR that adds the plumbing :)
…On Wed, Nov 29, 2017 at 12:36 AM, AlexShvedoff ***@***.***> wrote:
Makes sense. One other thing: it looks like we need plumbing for this new
property in RMQObjectProperty otherwise there's no way to plumb this from
the JNDI config all the way to where we need it. Sigh.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#35 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAAEQppAW5wybcpp2KuuM_Jp21FME8p4ks5s7Hz3gaJpZM4Qdw0r>
.
--
MK
Staff Software Engineer, Pivotal/RabbitMQ
|
|
@AlexShvedoff @michaelklishin I created an issue to follow up. |
4 participants
…durable topics with autogenerated names
Broker queues defined for Topic consumers of non-durable Topics are assigned auto-generated names that are not visible to JMS clients.
These broker queues are inherently transient and were previously (correctly) unbounded when the connection to the broker was closed. However, because these broker queues are created per consumer, the broker would effectively leak these until the connection was closed.
This change flags such broker queues with the auto-delete flag, enabling the broker to expunge them once the last consumer is closed.