Максимальный размер полезной нагрузки CloudQueueMessage - PullRequest
Новая
       52

Максимальный размер полезной нагрузки CloudQueueMessage

3 голосов
/ 06 июля 2011

Согласно MSDN , полезная нагрузка сообщения может достигать 8 КБ (8192 байта):

Метод AddMessage добавляет сообщение в конец очереди.Сообщение может иметь размер до 8 КБ.Его содержимое должно быть в формате, который можно кодировать с использованием UTF-8.

Однако при добавлении сообщений в очередь я получаю исключения для сообщений, чья полезная нагрузка должна составлять намного меньше, чем 8192 байта, магическая область, кажется, составляет около 6500 байтов.Данные, которые я отправляю, являются чистыми строками, размер которых проверяется как по элементу .Length, так и по длине, отправляемой источником, из которого они получены (существует постоянная разница в 2 байта для разделителя CRLF).

поэтому мой вопрос состоит из двух частей:

1) Есть ли какие-либо скрытые данные, добавленные к полезной нагрузке сообщения, которые бы увеличивали его размер или вызывали этот странный тип поведения?(например, ограничение, применяемое к объекту в целом, а не только к его полезной нагрузке, но даже тогда, как оно может составлять 1,5 КБ на сообщение?)

2) Как можно надежно проверить, что полезная нагрузка действительно ниже 8192?

и некоторую дополнительную информацию: я использую Azure SDK 1.4 с VS 2010 Ultimate, работающий через эмуляторы вычислений и хранения (я не развертывал этоприложение еще) с использованием SQLExpress (думаю, 2008).

Также подтверждается кодом, что максимальный размер составляет 8192 байта (в случае некоторого дополнительного ограничения системы): 

Trace.WriteLine("Max Queue Message Size: " + CloudQueueMessage.MaxMessageSize, "CloudQueueMessage");

CloudQueueMessage: максимальный размер сообщения в очереди: 8192

1 Ответ

9 голосов
/ 06 июля 2011

Клиентская библиотека хранилища .NET (Microsoft.WindowsAzure.StorageClient.dll) base-64 кодирует содержимое сообщения очереди, поэтому эффективный лимит составляет 8192 * .75 = 6144 байт при использовании.NET клиентская библиотека.(Это потому, что кодировка base 64 добавляет 1/3 накладных расходов.)

(Обратите внимание, что у вас нет для кодирования base 64. Просто так получается, что эта библиотека гарантирует, чтосодержимое сообщения очереди может быть безопасно встроено в XML, что является требованием, которое служба очереди помещает в сообщения.)

РЕДАКТИРОВАТЬ: Вот пример кода для использования пространства имен Microsoft.WindowsAzure.StorageClient.Protocolпоместить необработанный текст (не кодированный в 64) в сообщение очереди (и впоследствии получить его): 

using System;
using System.Net;
using Microsoft.WindowsAzure;
using Microsoft.WindowsAzure.StorageClient;
using Microsoft.WindowsAzure.StorageClient.Protocol;

class Program
{
    static void Main(string[] args)
    {
        var q = CloudStorageAccount.Parse("UseDevelopmentStorage=true").CreateCloudQueueClient().GetQueueReference("testqueue");
        q.CreateIfNotExist();

        var req = QueueRequest.PutMessage(new Uri(q.Uri, q.Name + "/messages"), 30, null);
        var body = QueueRequest.GenerateMessageRequestBody("hello world");
        req.ContentLength = body.Length;
        q.ServiceClient.Credentials.SignRequest(req);
        using (var stream = req.GetRequestStream())
        {
            stream.Write(body, 0, body.Length);
            stream.Close();
        }
        req.GetResponse();

        req = QueueRequest.GetMessages(new Uri(q.Uri, q.Name + "/messages"), 30, 32, null);
        q.ServiceClient.Credentials.SignRequest(req);
        using (var response = (HttpWebResponse)req.GetResponse())
        {
            using (var msgResponse = QueueResponse.GetMessages(response))
            {
                foreach (var msg in msgResponse.Messages)
                {
                    Console.WriteLine("MESSAGE: " + msg.Text);
                    q.DeleteMessage(msg.Id, msg.PopReceipt);
                }
            }
        }

        q.Delete();
    }
}
...