[SERVER-19393] new Mongo() connections to replica sets does not appear to be independent Created: 14/Jul/15  Updated: 10/Aug/15  Resolved: 10/Aug/15

Status: Closed
Project: Core Server
Component/s: Shell
Affects Version/s: 3.0.3
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: John Arrowwood Assignee: Sam Kleinman (Inactive)
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Operating System: ALL
Steps To Reproduce:

1. Create a replica set ONE, with authentication user ONE, password FOO, hosted on hosts: host1, host2, host3
2. Create a second replica set TWO, with authentication user TWO, password BAR, on host4, host5, host6
3. In the mongo shell (--nodb), attempt to interact with both of them at the same time, such as:

var c_one = new Mongo( 'ONE/host1,host2,host3' );
var c_two = new Mongo( 'TWO/host4,host5,host6' );

var db_one = c_one.getDB('someDB');
db_one.auth( 'ONE', 'FOO' );

var db_two = c_two.getDB('someOtherDB');
db_two.auth( 'TWO', 'BAR' );

The attempt to authenticate to db_two will fail.
Change only the order of declaration of c_one and c_two, and run it again, and the authentication to db_one will fail, and the authentication to db_two will succeed.

Participants:

 Description   

When I create multiple variables holding database connections, each with separate and distinct authentication credentials, which ever one I connect to second, I am unable to authenticate to. In my case, the database connections are both replica sets, though I do not know if that matters.

The shell SEEMS to be connecting to the different replica sets. However, something is not right because when I try to authenticate to the second one, it always fails. If I reverse the connection order, then the database that fails to authenticate reverses. There is not a credential problem. And it is not the order in which I authenticate, it is the order in which I connect.



 Comments   
Comment by Sam Kleinman (Inactive) [ 10/Aug/15 ]

The name of the replica set is, for the purposes of the shell (and likely other drivers) the unique identifier. I've tested the shell's behavior here, and with authenticated and unauthenticated connections, the shell manages connections correctly. Sorry about the confusion, I'm going to go ahead and close this ticket.

Regards,
samh

Comment by Kevin Pulo [ 15/Jul/15 ]

The name of the replica set is normally considered its unique identifier. Why else should they have a name? There are other things that will be confused by disjoint, separate replsets that the same name, for example, consider if a DNS problem accidentally swaps the IP addresses of a pair of perf and prod nodes. This isn't a problem for replsets with different names.

Comment by John Arrowwood [ 14/Jul/15 ]

It seems to me that a replica set should have a unique identifier. If it did, then the shell could cache and monitor the state of the replica set based on that unique identifier, and then this use case would be possible.

Comment by Randolph Tan [ 14/Jul/15 ]

The shell caches and monitors the state of the replica set globally so it does not support talking to disjoint replica sets with the same set name.

Comment by John Arrowwood [ 14/Jul/15 ]

One possible reason why I am getting this failure is the replica set names are the same, even though they are different sets. One is our production environment, one is our performance verification environment. The replica set names are the same because the one environment is a mirror of the other.

That is, I have two different connections, to different hosts, but with the same replica set name, and so the Mongo shell is treating them as the same connection, which is why the authentication is failing. This suggests that the object encapsulation one would expect by opening two different connections is somehow lost.

Generated at Thu Feb 08 03:50:49 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.