[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:
db.mycollection.find("_id", "JC &|1100222232010210")

    public byte[] searchEquals(String table, String key) {
        DBCollection col = db.getCollection(table);
        DBObject o = new BasicDBObject("_id", key);
        DBObject oo = col.findOne(o, id);
        if(oo==null) throw new RuntimeException("Mongo searching "+table+" for =="+key+" resulted in nothing.");
        return ((String)oo.get("_id")).getBytes();
    }

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?

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