[CDRIVER-413] Mongo C driver does not respect readPreferenceTags Created: 23/Aug/14 Updated: 26/Aug/14 Resolved: 26/Aug/14 |
|
| Status: | Closed |
| Project: | C Driver |
| Component/s: | None |
| Affects Version/s: | 0.96.4 |
| Fix Version/s: | 1.0.0 |
| Type: | Bug | Priority: | Critical - P2 |
| Reporter: | Denis Gladkikh | Assignee: | Christian Hergert |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Attachments: |
|
||||
| Issue Links: |
|
||||
| Description |
|
I have a replica set with 3 nodes:
1. It seems like having "readPreference=nearest" and "readPreferenceTags=instance:11111111-1111-1111-1111-111111111113" in connection strings does not change readPreference behavior, read preference needs to be explicitly set via one of the mongoc_client_set_read_prefs or mongoc_collection_set_read_prefs. Which is fine, not great, but fine. Also I attached an example which I used to verify that. When I use mongoc_read_prefs_t with tags - this example fails because it cannot find node, which should be used for search. |
| Comments |
| Comment by Christian Hergert [ 26/Aug/14 ] |
|
No thank you Denis! Fixing it is easy, finding the bug is the hard part! |
| Comment by Denis Gladkikh [ 26/Aug/14 ] |
|
Hi Christian, Thank you for fixing it. At the because we did not use readPreferenceTags (not intentionally) - we decided to just keep readPreference=nearest for this release. But for next release we will probably pick this change. Thank you for fixing it! |
| Comment by Christian Hergert [ 25/Aug/14 ] |
|
This commit will also be useful, to set a proper error response as found from your test case. https://github.com/mongodb/mongo-c-driver/commit/979f1c1b99cf45f3fbcb4f68600080dd3a1077f6 |
| Comment by Christian Hergert [ 25/Aug/14 ] |
|
Hi Denis, Would you mind applying this patch to your mongo-c-driver build and let me know how it goes? https://github.com/mongodb/mongo-c-driver/commit/022bc04198fc2d0e2100895eefabe46328bf334e |
| Comment by Christian Hergert [ 25/Aug/14 ] |
|
Thanks for reporting this Denis, I'll take a look Monday PDT and verify. |