System.TimeoutException
The exception that is thrown when the time allotted for a process or operation has expired.
Minimum version: >= 2.0 >= Core 1.0
Statistics
8
How to handle it
try
{
}
catch (System.TimeoutException e)
{
}try
{
}
catch (System.TimeoutException e) when (e.Message.Contains("something"))
{
}try
{
}
catch (System.TimeoutException e) when (LogException(e))
{
}
private static bool LogException(Exception e)
{
logger.LogError(...);
return false;
}How to avoid it
We haven't written anything about avoiding this exception yet. Got a good tip on how to avoid throwing System.TimeoutException? Feel free to reach out through the support widget in the lower right corner with your suggestions.
Links
YouTube videos
Possible fixes from StackOverflow
Protobuf's metadata inspection is not threadsafe. This error is "rare" but happens a lot in huge serializations that are done in parallel. I had this exact error in my project where I serialize approximately 70 million objects. You can fix it by generating the metadata AHEAD of serialization:
Serializer.PrepareSerializer<YourCustomType1>();
Serializer.PrepareSerializer<YourCustomType2>();
Do that code somewhere ahead of serialization, perhaps a static constructor, for each of your custom types that are serialized.
You can also try to increase Protobuf's metadata inspection timeout to try and aid you, but in the case of a true deadlock in the Protobuf code this really just delays your exception:
// Initialize Protobuf Serializer for 5 minutes of wait in the case of long-waiting locks
RuntimeTypeModel.Default.MetadataTimeoutMilliseconds = 300000;
I'm thinking that the TransactionAbortedException is actually a timeout. If so you should find that the InnerException of the TransactionAbortedException is a timeout.
You should be able to get rid of it by making sure that the timeout of the transactionscope is longer than the command timeout.
Try changing the transaction scope to something like this:
new TransactionScope(TransactionScopeOption.Required, TimeSpan.FromSeconds(60))
And also set an explicit timeout on your context. Should be something like:
myContext.CommandTimeout = 30; //This is seconds
This issue can happen in 2 scenarios.
- If your ActorService method processing is taking more than the default timeout, then you need to change OperationTimeout value. By default it is 5 minutes. If you want to change the timeout, you can change it by adding assembly FabricTransportServiceRemotingProviderAttribute in your client assembly.
- If first scenario is not the case, then you can try below mitigation for a known bug.
- Specify Port 0 in the Service Manifest for the ActorService endpoint. By default, ActorEndpoint will be listed in ServiceManifest but port won’t be there.
This is how it will look for ActorService after you make change.
<Endpoint Name="Actor1ActorServiceEndpoint" Port="0" />
We are aware of the problem and a fix is on the way.
According to the attached Rider and dotnet logs, this problem is not related to Rider IDE.
There appears to be some first-time experience feature of dotnet that requires an access to dotnet/sdk/NuGetFallbackFolder which is not given so you get an error in the logs but that is probably not the real root case.
The issue is somewhere in your network between your computer and NuGet server as per the log message The download of 'https://api.nuget.org/v3-flatcontainer/microsoft.win32.registry/4.4.0/microsoft.win32.registry.4.4.0.nupkg' timed out because no data was received for 60000ms.
You should probably check your network and dotnet/NuGet settings.
In case it helps anyone we were seeing these timeouts on long running (over 5 minute) operations. Following Suchi's hint about the FabricTransportServiceRemotingProviderAttribute we added the following lines to our SF projects AssemblyInfo.cs to increase the timeout to 1 hour.
[assembly: FabricTransportServiceRemotingProvider(OperationTimeoutInSeconds = 3600)]
[assembly: FabricTransportActorRemotingProvider(OperationTimeoutInSeconds = 3600)]
(Also note if you're using Azure Service Buses the maximum lock time is 5 minutes, so you'll have to implement some lock renewal code to support long running operations)
Source: Stack Overflow