[JAVA-627] readPreference=nearest fails sometimes Created: 22/Aug/12 Updated: 25/Jun/13 Resolved: 23/Aug/12 |
|
| Status: | Closed |
| Project: | Java Driver |
| Component/s: | API |
| Affects Version/s: | 2.9.0 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Paul Mahon | Assignee: | Unassigned |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
2.9.0-RC2 drivers, CentOS5, Mongo v. 2.0.6 |
||
| Description |
|
My java program performs some queries which fail only when the read preference is set to nearest (either through a mongo uri with readPreference=nearest, or by setting it in the Java code). The cluster I'm using has 4 replica sets, each one with a primary and a secondary. The query I'm trying to perform is similar to:
When running the method when the read preference is set to nearest, it throws the exception after running a few queries successfully. When running without read preference set to nearest, it doesn't throw the error. |
| Comments |
| Comment by Jeffrey Yemin [ 23/Aug/12 ] |
|
It's still a bit strange that you got back null though, rather than exception. Please post to mongodb-user if you don't get to the bottom of this yourself. |
| Comment by Paul Mahon [ 23/Aug/12 ] |
|
This may not be related to the Java API. The cluster ended up with a very large number of connections on the mongod processes for some reason. The number is slowly coming down. If I cannot reproduce with the connection count low, I'll close this bug as invalid. |
| Comment by Paul Mahon [ 22/Aug/12 ] |
|
Waiting a bit has no effect. Also the readPreference is not related. I managed to get the errors once with readPreference=secondary. It failed about 10% of the times I ran it. I have been unable to cause the errors when I list only a single mongos. |
| Comment by Paul Mahon [ 22/Aug/12 ] |
|
I should add that the program is multi-threaded, and I'm usually running it with 8-20 threads running queries. |
| Comment by Paul Mahon [ 22/Aug/12 ] |
|
I'm having some trouble reliably reproducing it. Sometimes I'll run it and it'll fail, and then if I run it again it'll succeed. Earlier today it was failing every time I ran it with nearest. Now it's failing only rarely with nearest. I think it fails more often if I don't run any queries for a few minutes, but I'm not sure. I'll see if I can get it to fail with just one mongos given. |
| Comment by Jeffrey Yemin [ 22/Aug/12 ] |
|
Can you try with a single mongos instead of a list? I want to rule out a bug in the mongos failover code. |
| Comment by Paul Mahon [ 22/Aug/12 ] |
|
Yes, 4 shards, using 2.0.6. The mongo URI I used to create the Mongo object lists all the mongos servers. |
| Comment by Jeffrey Yemin [ 22/Aug/12 ] |
|
To confirm: your cluster is sharded and the java driver is connecting to a mongos, and your mongos version is 2.0.6? |