Every repository with this icon (
) is private.
Every repository with this icon (
) is public.
| Description: | AMQP client implementation in Ruby/EventMachine edit |
-
If you turn on :immediate to true then writing to a queue that doesn't have any listeners causes AMQP gem to throw an exception.
/Users/dj2/Development/AideRSS/core/vendor/amqp/lib/mq.rb:74:in
process_frame': undefined methodarguments' for nil:NilClass (NoMethodError)from /Users/dj2/Development/AideRSS/core/vendor/amqp/lib/amqp/client.rb:9:in `process_frame' from /Users/dj2/Development/AideRSS/core/vendor/amqp/lib/amqp/client.rb:103:in `receive_data' from /Users/dj2/Development/AideRSS/core/vendor/eventmachine/core-0.12.3/lib/eventmachine.rb:237:in `run_machine'The problem seems to be that the AMQP::Protocol::Basic::Return packet isn't being processed in mq#process_frame so we end up not getting @method set properly.
Adding:
when Protocol::Basic::Return
@method = methodto the Frame::method section of the case fixes the issue but I'm pretty sure it's the completely wrong solution.
Comments
-
Is this on the roadmap?
Comments
-
on_disconnect should raise error and not reconnect if login and password are incorrect.
Comments
The problem is that it's not that simple with AMQP, since it doesn't require brokers to raise an error on authentication failures, they just close the connection. But that can happen at any point down the line as well.
So it pretty much boils down on the handshake of Start and StartOk where some sort of state could be stored, but that again doesn't seem very EventMachine-y. That state could be checked in on_disconnect. Personally I don't want my clients to bitterly fail, since I might have no way to bring them back up again, but in any way it could prevent the client from hammering the broker, and at least log a decent message.
Until there's a reasonable solution, you could do what I'm doing ATM, I'd suggest looking into this commit: http://github.com/melito/amqp/commit/e206ee1c03743e32d85b80c0c2cf7f2142ff5416. That's what we're using right now, but I'm not entirely happy with it.
-
0 votes
process_frame raises an error on Channel::Close instead of calling MQ.error
1 comment Created 3 months ago by ciconiaWhen a Channel::Close frame is received, an error is raised instead of calling MQ.error, causing the process to exit unless EM.error_handler is set. Here is a patch to correct this:
diff --git a/lib/mq.rb b/lib/mq.rb index 893325f..b6cd901 100644 --- a/lib/mq.rb +++ b/lib/mq.rb @@ -222,7 +222,7 @@ class MQ end when Protocol::Channel::Close - raise Error, "#{method.reply_text} in #{Protocol.classes[method.class_id].methods[method.method_id]} on #{@channel}" + MQ.error "#{method.reply_text} in #{Protocol.classes[method.class_id].methods[method.method_id]} on #{@channel}" when Protocol::Channel::CloseOk @closing = falseComments
-
1 vote
COMMAND_INVALID - unimplemented method in AMQP::Protocol::Basic::Reject
3 comments Created 3 months ago by kevnOn amqp 0.6.0, I get this error when calling header.reject(:requeue => true)
COMMAND_INVALID - unimplemented method in AMQP::Protocol::Basic::Reject
Interestingly, this error seems to result in a queue reconnect, which causes any unack'd messages to be requeued on the server. I believe disconnecting from the queue is the AMQP-specified method of noack'ing messages. However, the error message indicates this might be a side effect rather than intended.
Comments
I just realized 0.6.4 is available from github, and the problem occurs in that version as well.
COMMAND_INVALID is coming from rabbitmq, meaning that rabbitmq does not implement reject or requeue
Thanks Aman, that explains it perfectly. For others encountering this problem, see rabbit-discuss. The correct way to noack a message with rabbitmq is indeed disconnecting.
-
mq gem has a strong dependency with eventmachine, it works only with eventmachine gem not eventmachine-eventmachine more up-to-date gem I use.
When I install eventmachine-eventmachine (GitHub) gem I got this error:
/usr/local/lib/site_ruby/1.8/rubygems.rb:827:in `report_activate_error': Could not find RubyGem eventmachine (>= 0.12.4) (Gem::LoadError)When I install eventmachine (rubyforge) gem, it works.
Comments
-
0 votes
Unacknowledged messages received out of order on subsequent connect
1 comment Created about 1 month ago by eandrejkoIt seems that the messages that are not acknowledged are received in a different order when reconnecting to the AMQP (rabbit mq) server. Is this a problem in Rabbit MQ or in the AMQP gem? It seems surprising either way.
See http://gist.github.com/225671 for some sample code and output.
Comments
-
While binding the queue with exchange, it stores the binding options in instance variable and in next line it removes :key from options. When amqp tries to reset queue after unbind/disconnect it uses the previously stored binding options, which no more has :key hence new queues are created without any routing keys.
I have already submitted the pull request for it.
Comments
-
[Fri, /home/tester/vendor/gems/gems/amqp-0.6.5/lib/amqp/buffer.rb:252:in `min': comparison of Array with Array failed (ArgumentError)
from /home/tester/vendor/gems/gems/nanite-0.4.1.10/lib/nanite/cluster.rb:137:in `each' from /home/tester/vendor/gems/gems/nanite-0.4.1.10/lib/nanite/cluster.rb:137:in `min' from /home/tester/vendor/gems/gems/nanite-0.4.1.10/lib/nanite/cluster.rb:137:in `least_loaded' from /home/tester/vendor/gems/gems/nanite-0.4.1.10/lib/nanite/cluster.rb:23:in `__send__' from /home/tester/vendor/gems/gems/nanite-0.4.1.10/lib/nanite/cluster.rb:23:in `targets_for' from /home/tester/vendor/gems/gems/nanite-0.4.1.10/lib/nanite/mapper.rb:198:in `send_request' from /home/tester/vendor/gems/gems/nanite-0.4.1.10/lib/nanite/mapper.rb:191:in `request' from tester.rb:56:in `start' from /home/tester/vendor/gems/gems/eventmachine-0.12.10/lib/em/timers.rb:51:in `call' from /home/tester/vendor/gems/gems/eventmachine-0.12.10/lib/em/timers.rb:51:in `fire' from /home/tester/vendor/gems/gems/eventmachine-0.12.10/lib/eventmachine.rb:256:in `call' from /home/tester/vendor/gems/gems/eventmachine-0.12.10/lib/eventmachine.rb:256:in `run_machine' from /home/tester/vendor/gems/gems/eventmachine-0.12.10/lib/eventmachine.rb:256:in `run'It continues to happen repeatedly till the system is restarted.
Comments
