Last Modified: Apr 10, 2019
See more info
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.2, 11.5.2 HF1, 11.6.0, 11.6.0 HF1, 11.6.0 HF2, 11.6.0 HF3, 11.6.0 HF4
12.0.0, 11.6.0 HF5, 11.5.3, 11.4.1 HF9
Opened: Nov 13, 2014
Related AskF5 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.