【问题标题】:rabbitmq binding same queue with multiple binding keysrabbitmq 用多个绑定键绑定同一个队列
【发布时间】:2016-04-05 15:12:49
【问题描述】:

全部,

我正在尝试使用多个绑定键绑定队列。然而,并不是所有的键都是预先知道的。所以,我用一个已知的密钥执行amqp_queue_bind,然后在第二个密钥已知的情况下使用amqp_basic_consume,然后再次amqp_queue_bind

第二个amqp_queue_bind 卡住了,在使用 SIGSEGV 获取我的进程的核心时,我看到以下堆栈跟踪:

poll
recv_with_timeout
wait_frame_inner
amqp_simple_rpc
amqp_simple_rpc_decoded
amqp_queue_bind

如果我以后想添加绑定密钥,是否需要执行amqp_basic_cancel 并重新执行amqp_basic_consume

【问题讨论】:

  • 我也在link 发布了这个问题。

标签: rabbitmq amqp rabbitmq-c


【解决方案1】:

这是我犯的错误和解决方案:

这是应用流程:

有一个消息处理线程:

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

这是主应用程序线程: 在了解绑定键时,稍后会发生:

amqp_queue_bind 
if (!consume_done) { 
  amqp_basic_consume 
  consume_done 
}

在稍后阶段学习了多个绑定键,因此上述例程在主应用程序线程上下文中被多次调用。

第一次出价成功,我也收到消息了。但第二次amqp_queue_bind 通话挂起。

这里的问题是消息处理线程正在执行amqp_consume_message 无限超时,我们不应该期望amqp_queue_bind 在这种情况下从主线程通过。

解决方案是仅在amqp_consume_message 不等待消息时才调用amqp_queue_bind

现在看来,我犯了这个错误真是太愚蠢了。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2012-12-16
    • 2022-09-23
    • 1970-01-01
    • 2020-04-30
    • 1970-01-01
    • 2023-03-27
    • 1970-01-01
    相关资源
    最近更新 更多