Details
-
Bug
-
Resolution: Incomplete
-
Minor
-
None
-
3.0.1
-
Security Level: Public
-
None
-
We actively append to same key, we're doing 6 requests inside one second (and then stop updating).
We get ENGINE_TMPFAIL error from memcached daemon (tcp traced 11210) once in 20-30 seconds.
Update pattern:
# append
# if append fails /*does not exist*/, add
# if add fails /*other client did that add*/ appendWe actively append to same key, we're doing 6 requests inside one second (and then stop updating). We get ENGINE_TMPFAIL error from memcached daemon (tcp traced 11210) once in 20-30 seconds. Update pattern: # append # if append fails /*does not exist*/, add # if add fails /*other client did that add*/ append
Description
We get not well documented behavior of APPEND.
It gives ENGINE_TMPFAIL, while the system is not in degraded state.
We feel what happens is this:
case OPERATION_APPEND: |
case OPERATION_PREPEND: |
do { |
if ((ret = get(cookie, &i, it->getKey().c_str(), |
it->getNKey(), vbucket)) == ENGINE_SUCCESS) {
|
Item *old = reinterpret_cast<Item*>(i); |
|
if (old->getCas() == (uint64_t) -1) { |
// item is locked against updates |
itemRelease(cookie, i);
|
return ENGINE_TMPFAIL; |
}
|
Which results in this answer from memcached:
No. Time Source Destination Protocol Expert Info Len srcport
|
214162 2015-07-23 19:38:29.650829000 cust4sdf1db11 cust4rtc3 MEMCACHE Note Append Response (Unknown status: 134) 109 11210
|
|
Frame 214162: 109 bytes on wire (872 bits), 109 bytes captured (872 bits) on interface 0
|
Linux cooked capture
|
Internet Protocol Version 4, Src: cust4sdf1db11 (10.112.68.7), Dst: cust4rtc3 (10.112.68.42)
|
Transmission Control Protocol, Src Port: 11210 (11210), Dst Port: 53379 (53379), Seq: 1060019, Ack: 548139, Len: 41
|
Memcache Protocol, Append Response
|
Magic: Response (129)
|
Opcode: Append (14)
|
Key Length: 0
|
Extras length: 0
|
Data type: Raw bytes (0)
|
Status: Unknown (134)
|
[Value length: 17]
|
Total body length: 17
|
Opaque: 0
|
CAS: 0
|
Value: Temporary failure
|
We currently plan to work this around by retrying.
But we've very curious, what exactly goes on?
Maybe this is NOT a good behavior to put the burden of retrying to Client?
If the locking the comment talks about is a short one, and can be waited upon inside memcached daemon internally, why the problem is dumped on Client's head?!
That spends time to send answer to client, for it to think about it, to retry the call. It all goes through moxi in our setup.
We're not happy about that.
Attachments
Issue Links
- relates to
-
MB-21481 Request ability to distinguish concurrent access errors from other TMPFAILs
-
- Closed
-