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

22
elmah.io logo 9

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

If I had to hazard a guess, the issue is most likely a firewall issue. You should check the following

  • nslookup of the host (ds048719.mlab.com) from the C# Application Host
  • ping of the host (ds048719.mlab.com) from the C# Application Host (might fail, depending on mLab's settings)
  • That your IP address is whitelisted
  • Test the connection using the Mongo Shell from the same host where the C# Application is running. mLab has docs here.
  • Test the connection with a raw telnet, eg telnet ds048719.mlab.com 48719
  • Ensure you are using the correct authenticationDatabase (in your example, this is specified by the /db), this is usually admin but could be your database name if you are on a shared instance.

You can find the docs on connecting with the C# driver in the MongoDB C# Driver Docs. It is important to note the following:

The Database Component

The database component is optional and is used to indicate which database to authenticate against. When the database component is not provided, the “admin” database is used.

mongodb://host:27017/mydb

Above, the database by the name of “mydb” is where the credentials are stored for the application.

NOTE:

Some drivers utilize the database component to indicate which database to work with by default. The .NET driver, while it parses the database component, does not use the database component for anything other than authentication.

Finally, I would suggest in the future, obfuscate the hostname and port when posting to SO. While security through obscurity alone is a bad policy, it certainly adds a layer of defense for your MongoDB deployment.

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.

  1. 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.

https://msdn.microsoft.com/en-us/library/microsoft.servicefabric.services.remoting.fabrictransport.fabrictransportserviceremotingproviderattribute.aspx

  1. 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.

Solution: Updated SyncTimeout configuration to 10000. Tried with 5000 and failed, then with 10000 and fixed. Default value was 1000.

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)