Connection troubleshoot

Lucas Soares shared this problem 6 years ago
Solved

Hello.

I was wondering if you guys can create a "diagnostic" option to show debugging data when a connection are being estabelished.


I'm having some trouble with SSL connections in replicaset because the connection take very long time to stabilish (sometimes > 10 seconds). Connecting directly with the shell the connection are made in few miliseconds. I can't figure out what is going on.


Version: 4.5.6

Plataform: Windows


Thanks.

Replies (4)

photo
1

Hello. I made some tests and apparently the connection cannot be completed if I try to create a new one right after opening the program and after to connect to my previous session (automatically).

photo
1

ccb26af3482420c67d30963d2892754dThis picture shows the logging (uncomlete image for security reasons) and this connection spend almost 2 minutes to stabilish. Using the mongo tool it spend few milliseconds!

I wan't to help but there is no more information =/


Thanks.

photo
1

Thank you for your feedback.

Unfortunately, I can't reproduce the problem locally. If possible, could you give me the complete steps to reproduce it

photo
1

I made a blurred version of a heavy utilization of the NoSqlBooster. I think this will not help enough because of the blurry itself, but we can talk more about issues I found: https://youtu.be/QlaIrEvTY0o

The major part of the video shows connections (the connection itself or two clicks in a single collection or clicking to show the collection statistics) getting timeout.


Every time I connected to the database directly in the mongo shell. Once I even connected to all replica sets (with blurred screen) to show the replica statuses and oplog times.

All my replica sets are being monitored by Mongo Cloud Manager and I have not even one network or replication problem.


I think also the Replica read mode doesn't are working fine. I don't know what NoSqlBooster do different in those modes, but one replica set of mine connected with the secondary preferred read mode but didn't connected with the secondary.


A weird bug happened in 8:20 - The first two click in the collection doesn't worked (connection timeout). When I clicked run manually in the same editor, it runs but don't returned any document (isn't an empty collection). The second two click on the same collection doesn't work either, but running manually the script returned documents with the right response. The error in 6:15 is about the same thing. A red error saying the collection doesn't exists (in the admin) appeared, but I was trying to connect to a collection in another database.

I notice the description on the editor (with collection and database) was showing admin database for the first two clicks, but this is not the admin database.


Sorry for blurred screens but some information in those collection cannot be distributed.


I want NoSqlBooster to be great because I really like this tool, but me and many friends had those network issues. I also saw the log info and there is no information about connection issues.


I think you guys need multiple replica sets (not local machines) to make some stress test on the application... Creating connections, running scripts, closing connections, making all those many and many times in a row. I have like 100 mongo instances and I think this why I have so many problems with NoSqlBooster.


Thanks and I make myself available for testing any solution you guys can provide, even with my restricted time (this the reason I don't even tried to blurry only private information and maybe restricted more than needed).

photo
1

Also, one question. Why every time I double click a collection, the "connecting' loader is shown? The program should re-use the already made connection.

photo
2

Let me briefly respond to this question, each editor tab has an embedded MongoDB shell, and each embeded Shell will acquire an exclusive Mongo client. To reuse mongo client resource, we use a pool internally, if you close a tab, the tab's mongo client will be released to the free pool. Each-tab-each-connectoin does seem to be a waste of resources, but the advantage is that the programming model is simpler and easier to debug and locate errors. I also don't think this is the best way to do it. We may have multiple tabs sharing a connection in a future release

photo
1

I see.. I agree about the simpler programming model, but all mongo native drivers can manage connection pools by itself in the connection. I also think the tradeoff can be painfull if you have to create a connection every time, when errors by your own management can happen.


I think this update you said will help me and my friends a lot, because we use hundreds of editor tabs every day and we are wasting so much time waiting for connections to be stabilished.


Thank you very much for the answer. I hope my video can help you guys to improve your program and I'm waiting for next releases and fixes.

photo
1

Thank you for your patience.

We have worked out a new test build to add a run-time log console to "test connection" function. It will log more detailed connection-related events and time-related information. Please download and give it a try.

And, are you using an SSH connection in your video?

https://nosqlbooster.com/s3/download/releasesv4/nosqlbooster4mongo-4.5.7-beta.4.exe


/JfWLP8LHE2tlteUs5LX3wlT

photo
1

Hello! Thank you for this fast reply. I will give a try on this new build and then I let you know any news.


And not, I'm using normal connections with SSL only:


/UMjsyk8AAAAAElFTkSuQmCCAA==

/eGFQswEA00aGNQwAAACYNqBhAAAAjAo0DAAAgFGBhgEAADAq0DAAAABGBRoGAADAqEDDAAAAGBVoGAAAAKMCDQMAAGBU9KVhc+fONZlMubm5OQAAALJBbm6uyWTKy

photo
1

Hello again..

I did a first test using this new diagnostic logging and the first connection attempt never finished (I kept it running for almost two hours haha). I saved the log file and will attach with this message.

After that I changed the read preference to Preferred Primary and tried to connect again with success. And then I returned to the Secondary read preference and the connection was succesfully completed.

I don't know if this issue have a correlation to the read preference. This the configuration I'm using to connect (the first failed one):


/rLV30qFQqLe3Nx6PRyIRu91ONfAejoTQYrGsWbMmFArxro7u5TK1tbWiPYFAgC+tXr162bJl9fX18Xi8tbWVDJMtZ9FK1JdQKBSJRMhyqu348eOiDWvWrLHb7dRB3qiRnQMDAwMDA6Txqh5DihQpUqQppl1dXd3d3V1dXZRDn7u7uxUlTeLPzc3NvM1SlBP1jItRJkV2ziQdEgvQXXz4RhpAOhEIBEiBVK+Kx4OBQID0j7dBXCd9VtUnvkvsC1lI+WINqjaIn0nV6uvrxT7mfKSRIkWKdGqkrFuJFGvZsmUmiwALj0VCvMRxnEQlEAhYLBYO6LQLIUngkhaLhfWDPodCoe3bt0ciEZI0RryFRUvMFI2hRhVSKtbGmzNCllKxZu6CaqbFYuFN5JYtW+jD6tWrZV8BAADIjC4B1QKpipYoOQrRouivEC0K6FxSPPcjIpFIY2Mj386oi

photo
1

What's your MongoDB Server Version? you can run "db.version()" to get it.

photo
1

This specific one is 3.4.4


I have servers in those versions:

3.4.14, 3.4.10 and 3.4.7

photo
1

Add " Connection troubleshoot" feature in version 4.6.1

photo
1

Hello.


I had this same issue again with the version 4.7.1. Apparently the secondary read preference is freezing the connection. With secondary preferred I can connect normally and my replica set have all three members with normal status:


/2b273c391eece30c5eb4ff0aead2b0a4

photo
Leave a Comment
 
Attach a file