Azure的服务总线，确定的onMessage停止处理

问题描述

使用Azure的ServiceBus和调用的onMessage我正在寻找一种方法来确定是否在onMessage事件泵停止从队列中读取。

Using Azure ServiceBus and the OnMessage call I am looking for a way to determine if the OnMessage event pump stops reading from the queue.

我们的到的onMessage连接的配置如下：

Our connection to OnMessage is configured as below:

protected virtual void DoSubscription(string queueName, Func<QueueRequest, bool> callback)
{
    var client = GetClient(queueName, PollingTimeout);
    var transformCallback = new Action<BrokeredMessage>((message) =>
    {
        try
        {
            var request = message.ToQueueRequest();
            if (callback(request))
            {
                message.Complete();
            }
            else
            {
                message.Abandon();
                Log.Warn("DoSubscription: Message Failed to Process Gracefully: {0}{1}", Environment.NewLine, JsonConvert.SerializeObject(request));
            }
        }
        catch (Exception ex)
        {
            Log.Error("DoSubscription: Message Failed to Process With Exception:", ex);
            message.Abandon();
        }
    });
    var options = new OnMessageOptions
    {
        MaxConcurrentCalls = _config.GetInt("MaxThreadsPerQueue"),
        AutoComplete = false,
        AutoRenewTimeout = new TimeSpan(0,0,1)
    };
    options.ExceptionReceived += OnMessageError;
    client.OnMessage(transformCallback, options);
}

我们遇到的问题是一段时间没有消息排队排队等待未能通过的onMessage事件泵，直到重新启动应用程序被拾起新邮件了。

The problem we are encountering is after a period of time with no messages being queued new messages that are queued fail to be picked up by the OnMessage event pump until the application is restarted.

我知道有很多方法可以做到这一点使用工作者角色，但是，对于监控和管理的目的，我们决定在Web应用程序的应用开始实施这一点。

I realize there are ways to do this using Worker Roles, however for monitoring and management purposes we decided to implement this in the Application Start of a web app.

推荐答案

因此​​，与微软的Azure支持团队一个电话后没有一个事件时捕获的onMessage或OnMessageAsync错误。因为这些不阻塞调用，它启动事件泵和返回到执行的线程，这将创建一个挑战，以确定是否的onMessage *是做它的工作

So after a call with Microsoft's Azure support team there is not an event to trap when OnMessage or OnMessageAsync errors. As these are not blocking calls, it starts the event pump and returns to the executing thread, this creates a challenge to determine if OnMessage* is doing it's job.

从微软的建议是：

• 创建你自己的实现，它公开的OnClose上，您可以处理*方法QueueClientBase类。然而，这样做你必须做的消息的处理信封自己。


• 使用的onReceive在一个单独的线程循环，它可以捕获错误自己，立即重试。

不过，我并探索针对一些的onMessage子弹校对，发现它已经缓解我的担心一些事情。

However, I did explore some bullet proofing against OnMessage and discovered a few things which have eased my fears.

• 的onMessage是令人难以置信的容错
  
  
  • 我uplugged以太网电缆从我的笔记本电脑无线关闭，这打破了的onMessage对服务总线队列连接。等待10分钟后，我插入以太网电​​缆回，在onMessage马上开始处理排队元素。
  
  

  ALL-IN-所有我要继续使用的onMessage / OnMessageAsync现在，并保持它的眼睛。我会更新，如果我看到改变我的onMessage的看法的问题。

  All-in-all I'm going to continue using OnMessage/OnMessageAsync for now and keep an eye on it. I will update this if I see issues that change my opinion of OnMessage.

  除了 - 确保如果在您设置的永远在线配置选项为开一个蓝色的网站使用的onMessage永久性听力。否则，除非一个web请求进入的onMessage将被布置和消息将不再进行处理，直到web应用程序是由一个HTTP请求重新唤醒

  Aside - Make sure if you are using OnMessage for permanent listening in an Azure Web Site that you set the "Always On" configuration option to "On". Otherwise, unless a web request comes in OnMessage will be disposed and messages will no longer be processed until the web application is reawakened by a HTTP request.

  这篇关于Azure的服务总线，确定的onMessage停止处理的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！