IvanF

Eccoci con un altro piccolo incidente di percorso: la dimensione massima delle Azure Queue è stata portata da 8KB a 64KB dalla versione 2011-08-18 in poi. Fantastico! Un po’ più di spazio disponibile va benone, specialmente su messaggi con molti metadati da inviare.

Se però come me provate a creare un messaggio con una dimensione di 10KB usando l’SDK 1.5 (Ottobre 2011) riceverete un bell’errore.

A questo punto per capire esattamente dove fosse il problema mi sono armato di JustDecompile (visto che il buon vecchio Reflector non è più free, proviamo quello di Telerik) e ho decompilato il CloudQueueMessage da Microsoft.WindowsAzure.StorageClient.dll e… sorpresa! Nel costruttore c’è un bel limite massimo hardcoded a 8192 byte:

CloudQueueMessage.MaxMessageSize = (long)8192;

Come risolvere il problema? Scaricando la versione 1.6 dell’SDK di Azure dove le librerie client sono state aggiornate coi nuovi limiti e decompilando la stessa dll adesso si ha:

CloudQueueMessage.MaxMessageSize = (long)65536;

Oggi ho perso l'intero pomeriggio a lottare contro questo problema, quindi voglio condividere la cosa in modo da evitare ad altri di spaccarsi la testa sulla stessa cosa.
Stavo eseguendo una query semplice sul Table Storage di Azure utilizzando PartitionKey e RowKey per recuperare una specifica entità in una tabella specifica (es.: http://127.0.0.1:10002/devstoreaccount1/Spaceship (PartitionKey = '380 ',RowKey = '1234 ')).
Durante i test, il primo scenario era dove non esisteva entità con PK e RK date e ho usato una semplice query che termina con l'operatore FirstOrDefault tipo:

TableRepository.FindWhere (p => p.PartitionKey == entity.Spaceship.CountryCode.ToString () & &

. p.RowKey == entity.SerialNumber) FirstOrDefault ();

e mi aspettavo u null, ma in realtà ho cominciato a ricevere errori 404 col seguente dettaglio: 

<error xmlns="http://schemas.microsoft.com/ado/2007/08/dataservices/metadata"> 

  <code>ResourceNotFound</code> 

  <message xml:lang="en-US">The specified resource does not exist.</message> 

</error>

Finalmente siamo partiti! Un bel Proof of Concept su Azure per una bella architettura distribuita Cloud – OnPremise. Prima si prova Azure, poi AWS.

Cercherò di postare un po’ di “Appunti di viaggio” di quest’avventura con problemi, vantaggi, pregi e difetti, performance individuati in modo da poter aiutare futuri avventurieri.

Proveremo di tutto di più:

• Azure Table Storage – SimpleDB: come NoSQL per salvare grandi quantità di dati
• Blob Storage – S3: per salvare dati di grandi dimensioni
• Azure Queue – SQS: per la comunicazione tra i diversi ruoli sul cloud all’interno della stessa Region
• SQL Azure – MySql: per la parte relazione sul cloud
• SQL Data Sync: per sincronizzare database distribuiti cloud – OnPremise
• Service Bus – SNS+SQS: per utilizzare il pattern publish/subscribe per la distribuzione di dati tra region e OnPremise
• Traffice Manager: per bilanciare automaticamente le chiamate dei client alla region Azure più vicina
• MongoDB: ci saranno anche esperimenti con MongoDB per confrontare un NoSQL Document Based con I key-value offerti da Microsoft e Amazon
• Altro: MEF, Automapper, AppFabric, Caching, TPL

Si parte!