0
votes

I am using ReactiveMongo 0.12 with MongoDB 3.4. I am trying to understand how connection pooling works with MongoDB.

I have MongoDB installed in my remoteAddrr:27017. And I am using ReactiveMongo in my code as below.

import reactivemongo.api.MongoConnection
val driver = new reactivemongo.api.MongoDriver
val connection = driver.connection(List("remoteAddrr:27017")) 

According to documentation:

MongoConnection is a logical connection, not a physical one (not a network channel); It’s actually a connection pool. By default, a MongoConnection creates 10 physical network channels to each node.

So, in my code, I suppose the ReactiveMongo connection pool establishes 10 physical connections to the node remoteAddrr:27017.

But when I tested serverStatus inside mongo shell,

>var status = db.serverStatus()
> status.connections
{ "current" : 20, "available" : 51180, "totalCreated" : 66 }

So, how is it possible that there are 20 connections in the current shell session ? How is it possible that the number of unused incoming connections available is 51180 ? I also don't understand how the count of all incoming connections created to the server is 66.

1
Well (I'm guessing here), db.serverStatus is the status of the server, not the status of your client connections / sessions. - GPI
As indicated by the name serverStatus BTW, would rather not use such command but have a look at server log with a single client connected. - cchantep
@GPI So, am I wrong in understanding that the number of connections in the mongo server depends upon the number of connections opened by the client side driver ? - oblivion
@cchantep Could you please explain why would you not use serverStatus and what specifically to look at in the log ? - oblivion
@oblivion there is an obvious correlation. But even if your program is the single active client of the server, one might ask : have there been other clients since the last server reboot ? Are there any server connections that occur as part of the mongo cluster lifecycle ? ... And what else. You may very well find that the server issues connections juste by being part of a cluster or other internal purposes. I don't know. Seems possible though, and I would definitely not use a global server status "variable" to monitor a single client's activity. - GPI

1 Answers

2
votes

It may well be connections which weren't closed properly and which are currently waiting for their timeout. Depending of the driver you still have to "close" connections (actually you indicate that you no longer plan to use the connection you requested from the pool), despite the fact we are talking of a pool. That usually is caused by killing the application that maintained the pool, rather than doing a graceful shutdown.

But you are chasing a white rabbit here. To put it into perspective: you are using less than 0,04% of the available connections, consuming less than a three figure sum of RAM (a connection which does not execute a query consumes about 1MB serverside).

As per the 66 connections: this is the total number of connections created since the last restart of mongod.