MessageListenerContainer with existing queue with non-standard setup

[sundbp]

Hi,

It seems like the current code doesn't deal with queues that have been created using non-standard arguments very well. The code in SimpleMessageListenerContainer.cs, line 203 always does:
channel.QueueDeclare(name);

So for any queue that was created using anything but the standard constructor (i.e. it's a permanent and durable queue for example) this statement will throw an exception.

I think the best thing to do is to test if the queue already exists, and if so don't do the QueueDeclare(), and if not do the current. Adding that would require us to extend the interfaces somewhere to have a function QueueExists(name) function. Given the current RabbitMQ.Client setup there's however no suitable method on IModel to use for this and one would have to do something along the lines of the Rabbit.Admin implementation. I believe Qpid has some methods in its API to check for queue properties.

Or add a flag to decide if the queue is created at all?

[Mark Pollack]

Hi,

Thanks for pointing this out. There is a similar issue on the Java side. I've created an issue to fix this.

There is an overloaded method that takes a 'passive' boolean flag which might be helpful to determine if a queue of a given name exists. In the update to 1.8.x the Java API changed to now have a call on the channel.

AMQP.Queue.DeclareOk queueDeclarePassive(java.lang.String queue) throws java.io.IOException

Declare a queue passively; i.e., check if it exists. In AMQP 0-9-1, all arguments aside from nowait are ignored; and sending nowait makes this method a no-op, so we default it to false.

Thanks for the feedback!

Mark

[sundbp]

Great, thanks Mark.

Any indication for the M2 release date?

[Mark Pollack]

Hi,

Not sure, the scope of it is a bit big, the issues have been put into the Java issue tracker but I haven't copied them over to the .NET one yet. Perhaps early next month. We would like to reach 1.0 final by the SpringSource conference in October.

What we decided to do in this case is to remove any queue creation out of the listener container or message template. Instead you would declare an instance of the RabbitAdmin class and it will (by default) look for all Queue, Binding, and Exchange object definitions and declare them, before the message listener container starts. The MessageListenerContainer just needs string names.

I can get to this issue next week. In the meantime, you can just remove that code and be sure to call the appropriate RabbitAdmin code before initializing the Spring Container. This is how it is done in the sample stock application, there is a seperate program to declare all the amqp infrastructure.

Mark