I'm trying to use shared redis instance as a distributed cache for multiple aspnetcore services. My first idea was to simply prefix cache keys for each service to avoid clashes, but it doesn't seem to be possible (beside doing it manually when setting each value). At least I cannot find any such configuration option in AddStackExchangeRedis call.
Am I missing something, is this not supported or is my approach completely wrong?
I believe your approach is completely fine. The key prefix option exists under the InstanceName property and you can use it just as you would expect:
builder.Services.AddStackExchangeRedisCache(options =>
{
options.InstanceName = "your-key-prefix:";
});
Related
I see that Ignite currently supports the TTL feature to remove unusual keys. Is there any way to customize this TTL feature?
In my case, I have BinaryObjects in IgniteCache, key -> BinaryObject, and those BinaryObjects contain several values, one of them is a timestamp. Could I customize Ignite's built-in cleaning TTL functions somehow so that Ignite can check the timestamp value and decide to remove or keep a key?
Thank you
Yes and no. You can implement your own expiry policy if you like. You just need to create a class that implements ExpiryPolicy. And each row can have a different policy.
However, you'll note that the API does not give access to the record, so you can't have it automatically set the policy based on a column.
I have a weird issue with envFrom:
- name: template-api
envFrom:
- secretRef:
name: common-secrets
- secretRef:
name: template-api
in common-secrets I have variables like this:
MAILHOST=smtp.gmail.com
MAILPORT=587
And template-api is like:
MAIL_HOST=$MAILHOST
MAIL_PORT=$MAILPORT
This is like that, because pods have different variables names for same info.
But when the container is running the variables are replaced with literal $VAR instead of var value.
Maybe Im using the wrong solution for this. Did somebody face the same issue?
Kubernetes won't update it that way, if you are running that approach with any code or script it will work inside the code. like process.env($MAILHOST)
Whatever you have mentioned in secret it will get injected into the OS environment now if the same values are there it will get overwritten.
Kubernetes inject the secret based on the YAML configuration either to the file system or either inside the OS.
Kubernetes simply inject the values into the POD as set in secret. it won't check whether anything is already set in the environment and replaces it with values.
Background:
I'm building an SPA (Single Page Application) PWA (Progressive Web App) using Vue.js. I've a remote PostgreSQL database, serving the tables over HTTP with PostgREST. I've a working Workbox Service Worker and IndexedDB, which hold a local copy of the database tables. I've also registered some routes in my service-worker.js; everything is fine this far....
I'm letting Workbox cache GET calls that return tables from the REST service. For example:
https://www.example.com/api/customers will return a json object of the customers.
workbox.routing.registerRoute('https://www.example.com/api/customers', workbox.strategies.staleWhileRevalidate())
At this point, I need Workbox to do the stale-while-revalidate pattern, but to:
Not use a cache, but instead return the local version of this table, which I have stored in IndexedDB. (the cache part)
Make the REST call, and update the local version, if it has changed. (the network part)
I'm almost certain that there is no configurable option for this in this workbox strategy. So I would write the code for this, which should be fairly simple. The retrieval of the cache is simply to return the contents of the requested table from IndexedDB. For the update part, I'm thinking to add a data revision number to compare against. And thus decide if I need to update the local database.
Anyway, we're now zooming in on the actual question:
Question:
Is this actually a good way to use Workbox Routes/Caching, or am I now misusing the technology because I use IndexedDB as the cache?
and
How can I make my own version of the StaleWhileRevalidate strategy? I would be happy to understand how to simply make a copy of the existing Workbox version and be able to import it and use it in my Vue.js Service Worker. From there I can make my own necessary code changes.
To make this question a bit easier to answer, these are the underlying subquestions:
First of all, the StaleWhileRevalidate.ts (see link below) is a .ts (TypeScript?) file. Can (should) I simply import this as a module? I propably can. but then I get errors:
When I to import my custom CustomStaleWhileRevalidate.ts in my main.js, I get errors on all of the current import statements because (of course) the workbox-core/_private/ directory doesn't exist.
How to approach this?
This is the current implementation on Github:
https://github.com/GoogleChrome/workbox/blob/master/packages/workbox-strategies/src/StaleWhileRevalidate.ts
I don't think using the built-in StaleWhileRevalidate strategy is the right approach here. It might be possible to do what you're describing using StaleWhileRevalidate along with a number of custom plugin callbacks to override the default behavior... but honestly, you'd end up changing so much via plugins that starting from scratch would make more sense.
What I'd recommend that you do instead is to write a custom handlerCallback function that implements exactly the logic you want, and returns a Response.
// Your full logic goes here.
async function myCustomHandler({event, request}) {
event.waitUntil((() => {
const idbStuff = ...;
const networkResponse = await fetch(...);
// Some IDB operation go here.
return finalResponse;
})());
}
workbox.routing.registerRoute(
'https://www.example.com/api/customers',
myCustomHandler
);
You could do this without Workbox as well, but if you're using Workbox to handle some of your unrelated caching needs, it's probably easiest to also register this logic via a Workbox route.
I moved from EhCache to Infinispan and I have requirement that be able to toggle caches (not only globally but also for specific cache name).
Using EhCache there was a option setDisable(Boolean) to disable a cache.
I would like to achieve something similar with Infinispan, however I don't want to change my app code. I mean I don't want something like
if cache is enabled
...
else
...
I'm waiting to something that NoOp cache operation, like calling put(key, object) do nothing at all (not only storing, but no serialization, no computation) and same for others methods.
Since I'm using Spring integration I was thinking about using CompositeCacheManager with NoOpCacheManager fallback but current existing Spring integration uses dynamic cache creation, so getCache(String) never returns null (thus NoOpCacheManager is never used).
Set the property infinispan.embedded.cache.enabled to false
I'm trying to use the java servlet store instead of the :cookie_store when running in Tomcat. My application runs fine with the :cookie_store, but when using the :java_servlet_store, nothing gets stored no longer...
This seems to work, however, when I store something in the servlet_request.session, later on, I can't seem to get the value again... It seems to be gone...
In my session_store.rb:
require 'action_controller/session/java_servlet_store'
NameApplication::Application.config.session_store :java_servlet_store
In my application_controller.rb:
servlet_request.session.putValue(PROXYBRIDGEKEY, proxy_bridge)
seems to be working
But later on I'm trying to get the value and I'm getting nil...
servlet_request.session.getValue(PROXYBRIDGEKEY)
Any ideas as what could be the problem here?
To be clear, putting the value in the session does work (tested that). With a new html request, getting the value doesn't work anymore. So, there must be a problem with getting the cookie I guess...
One thing that you could try is defining your store as:
require 'action_controller/session/java_servlet_store'
NameApplication::Application.config.session_store :java_servlet_store, :key => "MyKey"
I'm not sure it's relevant, but it was necessary for the :cookie_store. It could make sense that you need to identify your servlet key in the java_servlet_store as well. This key will be the key of the cookie sent to the browser for subsequent requests.
Hope this helps.
If that didn't work for you, also make sure that you set the java_servlet_store key to "JSESSIONID" to use the standard JVM session.
From there in Ruby, all you need to do to read and write session (this will be accessing the JVM session object):
session.id
session[:yoursessionvariable]
Note: If you have not initialized session (assign a session variable value), session will be nil (making session.id undefined) until you do so.