Hi all, I have tried the same test, disabling all the caching in two nodes. It worked fine without any failures.
thanks, On Thu, Jul 19, 2018 at 5:46 PM Senthalan Kanagalingam <sentha...@wso2.com> wrote: > hi all, > > Have we implemented a cache invalidation mechanism for authentication > related caches? Because when I have tried with 2 node deployment without > the sticky session. I have faced significant failures in during the 2nd > step. > > After analysing the logs, we found the flow of the failed transactions, > [image: Untitled drawing.jpg] > 1 - Initialize request > 1.1 - Add authentication context to cache > 1.2 - Add authentication context to db > > 2 - 1st step authentication request > 2.1 - Check cache, no matching value > 2.2 - Get authentication context from db2 > 2.3 - Update the cache and db > > 3 - 2nd step authentication request > 3.1 - Check cache, found old authentication context > > Then the authentication fails as it has the old authentication context > > We need to invalidate the old cache in the first node when it updated in > the second node. I check in the framework module, there are no > CacheEntryListener implemented to perform this invalidation. I think we > haven't faced this issue as used sticky session. But we want to implement > this cache invalidation mechanism. > > thanks, > Senthalan. > -- > > *Senthalan Kanagalingam* > *Software Engineer - WSO2 Inc.* > *Mobile : +94 (0) 77 18 77 466* > <http://wso2.com/signature> > -- *Senthalan Kanagalingam* *Software Engineer - WSO2 Inc.* *Mobile : +94 (0) 77 18 77 466* <http://wso2.com/signature>
_______________________________________________ Dev mailing list Dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev
