Understanding reactivemongo log messages, possible performance issue in my application

[Victor Caballero]

Hi,

I'm trying to figure out the meaning of a reactivemongo log message because I don't know if I'm facing a performance issue or it's completely normal.

The message is:

2016-09-08 17:11:47,866 [DEBUG] from reactivemongo.core.actors.MongoDBSystem in reactivemongo-akka.actor.default-dispatcher-3 - [Supervisor-1/Connection-2] RefreshAll Job running... Status: {{NodeSet None Node[172.16.2.198:27017: Primary (1/10 available connections), latency=69], auth=Set() }}

I'm concerned about the part that says "1/10 connections".

During most of the time while the application is running I see "10/10 connections available."

I only use one connection in my application, see the following code:

override lazy val mainDb: DB = {
  val connection = driver1.connection(inject[List[String]](identified by 'MongoDBServers), MongoConnectionOptions())
  connection(inject[String](identified by 'MainMongoDatabase))
}

The thing is, does calling one connection() mean that I should see "9/10 connections available" at most? Are these numbers connection pool specific? Or are they the total mongodb connections that the database can handle?

Thank you all.

[Cédric Chantepie]

Hi,

First any possible issue is logged as WARN, rather than DEBUG which must only be considered to debug an already confirmed issue.

Then, I think there is a misunderstanding. The MongoConnection of ReactiveMongo doesn't represent a network connection, but a pool managing several physical/network connections ( http://reactivemongo.org/releases/0.11/documentation/tutorial/connect-database.html ).

From there, I don't see anything in the DEBUG message that could lead to think there is an issue.

Best regards

[Cédric Chantepie]

Take care to the following points:

- The mentioned code is using the MongoConnection.apply function, which is being deprecated , and should be replaced by the new database(..) function (which returns a Future of DefaultDB).
- The DB reference is assigned to a val, doing so if this ref is erroneous due to resolution issue (e.g. network issue), it will never be recovered as eval'ed only once (even more true with the new resolution).