This long-known architectural issue is that currently every operation is sent back in the order in which it had been received. Thus for a set of requests A, B, C, D, any background fetch latency on item B will also affect service times with C and D.
Existing memcached protocol does not state that operations must be handled in order, but owing to the one implementation doing so and all clients having been built/tested against that implementation, it's possible that there are erroneous dependencies on current behavior.
|For Gerrit Dashboard: MB-10291|
|87263,9||MB-10291: lock connection properties when #cmd > 1||master||kv_engine||Status: MERGED||+2||+1|
|87316,7||MB-10291: DCP cannot use unordered execution||master||kv_engine||Status: MERGED||+2||+1|
|109715,64||MB-10291: Add support for OutOfOrder execution||master||kv_engine||Status: MERGED||+2||+1|
|116777,1||Merge branch 'OoO' into clean||master||kv_engine||Status: ABANDONED||0||-1|