[SERVER-8950] Getlasterror call return wrong result when the previous write op has chunk splitt Created: 12/Mar/13 Updated: 13/Mar/13 Resolved: 12/Mar/13 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | 2.0.7 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | chensi | Assignee: | Unassigned |
| Resolution: | Duplicate | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Operating System: | ALL | ||||||||
| Participants: | |||||||||
| Description |
|
The reason from the source code: |
| Comments |
| Comment by Scott Hernandez (Inactive) [ 13/Mar/13 ] |
|
I believe that case has been fixed as well. Can you please upgrade to 2.2.3 if you need this fix. If you are able to reproduce this on 2.2.3 or above please let use know. |
| Comment by chensi [ 13/Mar/13 ] |
|
sorry, I don't mean that. In my case, the getlasterror correctly went to the write Shard, but the lasterror information is reset because Split issuse ShardConnection::sync() operation. So when the api calls getlasterror, the result is not wanted. The following is the getlasterror result when i update record: {"singleShard":"shard2\/10.36.69.34:7111,10.38.148.37:7111,10.48.89.56:7111","n":0,"lastOp":5853335336846884895,"connectionId":100937,"err":null,"ok":1}the "n" field is *0* , and "updatedExisting" field is *missing* , not expected by api. |
| Comment by Scott Hernandez (Inactive) [ 12/Mar/13 ] |
|
I think you are describing Please upgrade to get this fix and many others – 2.4.0 will be released in the next 2 weeks and 2.2.3 is the current stable release with these fixes if you can't wait. |