rabbitmq stomp returns error PRECONDITION_FAILED - inequivalent arg 'x-message-ttl', what's wrong?

[Paulo Lopes]

Hello everyone,

I am quite new to rabbitmq and am trying to get some stomp connector to consume messages from a TTL queue but I get that error when i connect. Here is a simple test case:

ConnectionFactory factory = new ConnectionFactory()
factory.setHost("localhost")

Connection connection = factory.newConnection()
Channel channel = connection.createChannel()

channel.queueDeclare(QUEUE_NAME, true, false, false, new HashMap<>{{put("x-message-ttl", 2000);}});

So then i push a ton of messages from the java side and so far so good...

However when i try to consume this messages from a stomp client i get:

reply-code=406, reply-text=PRECONDITION_FAILED - inequivalent arg 'x-message-ttl'for queue 'tims_test_queue' in vhost '/': received the value '2000' of type 'signedint' but current is none, class-id=50, method-id=10

Now my question, is what does this error really mean, and what am i doing wrong?


Thanks!
Paulo

[Michael Klishin]

 On 24 July 2014 at 15:16:51, Paulo Lopes (pml...@gmail.com) wrote:
> > reply-code=406, reply-text=PRECONDITION_FAILED - inequivalent
> arg 'x-message-ttl'for queue 'tims_test_queue' in vhost '/':
> received the value '2000' of type 'signedint' but current is
> none, class-id=50, method-id=10
>
> Now my question, is what does this error really mean, and what
> am i doing wrong?

Queue parameters must match exactly for queue.declare to succeed. The STOMP plugin will
declare queues and currently has no way of specifying the extra arguments such as TTL.

You can do two things:

 * Use /amq/queue/{queue} destinations, which assume the queue is pre-declared elsewhere
 * Add TTL via a policy ("rules" that inject extra arguments into queues with matching names, configured globally)

See http://rabbitmq.com/stomp.html and https://www.rabbitmq.com/parameters.html.

Note that the STOMP plugin in 3.3 uses slightly confusing (although consistent) naming
scheme for generated queue names. So a policy will work but it may be easier to just consume
from /amq/queue/{queue} (if you are not dealing with many queues).
--
MK

Staff Software Engineer, Pivotal/RabbitMQ