Connecting to an Azure Redis Cluster using node.js ioredis not working - node.js

I've been trying to connect to a Redis three node cluster in Azure using ioredis.
When I connect using the Redis.Cluster constructor:
new Redis.Cluster(['host.redis.cache.windows.net', 6380], {
scaleReads: 'all',
slotsRefreshTimeout: 2000,
redisOptions: {
password: 'some-secret',
tls: true as any
},
});
The error I get is:
2020-06-04T13:05:41.787Z ioredis:cluster getting slot cache from 127.0.0.1:6380
2020-06-04T13:05:41.788Z ioredis:redis status[127.0.0.1:6380 (ioredisClusterRefresher)]: [empty] -> wait
2020-06-04T13:05:41.788Z ioredis:redis status[127.0.0.1:6380 (ioredisClusterRefresher)]: wait -> connecting
2020-06-04T13:05:41.788Z ioredis:redis queue command[127.0.0.1:6380 (ioredisClusterRefresher)]: 0 -> cluster([ 'slots' ])
2020-06-04T13:05:41.790Z ioredis:connection error: Error: connect ECONNREFUSED 127.0.0.1:6380
2020-06-04T13:05:41.791Z ioredis:redis status[127.0.0.1:6380 (ioredisClusterRefresher)]: connecting -> close
2020-06-04T13:05:41.791Z ioredis:connection skip reconnecting because `retryStrategy` is not a function
2020-06-04T13:05:41.791Z ioredis:redis status[127.0.0.1:6380 (ioredisClusterRefresher)]: close -> end
2020-06-04T13:05:41.792Z [auth-middleware] Redis error { ClusterAllFailedError: Failed to refresh slots cache.
at tryNode (/app/node_modules/ioredis/built/cluster/index.js:359:31)
at /app/node_modules/ioredis/built/cluster/index.js:376:21
at duplicatedConnection.cluster.utils_2.timeout (/app/node_modules/ioredis/built/cluster/index.js:624:24)
at run (/app/node_modules/ioredis/built/utils/index.js:156:22)
at tryCatcher (/app/node_modules/standard-as-callback/built/utils.js:11:23)
at promise.then (/app/node_modules/standard-as-callback/built/index.js:30:51)
at process._tickCallback (internal/process/next_tick.js:68:7)
lastNodeError:
Error: Connection is closed.
at close (/app/node_modules/ioredis/built/redis/event_handler.js:179:25)
at TLSSocket.<anonymous> (/app/node_modules/ioredis/built/redis/event_handler.js:150:20)
at Object.onceWrapper (events.js:277:13)
at TLSSocket.emit (events.js:194:15)
at _handle.close (net.js:600:12)
at TCP.done (_tls_wrap.js:388:7) }
When I connect using a non-cluster Redis connection:
new Redis(6380, 'host.redis.cache.windows.net', { password: 'some-secret' });
The error I get is:
020-06-04T15:04:08.609Z ioredis:redis status[10.211.x.x:6380]: connecting -> connect
2020-06-04T15:04:08.614Z ioredis:redis write command[10.211.x.x:6380]: 0 -> auth([ 'some-secret' ])
2020-06-04T15:04:08.616Z ioredis:redis write command[10.211.x.x:6380]: 0 -> info([])
2020-06-04T15:05:16.114Z ioredis:connection error: Error: read ECONNRESET
2020-06-04T15:05:16.115Z [auth-middleware] Redis error { Error: read ECONNRESET
at TCP.onStreamRead (internal/stream_base_commons.js:111:27) errno: 'ECONNRESET', code: 'ECONNRESET', syscall: 'read' }
As you can see it is using TLS on port 6380. Azure provides me with one host+port combination and two different access-keys (primary/seconday) - which I find weird, which access-key should I use? Also I'm not sure if I should be connecting in Cluster mode, but I'd prefer to to gain the benefits of clustering. When I do it appears it tries to find the slots at 127.0.0.1:6380 which is probably not correct.
In Azure's quickstart they connect using node_redis with:
var redis = require("redis");
// Add your cache name and access key.
var client = redis.createClient(6380, process.env.REDISCACHEHOSTNAME,
{auth_pass: process.env.REDISCACHEKEY, tls: {servername: process.env.REDISCACHEHOSTNAME}});
I was hoping someone here would have come across the same issue and solved it.
Thanks!

