Comment 1 for bug 1251123

There are a couple things to address here. The first is that list_tokens does not actually need to only return valid tokens. The only cases where list_tokens should be used is on the revoke_tokens_for_{user|project|domain|trust|etc} calls. These calls don't actually care if the tokens are valid or not (it's checked before they are added to the revocation list).

In the Grizzly timeframe, this list regularly could be filled with bogus/invalid tokens and when the token list hits a memcache page size, no further tokens for that user can be issued (token data is not returned, and therefore token isn't usable). In Grizzly this list also was simply appended (using the memcache append call) rather than loaded and inspected in any cases.

Inherently, this is a flaw in the use of memcache as a token store and the need to maintain an active list of tokens for the user.

In the Icehouse development cycle we will be moving to a new token revocation event system that will help eliminate the need for this specific tracking list, and remove the need to do the CAS work in memcache to be able to properly revoke tokens on the events that need to revoke many tokens (e.g. password change).

Would it be possible to re-use tokens (especially in the case of booting 1 VM per second)? This would help to alleviate the extra load due to memcache token management.