[JAVA-3856] Database connection error is not notified or notified after server selection timeout. Created: 10/Oct/20 Updated: 22/Sep/21 Resolved: 20/Oct/20 |
|
| Status: | Closed |
| Project: | Java Driver |
| Component/s: | Cluster Management |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Andrew Kaplanov | Assignee: | Ross Lawley |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Description |
|
I try to connect to not existing database.
Further it prints on console:
This means that onError() was not called. When MongoClient is created with serverSelectionTimeout option as below:
Execution result is:
Both cases are unacceptable for me. Database connection error should return immediately. |
| Comments |
| Comment by Andrew Kaplanov [ 12/Oct/20 ] |
|
Hi Ross Lawley, thank you for reply. I hope double connection cost will be fixed in new release. I didn't understand at first about server selection timeout, since repeated connection attempts are not shown in the log. I made a test to check the connection to the database that appeared, everything works as it should. The task can be closed, thanks. Excuse for troubling.
|
| Comment by Ross Lawley [ 12/Oct/20 ] |
|
Thanks for the ticket, if you extended the latch await it would timeout shortly after the 60 seconds. It asks a good question, why does it take 60+ seconds when the server selection timeout is 30 seconds? This is an issue with how implicit sessions are handled within the driver which essentially requires a connection to determine if sessions are supported and then a connection for the operation.
The driver itself is backed by a connection pool and monitoring threads. Why does the driver not immediately return when a connection errors? This is because when working with distributed systems, network issues and server events can be expected. So the driver is designed to be as robust as possible. The common case for deployments are they are available, healthy and usable. All MongoDB drivers favor allowing operations to proceed as soon as possible in the common case, at the cost of surprising behavior in uncommon cases - such as network events, replicaset topology changes etc.. For more information please see the Server Discovery And Monitoring specification. All the best, Ross |