1

All,

I am trying to bind a queue with multiple binding keys. However, not all keys are known upfront. So, I do amqp_queue_bind with one known key and then amqp_basic_consume and later amqp_queue_bind again whren second key is known.

The second amqp_queue_bind gets stuck and on getting core of my process using SIGSEGV, I see following stack trace:

poll
recv_with_timeout
wait_frame_inner
amqp_simple_rpc
amqp_simple_rpc_decoded
amqp_queue_bind

Do I need to do amqp_basic_cancel and re-do amqp_basic_consume if I want to add a binding key later?

Ashish Vyas
  • 617
  • 1
  • 5
  • 19
  • I posted this problem at [link](http://rabbitmq.1065348.n5.nabble.com/Make-queue-bind-after-basic-consume-rabbitmq-c-td27879.html) as well. – Ashish Vyas Apr 06 '16 at 03:52

1 Answers1

0

Here is the mistake that I had made and solution:

Here is the app flow:

There is a message processing thread:

amqp_exchange_declare 
amqp_queue_declare 
while (1) { 
  if (consume_done) { 
    amqp_maybe_release_buffers 
    amqp_consume_message 
    app specific processing. 
  } 
}

This is main app thread: On getting to know a binding key, which happens later:

amqp_queue_bind 
if (!consume_done) { 
  amqp_basic_consume 
  consume_done 
}

There are multiple binding keys learnt at a later stage and so the above routine gets called multiple times in main app thread context.

The first time biding is successful and I also get messages. But second time amqp_queue_bind call hangs.

Here, the problem is message processing thread is doing amqp_consume_message with infinite timeout and we should not expect amqp_queue_bind to go through from main thread in this condition.

The solution is to call amqp_queue_bind only when amqp_consume_message is not waiting for messages.

It now seems it is so silly of me to have made this mistake.

Ashish Vyas
  • 617
  • 1
  • 5
  • 19