This project has moved and is read-only. For the latest updates, please go here.

using in ASP.NET MVC 3 with AutoFac

Aug 11, 2012 at 8:43 PM

I don't know if MVC 3 or Autofac or Azure is the issue, but I get random connection timeouts when making calls. I create a generic "context" class that has all of my Repository collections in it. Using AutoFac, that is injected into my controllers using:

            builder.RegisterType<Context>().InstancePerLifetimeScope();

Should I treat the MongoRepository instances as singletons? What's the best practice in an MVC app?

Aug 16, 2012 at 11:45 PM

Are you using the latest version? Older versions (relying on older mongo-csharp drivers) might be affected by this (see also this, this and this for connectionstring options etc.). I'm afraid without more information, a testcase or example code I can't reproduce the problem (also the MongoDB server itself might be causing some trouble because of old(er) versions or network related problems or... anything actually).

Aug 17, 2012 at 1:01 AM

I'm using mongorepository 1.3.2 and mongo driver 1.5. The stack is listed below. In this particular call, it's doing a mapreduce so it's going directly to the collection object in the driver. It happens after the app has been idle for a while (no recent requests have come in so I assume something ages out).

The "fix" is to kill the webserver (or make sure it's getting requests often enough that connections don't age out). My question is really more about best practice with using this lib a DI framework on an MVC app (ie, should the Repository objects be created per request, per session, etc.)

---

   at System.Net.Sockets.NetworkStream.Read(Byte[] buffer, Int32 offset, Int32 size)   at MongoDB.Bson.IO.BsonBuffer.LoadFrom(Stream stream, Int32 count) in C:\source\mongo-csharp-driver\Bson\IO\BsonBuffer.cs:line 307   at MongoDB.Bson.IO.BsonBuffer.LoadFrom(Stream stream) in C:\source\mongo-csharp-driver\Bson\IO\BsonBuffer.cs:line 280   at MongoDB.Driver.Internal.MongoConnection.ReceiveMessage[TDocument](BsonBinaryReaderSettings readerSettings, IBsonSerializationOptions serializationOptions) in C:\source\mongo-csharp-driver\Driver\Internal\MongoConnection.cs:line 442   at MongoDB.Driver.MongoCursorEnumerator`1.GetReply(MongoConnection connection, MongoRequestMessage message) in C:\source\mongo-csharp-driver\Driver\Core\MongoCursorEnumerator.cs:line 296   at MongoDB.Driver.MongoCursorEnumerator`1.GetFirst() in C:\source\mongo-csharp-driver\Driver\Core\MongoCursorEnumerator.cs:line 253   at MongoDB.Driver.MongoCursorEnumerator`1.MoveNext() in C:\source\mongo-csharp-driver\Driver\Core\MongoCursorEnumerator.cs:line 141   at System.Linq.Enumerable.FirstOrDefault[TSource](IEnumerable`1 source)   at MongoDB.Driver.MongoCollection.FindOneAs[TDocument](IMongoQuery query) in C:\source\mongo-csharp-driver\Driver\Core\MongoCollection.cs:line 526   at MongoDB.Driver.MongoCollection`1.FindOne(IMongoQuery query) in C:\source\mongo-csharp-driver\Driver\Core\MongoCollection.cs:line 1703   at MongoDB.Driver.MongoDatabase.RunCommandAs(Type commandResultType, IMongoCommand command) in C:\source\mongo-csharp-driver\Driver\Core\MongoDatabase.cs:line 965   at MongoDB.Driver.MongoDatabase.RunCommandAs[TCommandResult](IMongoCommand command) in C:\source\mongo-csharp-driver\Driver\Core\MongoDatabase.cs:line 942   at MongoDB.Driver.MongoCollection.MapReduce(BsonJavaScript map, BsonJavaScript reduce, IMongoMapReduceOptions options) in C:\source\mongo-csharp-driver\Driver\Core\MongoCollection.cs:line 1175   at GearGawker.Web.Database.Context.GetTagCounts() in C:\Users\jkeene\Projects\GearGawker\GearGawker.Web\Database\Context.cs:line 148   at GearGawker.Web.Controllers.BaseController..ctor(Context context) in C:\Users\jkeene\Projects\GearGawker\GearGawker.Web\Controllers\BaseController.cs:line 21   at GearGawker.Web.Controllers.GearController..ctor(Context context) in C:\Users\jkeene\Projects\GearGawker\GearGawker.Web\Controllers\GearController.cs:line 26   at lambda_method(Closure , Object[] )   at Autofac.Core.Activators.Reflection.ConstructorParameterBinding.Instantiate()

Aug 17, 2012 at 1:47 AM
Edited Aug 17, 2012 at 1:54 AM

I am assuming, based on your reply and gut-feel, that currently you're instantiating a repository per session (or even for longer lifetime). Personally I'd probably instantiate a repository per request (or even per method) since that would also be the way I'd do it for, say, a SqlServerConnection. MongoDB-CSharp uses a connection-pool (as does SqlServer) to retrieve connections from so there's (I guess) no need to create a long-lived connection since retrieving a connection from a connectionpool "costs" next-to-nothing.

Having a long-lived connection could cause your problem because of stuff timing out, connections with (even very little) packet-loss, or simply other related network I/O stuff (TCP keepalive etc.) I guess.

Having said that, it shouldn't be a problem to have a long-lived connection but since there is not "autoreconnect" a (for whatever reason) dropped connection should be handled by the application by catching the exception. More on this (and some possible causes) here. Also specifying a timeout in the connectionstring might help.

(Also: the stacktrace isn't really complete without the actual exception)

Aug 17, 2012 at 1:11 PM

That seems to have fixed it. I had that originally, but also was doing Dispose on my container and I guess that was causing conflicts. So Per Request and no IDisposable and seems to work great.

 

Thanks!