[JAVA-991] Cannot determine actual ReplSetStatus from singleton MongoClient getReplicaSetStatus() Created: 04/Oct/13 Updated: 31/Jan/18 Resolved: 31/Jan/18 |
|
| Status: | Closed |
| Project: | Java Driver |
| Component/s: | API |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Bob Kuhar | Assignee: | Unassigned |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Description |
|
Our application is such that the majority of it can work whenever the Mongo ReplicaSet is operating without a PRIMARY. Recently I had a requirement to produce a HealthCheck service that reported the following states based upon the availability and capability of the Mongo ReplicaSet ReadWrite: ReplSet is operating with a PRIMARY, GET services should 20x, PUT services should 20x I was surprised at how difficult it was to write this code with the 2.11.3 Java driver. The sticking point was that my application follows the http://docs.mongodb.org/ecosystem/tutorial/getting-started-with-java-driver/ convention of establishing a Singleton MongoClient. The ReplicaStatus object produced by this singleton provides no methods to assert the health of anything but the master (its toString(), however, does know this). This made it impossible to discriminate between ReadOnly and DOWN. I need the ReplicaSetStatus produced by the Singleton MongoClient to provide a direct way to interrogate the 3 states of the ReplSet as seen by the Application Server {ReadWrite, ReadOnly, DOWN}Here is my current ugly workaround. I am looking for a way to drive out the whole "freshClient" part. @Override else {
Alternatively, if I could as the MongoClient "can you support this ReadPreference right now?" or "can you support this WriteConcern currently?" that would work too, or maybe even better. /**
/**
|
| Comments |
| Comment by Jeffrey Yemin [ 31/Jan/18 ] |
|
I don't see this as something we should address. Even though getReplicaSetStatus presents a simple, synchronous API, it's not flexible enough to handle the wide variety of possible interrogations of the current ClusterDescription. Since registering a ClusterListener in MongoClientOptions is also fairly straightforward, and allows applications to detect whatever state they are interested in, I'm closing this one as Won't Fix. |
| Comment by Bob Kuhar [ 04/Dec/13 ] |
|
I can see how Thanks, |
| Comment by Jeffrey Yemin [ 04/Dec/13 ] |
|
Hi Bob, It looks like |