2016-07-05 157 views
-1

我们正在使用azure服务总线来协助通过监听队列的工作人员对消息进行并行处理。Azure请求 - 响应会话超时处理

首先收到一条聚合消息,然后将这条消息拆分为数千个通过请求 - 响应模式发布的单独消息,因为我们需要知道何时所有消息已经完成以运行单独的进程。

我们的问题是,请求 - 响应方法具有超时,这是造成了以下问题:

假设我们发布1000条消息进行处理并只有一个工人听力。在超时过期后留在队列中的消息被丢弃,这是我们不想要的。如果我们将失效时间设置为一个能保证处理所有消息的较大值,那么我们就会冒着信息失败的风险,不得不等待超时才能明白出现了问题。

有没有办法在请求 - 响应场景或其他任何我们应该考虑的模式中动态更改单个消息的到期时间?

谢谢!

回答

0

你弄错了,蔚蓝服务总线消息的生存时间https://msdn.microsoft.com/en-us/library/microsoft.servicebus.messaging.brokeredmessage.timetolive.aspx如果消息被消耗或不消耗,消息将在队列上的时间。

这不是超时,如果您发布消息的时间较长,消息会长时间保留在队列中,但如果您未能消耗,应警告另一端未能消耗这条信息。

您可以使用另一个队列执行此操作,并将另一个消息放置在该其他队列上,并显示失败的消息标识和错误。

这是一个异步过程,因此您不应该基于该过程来保存请求,而是使用该问题的异步本质。

+0

感谢您的回复。也许我没有足够好地解释这个问题。我不是指消息的TTL。 Azure总线支持用于将请求与响应相关联的会话。在一个队列中发出请求,并在另一个队列上提供响应。这里是一个示例[来自MSDN的示例](https://code.msdn.microsoft.com/Brokered-Messaging-Request-0ce8fcaf)。我指的是创建会话时需要提供的实际timeour属性。如果达到此超时并且没有处理器接收到消息,则消息响应将永远不会被拾取。 –

+0

我的错误是提到deadletter队列,你正确的将使用队列的TTL。 –

+0

我的答案最终解决了您的问题吗? –