I am using redis for cache.
Is caching of javascript and css possible in redis server?
I am trying to cache my css file in redis
Related
Assuming we want to automate the process of creating RDB files (and don't want to use Redis server for this purpose) what options are available?
The current process involves importing (with redis-cli) a set of RESP files to a Redis server and then saving a RDB file to disk (all that in a stateless Redis container, where the RDB file is not persistent and difficult to access automatically). The imported dictionaries are too large for automated data ingestion via a remote Redis python client (we have to import from files).
If the question's restrictions are liberalized somewhat to not running a local redis-server (as opposed to no dependency on any Redis server), is becomes possible to save (or more precisely, download) a remote Redis server database to a local (client-side) RDB file by connecting from a local client (redis-cli) to a remote redis-server instance (as pointed out by Itamar Haber in a comment to this answer), like this:
redis-cli -h <REMOTE_URL> -p <REMOTE_PORT> --rdb <LOCAL_PATH>/dump.rdb
It is equally possible to use redis-cli to first ingest the data from local RESP files to a remote Redis server (in order to later re-export the data to a local RDB file, as described above).
Is it possible to persist the ignite cache on local file system?
I need to perform cache operations like insert, update, delete on my look up data.
But this has to be persisted on local file system of the respective nodes to survive the data even after restart of the ignite cluster.
Alternatively I was able to persist the data on MySQL database.
But I'm looking for a persistence solution that works independent of databases and HDFS.
Ignite since version 2.1 has it own native Persistence. Moreover, it has advantages over integration with 3rd party databases.
You can read about it here: https://apacheignite.readme.io/docs/distributed-persistent-store
I have a 3 node ignite cluster and 1 client that creates cache. During the development and testing, I had to stop the cluster or interrupt the cache building several time and the entire system is broken now. Only one node starts and the other nodes crashes. The client is blocked and it does not do anythin.
Is there any way to clean everything and sort of start fresh?
I am using Ignite 2.1 and using Persistent Cache storage.
Thank you for your help.
Just delete Ignite work directory - by default, it's ${IGNITE_HOME}/work.
Also, if you configured WAL store path, you need to clean it too:
https://apacheignite.readme.io/docs/distributed-persistent-store#section-write-ahead-log
Note: All data in persistent store will be lost.
I want to make sure I'm not storing sensitive keys and credentials in source or in docker images. Specifically I'd like to store my MySQL RDS application credentials and copy them when the container/task starts. The documentation provides an example of retrieving the ecs.config file from s3 and I'd like to do something similar.
I'm using the Amazon ECS optimized AMI with an auto scaling group that registers with my ECS cluster. I'm using the ghost docker image without any customization. Is there a way to configure what I'm trying to do?
You can define a volume on the host and map it to the container with Read only privileges.
Please refer to the following documentation for configuring ECS volume for an ECS task.
http://docs.aws.amazon.com/AmazonECS/latest/developerguide/using_data_volumes.html
Even though the container does not have the config at build time, it will read the configs as if they are available in its own file system.
There are many ways to secure the config on the host OS.
In my past projects, I have achieved the same by disabling ssh into the host and injecting the config at boot-up using cloud-init.
I am using the infinispan cache in a grails project.
Is there any way I can hit a JMX port or anything to see the contents of the cache?
Thanks.
Here are docs for JMX operations. And no, there is no JMX operation that would show all entries.
In local/replicated mode, you can call values() on the cache to get all values, but this is not a recommended operation for production (it does not scale very well). Instead, look on Distributed Executors or Map/Reduce API.