I am building the application in Mule 4 to cache the response from http request component (for 1 hours). I use the response to validate the jwt. Whenever there is a failure, I need to clear the cache and re-invoke the http request. Component used is : Cache Scope
My Current Code looks like below:-
<ee:object-store-caching-strategy name="Caching_Strategy" doc:name="Caching Strategy" doc:id="50e44473-b55a-4bc3-b53a-18e4229a31a3" keyGenerationExpression="#['token']" >
<os:private-object-store persistent="false" maxEntries="${caching.maxEntries}" entryTtl="${caching.entryTtl}" expirationInterval="${caching.expirationInterval}" />
</ee:object-store-caching-strategy>
I don't have any specific requirement to make it private object store but disabling it does not allow me to configure the maxEntries, entryTTL and Expiration Interval.
It would be more helpful if you could guide me the ways to
clear the cache (could not find any docs mule 4 related to clear the cache)
how can i keep it as non private object store and define those parameters like entryTtl, maxEntries etc.
when do we need to use the private object stores?
I have already tried the exchanges examples for configure the cache ( but there is no mention of clear the cache).
I am using Mule Runtime 4.2.2 and On Prem Mule
I have raised a support ticket with Mulesoft and received the below replies
1) Invalidate Cache is shown only in the palette from the Anypoint Studio Version 7.4.1. Not shown in earlier version of studio.( I was using 7.3.2)
2) They are adding the documentation for the invalidate cache in Mule 4.
3) Usage Note : Cache Scope and the 'Invalidate Cache' processor should share the same Caching_Strategy).
4) In order to explicitly define object store and ttl for a Cache Scope, please ensure object store related modules are added to the project.
This can be done by simply adding a 'Store' processor in your mule flow, this will add all necessary modules to your mule application.
Then, on the Caching Strategy, General > Reference > Object Store, you can select Edit Inline and define your object store with explicit settings such as
- Max entries
- Entry ttl
- Expiration interval
You can remove the unused 'Store' processor as well.
Hope it helps others
There is a palette called invalidate cache in the latest Mule versions. You can simply use it to delete the cache for a cache scope.
You will require a private object store when you want to persist the key used for caching permanently and also to implement time limits like TTL for a cache.
Related
Using eko/gocache, the docs suggest that the dev can use a custom store by implementing the StoreInterface. I'm working on a custom cache to use as part of the library's chain cache but one sticking point is the Set. Here is its definition:
Set(ctx context.Context, key any, value any, options ...Option) error
Option is a function that takes and configures an Options object, both from the library package. here is how the library passes it to my cache's setter: github
Within the library's cache implementations, the configured Options object is then read to discern, for example, the expiration date of the cache entry: example
The issue I face is that Options (declared here) makes all its properties private, so when I implement my own Set(), I have no way to read it to figure out when the cached entry should expire.
How is the custom StoreInterface implementation supposed to figure out the caching options used?
The private properties were made public as part of version 4 of the library. I had to upgrade to the next major version to resolve my issue.
I want to develop a page where all the cache lists will show and the user can clear a cache by clicking a button.
But I am facing a problem to get all the cache keys which have been set.
Serenity doesn't needs cache keys as list. So there is no way to retrieve keys from serenity cache classes.
If you need to retrieve keys, you can create new classes what implement IDistributedCache and/or ILocalCache. Then register this classes from startup.cs. Also don't forget to remove serenity code from there
And before you register your own cache implementation, don't forget to add services.AddMemoryCache(); for memory cache implementation if you use.
Then you can get your implementation everywhere like code below. StaticProvider property is resolves registered classes for you.
(LocalCache.StaticProvider as MyCustomLocalCacheProvider).GetAllKeys();
(DistributedCache.StaticProvider as MyCustomDistributedCacheProvider).GetAllKeys();
Looking at caching settings in the web.config I came across the Caching.ScavengeInterval entry:
<!-- SCAVENGE INTERVAL
Determines how often scavengable caches are scavenged.
Default value: 3 minutes.
-->
<setting name="Caching.ScavengeInterval" value="00:03:00" />
Which caches does it affect, and is there automatic cache scavenging built in to Sitecore?
What does Cache scavenging do in a Sitecore context?
I'm particularly interested in whether it affects IsUserInRole caching.
This isn't going to answer your question directly, but hopefully it will give a push in the right direction.
You can use Sitecore Rocks to view the current caches, there is a column which tells you which caches are flagged to be scavengable:
http://www.sitecore.net/Community/Technical-Blogs/Trevor-Campbell/Posts/2013/02/28-Days-of-Sitecore-Rocks-Manage-Part-3.aspx
On a default install of Sitecore it only affects GeoIp and ClientDataStore. Unfortunately:
The client data store cache stores information about each
authenticated user, such as the username or other user properties.
Sitecore Cache Configuration Guide - page 20
That is the wrong cache for your needs, you are interested in the IsUserInRoleCache and that is flagged as Scavengable:false
You can dig into yourself, use dotPeek decompiler and take a look at the following class in Sitecore.Kernel.dll:
Sitecore.Caching.Cache
Sitecore.Caching.CacheManager
Sitecore.Configuration.ClientDataStore
Background: We are using grails 2.1.1. We are not using any DB as of now. We make a web service call for each response on another server.
Now the problem is, there is web service call which returns some static data in XML form and this data is usable throughout the application. The size of the xml is around 40kb. This xml contains static data like, project_list, status_type_list etc. and we have to use this in various dropdowns and menu items in different gsp pages.
So, please suggest us the best way to handle this data. So that it doesn't effect our page load time and browsing experience. And also we can easily use the data on client side.
responding to your comment on the question. I would prefer using annotation based caching over the plugin, if the requirement is as simple as you state that it is.
If the calls are being made from server-side and you want to cache the results of the parsed XML then you can do something like:
#Cacheable("staticDataCache")
def getStaticDataFromXML() {}
You can then use the above method to pull the maps, lists whatever data structure you've used to store the result and it will pull it from the cache.
and then another service method to flush the cache, which you can call frequently from a Job.
#CacheFlush("staticDataCache")
def flushStaticDataCache() {}
Use the cache plugin to cache the static xml data. And then add some policy as to when the cache should be updated... (i.e. using a job to check if the xml has changed every hour)
I'm new with AppFabric Server caching but after playing around with it everything has been working like a dream.
I can add for example datatables to my cache and get that back to use just fine.
I got exited about this functionality and tried to test this with one 3rd party vendors dll that includes login session data (session id, date's etc.)
I created WCF service with method where you consume this dll to login and I store that session to my cache.
This works just fine and I can verify this by looking at statistics of my cache with PowerShell.
Then I created another method that is supposed to pick up this cached session and use it to execute actions. This is where I'm running to the wall.
I can see that I have been able to get session from cache, but information within session object is null (session id, date's...)
I've been serching help for this from everywhere but nobody seams to face this issue.
So my question is
Can AppFabric server cache ALL field values of given object (Public/Non-public not having any role)?
Is there any way to see actual existing content of cache where you would see keys and cached objects with values?
Thanks for all possible comments!
Regards
Mikko
In AppFabric you can only cache objects that are serialisable (or serializable for US readers :-) ). The fact that you have been able to store your session objects in the cache suggests that they are indeed serialisable. But to figure out what's going on here we'll need to probe a little deeper.
By default with binary serialisation, all fields/properties of an object are serialised, public and private (whereas XML serialisation only picks up the public values). We aren't told which flavour of serialisation AppFabric uses, but binary serialisation tends to be more efficient so it's a reasonable assumption that that's what gets used under the covers. However, it's possible to override the serialisation behaviour using the NonSerialized attribute, so that items marked NonSerialized don't make it into the serialised version of the object. The MSDN page for Selective Serialisation specifically advises that security-sensitive information should be marked as nonserializable.
A session ID definitely comes under the heading of security-sensitive information as it's key for session hijacking, so I should say that's the problem you're facing. You could confirm this by having a look inside the 3rd party DLL with ILDasm or Reflector to see if the fields inside the session class are indeed marked as not serialised.
Can you get round this? Well there is, of course, nothing to stop you creating your own Session class that you populate from the 3rd party's object where you keep all the properties serialisable and caching that instead. Bear in mind, however, that you're then essentially doing the very thing they've tried to stop you doing...