轮询的Azure的服务总线队列使用Node.js的蔚蓝WebJob [英] Polling an Azure Service Bus Queue from an Azure WebJob using Node.js

查看：255
本文介绍了轮询的Azure的服务总线队列使用Node.js的蔚蓝WebJob的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！

问题描述

试图使用轮询写在Node.js的一个WebJob的Azure的服务总线队列我创建了2 WebJobs。第一个是在需求，并发送10个独特的消息到队列中。第二个作业是连续的轮询队列中的消息。

遭遇了以下问题：


  1. 轮询是缓慢的。它需要大约10分钟的平均接收10条信息。请参阅下面的示例日志的详细信息。基本上不可用在这个速度。所有延迟是指从获得从 receiveQueueMessage 的响应。响应时间为0秒不等至〜120秒，平均为60秒。


  2. 正在以随机的顺序接收到的消息。不是FIFO。


  3. 有时邮件接收两次，即使他们在ReceiveAndDelete模式下读取（我没有读模式参数试过它应该默认为ReceiveAndDelete，与 {isReceiveAndDelete：真正} 和 {isPeekLock：假} 具有相同的结果）

    4. 。

  4. 在队列为空时，它应保持收到请求每天开放，但它总是230秒后无消息，返回错误。根据该文件最大为24天，以便我不知道在哪里230秒是来自：



  

在服务总线阻塞接收操作的最大超时
  队列是24天。然而，基于REST的超时有一个最大值
  55秒。


基本上没有什么像宣传的那样。我在做什么错了？

送信测试工作：

  VAR UUID =要求（'节点的uuid'）;
VAR蔚蓝=要求（'蔚蓝'）;
VAR serviceBus = azure.createServiceBusService（process.env.busSearchConnectionString）;
变种messagesToSend = 10;的sendMessage（0）;功能的sendMessage（计数）
{
    VAR消息= {
        身体：测试消息，
        对象customProperties：{
            message_number：算，
            sent_date：新的日期
        }，
        brokerProperties：{
            的MessageId：uuid.v4（）//保证服务总线并不认为这是重复的消息
        }
    };    serviceBus.sendQueueMessage（process.env.busSearchQueueName，消息功能（错误）{        如果（！ERR）{
            的console.log（'发送的测试消息编号+ count.toString（））;
        }其他{
            console.error（'错误发送消息：+ ERR）;
        }    }）;    //等待5秒钟，以确保消息通过服务总线在正确的顺序接收
    如果（计数＆LT; messagesToSend）{
        的setTimeout（函数（newCount）{
            //发送下一条消息
            的sendMessage（newCount）;
        }，5000，算上+ 1）;
    }
}

接收消息连续工作：

 的console.log（'监听作业开始'）;
VAR蔚蓝=要求（'蔚蓝'）;
VAR serviceBus = azure.createServiceBusService（process.env.busSearchConnectionString）;
listenForMessages（serviceBus）;功能li​​stenForMessages（serviceBus）
{
    VAR开始= process.hrtime（）;
    VAR TIMEOUT = 60 * 60 * 24; //长轮询1天
    serviceBus.receiveQueueMessage（process.env.busSearchQueueName，{timeoutIntervalInS：超时，isReceiveAndDelete：真正}，功能（ERR，消息）{        VAR结束= process.hrtime（开始）;
        的console.log（'收到％DS秒的响应，结束[0]）;        如果（ERR）{            的console.log（'错误请求消息：'+ ERR）;
            listenForMessages（serviceBus）;        }其他{            如果（消息== NULL和放大器;！＆安培; typeof运算消息==='对象'和;在message.customPropertiesmessage_number'和;'对象customProperties的消息和;＆AMP）{                的console.log（'收到的测试消息编号+ message.customProperties.message_number.toString（））;
                listenForMessages（serviceBus）;            }其他{                的console.log（'无效的消息中收到'）;
                listenForMessages（serviceBus）;            }        }    }）;
}

示例日志输出：

  [2015年5月6日21点五十分14秒＆GT; 8c2504：SYS INFO]状态改为运行
