30

Jun

Windows Azure Lab – Storage pt.3 – Utilizzo delle Azure Storage Queues

Tralasciando il perchè si debbano utilizzare le code e l’esposizione di alcuni scenari tipi di utilizzo, spieghiamo semplicemente quali siano le API fondamentali per leggere/scrivere su una coda.

Come per ogni storage endpoint, bisogna creare l’account da cui estrapolare il client:

// initialize the account information
var storageAccount = CloudStorageAccount.FromConfigurationSetting("DataConnectionString");

// retrieve a reference to the messages queue
var queueClient = storageAccount.CreateCloudQueueClient();
var queue = queueClient.GetQueueReference("messagequeue");
queue.CreateIfNotExist();

Supponendo di avere una interfaccia in cui l’utente tramite una textbox voglia inviare un messaggio sulla coda, scriviamo:

  // add the message to the queue
var msg = new CloudQueueMessage(txtMessage.Text);
  queue.AddMessage(msg);
  txtMessage.Text = string.Empty;

E abbiamo finito. Per quanto riguarda la lettura, che può essere effettuata da qualsiasi applicazione in qualsiasi linguaggio (a patto di poter usare REST), questo è il codice .NET per estrapolare un messaggio:

// initialize the account information
  var storageAccount = CloudStorageAccount.FromConfigurationSetting("DataConnectionString");
  // retrieve a reference to the messages queue
  var queueClient = storageAccount.CreateCloudQueueClient();
  var queue = queueClient.GetQueueReference("messagequeue");

// retrieve messages and write them to the compute emulator log
  while (true)
  {
    Thread.Sleep(10000);
    if (queue.Exists())
    {
      var msg = queue.GetMessage();
      if (msg != null)
      {
        Trace.TraceInformation(string.Format("Message '{0}' processed.", msg.AsString));
        queue.DeleteMessage(msg);
      }
    }
  }

Nell’esempio sopra abbiamo un loop che itera sui messaggi disponibili. Inoltre, se il messaggio viene processato correttamente, è necessario rimuoverlo dalla coda.

Perchè rimuovere il CloudQueueMessage dalla coda? perchè di default il meccanismo di Azure fa “nascondere” il messaggio per un lease time, durante il quale se il consumer fallisce o si blocca o non computa correttamente il dato, il messaggio viene reimpostato visibile a tutti. Motivo per cui, se il processo va a buon fine, è necessario occuparsi direttamente della cancellazione dell’elemento.

by Roberto Freato on 6/30/2011
Post archive