Is it possible to see inside redis module bundled with socket.io - node.js

Question

Since we can configure socket.io to use redis for it's internal workings like this:
var RedisStore = require('socket.io/lib/stores/redis')
, redis = require('socket.io/node_modules/redis')
, pub = redis.createClient()
, sub = redis.createClient()
, client = redis.createClient();
io.set('store', new RedisStore({
redisPub : pub
, redisSub : sub
, redisClient : client
}));
How is it possible to see inside of this RedisStore to see what data socket.io is inserting and removing. I set my socket.io configuration to use the redis instance installed from node-redis like this:
redis = require('redis')
but I don't see any socket.io activity going on and I wonder if socket.io is actually using redis. I do see my cookies being stored in redis because I configured express and connect to use redis as the MemoryStore, but I don't see anything related to socket.io.

Answer 1

For local redis node.js development/debugging I do this.
Start redis server in background and run the cli monitor in the same tty:
redis-server &
redis-cli monitor -h host -p port
You can leave - switches off if using local defaults.
You can also run a redis slave that echos all master commands and SYNCs the current redis-server's memory held data into a textfile defaulting to ./dump.rdb. The file can be loaded into redis and viewed with a text editor.
redis-cli --slave -h host -p port
vim ./dump.rdb
A basic node.js Passport session-cookie would look something like this:
sess:L2C4MPtAUmlO4zHGkXnq4icuÃ#U#Z{"cookie":{"originalMaxAg null,"expiresÀhttpOnly":true,"path":"/"}passport L}
To further help see inside you may want to step through your app and put breakpoints in the areas where your node code and redis driver interact.
You can use this to watch the handshake process, see incorrect data exchanging, problems with the socket, etc by stepping through your functions, and observing the changes in state during control flow.
The node app for this job is node-inspector.
It will allow you to view your app running in a debugging environment similar
to Chrome dev tools, where you can set breakpoints to pause, step in and out
of functions, and move forward in time until the next breakpoint or exception
triggers a pause.
npm -g install node-inspector
You install it with the '-g' global switch as you use it across multiple projects.
running the program without any options in a terminal window produces this output for me:
~/passaic-streaming git:weekend-refactor ❯❯❯
Node Inspector v0.7.0
Visit http://localhost:8080/debug?port=5858 to start debugging.
You can configure the HOST, PORT, DEBUG-PORT using config or ENV variables
(DEBUG_PORT, port 5858, passed as a parameter sets up a socket connection
between the running node process and your browser running the web-app).
Now, there are three ways to run your node.js code in debug mode. You do this after first running node-inspector:
node --debug-brk app.js
node --debug app.js
node app.js // then send a SIGUSR1 to the node process:
// pgrep node
// kill -s USR1 PID
Use the first command '--debug-brk', until you got everything working, as it tells your code to stop on your module's first line.
browser http://localhost:8080/debug?port=5858
It can take a little time to load depending on your app size. But once there you'll have a source tab to step through code, and a console tab.
The '--debug' will work fine on an express app, you may just need to hit an endpoint or do some transaction or tell it to pause at a breakpoint manually.
Some node scripts are too fast to get caught by the node-inspector listener and until you set up breakpoints in the source code it can be convenient to break on the first line, hence the command.
You can also put 'node debugger';lines around areas like:
// connect to Redis for sessionStore
node debugger; // node-inspector will pause here.
redisClient = redis.createClient(
options.PORT, options.HOST, options.REDIS_OPTIONS));
The main reason you may need to use the SIGUSR1 and not start the app in debug mode is if you are using the node.js cluster API.
If you try to monitor an app that is using clustering and creating multiples node processes, then if you try to debug in node < 0.11.x you'll see this problem with the socket:
Failed to open socket on port 5858, waiting 1000 ms before retrying
Failed to open socket on port 5858, waiting 1000 ms before retrying
In the unstable node versions the child_process.fork command listens on a debugger port 5858+1, so 59, 60, etc, depending on the workers you have.
For now in node 0.10.x if you need to inspect the state of a worker in a clustered app you'll have to start node not in '--debug' mode and instead send the kill USR1 signal to the process.
To coerce more logging out of node with redis put your node_redis driver in debug mode:
redis = require('redis');
redis.debug_mode = true; //turn on debug mode
Also if using connect-redis middleware if you start like this:
DEBUG=* node app.js
Then you will see connect-redis output like this:
connect:redis SETEX "sess:FVDBpNoFDFIOkynFDLcpM6St" ttl:604799
{"cookie":{"originalMaxAge":604799991,"expires":"2014-03-08T22:38:32.620Z","httpOnly":true,"path":"/"},"passport":{"user":"52edfdfdf3da2rer0c06eb34"}} +50ms
Finally, the team at StrongOps/Strongloop has part of their command line tools node-inspector baked in.
npm install -g strong-cli
slc debug app.js
It will boot the node-inspector, open the web browser to the proper inspector, and in the latest node versions -- it understands clustering.