search

wso2 / product-is

Welcome to the WSO2 Identity Server source code! For info on working with the WSO2 Identity Server repository and contributing code, click the link below.
http://wso2.github.io/
Apache License 2.0
741 stars 719 forks source link

Cache Invalidation API #4916

Open mefarazath opened 5 years ago

mefarazath commented 5 years ago

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.

darshanasbg commented 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?

omindu commented 5 years ago

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

mefarazath commented 5 years ago

@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.

image

This would be more useful in a dev scenario

tharindu-b-hewage commented 5 years ago

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?

janakamarasena commented 5 years ago

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.

darshanasbg commented 5 years ago

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.

mefarazath commented 5 years ago

@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.

darshanasbg commented 5 years ago

@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.

darshanasbg commented 5 years ago

@mefarazath : Agreed on your view on XACML policies... In that aspect, it makes sense to have this capability XACML caches we have...