Istnieje bilet JIRA CSHARP-1018 śledzić ten problem. Zasadniczo sterownik ignoruje opcję limitu czasu, gdy maszyna jest niedostępna. Opcja limitu czasu jest ignorowana, jeśli urządzenie jest wyłączone lub niedostępne.
Proszę odnieść się do zgłoszenia JIRA, aby śledzić postępy w tej kwestii.
Zobacz obejście opublikowane w CSHARP-1231 dla sposobu, w jaki ServerSelectionTimeout można ustawić w bieżącej wersji 2.0.0 sterownika, jeśli wolisz takie podejście do używania krótszych limitów czasu dla określonych operacji.
Jeśli korzystasz z nowego interfejsu asynchronicznego interfejsu API 2.0, możesz użyć tokena anulowania, aby zastosować własny limit czasu do całej operacji.
Więc polecam podejście tokena anulowania w poprzednim komentarzu. Używanie krótkich limitów czasu wyboru serwera może skutkować fałszywymi wyjątkami podczas wyborów zestawu replik, jeśli limit czasu wyboru serwera jest krótszy niż czas potrzebny na zakończenie wyborów.
Możesz napisać coś takiego:
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);
}
W tym przykładzie, mimo że ServerSelectionTimeout jest nadal domyślną wartością 30 sekund, ta konkretna operacja zostanie anulowana po zaledwie 500 milisekundach (w przybliżeniu anulowanie może czasami potrwać nieco dłużej).
