During the adhesive test, a serious bug was found in the MongoDB official drive 1.1.0.4184.

During the adhesive test, we found that after using the background for a period of time, we would not be able to connect to the database. The error reported by viewing logs is roughly

Connection refused because too enabled open connections: 819

Checking the number of connections through mongostat is indeed exaggerated because there are nearly 819 connections. Trying to specify the maximum number of connections to 10000 at startup seems to solve the problem of restarting MongoDB.

However, after several page refreshes, the number of connections reaches 4000. In the past, even if the number of connections was under great online pressure, it was within 50. The first time we saw the number of connections was several thousand.

First, do you wantProgramThe problem is caused by the fact that in the program, we need to perform a count operation of about 100 times for each line chart to get the total number of points:

Although the Parallel library is used in the program, it is single-threaded when there is only one line, so the Parallel library problem is eliminated.

In addition, the number of connections on each page is greatly increased, and there is no time to fall back.

This is because the connection is not released. After checking the official documentation, you do not need to explicitly release the connection after each call.

Write a simple program to test:

StaticLogin Server = MongoDB. Driver. Login server. Create ("MongoDB: // 192.168.129.172: 20000 /? Slaveok = true");Static VoidMain (String[] ARGs ){While(True) {Console. Readline (); var DB = server. getdatabase ("Qqtest"); Var Col = dB. getcollection ("Test");Try{Console. writeline (Col. Count ());}Catch(Exception ex) {console. writeline (ex. Message );}}}
 

Obviously, press enter once to increase the number of connections by 1! However, the strange thing is that the master that writes data does not have this problem, so the connection string is changed to the Master Address.

MongoDB: // 192.168.129.142: 20000/

It is normal. No matter how you press ENTER or loop several hundred times, only one connection is added, indicating that the connection is reused.

At this point, it must be the connection to the slave. This problem is also hidden.

At that time, this version was directly referenced from nuget.Source codeDownload To The 1.1.0.4184 SourceCodeDebugging

After debugging, we found that mongoserver. CS has one method:

  Private   Void Instancestatechanged ( Object Sender, Object ARGs ){ Lock (Instances ){ If (Instances. Any (I => I. State = running serverstate. Connected & I. isprimary )){// Console. writeline ("server state: connected "); State = mongoserverstate. connected; Return ;} If (Settings. slaveok ){  If(Instances. Any (I => I. State = running serverstate. Connected & (I. issecondary | I. ispassive ))){                          // Console. writeline ("server state: connected "); State = mongoserverstate. connected; Return ;}} If (Instances. Any (I => I. State = running serverstate. Connecting )){// Console. writeline ("server state: connecting "); State = mongoserverstate. Connecting; Return ;} // Console. writeline ("server state: disconnected "); State = mongoserverstate. disconnected ;}}

Remove the comment statement to check the running status:

In this method, the server status will be changed according to the connection status change. After connecting to the database, because slaveok enters the blackbody statement, instances already has a status of connected, however, because I is neither issecondary nor ispassive, it cannot meet the conditions and is directly changed to state = unknown serverstate. disconnected. That is to say, for slaveok, the database cannot be considered to have been connected every time, and the database is reconnected every time! We can see that every time we finally go to state = mongoserverstate. Disconnected, we should actually run state = mongoserverstate. Connected. I think the author here is probably trying to add a slaveok judgment. For slave, issecondary and ispassive are both false, so I changed the simhei code to the following:

 If(Instances. Any (I => I. State = running serverstate. Connected &&(! I. isprimary ))){
 

Run the program again and find that this problem has been solved... Let's take a look at the running situation:

This is the case. After a connection, no connection is initiated for subsequent requests.

 

If you want to update the client to see if the latest client version solves this problem, you can download the latest version 1.3 from the official website. So I want to see how the author modified the file, view the history of the file, and see the change record of the Code in a history:

We can see that the previous judgment section has been deleted. This is a lot clearer! Set the corresponding status directly. The slaveok judgment is not related to the status setting.

I will share with you the troubleshooting process and remind you to be careful when using open-source components.