L'événement RetryPolicy.Retrying ne se déclenche pas lors du traitement des erreurs transitoires pour SQL Azure?

Question

J'ai un site web hébergé en azure (en tant que service web) qui utilise sql azure comme backend.

Mes journaux d'erreurs ont été lourdement remplis avec ce qui semble être des erreurs transitoires de connexion réseau et sql. En tant que tel, j'ai implémenté le bloc de gestion des erreurs transitoires de la bibliothèque d'entreprise. Dans les tests il semblerait que son fonctionnement correctement.

Le problème que je rencontre est que je voudrais enregistrer les instances où cette logique de tentative se produit. De la documentation RetryPolicy.Retrying semble être l'événement que je suis après mais dans les tests il ne tire pas. Il y a beaucoup d'exemples en C# qui suivent le schéma suivant au feu cet événement:

var retryPolicy = new RetryPolicy<SqlAzureTransientErrorDetectionStrategy>(retryStrategy); 
// Receive notifications about retries. 
retryPolicy.Retrying += (sender, args) => 
{ 
    // Log details of the retry. 
    var msg = String.Format("Retry - Count:{0}, Delay:{1}, Exception:{2}", 
     args.CurrentRetryCount, args.Delay, args.LastException); 
    Trace.WriteLine(msg, "Information"); 
}; 

Je pensais que je l'avais adapté cela correctement mais en bref, ce qui ne va pas avec le code ci-dessous ?!

Private RetryManager As RetryManager 
Private WithEvents RetryPolicy As RetryPolicy 

Private Sub RetryPolicy_Retrying(ByVal sender As Object, ByVal args As RetryingEventArgs) 
    ' Log details of the retry. 
    Dim msg = String.Format("Retry - Count:{0}, Delay:{1}, Exception:{2}", args.CurrentRetryCount, args.Delay, args.LastException) 
    Trace.TraceInformation(msg) 
End Sub 

Private Sub SetupRetryPolicy() 
    'If its already set then lets not do it again 
    If RetryPolicy Is Nothing Then 
     RetryManager = EnterpriseLibraryContainer.Current.GetInstance(Of RetryManager)() 
     RetryPolicy = RetryManager.GetRetryPolicy(Of SqlAzureTransientErrorDetectionStrategy)("Exponential Backoff Retry Strategy") 
     ' connect sub as handler to event when retry occurs 
     AddHandler RetryPolicy.Retrying, AddressOf RetryPolicy_Retrying 
    End If 
End Sub 


Public Sub ExecuteAndDoStuff(ByVal connString As String, ByVal cmdText As String) 

    SetupRetryPolicy() 

    'get a connection with retry 
    Using conn As New ReliableSqlConnection(connString, RetryPolicy, RetryPolicy) 
     conn.Open() 
     Using cmd As SqlCommand = conn.CreateCommand 
      Try 
       cmd.CommandText = cmdText 
       ' this might be overkill, do I need to pass the retry policy in again for the command? 
       Dim dr As SqlDataReader = cmd.ExecuteReaderWithRetry(RetryPolicy, RetryPolicy) 
       '... do something with this datareader 

      Catch ex As Exception 
       'log error 
       Trace.TraceError("Query failed to execute despite retry logic: " & ex.ToString) 
       'continue to throw the error (picked up higher up the chain) 
       Throw ex 
      End Try 

     End Using 

    End Using 

End Sub 

Je suis tout à fait nouveau au moins la moitié de ce qui se passe dans ce bloc de code, mais avant tout un thows RTFM à moi - j'essayé!

Answer 1

Il est difficile de dire si quelque chose ne va pas dans votre code; il se pourrait qu'il n'y ait aucune erreur transitoire détectée. Comment faites-vous la détermination qu'il y a des erreurs transitoires? La première chose que je ferais est de m'assurer que vous avez une façon répétable de créer une erreur transitoire. La façon dont je configurerais le test est d'avoir une base de données de 1 Go dans la base de données SQL Azure, de la remplir avec des données jusqu'à ce qu'elle atteigne sa limite de stockage, puis d'ajouter plus de données (ce qui génèrera une erreur transitoire). à chaque fois).

Il y a deux choses à garder à l'esprit avec SQL Azure erreurs transitoires:

1) Ils sont très difficiles à tester car beaucoup d'entre eux dépendent de variables qui sont hors de votre contrôle; 2) Il y a quelques autres types d'erreurs qui peuvent être déclenchées, telles que les conditions de sweepage du routeur dans Azure, qui ne sont pas considérées comme transitoires; par exemple, les erreurs IOException ne sont pas capturées par la stratégie SQL Transient. Par conséquent, vous devez soit comptabiliser ces types d'erreurs séparément, soit personnaliser la stratégie pour inclure ces erreurs. Votre bloc catch doit intercepter ces erreurs dans votre implémentation actuelle.