[SERVER-9055] Explicitly detect invalid gle reuse when using 'releaseConnectionsAfterResponse' mode Created: 21/Mar/13 Updated: 10/Dec/14 Resolved: 01/Apr/13 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Greg Studer | Assignee: | Unassigned |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||
| Participants: | |||||||||
| Description |
|
If a application disobeys the always-gle-after-write requirements for the 'releaseConnnectionsAfterResponse' mode, we may not explicitly detect the failure but instead potentially return bad data from potentially another connection. Potential fix - method in ClientConnections::areAllAvailable( const vector<string> gleHosts ) and logic block in ClientInfo::getLastError() which throws a "incorrect use of gle in 'release connections after response' mode" error. |
| Comments |
| Comment by Eliot Horowitz (Inactive) [ 01/Apr/13 ] |
|
closing per conversation |
| Comment by Scott Hernandez (Inactive) [ 21/Mar/13 ] |
|
We should really do this as finding these mistakes in user code will be fairly hard and very annoying that the system didn't simply keep it from happening. Returning a false positive gle in either direction could dramatically effect the user code and application. |