This approach will work for clearing caches when an API update or an Application/Subscription update happens. Which are quite rare occurrences of a production system. IMO what happens more frequently in a running system is the refresh and revoke of actual end user tokens (based on the behaviour of the applications). I still don't see how we can easily clear a cache entry on that kind of a scenario through this approach. Does that process become easier in some way as well?
Thanks, NuwanD. On Wed, May 6, 2015 at 7:20 PM, Sanjeewa Malalgoda <[email protected]> wrote: > Yes i think this should work and it will make our life easy :) > > Lets isolate user flows associated with cache. Please add if i missed > anything. > > 01. Invoke API and then we need to add validation information to cache. > 02. Delete Application - delete all tokens associated with application > 03. Remove subscription - remove cache entries associated with > unsubscribed API. > 04. Remove API - remove cache entries associated with API. > 05. Regenerate access token - remove cache entry for previous token. > 06. Revoke access token - then remove all cache entries assicated with > revoked token. > 07. Revoke access tokens by application , user - remove cache entries. > > Also as discussed need to check the effect of having 2 cache with 2 > different validity periods. And what happen if one cache expired while > other is still pointing to it. > Lets carefully evaluate these flows and fix this. > > Thanks, > sanjeewa. > > On Wed, May 6, 2015 at 11:44 AM, Uvindra Dias Jayasinha <[email protected]> > wrote: > >> +1, Looks good to me. >> >> On 6 May 2015 at 11:34, Amila De Silva <[email protected]> wrote: >> >>> Hi All, >>> >>> When caching is enabled on Gateway, KeyValidationInfoDTO object is kept >>> in the cache against a cache key having the following structure; >>> >>> cacheKey = accessToken + ":" + apiContext + "/" + apiVersion + >>> resourceUri + ":" + httpVerb + ":" + authLevel; >>> >>> This structure makes cache retrievals efficient, but poses several >>> problems when removing entries. >>> >>> For example, when removing an API subscribed under an Application, we >>> have to delete cache entries associated with that API. But since the cache >>> key is a composition of several parts, finding cache entries related to a >>> given API is not a straightforward task. >>> >>> With the existing implementation, following steps are performed when >>> removing entries linked with a particular API, >>> a. Finding all Applications the API is subscribed to >>> b. Getting all active tokens issued for those Applications. >>> c. Creating all possible cache keys that could be present in the key >>> cache. >>> d. Calling cache.remove on all the keys created >>> >>> Since we have access to the database in which tokens are stored, we have >>> the ability of finding all the tokens associated with an API. But when >>> having a third party Key Manager, this option won't work. Therefore a >>> different mechanism is needed to find Cache entries associated with an API. >>> >>> Proposed solution is to introduce a second cache, which acts as an index >>> for the main (existing) cache. Structure of the existing cache and the >>> cache Key will remain the same. >>> >>> *Structure of the new cache * >>> >>> The combination of apicontext, version will be used as the cache key and >>> the entry will be an APIEntry. Structure of the APIEntry will be like this. >>> >>> [image: Inline image 4] >>> >>> When needed to delete cache entries for an API, first the Index cache >>> will be looked up using API context + version as the key. This will return >>> all the ApplicationEntries which are present in the main cache and also to >>> which the API has subscribed to. ApplicationEntry will have a list of cache >>> keys, which are present in the main cache, and which contains a token >>> obtained under the enclosing Application. >>> >>> We have to add entries to the Indexing cache at the same time we add a >>> new entry to main cache. >>> >>> Will explain how different invalidation tasks are performed by only >>> using these two caches in a mail to follow. >>> >>> Would highly appreciate your thoughts on this approach. >>> >> >> >> >> -- >> Regards, >> Uvindra >> >> Mobile: 777733962 >> > > > > -- > > *Sanjeewa Malalgoda* > WSO2 Inc. > Mobile : +94713068779 > > <http://sanjeewamalalgoda.blogspot.com/>blog > :http://sanjeewamalalgoda.blogspot.com/ > <http://sanjeewamalalgoda.blogspot.com/> > > > -- Nuwan Dias Technical Lead - WSO2, Inc. http://wso2.com email : [email protected] Phone : +94 777 775 729
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
