Problèmes de délai d'expiration du pool de connexion Akka .NET

Question

Nous créons un nouveau système utilisant Akka.NET et disposons d'une configuration de base de cluster avec fragmentation et persistance.

Nous avons utilisé la documentation officielle ainsi que certains articles de blogs Petabridge pour que le sharding fonctionne correctement. Cependant, nous avons rencontré un problème où les fragments dépassent le nombre maximal de connexions autorisées par le pool de connexions SQL Server. En tant que tel, nous recevons le message suivant ...

2017-04-20 14: 04: 31,433 +01:. 00 [Avertissement] « Délai d'attente expiré Le délai d'expiration écoulé avant d'obtenir une connexion Cela peut être dû au fait que toutes les connexions groupées étaient utilisées et que la taille maximale du pool a été atteinte. "

Nous pensons que cela se produit lorsque les fragments mettent à jour le journal de fragmentation.

Comment le module sharding ne gère-t-il pas correctement ses connexions SQL? Y a-t-il un problème de configuration ici?

Est-il possible de l'amener à réessayer lorsque ce type d'erreur se produit? En l'état, nous perdons des messages pour chaque occurrence de cette erreur.

Voici les HOCON pertinentes

cluster.sharding { 
    journal-plugin-id = "akka.persistence.journal.sharding" 
    snapshot-plugin-id = "akka.persistence.snapshot-store.sharding" 
} 
persistence { 
    journal { 
     plugin = "akka.persistence.journal.sql-server" 
     sql-server { 
      class = "Akka.Persistence.SqlServer.Journal.SqlServerJournal, Akka.Persistence.SqlServer" 
      connection-string = "Server=.;Database=akkasystem;Integrated Security=true" 
      schema-name = dbo 
      auto-initialize = on 
     } 
     # a separate config used by cluster sharding only 
     sharding { 
      connection-string = "Server=.;Database=akkasystem;Integrated Security=true" 
      auto-initialize = on 
      plugin-dispatcher = "akka.actor.default-dispatcher" 
      class = "Akka.Persistence.SqlServer.Journal.SqlServerJournal, Akka.Persistence.SqlServer" 
      connection-timeout = 30s 
      schema-name = dbo 
      table-name = ShardingJournal 
      timestamp-provider = "Akka.Persistence.Sql.Common.Journal.DefaultTimestampProvider, Akka.Persistence.Sql.Common" 
      metadata-table-name = ShardingMetadata 
     } 
    } 
    snapshot-store { 
     sharding { 
      class = "Akka.Persistence.SqlServer.Snapshot.SqlServerSnapshotStore, Akka.Persistence.SqlServer" 
      plugin-dispatcher = "akka.actor.default-dispatcher" 
      connection-string = "Server=.;Database=akkasystem;Integrated Security=true" 
      connection-timeout = 30s 
      schema-name = dbo 
      table-name = ShardingSnapshotStore 
      auto-initialize = on 
     } 
    } 
} 

Answer 1

Il peut être un signe que la revue SQL est inondé avec les événements entrants si fortement, que les déclencheurs de délai d'attente de connexion, alors qu'un événement est en attente pour la prochaine connexion de la piscine pour être libéré. De votre config je soupçonne, que cela pourrait avoir lieu si vous avez commencé à persister un événement et créer des fragments/entités avec un ratio élevé. Les journaux SQL existants vont connaître une augmentation significative de la vitesse dans un avenir proche (voir batching journals). Espérons que cela pourrait aider à résoudre vos problèmes.