[2015年5月6日21时五十分14秒＆GT; 8c2504：INFO]监听器开始工作
[2015年5月6日21时51分23秒＆GT; 8c2504：INFO]收到1秒秒响应
[2015年5月6日21时51分23秒＆GT; 8c2504：INFO]收到的​​测试消息数0
[2015年5月6日21点51分25秒＆GT; 8c2504：INFO]收到2秒秒响应
[2015年5月6日21点51分26秒＆GT; 8c2504：INFO]收到的​​测试消息4号
[2015年5月6日21时51分27秒＆GT; 8c2504：INFO]收到1秒秒响应
[2015年5月6日21时51分27秒＆GT; 8c2504：INFO]收到的​​测试消息7号
[2015年5月6日21时51分28秒＆GT; 8c2504：INFO]收到0秒响应
[2015年5月6日21时51分29秒＆GT; 8c2504：INFO]收到的​​测试消息9号
[2015年5月6日21时51分49秒＆GT; 8c2504：INFO]收到20多岁秒的响应
[2015年5月6日21时51分49秒＆GT; 8c2504：INFO]收到的​​测试消息1号
[2015年5月6日21点53分35秒＆GT; 8c2504：INFO]收到106S秒的响应
[2015年5月6日21点53分35秒＆GT; 8c2504：INFO]收到的​​测试消息1号
[2015年5月6日21时54分26秒＆GT; 8c2504：INFO]收到50多岁秒的响应
[2015年5月6日21时54分26秒＆GT; 8c2504：INFO]收到的​​测试消息5号
[2015年5月6日21点54分35秒＆GT; 8c2504：INFO]收到787-9秒的响应
[2015年5月6日21点54分35秒＆GT; 8c2504：INFO]收到的​​测试消息9号
[2015年5月6日21时55分28秒＆GT; 8c2504：INFO]收到53S秒的响应
[2015年5月6日21时55分28秒＆GT; 8c2504：INFO]收到的​​测试消息2号
[2015年5月6日21点57分26秒＆GT; 8c2504：INFO]收到118S秒的响应
[2015年5月6日21点57分26秒＆GT; 8c2504：INFO]收到的​​测试消息6号
[2015年5月6日21点58分28秒＆GT; 8c2504：INFO]收到61S秒的响应
[2015年5月6日21点58分28秒＆GT; 8c2504：INFO]收到的​​测试消息8号
[2015年5月6日22时00分35秒＆GT; 8c2504：INFO]收到126S秒的响应
[2015年5月6日22时00分35秒＆GT; 8c2504：INFO]收到的​​测试消息3号
[2015年5月6日22时04分25秒＆GT; 8c2504：INFO]收到230S秒的响应
[2015年5月6日22时04分25秒＆GT; 8c2504：INFO]错误请求消息：没有邮件接收
[2015年5月6日22时08分16秒＆GT; 8c2504：INFO]收到230S秒的响应
[2015年5月6日22时04分25秒＆GT; 8c2504：INFO]错误请求消息：没有邮件接收


解决方案

和问题是（创造了在Azure门户队列时的默认选项）我用分配队列中。有一次，我创建了一个不分区的一个新的队列，一切都如预期无延迟（比上一长轮询尝试怪异230秒超时等）。所以基本上Node.js的库没有对分区队列工作。在所有。浪费了很多天盘算，一出。这里将离开这个别人。

Trying to poll an Azure Service Bus Queue using a WebJob written in Node.js. I created 2 WebJobs. The first is on demand and sends 10 unique messages to the queue. The second job is continuous and polls the queue for messages.

Encountering the following issues:

  1. The polling is SLOW. It takes an average of about 10 minutes to receive 10 messages. See sample log details below. Basically unusable at this speed. All the delay is from getting a response from receiveQueueMessage. Response times vary from 0 seconds to ~120 seconds, with an average of 60 seconds.

  2. The messages are being received in a random order. Not FIFO.

  3. Sometimes messages are received twice, even though they are being read in ReceiveAndDelete mode (I have tried with no read mode parameter which should default to ReceiveAndDelete, with {isReceiveAndDelete:true} and with {isPeekLock:false} with the same results).

  4. When the queue is empty, it should keep the receive request open for a day, but it always returns with a no message error after 230 seconds. According to the documentation the max is 24 days so I don't know where 230 seconds is coming from:

The maximum timeout for a blocking receive operation in Service Bus queues is 24 days. However, REST-based timeouts have a maximum value of 55 seconds.

Basically nothing works as advertised. What am I doing wrong?

Send Message Test Job:

var uuid = require('node-uuid');
var azure = require('azure');
var serviceBus = azure.createServiceBusService(process.env.busSearchConnectionString);
var messagesToSend = 10;

sendMessage(0);

