Open mefarazath opened 5 years ago
Product APIs should expose the intentional business functionalities related to its domain.
IMO, introducing an API to troubleshoot cache issues is not a valid requirement. WDYT?
Providing this capability through JMX is also an option. Basically we can expose the cache clear functionality through an MBean. Something similar can be found at [1]
[1] - https://github.com/omindu/test-mediator/tree/master/src/main/java/org/wso2/sample/mediator
@darshanasbg API is not the correct word I guess. What I had in my mind was a mechanism to clear the caches.
Something similar to what we have in XACML.
This would be more useful in a dev scenario
We can have a developer mode of the WSO2 Identity Server. The developer mode will include all the standard features, plus developer features like the mentioned Cache Invalidation API. This should resolve the concern raised by @darshanasbg. WDYT?
I like that idea. Any other developer-friendly features we find down the road we can add into this mode. And it will not affect the normal functionality of the server.
Having a general mechanism to clear cache would not be the correct thing to have.
I'm not convinced on the XACML caching clearing capabilities as well...
One example I could think is, where IS connected to external user store, and there are other applications also directly updating the user store... There it would make sense to have cache API to clear user-mgt related cache... (Please note this is just a close example I could think right now. This one is not perfect use case)
Likewise, we need to think about what's the problem we solve by providing this capability & whether this is the right approach to solve that.
@darshanasbg Agreed. Not all caches need to be cleared or invalidated from outside.
Similar to your example, in XACML the attribute store could be an external user store which can be updated directly without going through IS. So I guess the cache clearing for attribute cache can be justified in such scenarios.
@tharindu-bandara : DX of the product another aspect, where product users will develop some artifacts (like adaptive authentication scripts, XACML policies, SP configs, IdP configs) etc, test that and deploy it on the server...
But I assume you all not referring that aspect. You want to trace, monitor how server\runtime behave...
@mefarazath The solve the original topic, we can switch off cache by configurations (in identity.xml)... And still, I think this is also something we should get rid of sense for end users (identity admins, dev ops) those configurations not relevant.
@mefarazath : Agreed on your view on XACML policies... In that aspect, it makes sense to have this capability XACML caches we have...
This is a suggestion to have an API that can be used to invalidate local caches. This could be useful in testing and during troubleshooting cache related issues/functionality.
Right now the most reliable way to clear a cache would be to restart the server.