Bug ID 490681: Memcache entry for dynamic user leaks

Last Modified: Nov 07, 2022

Affected Product(s):
BIG-IP APM(all modules)

Known Affected Versions:
11.4.1, 11.5.0, 11.5.1, 11.5.1 HF1, 11.5.1 HF10, 11.5.1 HF11, 11.5.1 HF2, 11.5.1 HF3, 11.5.1 HF4, 11.5.1 HF5, 11.5.1 HF6, 11.5.1 HF7, 11.5.1 HF8, 11.5.1 HF9, 11.5.10, 11.5.2, 11.5.2 HF1, 11.6.0, 11.6.0 HF1, 11.6.0 HF2, 11.6.0 HF3, 11.6.0 HF4

Fixed In:
12.0.0, 11.6.0 HF5, 11.5.3, 11.4.1 HF9

Opened: Nov 13, 2014

Severity: 3-Major

Related Article: K17470


A race condition causes a memcache entry to remain in memcache forever.


The user state information for the user remains unchanged. If the user is locked out in memcache, the user state remains locked out.


Due to a race condition between identifying dynamic users in MySQL and removing them from memcache (based on timestamp), some memcache entries remain. Although the entry is removed from MySQL, it remains in memcache.


The only way to recover is to remove the user using telnet to access memcache (which is not a typical operation and is difficult to perform).

Fix Information

Now a self expiry is set for each memcache object (which is configurable). With this change, each user remains in the cache only for the configured duration.

Behavior Change

Guides & references

K10134038: F5 Bug Tracker Filter Names and Tips