function sendMessage(count)
{
    var message = {
        body: 'test message',
        customProperties: {
            message_number: count,
            sent_date: new Date
        },
        brokerProperties: {
            MessageId: uuid.v4() //ensure that service bus doesn't think this is a duplicate message
        }
    };

    serviceBus.sendQueueMessage(process.env.busSearchQueueName, message, function(err) {

        if (!err) {
            console.log('sent test message number ' + count.toString());
        } else {
            console.error('error sending message: ' + err);
        }

    });

    //wait 5 seconds to ensure messages are received by service bus in correct order
    if (count < messagesToSend) {
        setTimeout(function(newCount) {
            //send next message
            sendMessage(newCount);
        }, 5000, count+1);
    }
}

Receive Message Continuous Job:

console.log('listener job started');
var azure = require('azure');
var serviceBus = azure.createServiceBusService(process.env.busSearchConnectionString);
listenForMessages(serviceBus);

function listenForMessages(serviceBus)
{
    var start = process.hrtime();
    var timeOut = 60*60*24; //long poll for 1 day
    serviceBus.receiveQueueMessage(process.env.busSearchQueueName, {timeoutIntervalInS: timeOut, isReceiveAndDelete: true}, function(err, message) {

        var end = process.hrtime(start);
        console.log('received a response in %ds seconds', end[0]);

        if (err) {

            console.log('error requesting message: ' + err);
            listenForMessages(serviceBus);

        } else {

            if (message !== null && typeof message === 'object' && 'customProperties' in message && 'message_number' in message.customProperties) {

                console.log('received test message number ' + message.customProperties.message_number.toString());
                listenForMessages(serviceBus);

            } else {

                console.log('invalid message received');
                listenForMessages(serviceBus);

            }

        }

    });
}

Sample Log Output:

[05/06/2015 21:50:14 > 8c2504: SYS INFO] Status changed to Running
[05/06/2015 21:50:14 > 8c2504: INFO] listener job started
[05/06/2015 21:51:23 > 8c2504: INFO] received a response in 1s seconds
[05/06/2015 21:51:23 > 8c2504: INFO] received test message number 0
[05/06/2015 21:51:25 > 8c2504: INFO] received a response in 2s seconds
[05/06/2015 21:51:26 > 8c2504: INFO] received test message number 4
[05/06/2015 21:51:27 > 8c2504: INFO] received a response in 1s seconds
[05/06/2015 21:51:27 > 8c2504: INFO] received test message number 7
[05/06/2015 21:51:28 > 8c2504: INFO] received a response in 0s seconds
[05/06/2015 21:51:29 > 8c2504: INFO] received test message number 9
[05/06/2015 21:51:49 > 8c2504: INFO] received a response in 20s seconds
[05/06/2015 21:51:49 > 8c2504: INFO] received test message number 1
[05/06/2015 21:53:35 > 8c2504: INFO] received a response in 106s seconds
[05/06/2015 21:53:35 > 8c2504: INFO] received test message number 1
[05/06/2015 21:54:26 > 8c2504: INFO] received a response in 50s seconds
[05/06/2015 21:54:26 > 8c2504: INFO] received test message number 5
[05/06/2015 21:54:35 > 8c2504: INFO] received a response in 9s seconds
[05/06/2015 21:54:35 > 8c2504: INFO] received test message number 9
[05/06/2015 21:55:28 > 8c2504: INFO] received a response in 53s seconds
[05/06/2015 21:55:28 > 8c2504: INFO] received test message number 2
[05/06/2015 21:57:26 > 8c2504: INFO] received a response in 118s seconds
[05/06/2015 21:57:26 > 8c2504: INFO] received test message number 6
[05/06/2015 21:58:28 > 8c2504: INFO] received a response in 61s seconds
[05/06/2015 21:58:28 > 8c2504: INFO] received test message number 8
[05/06/2015 22:00:35 > 8c2504: INFO] received a response in 126s seconds
[05/06/2015 22:00:35 > 8c2504: INFO] received test message number 3
[05/06/2015 22:04:25 > 8c2504: INFO] received a response in 230s seconds
[05/06/2015 22:04:25 > 8c2504: INFO] error requesting message: No messages to receive
[05/06/2015 22:08:16 > 8c2504: INFO] received a response in 230s seconds    
[05/06/2015 22:04:25 > 8c2504: INFO] error requesting message: No messages to receive

解决方案

And the issue was the queue I was using was partitioned (the default option when creating a queue in the Azure portal). Once I created a new queue that was not partitioned, everything worked as expected without the lag (other than the weird 230 second timeout on a long poll attempt). So basically the node.js library doesn't work for partitioned queues. At all. Wasted many days figuring that one out. Will leave this here for others.

这篇关于轮询的Azure的服务总线队列使用Node.js的蔚蓝WebJob的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！

查看全文
相关文章
云存储最新文章
热门教程
热门工具
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