Hi Nuwan, APIEntry was brought to the top most level, with the intention of making the cache clearing optimal when API/Subscription update happens. However if we are to clear the cache more efficiently while revoke and refresh happens, then we have to think of a different structure. Then ApplicationEntry would have to be brought to the top most level, and ApplicationEntry would have a list of TokenEntries instead of APIEntries. A TokenEntry being the object at the leaf level would have all the cache keys, starting with a specific access token.
[image: Inline image 1] I think with one type of Index we can only make one type of removal more efficient. Either we have to choose which operation we need to make more efficient, or else we have introduce two index caches. AmilaD On Wed, May 6, 2015 at 3:10 PM, Nuwan Dias <[email protected]> wrote: > 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 > -- *Amila De Silva* WSO2 Inc. mobile :(+94) 775119302
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
