Closed GoogleCodeExporter closed 8 years ago
I try to understand the process, tell me if i misunderstood:
1. a "get" operation hit:
https://github.com/memcached/memcached/blob/1.4.22/memcached.c#L2961 , the
state is it->refcount > 1 and it->time is not updated.
2. at the same time, a "set" operation is going and hit
https://github.com/memcached/memcached/blob/1.4.22/items.c#L150, the "search"
item happens to be the "get" item.
3. the "search" item's refcount force to be 1 and free by slabs_free!
4. the "set" operation then call slabs_alloc and get the same item.
5. the "set" operation update(overlayed) the item.
6. the "get" operation response the overlayed item to requester.
Original comment by zarcardfly@gmail.com
on 28 Mar 2015 at 2:28
That is the bug with tail_repair_time, and is why we turned it off by default
in newer versions. It's only supposed to exist to work around a legitimate
refcount leak, which we haven't had in a while.
Do you have this bug outside of tail_repair_time?
Original comment by dorma...@rydia.net
on 28 Mar 2015 at 5:36
No, thanks for your reply.
Original comment by zarcardfly@gmail.com
on 29 Mar 2015 at 3:11
ok, closing this.
Original comment by dorma...@rydia.net
on 29 Mar 2015 at 4:44
The help tips say that tail_repair_time is default to be 3 hours, it may need
to be fixed, and maybe add a warning.
[10:43:34]~/prog/memcached-1.4.22 $ ./memcached -h | grep -A 2
'tail_repair_time'
- tail_repair_time: Time in seconds that indicates how long to wait before
forcefully taking over the LRU tail item whose refcount has leaked.
The default is 3 hours.
Original comment by zarcardfly@gmail.com
on 30 Mar 2015 at 2:49
Original issue reported on code.google.com by
zarcardfly@gmail.com
on 28 Mar 2015 at 1:59