taille de la charge utile maximale CloudQueueMessage question

Question

Selon MSDN, la charge utile du message peut se prolonger jusqu'à 8 Ko (8192 octets):

La méthode AddMessage ajoute un message à l'arrière de la file d'attente. La taille d'un message peut atteindre 8 Ko. Son contenu doit être dans un format pouvant être encodé avec UTF-8.

Cependant, lors de l'ajout de messages dans la file d'attente que je reçois des exceptions pour les messages qui est la charge utile devrait être façon moins que 8192 octets, la région magique semble être autour de 6500 octets. Les données que j'envoie sont des chaînes pures, dont la taille est validée à la fois par le membre .Length et par une longueur envoyée par la source d'où elles proviennent (il existe une différence constante de 2 octets pour un délimiteur CRLF).

donc ma question est double:

1) Y at-il des données cachées jointes à la charge utile du message qui balloon sa taille ou de provoquer ce genre de comportement étrange? (Comme la limite étant appliquée à l'objet dans son ensemble et non pas seulement sa charge utile, mais même alors, comment peut-il compte par message 1,5 kb?)

2) Comment puis-je fiable vérifier que la charge utile est en effet en dessous de 8192?

et quelques informations supplémentaires: J'utilise le SDK 1.4 Azure avec VS 2010 Ultimate, exécutant les émulateurs de stockage de calcul & (je n'ai pas encore déployé cette application) en utilisant SQLExpress (2008 je pense).

confirmé également par l'intermédiaire du code que la taille maximale est de 8192 octets (dans le cas d'une certaine limite imposée du système d'appoint):

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

CloudQueueMessage: Max file d'attente Taille Message: 8192

Answer 1

Le La bibliothèque de client de stockage .NET (Microsoft.WindowsAzure.StorageClient.dll) base-64-encode le contenu du message de file d'attente, donc la limite effective est 8192 * .75 = octets lorsque vous utilisez la bibliothèque client .NET. (En effet, la base 64 codage ajoute une surcharge de 1/3.)

(Notez que vous ne ont à la base 64 encode. Il se trouve être la façon dont cette bibliothèque assure que le contenu du message de file d'attente peut être en toute sécurité intégrée dans XML, qui est l'exigence des places de service de file d'attente sur les messages)

---

EDIT:. Voici un exemple de code pour l'utilisation de l'espace de noms Microsoft.WindowsAzure.StorageClient.Protocol pour mettre du texte brut (base non 64 codé) dans un message de file d'attente (et par la suite le récupérer):

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(); 
    } 
}