Okay I've managed to connect to Azure Redis Cluster using a non-tls connection:
new Redis.Cluster(['host.redis.cache.windows.net', 3679], {
scaleReads: 'all',
slotsRefreshTimeout: 2000,
redisOptions: {
password: 'some-secret',
},
})
For some reason connecting to 6380 with TLS enabled does not work.

Related

Problems implementing reconnection strategy for mongodb using mongoose on a replica set

I have an experimental app that uses a NodeJS backend which connects to a mongodb instance using mongoose. Mongodb is configured to run as single-node replica set to give me access to change streams which I use for real-time updates over a websocket connection.
For several reasons I'd like to be able to start the backend without the DB service running and have it connect as soon as it becomes available (primary reason: Docker startup). Also, I would like it to reconnect if the db server becomes unavailable for some reason.
A promising fix for reconnecting to mongodb seems to be https://stackoverflow.com/a/41859984/8447743. However, it does not seem to work in my case. It does work for delayed connection (mongod service starting after app), but gives an error on reconnection:
C:\Users\<Path to app>\node_modules\mongoose\node_modules\mongodb\src\cmap\connection.ts:740
callback(new MongoServerError(document));
^
MongoServerError: Cannot run getMore on cursor 8780071429437342673, which was created in session 993f2cbd-db02-4565-af56-f0c9a88ba012 - 47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=, without an lsid
at MessageStream.messageHandler (C:\Users\<Path to app>\node_modules\mongoose\node_modules\mongodb\src\cmap\connection.ts:740:20)
at MessageStream.emit (node:events:526:28)
at MessageStream.emit (node:domain:475:12)
at processIncomingData (C:\Users\<Path to app>\node_modules\mongoose\node_modules\mongodb\src\cmap\message_stream.ts:167:12)
at MessageStream._write (C:\Users\<Path to app>\node_modules\mongoose\node_modules\mongodb\src\cmap\message_stream.ts:64:5)
at writeOrBuffer (node:internal/streams/writable:389:12)
at _write (node:internal/streams/writable:330:10)
at MessageStream.Writable.write (node:internal/streams/writable:334:10)
at Socket.ondata (node:internal/streams/readable:754:22)
at Socket.emit (node:events:526:28) {
ok: 0,
code: 50737,
codeName: 'Location50737',
'$clusterTime': {
clusterTime: Timestamp { low: 2, high: 1650366308, unsigned: true },
signature: { hash: [Binary], keyId: 0 }
},
operationTime: Timestamp { low: 2, high: 1650366308, unsigned: true }
}
[nodemon] app crashed - waiting for file changes before starting...
According to https://www.mongodb.com/docs/manual/reference/command/lockInfo/ I might able to get this lsid that seems to be missing, but I haven't found a way to make that known to mongoose for reconnecting. Is that possible somehow? Is there another way to avoid the error?

ioredis connection keeps resetting when connecting to local redis cluster from docker container

