Det finns en JIRA-biljett CSHARP-1018 för att spåra det här problemet. I princip ignorerar föraren timeout-alternativet när maskinen inte är tillgänglig. Timeout-alternativet ignoreras om maskinen är avstängd eller inte tillgänglig.
Se JIRA-biljetten för att följa utvecklingen i denna fråga.
Se lösningen som publicerats på CSHARP-1231 för ett sätt att ServerSelectionTimeout kan ställas in i den aktuella 2.0.0-versionen av drivrutinen om du föredrar det tillvägagångssättet för att använda kortare timeouts för specifika operationer.
Om du använder det nya 2.0 async API kan du använda en avbokningstoken för att tillämpa din egen timeout för den övergripande operationen.
Så jag skulle rekommendera metoden för avbokningstoken i den tidigare kommentaren. Att använda korta servervalstimeouter kan resultera i falska undantag under replikuppsättningsval om servervalstimeouten är kortare än den tid det tar för ett val att slutföra.
Du kan skriva något så här:
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);
}
I det här exemplet, även om ServerSelectionTimeout
fortfarande är standardvärdet på 30 sekunder, avbryts just denna operation efter bara 500 millisekunder (ungefär, avbrytningen kan ibland ta något längre tid).