Last Modified: Oct 16, 2023
Affected Product(s):
BIG-IP APM
Known Affected Versions:
11.5.1 HF1, 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.1 HF10, 11.5.1 HF11, 11.5.2 HF1, 11.5.3 HF1, 11.5.3 HF2, 11.5.4 HF1, 11.5.4 HF2, 11.5.4 HF3, 11.5.4 HF4, 11.4.1, 11.5.0, 11.5.1, 11.5.2, 11.6.0, 11.6.1, 11.6.2, 11.6.3, 11.6.3.1, 11.6.3.2, 11.6.3.3, 11.6.3.4, 11.6.4, 11.6.5, 11.6.5.1, 11.6.5.2, 11.6.5.3, 12.1.0 HF1, 12.1.0 HF2, 12.1.1 HF1, 12.1.1 HF2, 12.1.2 HF1, 12.1.2 HF2
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).
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.