I have a docker compose containerized client/server node app that is failing to create a stable connection to a redis cluster I have running on my local environment. The redis cluster has 6 nodes (3 master, 3 replica configuration) running on my local machine. Every time I start my app and attempt to connect to redis, the connect event is spammed and I get the following error on my client:
Proxy error: Could not proxy request /check-login from localhost:3000 to http://server.
See https://nodejs.org/api/errors.html#errors_common_system_errors for more information (ECONNRESET)
I have made sure to configure the redis cluster to have the settings protected-mode to no and bind to 0.0.0.0 to allow remote access to the cluster. I have confirmed that I can access the cluster locally by pinging one of the cluster nodes redis-cli -h 127.0.0.1 -p 30001:
127.0.0.1:30001> ping
PONG
127.0.0.1:30001> exit
I am setting my REDIS_HOSTS environment to be "host.docker.internal:30001,host.docker.internal:30005,host.docker.internal:30006". This should allow me to connect to my redis cluster running at 127.0.0.1 on my host machine. My node application code:
const Redis = require("ioredis");
const hosts = process.env.REDIS_HOSTS.split(",").map((connection) => {
const [host, port] = connection.split(":");
return {
host,
port,
};
});
const client = new Redis.Cluster(hosts, {
enableAutoPipelining: true,
slotsRefreshTimeout: 100000,
});
client.on("error", (error) => {
console.log("redis connection failed: ", error);
});
client.on("connect", () => {
console.log("redis connection established");
});
module.exports = client;
My ioredis logs:
2022-02-11T23:52:09.970Z ioredis:cluster status: [empty] -> connecting
info: Listening on port 80
2022-02-11T23:52:15.449Z ioredis:cluster resolved hostname host.docker.internal to IP 192.168.65.2
2022-02-11T23:52:15.476Z ioredis:cluster:connectionPool Reset with [
{ host: '192.168.65.2', port: 30001 },
{ host: '192.168.65.2', port: 30002 },
{ host: '192.168.65.2', port: 30003 }
]
2022-02-11T23:52:15.482Z ioredis:cluster:connectionPool Connecting to 192.168.65.2:30001 as master
2022-02-11T23:52:15.504Z ioredis:redis status[192.168.65.2:30001]: [empty] -> wait
2022-02-11T23:52:15.511Z ioredis:cluster:connectionPool Connecting to 192.168.65.2:30002 as master
2022-02-11T23:52:15.517Z ioredis:redis status[192.168.65.2:30002]: [empty] -> wait
2022-02-11T23:52:15.519Z ioredis:cluster:connectionPool Connecting to 192.168.65.2:30003 as master
2022-02-11T23:52:15.521Z ioredis:redis status[192.168.65.2:30003]: [empty] -> wait
2022-02-11T23:52:15.530Z ioredis:cluster getting slot cache from 192.168.65.2:30002
2022-02-11T23:52:15.541Z ioredis:redis status[192.168.65.2:30002 (ioredis-cluster(refresher))]: [empty] -> wait
2022-02-11T23:52:15.590Z ioredis:redis status[192.168.65.2:30002 (ioredis-cluster(refresher))]: wait -> connecting
2022-02-11T23:52:15.603Z ioredis:redis queue command[192.168.65.2:30002 (ioredis-cluster(refresher))]: 0 -> cluster([ 'slots' ])
2022-02-11T23:52:15.614Z ioredis:cluster:subscriber selected a subscriber 192.168.65.2:30001
2022-02-11T23:52:15.621Z ioredis:redis status[192.168.65.2:30001 (ioredis-cluster(subscriber))]: [empty] -> wait
2022-02-11T23:52:15.622Z ioredis:cluster:subscriber started
2022-02-11T23:52:15.734Z ioredis:redis status[192.168.65.2:30002 (ioredis-cluster(refresher))]: connecting -> connect
2022-02-11T23:52:15.737Z ioredis:redis status[192.168.65.2:30002 (ioredis-cluster(refresher))]: connect -> ready
2022-02-11T23:52:15.739Z ioredis:connection set the connection name [ioredis-cluster(refresher)]
2022-02-11T23:52:15.742Z ioredis:redis write command[192.168.65.2:30002 (ioredis-cluster(refresher))]: 0 -> client([ 'setname', 'ioredis-cluster(refresher)' ])
2022-02-11T23:52:15.749Z ioredis:connection send 1 commands in offline queue
2022-02-11T23:52:15.750Z ioredis:redis write command[192.168.65.2:30002 (ioredis-cluster(refresher))]: 0 -> cluster([ 'slots' ])
2022-02-11T23:52:15.781Z ioredis:cluster cluster slots result count: 3
2022-02-11T23:52:15.783Z ioredis:cluster cluster slots result [0]: slots 0~5460 served by [ '127.0.0.1:30001', '127.0.0.1:30004' ]
2022-02-11T23:52:15.788Z ioredis:cluster cluster slots result [1]: slots 5461~10922 served by [ '127.0.0.1:30002', '127.0.0.1:30005' ]
2022-02-11T23:52:15.792Z ioredis:cluster cluster slots result [2]: slots 10923~16383 served by [ '127.0.0.1:30003', '127.0.0.1:30006' ]
2022-02-11T23:52:15.849Z ioredis:cluster:connectionPool Reset with [
{ host: '127.0.0.1', port: 30001, readOnly: false },
{ host: '127.0.0.1', port: 30004, readOnly: true },
{ host: '127.0.0.1', port: 30002, readOnly: false },
{ host: '127.0.0.1', port: 30005, readOnly: true },
{ host: '127.0.0.1', port: 30003, readOnly: false },
{ host: '127.0.0.1', port: 30006, readOnly: true }
]
2022-02-11T23:52:15.850Z ioredis:cluster:connectionPool Disconnect 192.168.65.2:30001 because the node does not hold any slot
2022-02-11T23:52:15.851Z ioredis:redis status[192.168.65.2:30001]: wait -> close
2022-02-11T23:52:15.851Z ioredis:connection skip reconnecting since the connection is manually closed.
2022-02-11T23:52:15.852Z ioredis:redis status[192.168.65.2:30001]: close -> end
2022-02-11T23:52:15.857Z ioredis:cluster:connectionPool Remove 192.168.65.2:30001 from the pool
2022-02-11T23:52:15.858Z ioredis:cluster:connectionPool Disconnect 192.168.65.2:30002 because the node does not hold any slot
2022-02-11T23:52:15.858Z ioredis:redis status[192.168.65.2:30002]: wait -> close
2022-02-11T23:52:15.859Z ioredis:connection skip reconnecting since the connection is manually closed.
2022-02-11T23:52:15.859Z ioredis:redis status[192.168.65.2:30002]: close -> end
2022-02-11T23:52:15.861Z ioredis:cluster:connectionPool Remove 192.168.65.2:30002 from the pool
2022-02-11T23:52:15.861Z ioredis:cluster:connectionPool Disconnect 192.168.65.2:30003 because the node does not hold any slot
2022-02-11T23:52:15.861Z ioredis:redis status[192.168.65.2:30003]: wait -> close
2022-02-11T23:52:15.865Z ioredis:connection skip reconnecting since the connection is manually closed.
2022-02-11T23:52:15.866Z ioredis:redis status[192.168.65.2:30003]: close -> end
2022-02-11T23:52:15.866Z ioredis:cluster:connectionPool Remove 192.168.65.2:30003 from the pool
2022-02-11T23:52:15.867Z ioredis:cluster:connectionPool Connecting to 127.0.0.1:30001 as master
2022-02-11T23:52:15.869Z ioredis:redis status[127.0.0.1:30001]: [empty] -> wait
2022-02-11T23:52:15.871Z ioredis:cluster:connectionPool Connecting to 127.0.0.1:30004 as slave
2022-02-11T23:52:15.873Z ioredis:redis status[127.0.0.1:30004]: [empty] -> wait
2022-02-11T23:52:15.874Z ioredis:cluster:connectionPool Connecting to 127.0.0.1:30002 as master
2022-02-11T23:52:15.877Z ioredis:redis status[127.0.0.1:30002]: [empty] -> wait
2022-02-11T23:52:15.877Z ioredis:cluster:connectionPool Connecting to 127.0.0.1:30005 as slave
2022-02-11T23:52:15.882Z ioredis:redis status[127.0.0.1:30005]: [empty] -> wait
2022-02-11T23:52:15.883Z ioredis:cluster:connectionPool Connecting to 127.0.0.1:30003 as master
2022-02-11T23:52:15.885Z ioredis:redis status[127.0.0.1:30003]: [empty] -> wait
2022-02-11T23:52:15.886Z ioredis:cluster:connectionPool Connecting to 127.0.0.1:30006 as slave
2022-02-11T23:52:15.887Z ioredis:redis status[127.0.0.1:30006]: [empty] -> wait
2022-02-11T23:52:15.893Z ioredis:cluster status: connecting -> connect
2022-02-11T23:52:15.904Z ioredis:redis status[127.0.0.1:30002]: wait -> connecting
2022-02-11T23:52:15.906Z ioredis:redis queue command[127.0.0.1:30002]: 0 -> cluster([ 'info' ])
2022-02-11T23:52:15.916Z ioredis:cluster:subscriber subscriber has left, selecting a new one...
2022-02-11T23:52:15.917Z ioredis:redis status[192.168.65.2:30001 (ioredis-cluster(subscriber))]: wait -> close
2022-02-11T23:52:15.918Z ioredis:connection skip reconnecting since the connection is manually closed.
2022-02-11T23:52:15.918Z ioredis:redis status[192.168.65.2:30001 (ioredis-cluster(subscriber))]: close -> end
2022-02-11T23:52:15.919Z ioredis:cluster:subscriber selected a subscriber 127.0.0.1:30004
2022-02-11T23:52:15.921Z ioredis:redis status[127.0.0.1:30004 (ioredis-cluster(subscriber))]: [empty] -> wait
2022-02-11T23:52:16.000Z ioredis:connection error: { Error: connect ECONNREFUSED 127.0.0.1:30002
at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1148:16)
errno: -111,
code: 'ECONNREFUSED',
syscall: 'connect',
address: '127.0.0.1',
port: 30002 }
2022-02-11T23:52:16.030Z ioredis:redis status[127.0.0.1:30002]: connecting -> close
2022-02-11T23:52:16.031Z ioredis:connection skip reconnecting because `retryStrategy` is not a function
2022-02-11T23:52:16.032Z ioredis:redis status[127.0.0.1:30002]: close -> end
2022-02-11T23:52:16.034Z ioredis:cluster:connectionPool Remove 127.0.0.1:30002 from the pool
2022-02-11T23:52:16.036Z ioredis:cluster Ready check failed (Error: Connection is closed.
at close (/usr/src/app/node_modules/ioredis/built/redis/event_handler.js:184:25)
at Socket.<anonymous> (/usr/src/app/node_modules/ioredis/built/redis/event_handler.js:155:20)
at Object.onceWrapper (events.js:520:26)
at Socket.emit (events.js:400:28)
at Socket.emit (domain.js:470:12)
at TCP.<anonymous> (net.js:675:12)). Reconnecting...
2022-02-11T23:52:16.042Z ioredis:cluster status: connect -> disconnecting
...
The clue to the solution was found in the following log snippet:
2022-02-11T23:52:15.750Z ioredis:redis write command[192.168.65.2:30002 (ioredis-cluster(refresher))]: 0 -> cluster([ 'slots' ])
2022-02-11T23:52:15.781Z ioredis:cluster cluster slots result count: 3
2022-02-11T23:52:15.783Z ioredis:cluster cluster slots result [0]: slots 0~5460 served by [ '127.0.0.1:30001', '127.0.0.1:30004' ]
2022-02-11T23:52:15.788Z ioredis:cluster cluster slots result [1]: slots 5461~10922 served by [ '127.0.0.1:30002', '127.0.0.1:30005' ]
2022-02-11T23:52:15.792Z ioredis:cluster cluster slots result [2]: slots 10923~16383 served by [ '127.0.0.1:30003', '127.0.0.1:30006' ]
The internal redis cluster network was still communicating between nodes on network address 127.0.0.1, creating the connect ECONNREFUSED errors when the ioredis client attempted to use those network mappings to establish the cluster connection.
I had to use the natMap option in the ioredis client to remap the internal cluster network connections to the network address of the docker container:
let natMap = {};
const localHost = "127.0.0.1";
const hosts = process.env.REDIS_HOSTS.split(",").map((connection) => {
const [host, port] = connection.split(":");
// assign nat host address mappings
// when accessing local redis cluster from containerized network
natMap[`${localHost}:${port}`] = { host, port };
return {
host,
port,
};
});
// natMap output
// {
// "127.0.0.1:30001": { host: "docker.internal.network", port: 30001 },
// "127.0.0.1:30002": { host: "docker.internal.network", port: 30002 },
// "127.0.0.1:30003": { host: "docker.internal.network", port: 30003 },
// }
// create redis cluster client
const client = new Redis.Cluster(hosts, {
enableAutoPipelining: true,
slotsRefreshTimeout: 100000,
natMap,
});

