Azure Table Service - 409 erreurs partout

Question

Au cours des 4 dernières heures, plus de 200 demandes ont échoué sur le rapport de table azure 409. J'ai regardé autour et cela signifie la duplication PK. Comme il est une table spécifique pour l'exploitation forestière, je ne me soucie pas des clés pour mon RowKey est Guid.NewGuid() ...

Y at-il une autre raison pour la table d'azur pour retourner un 409 ou que je vois en fait UUID entrent en collision?

PS: Je l'espère vraiment qu'il ya une autre raison, parce que sur les 4 dernières heures, je l'ai seulement 50k demandes manié ...

Answer 1

Très probablement votre client n'a pas vu la réponse HTTP 200 indiquant une insertion réussie (timeout du client, erreur réseau, etc.), mais l'insertion s'est bien passée du côté serveur. Puis, lorsque le client a réessayé l'opération, il a reçu un 409 puisque l'entité existait déjà sur le serveur.

Vous pourrez voir une preuve de cela dans les journaux d'analyse de stockage si vous les activez.

Vous pouvez essayer de résoudre la défaillance initiale du client, mais cela ne résout finalement pas le problème car vous devez de toute façon gérer ce type de défaillance. Puisque vous écrivez simplement des données de journalisation alors vous ne vous souciez probablement pas du 409 sur la nouvelle tentative, donc la meilleure solution est de simplement l'ignorer. D'autres solutions possibles consistent à utiliser les opérations «Insérer ou remplacer» ou «Insérer ou fusionner» au lieu d'insérer simplement une insertion. Pour plus de contexte, voir https://github.com/Azure/azure-storage-java/issues/35 ou https://social.msdn.microsoft.com/Forums/azure/en-US/9ab80192-6450-41c2-a964-4ea092c1f6ef/table-storage-handling-retry-error-where-item-already-exists?forum=windowsazuredata.

Answer 2

Si vous appelez Guid.NewGuid() plus rapidement que l'horloge, cela peut générer le même Guid. Essayez de mettre quelques millisecondes entre Guid.NewGuid() appels.