When listening to Keyspace Notifications it looks like this:
λ redis-cli --csv psubscribe '__keyspace#0__:myset:*'
Reading messages... (press Ctrl-C to quit)
"psubscribe","__keyspace#0__:myset:*",1
"pmessage","__keyspace#0__:myset:*","__keyspace#0__:myset:1","sadd"
"pmessage","__keyspace#0__:myset:*","__keyspace#0__:myset:1","srem"
The problem is that it never says the actual set key that is being added or removed. Is there any way to access the string that is being added or removed within a set via Keyspace Notifications? If it not possible is there a workaround?
The messages sent by the keyspace notifications mechanism do not include the actual data, only the key names.
You can make your own notifications just by calling PUBLISH alongside the calls that modify the data - for atomicity consider using transactions or a Lua script.
Related
I have configured a stream on a rabbitmq docker container. I am able to use the command rabbitmqadmin to publish to it. I can also see that the message got appended to the stream when I run a rabbitmqaddmin publish. But for some reason a rabbitmqadmin get command on the stream fails saying "540 basic.get not supported by stream queues queue "xxxx" in vhost".
Looks like a different command is needed to read from a stream or cannot be done from command console. Anyone have any ideas how to over come this?
On ubuntu 16.04. Interacting with a local redis instance via redis-cli. Working with a node hubot script which uses redis as its primary data store.
when I type keys * I get a single key hubot:storage
so I FLUSHALL and get an ok response. But if the Hubot is running or else as soon as it turns on, it restores the value of that key immediately so I can never delete it.
I'v used the info command to try to see if it is persisting on some other redis instance and I've cleared all backup files from /var/redis. Basically I can't figure out where this data is being stored to keep getting restored from.
Any advice regarding how I could clear this out or where Hubot may be caching this?
It seems to be related to this code: https://github.com/hubotio/hubot-redis-brain/blob/master/src/redis-brain.js specifically the chunk at line 49 is what gets called before each restore.
Steps
Stop hubot
Flush redis (important that this is done while hubot is NOT running)
Start hubot
The reasoning is that hubot has an in-memory representation of the brain and will write it out to redis at intervals. Perhaps a nicer solution to this which would help during script development would be a command that can empty the brain and save that, but I can't see an obvious API for that in either robot.brain or hubot-redis-brain
Just doing some testing on local machine, would like somewhere to inspect messages that are published and persisted by RabbitMQ (deliveryMode = 2). Or at least to have a time when messages was actually persisted. First try was RabbitMQ admin management, went trough all options and closest what i have found is following:
Database directory: /usr/local/var/lib/rabbitmq/mnesia/rabbit#localhost
There i can found many files with rdq extenstions and many logs file, but can't actually see nothing.
you can't, RabbitMQ uses a custom database and it is not possible to browse it.
you can only browse the RabbitMQ definitions as "queues", "users", "exchanges" etc.. but not the messages.
By default, the messages index is inside:
/usr/local/var/lib/rabbitmq/mnesia/rabbit#localhost/queues/HASHQUEUE
The only way it is as suggested by #Johansson
It's possible to manually inspect your message in the queue via the Management interface. Press on the queue that has the message, and then "Get message". If you mark it as "requeue", RabbitMQ puts it back to the queue in the same order.
https://www.cloudamqp.com/blog/2015-05-27-part3-rabbitmq-for-beginners_the-management-interface.html
My question builds off this one: Temporary queue made in Celery
My application needs to retrieve results, as it uploads them to an S3 file. however, the number of temporary queues being made is causing my broker to crash (machine doesn't have enough memory). I want to delete the temporary queue once the corresponding result as been retrieved. In my celery client script, I am iterating through a list of of results (where each result is from function.delay() ):
for result in result_list:
while True:
if result.ready():
#do something with result
#I WANT TO DELETE TEMPORARY QUEUE HERE
Is there any way I can achieve the above -- deleting the temporary queue once the result has been retrieved?
I would have used CELERY_TASK_RESULT_EXPIRES option in my celeryconfig , but I don't know when I can safely clean up the temporary queue, as the result may not have been retrieved. Is there anyway I can delete specific queues in this script (note that I have the queue Id from the result).
ADDITIONAL NOTE:
I am running all rabbitmq servers in a cluster with HA enabled.
The way I did this was to use the rabbitmqadmin from rabbitmq. I downloaded it via
wget localhost:15672/cli/rabbitmqadmin
after installing the management plugin
rabbitmq-plugins enable rabbitmq_management
Make sure your user has the administrator tag for rabbitmq, or you will not be able to perform commands. I then deleted the queue in my script using python subprocess import and rabbitmqadmin delete queue name='' . Keep in mind that the queue name is the same as the corresponding result id, except without the hyphens.
Also make sure you add the params -v myvhost -u myusername -p mypassword in rabbitmqadmin commands, default vhost is /.
I believe this will delete queues across all nodes in a cluster, though I am not completely sure of this.
I am using Spring Jedis Client to use Redis in my application. I want to rename the commands so that no one else can fire the same just in case they are able to connect to my server.
Can anyone give an example of how to use rename command from Jedis and then how to fire subsequent commands using the the modified one ?
You can't rename a Redis command yet w/o changing the config file issue #640.
Even if you add the rename-command config file directive and restart your Redis, Jedis doesn't seem to allow sending arbitrary commands easily or to provide a trivial (i.e. no code changes) way to rename them.
What you could do, however, if you're really insistent on renaming a command and then calling it from Jedis is EVAL it. This will probably go in my pantheon of ugly hacks (:)) but after adding rename-command get foo to my /etc/redis/redis.conf and doing service redis-server restart look what I can do:
$ redis-cli
redis 127.0.0.1:6379> set bar baz
OK
redis 127.0.0.1:6379> get bar
(error) ERR unknown command 'get'
redis 127.0.0.1:6379> foo bar
"baz"
redis 127.0.0.1:6379> eval "return(redis.call('get', KEYS[1]))" 1 bar
(error) ERR Error running script (call to f_db0e060e4f58231d51f21685b20ff847de8ab9e1): Unknown Redis command called from Lua script
redis 127.0.0.1:6379> eval "return(redis.call('foo', KEYS[1]))" 1 bar
"baz"
redis 127.0.0.1:6379>
Of course, if you take this route your code can get pretty messy in no time at all so be careful where you tread... Good luck!
If a malicious user connects directly to Redis, then one can access all opcodes.
There is no feature in the Redis library to rename commands. Even if you expose access to a custom API that renames commands, you cannot change the inner opcodes of Redis itself.
Edit:
You're right, it is possible to rename commands by changing the config file indeed!
After you set the new command names, you have to recompile Jedis.
First rename the enum on src/main/java/redis/clients/jedis/Protocol.java, line 203.
Now find the corresponding enum usage on src/main/java/redis/clients/jedis/BinaryClient.java and change it also.
It may be sufficient: everywhere you still keep the old command java interfaces (e.g. zadd etc.), and inside Jedis it will talk to Redis calling the renamed command.
Is that your intention ?