[JAVA-3484] MongoDB Java driver SRV record resolving is ignoring the port from the record Created: 25/Oct/19  Updated: 27/Oct/23  Resolved: 05/Nov/19

Status: Closed
Project: Java Driver
Component/s: Cluster Management
Affects Version/s: None
Fix Version/s: None

Type: Task Priority: Major - P3
Reporter: Atwood Wang Assignee: Jeffrey Yemin
Resolution: Works as Designed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Hi,

 

According to the public documentation regarding the "DNS Seedlist Connection Format" and its examples, the java driver is supposed to resolve both the hostname and port behind the SRV record.

 

However, in the implementation of DnsSrvResolver, it is only getting the host from the SRV record and it constructs the ServerAddress assuming the mongo instance is running on the default port: 27017.

 

Is this a bug in the code or is this by design? If it is by design, I suggest we update the documentation and clearly states that the java driver assumes the mongo is running on the default port.

 

Related source code:

https://github.com/mongodb/mongo-java-driver/blob/29edbd42c9acce4e197e764c481b58808bb45f73/driver-core/src/main/com/mongodb/internal/connection/DefaultDnsSrvRecordMonitor.java#L77-L78

 

Thanks a lot,

Atwood

 



 Comments   
Comment by Atwood Wang [ 05/Nov/19 ]

I see, thanks a lot for the explanation, you can close this issue.

Comment by Jeffrey Yemin [ 04/Nov/19 ]

wangzicong@bytedance.com

I stepped through the code and it appears to be working as per specification. The relevant test that demonstrates it is here.

I'm guessing the root cause of the confusion when looking at the source is the behavior of the ServerAddress(host, port) constructor. Note that this condition will evaluate to true:

 
new ServerAddress("host:27018", 27017).getPort() == 27018

The constructor privileges the default mongod/mongos port (27017) and allows it to be overruled by a port in the host name.

Generated at Thu Feb 08 08:59:43 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.