[rabbitmq-discuss] Ruby AMQP client not 1.8.0 friendly

[Jon Brisbin]

Upgraded my RabbitMQ server the other day to 1.8.0. Java stuff works fine, of course, because I just bumped the version number in Maven. But Ruby AMQP gem (v. 0.6.7) is now complaining. Downloaded the amqp-0.9.1.json file and re-generated the spec.rb file, which made errors go away, but now it looks like queue subscriptions don't work.

I'm not 100% sure where to go from here (already posted on the ruby-amqp list) other than to downgrade to 1.7.2 server. I'm sure there's some hacking that needs to take place. It's likely in the code that actually issues the queue subscription. There are no errors returned, so I assume it's just not attaching itself to the right spot on the server side because the client isn't sending the right information (or sending the right stuff, but in the wrong order).

Thanks ahead of time for the help! :)

Jon Brisbin
Portal Webmaster
NPC International, Inc.

_______________________________________________
rabbitmq-discuss mailing list
rabbitmq...@lists.rabbitmq.com
https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss

[Tony Garnock-Jones]

Jon Brisbin wrote:
> Upgraded my RabbitMQ server the other day to 1.8.0. Java stuff works fine,
> of course, because I just bumped the version number in Maven. But Ruby AMQP
> gem (v. 0.6.7) is now complaining. Downloaded the amqp-0.9.1.json file and
> re-generated the spec.rb file, which made errors go away, but now it looks
> like queue subscriptions don't work.

What kind of complaining is it doing with the stock 0.6.7 gem? What error
messages are you seeing, and which operation is failing? Is there anything in
the RabbitMQ server logs?

(Note BTW also that the 1.8.0 release of RabbitMQ is an AMQP *0-8* release, not
a 0-9-1 release.)

Tony

[Jon Brisbin]

Test program trying to get 4 messages in a queue.

The queue:

vcloud.deployment.events xportal.war []

The test code:

#!/opt/ruby-enterprise-1.8.7-2010.02/bin/ruby

require "rubygems"
require "mq"

em_thread = Thread.new { EM.run }
AMQP.start(:host => "mq2.cloud.npci.com",
:port => 5672,
:user => "cloud",
:pass => "vcloud",
:vhost => "cloud") do
puts "Before subscribe"
MQ.queue("xportal.war").bind("vcloud.deployment.events").subscribe(:ack => true) do |headers, body|
md5sum = headers.properties[:correlation_id]
artifact = body

puts "MD5: #{md5sum}"
end
puts "After subscribe"
end

em_thread.join()

+-( ~/scratch ):> ./mq_test.rb
Before subscribe
After subscribe
/opt/ruby-enterprise-1.8.7-2010.02/lib/ruby/gems/1.8/gems/amqp-0.6.7/lib/mq.rb:225:in `process_frame': PRECONDITION_FAILED - parameters for queue 'xportal.war' in vhost 'cloud' not equivalent in AMQP::Protocol::Queue::Declare on 1 (MQ::Error)
from ./mq_test.rb:22:in `join'
from ./mq_test.rb:22

The server log:

=INFO REPORT==== 1-Jul-2010::08:04:36 ===
accepted TCP connection on 0.0.0.0:5672 from 172.16.0.131:63535

=INFO REPORT==== 1-Jul-2010::08:04:36 ===
starting TCP connection <0.793.0> from 172.16.0.131:63535

=ERROR REPORT==== 1-Jul-2010::08:04:36 ===
connection <0.793.0> (running), channel 1 - error:
{amqp_error,precondition_failed,
"parameters for queue 'xportal.war' in vhost 'cloud' not equivalent",
'queue.declare'}

=WARNING REPORT==== 1-Jul-2010::08:04:36 ===
exception on TCP connection <0.793.0> from 172.16.0.131:63535
connection_closed_abruptly

=INFO REPORT==== 1-Jul-2010::08:04:36 ===
closing TCP connection <0.793.0> from 172.16.0.131:63535

Jon Brisbin
Portal Webmaster
NPC International, Inc.

[Matthew Sackman]

On Thu, Jul 01, 2010 at 08:11:01AM -0500, Jon Brisbin wrote:
> /opt/ruby-enterprise-1.8.7-2010.02/lib/ruby/gems/1.8/gems/amqp-0.6.7/lib/mq.rb:225:in `process_frame': PRECONDITION_FAILED - parameters for queue 'xportal.war' in vhost 'cloud' not equivalent in AMQP::Protocol::Queue::Declare on 1 (MQ::Error)
>

> =ERROR REPORT==== 1-Jul-2010::08:04:36 ===
> connection <0.793.0> (running), channel 1 - error:
> {amqp_error,precondition_failed,
> "parameters for queue 'xportal.war' in vhost 'cloud' not equivalent",
> 'queue.declare'}

Yup, looks like you're redeclaring the queue with different parameters
than it was originally declared with. This is something that was changed
with the 1.8.0 release where we're moving closer to 0-9-1 semantics, and
is covered towards the bottom of
http://lists.rabbitmq.com/pipermail/rabbitmq-announce/2010-June/000025.html

Matthew

[Tony Garnock-Jones]

Hi Jon,

Jon Brisbin wrote:
> =ERROR REPORT==== 1-Jul-2010::08:04:36 ===
> connection <0.793.0> (running), channel 1 - error:
> {amqp_error,precondition_failed,
> "parameters for queue 'xportal.war' in vhost 'cloud' not equivalent",
> 'queue.declare'}

As Matthew said, this is the result of a new server feature in 1.8.0 that
checks the Durable and AutoDelete flags for equivalence across separate
queue.declare calls for a given queue name.

To be clear, you should be fine with the AMQP gem as released, so long as you
are able to change your application to make sure that the Durable and
AutoDelete settings for a given queue are consistent across time.

Regards,