> Thanks Robert. I'll try to get to this in the next couple of hours. If I
> don't I'll send update with my findings on Monday.

> On Friday, October 26, 2012 10:09:58 AM UTC-4, Robert Stam wrote:

>> In 1.6 it was possible for ReadPreference.PrimaryPreferred to use a
>> Secondary even if the Primary was available if the primary's ping time was
>> more than 15 ms slower than the primary. In 1.6.1 PrimaryPreferred will
>> always use the Primary if possible, and only use a Secondary if there is no
>> Primary (regardless of ping times). That could explain your first result.

>> The second result is harder to explain. It looks like you are connecting
>> directly to a secondary, because the ReadPreference appears to be ignored,
>> which only happens when connecting directly to a server.

>> Can you make sure you are actually connecting to the replica set in
>> replica set mode? One way you could do that is to put a breakpoint on your
>> call that is throwing the exception and checking the MongoServer.Instances
>> property and reporting back how many entries the Instances array has and
>> what the InstanceType is for each instance.

>> You could also check your MongoCursor.ReadPreference just before
>> executing the query to verify that the cursor has the ReadPreference you
>> wanted. In order to examine the cursor you might have to introduce an
>> intermediate variable.

>> Let me know what you find and we can proceed from there.

>> On Thu, Oct 25, 2012 at 5:39 PM, Nik Kolev <nko...@gmail.com> wrote:

>>> Environment:
>>> - host: Windows 7
>>> - mongod: v2.2 (mongodb-win32-x86_64-2008plus-2.2.0)
>>> - mongo setup: 3 mongod processes running on the same host in a replica
>>> set, 2 real and 1 arbiter
>>> - csharp driver: v.1.6.0.4624

>>> I create a MongoServer by providing a MongoServerSetings with the
>>> following properties:
>>> - SafeMode = SafeMode.True
>>> - Servers = a collecttion of all 3 mongods' MongoServerAddress-es
>>> - ReadPreference = PrimaryPrefered

>>> I have a function that asks the MongoServer for a collection
>>> (MongoCollection) of a database, first does a read on the collection and
>>> then attempts to do a write. The read succeeds but the write fails with the
>>> following stack trace (wrapped as JSON doc as Mongo in this case is backing
>>> a web service - please excuse the ugliness):
>>> ===
>>> {"responseStatus":{"errorCode":"MongoSafeModeException","message":"Safemode
>>> detected an error 'not master'. (Response was { \"err\" : \"not master\",
>>> \"code\" : 10056, \"n\" : 0, \"lastOp\" : { \"$timestamp\" : NumberLong(0)
>>> }, \"connectionId\" : 1569, \"ok\" : 1.0 }).","stackTrace":"[ById:
>>> 10/25/2012 8:53:40 PM]:\n[REQUEST:
>>> {id:1}]MongoDB.Driver.MongoSafeModeException: Safemode detected an error
>>> 'not master'. (Response was { \"err\" : \"not master\", \"code\" : 10056,
>>> \"n\" : 0, \"lastOp\" : { \"$timestamp\" : NumberLong(0) },
>>> \"connectionId\" : 1569, \"ok\" : 1.0 }).\r\n   at
>>> MongoDB.Driver.Internal.MongoConnection.SendMessage(MongoRequestMessage
>>> message, SafeMode safeMode, String databaseName) in
>>> C:\\work\\rstam\\mongo-csharp-driver\\Driver\\Internal\\MongoConnection.cs: line
>>> 549\r\n   at MongoDB.Driver.MongoCollection.Remove(IMongoQuery query,
>>> RemoveFlags flags, SafeMode safeMode) in
>>> C:\\work\\rstam\\mongo-csharp-driver\\Driver\\Core\\MongoCollection.cs:line
>>> 1312\r\n   at MongoDB.Driver.MongoCollection.Remove(IMongoQuery query) in
>>> C:\\work\\rstam\\mongo-csharp-driver\\Driver\\Core\\MongoCollection.cs:line
>>> 1272
>>> ===

>>> What's

>>> Guessing here the collection when initially obtained was backed by a
>>> connection to the slave replica and that's why the read succeeded but the
>>> write did not. If that's the case how would one use the driver for such
>>> scenarios?

>>> Moreover, going with my guess I changed the read preference to Primary
>>> (just Primary). Then even more weirdness happened. I got an exception even
>>> before the write was attempted, but when the function was trying to do the
>>> read:
>>> ===
>>> {"responseStatus":{"errorCode":"MongoQueryException","message":"QueryFailur e
>>> flag was not master and slaveOk=false (response was { \"$err\" : \"not
>>> master and slaveOk=false\", \"code\" : 13435 }).","stackTrace":"[ById:
>>> 10/25/2012 9:05:30 PM]:\n[REQUEST:
>>> {id:1}]MongoDB.Driver.MongoQueryException: QueryFailure flag was not master
>>> and slaveOk=false (response was { \"$err\" : \"not master and
>>> slaveOk=false\", \"code\" : 13435 }).\r\n   at
>>> MongoDB.Driver.Internal.MongoReplyMessage`1.ReadFrom(BsonBuffer buffer,
>>> IBsonSerializationOptions serializationOptions) in
>>> C:\\work\\rstam\\mongo-csharp-driver\\Driver\\Internal\\MongoReplyMessage.c s:line
>>> 99\r\n   at
>>> MongoDB.Driver.Internal.MongoConnection.ReceiveMessage[TDocument](BsonBinar yReaderSettings
>>> readerSettings, IBsonSerializationOptions serializationOptions) in
>>> C:\\work\\rstam\\mongo-csharp-driver\\Driver\\Internal\\MongoConnection.cs: line
>>> 475\r\n   at
>>> MongoDB.Driver.MongoCursorEnumerator`1.GetReply(MongoConnection connection,
>>> MongoRequestMessage message) in
>>> C:\\work\\rstam\\mongo-csharp-driver\\Driver\\Core\\MongoCursorEnumerator.c s:line
>>> 296\r\n   at MongoDB.Driver.MongoCursorEnumerator`1.GetFirst() in
>>> C:\\work\\rstam\\mongo-csharp-driver\\Driver\\Core\\MongoCursorEnumerator.c s:line
>>> 253\r\n   at MongoDB.Driver.MongoCursorEnumerator`1.MoveNext() in
>>> C:\\work\\rstam\\mongo-csharp-driver\\Driver\\Core\\MongoCursorEnumerator.c s:line
>>> 141
>>> ===

>>> I see the error in the mongod's log (this is the SECONDARY mongod's log):
>>> ===
>>> Thu Oct 25 22:05:30 [conn1665] assertion 13435 not master and
>>> slaveOk=false ns:mdm.policies query:{ ids: "1" }
>>> Thu Oct 25 22:05:30 [conn1665] problem detected during query over
>>> mdm.policies : { $err: "not master and slaveOk=false", code: 13435 }
>>> ===
>>> FWIW I don't see the first error I discussed captured in one shape or
>>> another in the mongod's logs - I checked in the logs for all 3 of my mongod
>>> processes.

>>> I assumed that setting the ReadPreference to Primary would let the
>>> driver know that all connections need to be asked of the primary mongod. I
>>> guess that's not what happened here for me?

>>> Ideas/Suggestions/Recs would be greatly appreciated.

>>> Thanks, -nik