[CSHARP-1260] Socket exceptions connecting to MongoDB Created: 28/Apr/15  Updated: 05/Apr/19  Resolved: 13/May/15

Status: Closed
Project: C# Driver
Component/s: Connectivity
Affects Version/s: 1.9.2
Fix Version/s: None

Type: Task Priority: Major - P3
Reporter: Matthew Evans [X] Assignee: Craig Wilson
Resolution: Done Votes: 0
Labels: question
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows Web Server 2008 R2 (SP1)


Attachments: Text File DocumentDatabaseOutputCacheProvider.cs    

 Description   

We have implemented a MongoDB based output cache provider for a hybrid ASP.NET web forms / MVC application.

The basic provider was modelled on this https://msdn.microsoft.com/en-us/gg650661.aspx

We modified the code to use the official C# provider (see attached)

Since deployment, we have seen a number of these exceptions:

System.Net.Sockets.SocketException (0x80004005): A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond <IP ADDRESS>>:27017

There are no obvious networking issues in our live environment. The MongoDB server is also currently the ASP.NET session state server.

Any pointers as to how to debug / configuration to check?



 Comments   
Comment by Craig Wilson [ 13/May/15 ]

Thanks for the update Matthew.

If you are using a replica set, then we'll ultimately use whatever is in the replica set configuration anyways (rs.config() from the shell). This means that, even if you change the app to use an IPAddress, if the replica set config is using a hostname, the driver will end up dropping the IPAddress and use the hostname.

In addition, for portability, we always recommending using the fully qualified domain name, so I'd suggest sticking with it and figuring out to rectify the DNS problems. Regardless, I'm glad you figured it out. Please feel free to ping back if you see any further troubles.

Craig

Comment by Matthew Evans [X] [ 13/May/15 ]

HI there,

Please close this ticket.

Network tracing indicated that we were having DNS resolution issues internally for our MongoDB server using the server name. Changing to the IP for the MongoServerAddress seems to have resolved the issue.

Thanks for your help

Comment by Matthew Evans [X] [ 29/Apr/15 ]

Hi Craig

Thanks.

We don't see similar issues with session state. We do sometimes see the following error in the log though

The state server has closed an expired TCP/IP connection. The IP address of the client is 192.168.16.111. The expired Read operation began at 04/28/2015 12:55:13.

Would you recommend installing the database on its own server? Rather than sharing resources with ASP.NET state service etc.

1. We dont use a connection string as such. We connect using the following code:

MongoServerSettings settings = new MongoServerSettings

{ Server = new MongoServerAddress(Settings.Instance.Get("Caching.OutputCache", "MongoDBName"), 27017) }

;
MongoServer server = new MongoServer(settings);

MongoDatabase mongo = server.GetDatabase("OutputCacheDB");
_cacheItems = mongo.GetCollection("CacheItems")

Settings.Instance.Get("Caching.OutputCache", "MongoDBName") returns the server name ("sunset")

Note no username and password. The server is not publicly accessible.

2. This is currently a standalone instance.

3. We have currently disabled the Mongo output cache and reverted to in memory. I will reimplement on on of the servers and see if we can get a trace for you.

Comment by Craig Wilson [ 28/Apr/15 ]

Hi Matthew,

Sorry you're having issues. Do you not see these problems with your session state? A few other questions:

1) What is your connection string?
2) What is your setup? Replica Set, standalone, etc...? If a replica set, could you provide the output of rs.config()?
3) Would it possible to get a network trace during one of the problems? https://msdn.microsoft.com/en-us/library/ty48b824%28v=vs.110%29.aspx. Specifically, we care about System.Net.Sockets.

Craig

Generated at Wed Feb 07 21:39:06 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.