STOMP: stop using a queue property combination that is deprecated

[ikavgo]

Describe the bug

https://discord.com/channels/1092487794984755311/1092487794984755314/1323581561437814836

Reproduction steps

omq stomp -x 0 -T /topic/foo --queue-durability none

Expected behavior

We think by default stomp subscription queues should be exclusive

Additional context

No response

[ikavgo]

The obvious fix of marking respective queues exclusive has very interesting consequences - the queue names STOMP generates for topics appear to be deterministic - meaning for the same subscription endpoint same queue name generated. This fact plus exclusive: true make tests such as this:

def test_share_subscription(self):
        destination = '/topic/durable-shared'

        conn2 = self.create_connection()
        conn2.set_listener('', self.listener)

        try:
            self.__subscribe(destination)
            self.__assert_receipt()
            self.listener.reset(1)
            self.__subscribe(destination, conn2)
            self.__assert_receipt()

            self.listener.reset(100)

            n = 100
            # send 100 messages
            for x in range(0, n):
                self.conn.send(destination, "msg" + str(x))

            self.assertTrue(self.listener.wait_for_complete_countdown())
            self.assertEqual(n, len(self.listener.messages))
        finally:
            conn2.disconnect()

fail with logs like this:

025-01-04 20:43:17.343411+01:00 [error] <0.5063.0> Channel error on connection <0.5051.0> ([::1]:40414 -> [::1]:61613, vhost: '/', user: 'guest'), channel 1:
2025-01-04 20:43:17.343411+01:00 [error] <0.5063.0> operation queue.declare caused a channel exception resource_locked: cannot obtain exclusive access to locked queue 'stomp-subscription-As-CQ37wutHLc9H0PmjIPw' in vhost '/'. It could be originally declared on another connection or the exclusive property value does not match that of the original declaration.
2025-01-04 20:43:17.343517+01:00 [error] <0.5048.0> STOMP error frame sent:
2025-01-04 20:43:17.343517+01:00 [error] <0.5048.0> Message: resource_locked
2025-01-04 20:43:17.343517+01:00 [error] <0.5048.0> Detail: "RESOURCE_LOCKED - cannot obtain exclusive access to locked queue 'stomp-subscription-As-CQ37wutHLc9H0PmjIPw' in vhost '/'. It could be originally declared on another connection or the exclusive property value does not match that of the original declara..."
2025-01-04 20:43:17.343517+01:00 [error] <0.5048.0> Server private detail: none
2025-01-04 20:43:17.343699+01:00 [info] <0.5048.0> closing STOMP connection <0.5048.0> ([::1]:40414 -> [::1]:61613)

repeated runs of the same test produce same-looking log, like the one above with exact queue name!

[michaelklishin]

@ikavgo yes, a subscription ID is used when provided. I suspect stomp.py could be generating such IDs per consumer (listener).

[acutus]

Hi,

I was wondering whether this issue will be a blocker for the removal of transient non-exclusive queues, or might we find ourselves in a situation where rabbit-server would refuse to create these queues? It seems to me that Spring STOMP broker sets a subscription ID and apparently that leads to a deterministic name for the queues, causing issues if queues are made exclusive by default. Or did I misunderstand the above discussion?

If I understood correctly, it seems to me that setting the queues exclusive would break backwards compatibility and cause issues with at least users of Spring STOMP brokers.

[michaelklishin]

@acutus Spring STOMP will have to switch to durable client-named queues. The Shovel plugin will no longer support transient entities in the future.

It will not be a blocker for transient queue removal. Khepri does not have a concept of transient entities and never will, and one day Khepri will be the metadata store in RabbitMQ.

The durability property can be ignored to simplify upgrades, for example.

[acutus]

@michaelklishin thank you for the prompt reply. I created spring-projects/spring-framework#34540 to make spring-framework aware of this.