Il existe un ticket JIRA CSHARP-1018 pour suivre ce problème. Fondamentalement, le pilote ignore l'option de délai d'attente lorsque la machine n'est pas accessible. Option de temporisation elle est ignorée si la machine est éteinte ou non accessible.
Veuillez vous référer au ticket JIRA pour suivre l'évolution de ce problème.
Voir la solution de contournement publiée sur CSHARP-1231 pour que le ServerSelectionTimeout puisse être défini dans la version 2.0.0 actuelle du pilote si vous préférez cette approche à l'utilisation de délais d'attente plus courts pour des opérations spécifiques.
Si vous utilisez la nouvelle API asynchrone 2.0, vous pouvez utiliser un jeton d'annulation pour appliquer votre propre délai d'expiration à l'opération globale.
Je recommanderais donc l'approche du jeton d'annulation dans le commentaire précédent. L'utilisation de courts délais de sélection de serveur peut entraîner de fausses exceptions lors des élections de jeux de réplicas si le délai de sélection de serveur est plus court que le temps nécessaire à l'exécution d'une élection.
Vous pouvez écrire quelque chose comme ceci :
var startTime = DateTime.UtcNow;
try
{
using (var timeoutCancellationTokenSource = new CancellationTokenSource(TimeSpan.FromMilliseconds(500)))
{
await collection.Find("{ _id : 1 }").ToListAsync(timeoutCancellationTokenSource.Token);
}
}
catch (OperationCanceledException ex)
{
var endTime = DateTime.UtcNow;
var elapsed = endTime - startTime;
Console.WriteLine("Operation was cancelled after {0} seconds.", elapsed.TotalSeconds);
}
Dans cet exemple, même si le ServerSelectionTimeout est toujours la valeur par défaut de 30 secondes, cette opération particulière sera annulée après seulement 500 millisecondes (environ, l'annulation peut parfois prendre un peu plus de temps).