CentOS + Node.js (v8.15.0) + Sequelize (v4.38.0) to Azure SQL Intermittent Connection Issues

On our production Azure Hosted CentOS API server we are having intermittent Sequelize connection issues to our Azure SQL database.
Our connection settings are as follows:
const sequelize = new Sequelize(dbDatabase, dbUser, dbPassword, {
host: dbHost,
dialect: 'mssql',
operatorsAliases: false,
pool: {
max: 5092,
min: 0,
acquire: 10000,
idle: 10000,
evict: 500,
},
dialectOptions: {
encrypt: false, // Use this if you're on Windows Azure
requestTimeout: 60000 * 2,
},
}
We have also set the ulimit for open files by the process to the system max.
We are using PM2 to run the server.
The two errors that sometimes appear in our logs roughly every 10-20 minutes are:
SequelizeConnectionError
at Connection.connection.on (/home/AZ-admin/XXX/node_modules/sequelize/lib/dialects/mssql/connection-manager.js:75:16)
at emitNone (events.js:106:13)
at Connection.emit (events.js:208:7)
at Connection.cleanupConnection (/home/AZ-admin/XXX/node_modules/tedious/lib/connection.js:568:16)
at Connection.enter (/home/AZ-admin/XXX/node_modules/tedious/lib/connection.js:1961:12)
at Connection.transitionTo (/home/AZ-admin/XXX/node_modules/tedious/lib/connection.js:993:26)
at Connection.socketEnd (/home/AZ-admin/XXX/node_modules/tedious/lib/connection.js:1036:12)
at Socket.<anonymous> (/home/AZ-admin/XXX/node_modules/tedious/lib/connection.js:877:18)
at emitNone (events.js:111:20)
at Socket.emit (events.js:208:7)
at endReadableNT (_stream_readable.js:1064:12)
at _combinedTickCallback (internal/process/next_tick.js:139:11)
at process._tickCallback (internal/process/next_tick.js:181:9)
or
SequelizeHostNotFoundError: Failed to connect to xxx-prod.database.windows.net:1433 - getaddrinfo ENOTFOUND xxx-prod.database.windows.net
at Connection.connection.on.err (/home/XXX/node_modules/sequelize/lib/dialects/mssql/connection-manager.js:98:22)
at emitOne (events.js:116:13)
at Connection.emit (events.js:211:7)
at Connection.socketError (/home/XXX/node_modules/tedious/lib/connection.js:1016:14)
at /home/XXX/node_modules/tedious/lib/connection.js:861:25
at GetAddrInfoReqWrap.callback (/home/XXX/node_modules/tedious/lib/connector.js:69:18)
at GetAddrInfoReqWrap.onlookupall [as oncomplete] (dns.js:79:17)
We think this could anything from an issue with connections/files being opened and not closed and reaching a limit to a problem with our DNS looking up the domain name.
It does appear to be somewhat tied to an increase in traffic, but the correlation is not 100% clear.
I saw your sample code missing options in dialectOptions.
It should be like below.
"dialectOptions": {
options: {
encrypt: true,
}
}
Before I have create a sample project to connect mssql and mysql. Hope it can help you. For more details, please check my answer in below post.
Azure Database for MySQL - webapp nodejs

Error! MongoNetworkError: failed to connect to server - after connect to another wifi network

I created an entire, working application with backend in Node.js and Mongodb (Mean stack). Everything is fine, but when I connect to another wifi network there is an error. Please help me.
If I have to send more code from the app, write it.
Error! MongoNetworkError: failed to connect to server [eventsdb-shard-00-00-ydx5k.mongodb.net:27017] on first connect [MongoNetworkError: connection 5 to eventsdb-shard-00-00-ydx5k.mongodb.net:27017 closed
at TLSSocket.<anonymous>
at Object.onceWrapper (events.js:300:26)
at TLSSocket.emit (events.js:210:5)
at net.js:659:12
at TCP.done (_tls_wrap.js:481:7) {
name: 'MongoNetworkError',
[Symbol(mongoErrorContextSymbol)]: {}
}]
...\App\server\node_modules\mongodb\lib\core\connection\connection.js:372:9 :
function closeHandler(conn) {
return function(hadError) {
if (connectionAccounting) deleteConnection(conn.id);
if (conn.logger.isDebug()) {
conn.logger.debug(`connection ${conn.id} with for [${conn.address}] closed`);
}
if (!hadError) {
conn.emit(
'close',
new MongoNetworkError(`connection ${conn.id} to ${conn.address} closed`), // <------ 372
conn
);
}
};
}
I solved my problem. On the Mongodb website, where I have a database, I entered "Network Access" -> "Add IP Address", I added my new ip address and there was no error.

Hazelcast Nodejs Client Connection Refused

I am trying to run the basic example code provided in the "Using the Client" section of https://github.com/hazelcast/hazelcast-nodejs-client
I am getting a connection refused error. I tried this on both my Mac and my PC machines with the same result. They are running Node v6.9.1. I do not have any special firewall settings. Even tried turning of the Windows firewall completely.
Is there something I am missing?
[DefaultLogger] WARN at ClientConnection: Could not connect to address localhost:5701
{ Error: connect ECONNREFUSED 127.0.0.1:5701
at Object.exports._errnoException (util.js:1026:11)
at exports._exceptionWithHostPort (util.js:1049:20)
at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1085:14)
code: 'ECONNREFUSED',
errno: 'ECONNREFUSED',
syscall: 'connect',
address: '127.0.0.1',
port: 5701 }
Unhandled rejection Error: Unable to connect to any of the following addresses: localhost:5701
at Immediate.<anonymous> (C:\Users\Jennie Lyn\node_modules\hazelcast-client\lib\invocation\ClusterService.js:95:33)
at runCallback (timers.js:637:20)
at tryOnImmediate (timers.js:610:5)
at processImmediate [as _immediateCallback] (timers.js:582:5)
First i created an empty node project then:
npm install hazelcast-client --save
Then created one js file with:
var HazelcastClient = require('hazelcast-client').Client;
var person = {
firstName: "Joe",
lastName: "Doe",
age: 42
};
var map;
HazelcastClient.newHazelcastClient().then(function (hazelcastClient) {
map = hazelcastClient.getMap("personMap");
map.put(1, person).then(function (val) {
// prints previous value for key `1`
console.log(val);
});
map.get(1).then(function (value) {
console.log(value);
})
});
That's all the documentation says to do. Is there something else that needs to be done to start a single client cluster on the localhost using hazelcast-client for nodejs?
Before you start
download latest Hazelcast distribution from https://hazelcast.org/download/
unzip to any folder
start Hazelcast member using startup script /bin/start.sh
you can use samples now
Let me know if it works
Cheers,
Vik

Resources