I create a new Azure Redis Cache, which take almost 5 minutes to finish creating. I'm using the node-redis package, here's my code
var client = redis.createClient(
process.env.REDIS_PORT || 6379,
process.env.REDIS_HOST || '127.0.0.1'
);
if(process.env.REDIS_HOST) {
client.auth(process.env.REDIS_KEY);
}
Yes those environment variables are properly set, it just hang on for a while and raise an error: Redis connection to mycache.redis.cache.windows.net:6380 failed - read ECONNRESET.
Now, when I use the redis-cli to try to connect with redis-cli -h myhost -p 6380 -a the-auth-key it just hang at the command line and no connection seems to be established, but no error either. It's just doing nothing. If I change the port etc, I get connection error. So I'm currently wondering what I'm doing wrong?
I've created another redis cache on a different region an plan (I took the biggest, with 99.9 SLA etc). Still, no connection is possible.
Any help would be appreciated.
New caches only have the SSL endpoint (port 6380) enabled by default. Some clients (like redis-cli) do not support SSL. You would need to check if node-redis supports SSL. You will get erorrs if you try to connect to the SSL port with a client that doesn't support SSL.
If you need to use a client does not support SSL, there are two options. One is to create an SSL tunnel between the local machine and the Redis cache, using an application like 'stunnel'. I know stunnel works well for ad-hoc scenarios like redis-cli, but I'm not sure how it would perform under production load.
The second option is to enable the non-SSL endpoint (port 6379) in the Azure portal. However, we don't recommend this for production caches since your access key and data will all be sent in plaintext.
Related
from development environment, developpers need to access redis cache.
Connection to the azure redis cache is done via socks protocol on port 6380.
Issue is due to the fact that external access to the internet is done via a proxy in our company.
If it's HTTP(S) access, in nodejs for example, we use npm package 'dotenv' where we specify 'HTTP(S)' proxy settings (example for package ms-rest azure).
But here we don't find any solutions to for proxy usage for socks access.
We use the npm package 'redis' in that case.
Anyone has a solution to for proxy usage ??
Thanks in advance Mathieu
It seems to be impossible for directly connecting to Azure Redis Cache from a client behind a proxy. The reason as below:
Redis only supports tcp connection via its protocol like telnet, it's infeasible if your proxy does not support socks.
After I searched two recommended NodeJS redis clients ioredis & node_redis, both don't support build connection via proxy.
So here are two possible solutions for your current scenario.
If your proxy supports socks, you can try to create a new redis client via change some code based on the existing redis client to support socks proxy.
Recommended for the current case. I suggest that you can create a HTTP service on Azure to handle the requests from your client behind your proxy, which can pass the parameters of HTTP requests to Azure Redis Cache and wrap the result into the HTTP responses. It's Redis over HTTP like solutious/bone.
Hope it helps.
What does this error message means and what are the possible causes for it? I'm using node 6.10.0 and redis 2.7.1. I run Redis store in separately Docker container and the container is successfully built. After that I prime the store with access tokens that I need in my application. I do it with script and at that moment I get the error message.
The error appears as the result of a broken connection (Your software somehow lost connection with the Redis server).
It can be one of two scenarios (or both) - the connection has timed out or the reconnect attempts have exceeded the maximum number specified in a config.
For me the issue was a missing "bind" directive in redis config and, as a result, redis worked in "protected mode". Nodejs client didn't show the full response, so I only found the reason for the issue when connecting to redis from standard redis-cli:
DENIED Redis is running in protected mode because protected mode is
enabled, no bind address was specified, no authentication password is
requested to clients. In this mode connections are only accepted from
the loopback interface. If you want to connect from external computers
to Redis you may adopt one of the following solutions: 1) Just disable
protected mode sending the command 'CONFIG SET protected-mode no' from
the loopback interface by connecting to Redis from the same host the
server is running, however MAKE SURE Redis is not publicly accessible
from internet if you do so. Use CONFIG REWRITE to make this change
permanent. 2) Alternatively you can just disable the protected mode by
editing the Redis configuration file, and setting the protected mode
option to 'no', and then restarting the server. 3) If you started the
server manually just for testing, restart it with the
'--protected-mode no' option. 4) Setup a bind address or an
authentication password. NOTE: You only need to do one of the above
things in order for the server to start accepting connections from the
outside.
As my app is currently under development, my local computer is temporarily acting as the server. Using the service by no-ip.com, I have managed to establish internet connection to the NodeJS server at my home, which has been supported by socket.io. However, although the HTTP connection is fine, every now and then the socket.io connection would fail until I restart the server. I have been investigating the cause of this. I wonder whether when the dynamic IP of the server changes, the socket.io which is listening to the ports fails. Could someone confirm this with me?
Its definitely not the answer of your question but i think you're gonna like it ! use NGROK download & install it
once it's done
launch your dev server
open cmd and type
c:\>ngrok http 3000
3000 is your dev server PORT so if its something else change it
This will give you an address like that https://xxx232xx.ngrok.io
use this address to access your app now from any connected device
One last thing , when you use socket.io with https domains change your config and add the address
Example
var ioSocket = io('https://xxx232xx.ngrok.io', {
'reconnection delay': 2500,
'secure':true,
'max reconnection attempts': 10,
'reconnection':true
});
Hope it helps !
I was unable to find existing answers on this topic.
I am running a redis client that connects to a remote redis server (not on the same host).
I can connect either via the domain name or via the server's IP, i.e. I can launch the client either via redis-cli -h 123.123.123.123 or redis-cli -h my.domain.com. It is more convenient to use the domain name.
Speed is important for my use case, therefore I would like to know whether the "costly" DNS lookup happens only once at startup or multiple times throughout the life of the client.
Thanks!
The overhead will be paid only when a connection is established.
If you make sure that your application is keeping permanent connections to the Redis instances instead of systematically connecting/disconnecting, I would say the overhead is negligible.
I'm using passport.socketio. The debug statements for the Authorization success are firing, but not the connect event. I get these debug statements on the server:
setting poll timeout
discarding transport
cleared post timeout for client laknraalkn3but
clearing poll timeout
jsonpolling writing to io.j[o]("8::");
set post timeout for client laknraalkn3but
jsonpolling closed due to exceeded duration
setting request GET /socket.io/1/jsonp-polling/laknraalkn3but
Not sure if this is the problem, but I'm trying to connect on port 8086, which some have told me could be too high of a port for a university web server. Where can I allow the ports? In the server firewall? I'm using windows server 2008 and IIS 7, and I've set up a reverse proxy to forward all traffic to port 8086.
Thanks!
This is definitely a firewall issue, but without knowing your full setup, it's kind of impossible to diagnose. Make sure port 8806 is open on the server, then see if there is a physical hardware firewall between you and the server and port 8806 is open on that as well.