🚀 A robust, performance-focused and full-featured Redis client for Node.js.

Overview

ioredis

Build Status code style: prettier Join the chat at https://gitter.im/luin/ioredis Commitizen friendly semantic-release npm latest version npm next version

A robust, performance-focused and full-featured Redis client for Node.js.

Supports Redis >= 2.6.12 and (Node.js >= 6). Completely compatible with Redis 6.x.

Features

ioredis is a robust, full-featured Redis client that is used in the world's biggest online commerce company Alibaba and many other awesome companies.

  1. Full-featured. It supports Cluster, Sentinel, Streams, Pipelining and of course Lua scripting & Pub/Sub (with the support of binary messages).
  2. High performance.
  3. Delightful API. It works with Node callbacks and Native promises.
  4. Transformation of command arguments and replies.
  5. Transparent key prefixing.
  6. Abstraction for Lua scripting, allowing you to define custom commands.
  7. Support for binary data.
  8. Support for TLS 🔒 .
  9. Support for offline queue and ready checking.
  10. Support for ES6 types, such as Map and Set.
  11. Support for GEO commands 📍 .
  12. Support for Redis ACL.
  13. Sophisticated error handling strategy.
  14. Support for NAT mapping.
  15. Support for autopipelining

Links


Download on the App Store

[AD] Medis: Redis GUI for OS X

Looking for a Redis GUI manager for OS X, Windows and Linux? Here's Medis!

Medis is an open-sourced, beautiful, easy-to-use Redis GUI management application.

Medis starts with all the basic features you need:

  • Keys viewing/editing
  • SSH Tunnel for connecting with remote servers
  • Terminal for executing custom commands
  • JSON/MessagePack format viewing/editing and built-in highlighting/validator
  • And other awesome features...

Medis is open sourced on GitHub

[AD] Kuber: Kubernetes Dashboard for iOS

Download on the App Store


Quick Start

Install

$ npm install ioredis

Basic Usage

const Redis = require("ioredis");
const redis = new Redis(); // uses defaults unless given configuration object

// ioredis supports all Redis commands:
redis.set("foo", "bar"); // returns promise which resolves to string, "OK"

// the format is: redis[SOME_REDIS_COMMAND_IN_LOWERCASE](ARGUMENTS_ARE_JOINED_INTO_COMMAND_STRING)
// the js: ` redis.set("mykey", "Hello") ` is equivalent to the cli: ` redis> SET mykey "Hello" `

// ioredis supports the node.js callback style
redis.get("foo", function (err, result) {
  if (err) {
    console.error(err);
  } else {
    console.log(result); // Promise resolves to "bar"
  }
});

// Or ioredis returns a promise if the last argument isn't a function
redis.get("foo").then(function (result) {
  console.log(result); // Prints "bar"
});

// Most responses are strings, or arrays of strings
redis.zadd("sortedSet", 1, "one", 2, "dos", 4, "quatro", 3, "three");
redis.zrange("sortedSet", 0, 2, "WITHSCORES").then((res) => console.log(res)); // Promise resolves to ["one", "1", "dos", "2", "three", "3"] as if the command was ` redis> ZRANGE sortedSet 0 2 WITHSCORES `

// All arguments are passed directly to the redis server:
redis.set("key", 100, "EX", 10);

See the examples/ folder for more examples.

Connect to Redis

When a new Redis instance is created, a connection to Redis will be created at the same time. You can specify which Redis to connect to by:

new Redis(); // Connect to 127.0.0.1:6379
new Redis(6380); // 127.0.0.1:6380
new Redis(6379, "192.168.1.1"); // 192.168.1.1:6379
new Redis("/tmp/redis.sock");
new Redis({
  port: 6379, // Redis port
  host: "127.0.0.1", // Redis host
  family: 4, // 4 (IPv4) or 6 (IPv6)
  password: "auth",
  db: 0,
});

You can also specify connection options as a redis:// URL or rediss:// URL when using TLS encryption:

// Connect to 127.0.0.1:6380, db 4, using password "authpassword":
new Redis("redis://:[email protected]:6380/4");

// Username can also be passed via URI.
// It's worth to noticing that for compatibility reasons `allowUsernameInURI`
// need to be provided, otherwise the username part will be ignored.
new Redis(
  "redis://username:[email protected]:6380/4?allowUsernameInURI=true"
);

See API Documentation for all available options.

Pub/Sub

Redis provides several commands for developers to implement the Publish–subscribe pattern. There are two roles in this pattern: publisher and subscriber. Publishers are not programmed to send their messages to specific subscribers. Rather, published messages are characterized into channels, without knowledge of what (if any) subscribers there may be.

By leveraging Node.js's built-in events module, ioredis makes pub/sub very straightforward to use. Below is a simple example that consists of two files, one is publisher.js that publishes messages to a channel, the other is subscriber.js that listens for messages on specific channels.

// publisher.js

const Redis = require("ioredis");
const redis = new Redis();

setInterval(() => {
  const message = { foo: Math.random() };
  // Publish to my-channel-1 or my-channel-2 randomly.
  const channel = `my-channel-${1 + Math.round(Math.random())}`;

  // Message can be either a string or a buffer
  redis.publish(channel, JSON.stringify(message));
  console.log("Published %s to %s", message, channel);
}, 1000);
// subscriber.js

const Redis = require("ioredis");
const redis = new Redis();

redis.subscribe("my-channel-1", "my-channel-2", (err, count) => {
  if (err) {
    // Just like other commands, subscribe() can fail for some reasons,
    // ex network issues.
    console.error("Failed to subscribe: %s", err.message);
  } else {
    // `count` represents the number of channels this client are currently subscribed to.
    console.log(
      `Subscribed successfully! This client is currently subscribed to ${count} channels.`
    );
  }
});

redis.on("message", (channel, message) => {
  console.log(`Received ${message} from ${channel}`);
});

// There's also an event called 'messageBuffer', which is the same as 'message' except
// it returns buffers instead of strings.
// It's useful when the messages are binary data.
redis.on("messageBuffer", (channel, message) => {
  // Both `channel` and `message` are buffers.
  console.log(channel, message);
});

It worth noticing that a connection (aka Redis instance) can't play both roles together. More specifically, when a client issues subscribe() or psubscribe(), it enters the "subscriber" mode. From that point, only commands that modify the subscription set are valid. Namely, they are: subscribe, psubscribe, unsubscribe, punsubscribe, ping, and quit. When the subscription set is empty (via unsubscribe/punsubscribe), the connection is put back into the regular mode.

If you want to do pub/sub in the same file/process, you should create a separate connection:

const Redis = require("ioredis");
const sub = new Redis();
const pub = new Redis();

sub.subscribe(/* ... */); // From now, `sub` enters the subscriber mode.
sub.on("message" /* ... */);

setInterval(() => {
  // `pub` can be used to publish messages, or send other regular commands (e.g. `hgetall`)
  // because it's not in the subscriber mode.
  pub.publish(/* ... */);
}, 1000);

PSUBSCRIBE is also supported in a similar way when you want to subscribe all channels whose name matches a pattern:

redis.psubscribe("pat?ern", (err, count) => {});

// Event names are "pmessage"/"pmessageBuffer" instead of "message/messageBuffer".
redis.on("pmessage", (pattern, channel, message) => {});
redis.on("pmessageBuffer", (pattern, channel, message) => {});

Streams

Redis v5 introduces a new data type called streams. It doubles as a communication channel for building streaming architectures and as a log-like data structure for persisting data. With ioredis, the usage can be pretty straightforward. Say we have a producer publishes messages to a stream with redis.xadd("mystream", "*", "randomValue", Math.random()) (You may find the official documentation of Streams as a starter to understand the parameters used), to consume the messages, we'll have a consumer with the following code:

const Redis = require("ioredis");
const redis = new Redis();

const processMessage = (message) => {
  console.log("Id: %s. Data: %O", message[0], message[1]);
};

async function listenForMessage(lastId = "$") {
  // `results` is an array, each element of which corresponds to a key.
  // Because we only listen to one key (mystream) here, `results` only contains
  // a single element. See more: https://redis.io/commands/xread#return-value
  const results = await redis.xread("block", 0, "STREAMS", "mystream", lastId);
  const [key, messages] = results[0]; // `key` equals to "mystream"

  messages.forEach(processMessage);

  // Pass the last id of the results to the next round.
  await listenForMessage(messages[messages.length - 1][0]);
}

listenForMessage();

Handle Binary Data

Arguments can be buffers:

redis.set("foo", Buffer.from("bar"));

And every command has a method that returns a Buffer (by adding a suffix of "Buffer" to the command name). To get a buffer instead of a utf8 string:

redis.getBuffer("foo", (err, result) => {
  // result is a buffer.
});

Pipelining

If you want to send a batch of commands (e.g. > 5), you can use pipelining to queue the commands in memory and then send them to Redis all at once. This way the performance improves by 50%~300% (See benchmark section).

redis.pipeline() creates a Pipeline instance. You can call any Redis commands on it just like the Redis instance. The commands are queued in memory and flushed to Redis by calling the exec method:

const pipeline = redis.pipeline();
pipeline.set("foo", "bar");
pipeline.del("cc");
pipeline.exec((err, results) => {
  // `err` is always null, and `results` is an array of responses
  // corresponding to the sequence of queued commands.
  // Each response follows the format `[err, result]`.
});

// You can even chain the commands:
redis
  .pipeline()
  .set("foo", "bar")
  .del("cc")
  .exec((err, results) => {});

// `exec` also returns a Promise:
const promise = redis.pipeline().set("foo", "bar").get("foo").exec();
promise.then((result) => {
  // result === [[null, 'OK'], [null, 'bar']]
});

Each chained command can also have a callback, which will be invoked when the command gets a reply:

redis
  .pipeline()
  .set("foo", "bar")
  .get("foo", (err, result) => {
    // result === 'bar'
  })
  .exec((err, result) => {
    // result[1][1] === 'bar'
  });

In addition to adding commands to the pipeline queue individually, you can also pass an array of commands and arguments to the constructor:

redis
  .pipeline([
    ["set", "foo", "bar"],
    ["get", "foo"],
  ])
  .exec(() => {
    /* ... */
  });

#length property shows how many commands in the pipeline:

const length = redis.pipeline().set("foo", "bar").get("foo").length;
// length === 2

Transaction

Most of the time, the transaction commands multi & exec are used together with pipeline. Therefore, when multi is called, a Pipeline instance is created automatically by default, so you can use multi just like pipeline:

redis
  .multi()
  .set("foo", "bar")
  .get("foo")
  .exec((err, results) => {
    // results === [[null, 'OK'], [null, 'bar']]
  });

If there's a syntax error in the transaction's command chain (e.g. wrong number of arguments, wrong command name, etc), then none of the commands would be executed, and an error is returned:

redis
  .multi()
  .set("foo")
  .set("foo", "new value")
  .exec((err, results) => {
    // err:
    //  { [ReplyError: EXECABORT Transaction discarded because of previous errors.]
    //    name: 'ReplyError',
    //    message: 'EXECABORT Transaction discarded because of previous errors.',
    //    command: { name: 'exec', args: [] },
    //    previousErrors:
    //     [ { [ReplyError: ERR wrong number of arguments for 'set' command]
    //         name: 'ReplyError',
    //         message: 'ERR wrong number of arguments for \'set\' command',
    //         command: [Object] } ] }
  });

In terms of the interface, multi differs from pipeline in that when specifying a callback to each chained command, the queueing state is passed to the callback instead of the result of the command:

redis
  .multi()
  .set("foo", "bar", (err, result) => {
    // result === 'QUEUED'
  })
  .exec(/* ... */);

If you want to use transaction without pipeline, pass { pipeline: false } to multi, and every command will be sent to Redis immediately without waiting for an exec invocation:

redis.multi({ pipeline: false });
redis.set("foo", "bar");
redis.get("foo");
redis.exec((err, result) => {
  // result === [[null, 'OK'], [null, 'bar']]
});

The constructor of multi also accepts a batch of commands:

redis
  .multi([
    ["set", "foo", "bar"],
    ["get", "foo"],
  ])
  .exec(() => {
    /* ... */
  });

Inline transactions are supported by pipeline, which means you can group a subset of commands in the pipeline into a transaction:

redis
  .pipeline()
  .get("foo")
  .multi()
  .set("foo", "bar")
  .get("foo")
  .exec()
  .get("foo")
  .exec();

Lua Scripting

ioredis supports all of the scripting commands such as EVAL, EVALSHA and SCRIPT. However, it's tedious to use in real world scenarios since developers have to take care of script caching and to detect when to use EVAL and when to use EVALSHA. ioredis exposes a defineCommand method to make scripting much easier to use:

const redis = new Redis();

// This will define a command echo:
redis.defineCommand("echo", {
  numberOfKeys: 2,
  lua: "return {KEYS[1],KEYS[2],ARGV[1],ARGV[2]}",
});

// Now `echo` can be used just like any other ordinary command,
// and ioredis will try to use `EVALSHA` internally when possible for better performance.
redis.echo("k1", "k2", "a1", "a2", (err, result) => {
  // result === ['k1', 'k2', 'a1', 'a2']
});

// `echoBuffer` is also defined automatically to return buffers instead of strings:
redis.echoBuffer("k1", "k2", "a1", "a2", (err, result) => {
  // result[0] equals to Buffer.from('k1');
});

// And of course it works with pipeline:
redis.pipeline().set("foo", "bar").echo("k1", "k2", "a1", "a2").exec();

If the number of keys can't be determined when defining a command, you can omit the numberOfKeys property and pass the number of keys as the first argument when you call the command:

redis.defineCommand("echoDynamicKeyNumber", {
  lua: "return {KEYS[1],KEYS[2],ARGV[1],ARGV[2]}",
});

// Now you have to pass the number of keys as the first argument every time
// you invoke the `echoDynamicKeyNumber` command:
redis.echoDynamicKeyNumber(2, "k1", "k2", "a1", "a2", (err, result) => {
  // result === ['k1', 'k2', 'a1', 'a2']
});

Transparent Key Prefixing

This feature allows you to specify a string that will automatically be prepended to all the keys in a command, which makes it easier to manage your key namespaces.

Warning This feature won't apply to commands like KEYS and SCAN that take patterns rather than actual keys(#239), and this feature also won't apply to the replies of commands even if they are key names (#325).

const fooRedis = new Redis({ keyPrefix: "foo:" });
fooRedis.set("bar", "baz"); // Actually sends SET foo:bar baz

fooRedis.defineCommand("echo", {
  numberOfKeys: 2,
  lua: "return {KEYS[1],KEYS[2],ARGV[1],ARGV[2]}",
});

// Works well with pipelining/transaction
fooRedis
  .pipeline()
  // Sends SORT foo:list BY foo:weight_*->fieldname
  .sort("list", "BY", "weight_*->fieldname")
  // Supports custom commands
  // Sends EVALSHA xxx foo:k1 foo:k2 a1 a2
  .echo("k1", "k2", "a1", "a2")
  .exec();

Transforming Arguments & Replies

Most Redis commands take one or more Strings as arguments, and replies are sent back as a single String or an Array of Strings. However, sometimes you may want something different. For instance, it would be more convenient if the HGETALL command returns a hash (e.g. { key: val1, key2: v2 }) rather than an array of key values (e.g. [key1, val1, key2, val2]).

ioredis has a flexible system for transforming arguments and replies. There are two types of transformers, argument transformer and reply transformer:

const Redis = require("ioredis");

// Here's the built-in argument transformer converting
// hmset('key', { k1: 'v1', k2: 'v2' })
// or
// hmset('key', new Map([['k1', 'v1'], ['k2', 'v2']]))
// into
// hmset('key', 'k1', 'v1', 'k2', 'v2')
Redis.Command.setArgumentTransformer("hmset", (args) => {
  if (args.length === 2) {
    if (typeof Map !== "undefined" && args[1] instanceof Map) {
      // utils is a internal module of ioredis
      return [args[0]].concat(utils.convertMapToArray(args[1]));
    }
    if (typeof args[1] === "object" && args[1] !== null) {
      return [args[0]].concat(utils.convertObjectToArray(args[1]));
    }
  }
  return args;
});

// Here's the built-in reply transformer converting the HGETALL reply
// ['k1', 'v1', 'k2', 'v2']
// into
// { k1: 'v1', 'k2': 'v2' }
Redis.Command.setReplyTransformer("hgetall", (result) => {
  if (Array.isArray(result)) {
    const obj = {};
    for (let i = 0; i < result.length; i += 2) {
      obj[result[i]] = result[i + 1];
    }
    return obj;
  }
  return result;
});

There are three built-in transformers, two argument transformers for hmset & mset and a reply transformer for hgetall. Transformers for hmset and hgetall were mentioned above, and the transformer for mset is similar to the one for hmset:

redis.mset({ k1: "v1", k2: "v2" });
redis.get("k1", (err, result) => {
  // result === 'v1';
});

redis.mset(
  new Map([
    ["k3", "v3"],
    ["k4", "v4"],
  ])
);
redis.get("k3", (err, result) => {
  // result === 'v3';
});

Another useful example of a reply transformer is one that changes hgetall to return array of arrays instead of objects which avoids a unwanted conversation of hash keys to strings when dealing with binary hash keys:

Redis.Command.setReplyTransformer("hgetall", (result) => {
  const arr = [];
  for (let i = 0; i < result.length; i += 2) {
    arr.push([result[i], result[i + 1]]);
  }
  return arr;
});
redis.hset("h1", Buffer.from([0x01]), Buffer.from([0x02]));
redis.hset("h1", Buffer.from([0x03]), Buffer.from([0x04]));
redis.hgetallBuffer("h1", (err, result) => {
  // result === [ [ <Buffer 01>, <Buffer 02> ], [ <Buffer 03>, <Buffer 04> ] ];
});

Monitor

Redis supports the MONITOR command, which lets you see all commands received by the Redis server across all client connections, including from other client libraries and other computers.

The monitor method returns a monitor instance. After you send the MONITOR command, no other commands are valid on that connection. ioredis will emit a monitor event for every new monitor message that comes across. The callback for the monitor event takes a timestamp from the Redis server and an array of command arguments.

Here is a simple example:

redis.monitor((err, monitor) => {
  monitor.on("monitor", (time, args, source, database) => {});
});

Here is another example illustrating an async function and monitor.disconnect():

async () => {
  const monitor = await redis.monitor();
  monitor.on("monitor", console.log);
  // Any other tasks
  monitor.disconnect();
};

Streamify Scanning

Redis 2.8 added the SCAN command to incrementally iterate through the keys in the database. It's different from KEYS in that SCAN only returns a small number of elements each call, so it can be used in production without the downside of blocking the server for a long time. However, it requires recording the cursor on the client side each time the SCAN command is called in order to iterate through all the keys correctly. Since it's a relatively common use case, ioredis provides a streaming interface for the SCAN command to make things much easier. A readable stream can be created by calling scanStream:

const redis = new Redis();
// Create a readable stream (object mode)
const stream = redis.scanStream();
stream.on("data", (resultKeys) => {
  // `resultKeys` is an array of strings representing key names.
  // Note that resultKeys may contain 0 keys, and that it will sometimes
  // contain duplicates due to SCAN's implementation in Redis.
  for (let i = 0; i < resultKeys.length; i++) {
    console.log(resultKeys[i]);
  }
});
stream.on("end", () => {
  console.log("all keys have been visited");
});

scanStream accepts an option, with which you can specify the MATCH pattern, the TYPE filter, and the COUNT argument:

const stream = redis.scanStream({
  // only returns keys following the pattern of `user:*`
  match: "user:*",
  // only return objects that match a given type,
  // (requires Redis >= 6.0)
  type: "zset",
  // returns approximately 100 elements per call
  count: 100,
});

Just like other commands, scanStream has a binary version scanBufferStream, which returns an array of buffers. It's useful when the key names are not utf8 strings.

There are also hscanStream, zscanStream and sscanStream to iterate through elements in a hash, zset and set. The interface of each is similar to scanStream except the first argument is the key name:

const stream = redis.hscanStream("myhash", {
  match: "age:??",
});

You can learn more from the Redis documentation.

Useful Tips It's pretty common that doing an async task in the data handler. We'd like the scanning process to be paused until the async task to be finished. Stream#pause() and Stream#resume() do the trick. For example if we want to migrate data in Redis to MySQL:

const stream = redis.scanStream();
stream.on("data", (resultKeys) => {
  // Pause the stream from scanning more keys until we've migrated the current keys.
  stream.pause();

  Promise.all(resultKeys.map(migrateKeyToMySQL)).then(() => {
    // Resume the stream here.
    stream.resume();
  });
});

stream.on("end", () => {
  console.log("done migration");
});

Auto-reconnect

By default, ioredis will try to reconnect when the connection to Redis is lost except when the connection is closed manually by redis.disconnect() or redis.quit().

It's very flexible to control how long to wait to reconnect after disconnection using the retryStrategy option:

const redis = new Redis({
  // This is the default value of `retryStrategy`
  retryStrategy(times) {
    const delay = Math.min(times * 50, 2000);
    return delay;
  },
});

retryStrategy is a function that will be called when the connection is lost. The argument times means this is the nth reconnection being made and the return value represents how long (in ms) to wait to reconnect. When the return value isn't a number, ioredis will stop trying to reconnect, and the connection will be lost forever if the user doesn't call redis.connect() manually.

When reconnected, the client will auto subscribe to channels that the previous connection subscribed to. This behavior can be disabled by setting the autoResubscribe option to false.

And if the previous connection has some unfulfilled commands (most likely blocking commands such as brpop and blpop), the client will resend them when reconnected. This behavior can be disabled by setting the autoResendUnfulfilledCommands option to false.

By default, all pending commands will be flushed with an error every 20 retry attempts. That makes sure commands won't wait forever when the connection is down. You can change this behavior by setting maxRetriesPerRequest:

const redis = new Redis({
  maxRetriesPerRequest: 1,
});

Set maxRetriesPerRequest to null to disable this behavior, and every command will wait forever until the connection is alive again (which is the default behavior before ioredis v4).

Reconnect on error

Besides auto-reconnect when the connection is closed, ioredis supports reconnecting on certain Redis errors using the reconnectOnError option. Here's an example that will reconnect when receiving READONLY error:

const redis = new Redis({
  reconnectOnError(err) {
    const targetError = "READONLY";
    if (err.message.includes(targetError)) {
      // Only reconnect when the error contains "READONLY"
      return true; // or `return 1;`
    }
  },
});

This feature is useful when using Amazon ElastiCache instances with Auto-failover disabled. On these instances, test your reconnectOnError handler by manually promoting the replica node to the primary role using the AWS console. The following writes fail with the error READONLY. Using reconnectOnError, we can force the connection to reconnect on this error in order to connect to the new master. Furthermore, if the reconnectOnError returns 2, ioredis will resend the failed command after reconnecting.

On ElastiCache insances with Auto-failover enabled, reconnectOnError does not execute. Instead of returning a Redis error, AWS closes all connections to the master endpoint until the new primary node is ready. ioredis reconnects via retryStrategy instead of reconnectOnError after about a minute. On ElastiCache insances with Auto-failover enabled, test failover events with the Failover primary option in the AWS console.

Connection Events

The Redis instance will emit some events about the state of the connection to the Redis server.

Event Description
connect emits when a connection is established to the Redis server.
ready If enableReadyCheck is true, client will emit ready when the server reports that it is ready to receive commands (e.g. finish loading data from disk).
Otherwise, ready will be emitted immediately right after the connect event.
error emits when an error occurs while connecting.
However, ioredis emits all error events silently (only emits when there's at least one listener) so that your application won't crash if you're not listening to the error event.
close emits when an established Redis server connection has closed.
reconnecting emits after close when a reconnection will be made. The argument of the event is the time (in ms) before reconnecting.
end emits after close when no more reconnections will be made, or the connection is failed to establish.
wait emits when lazyConnect is set and will wait for the first command to be called before connecting.

You can also check out the Redis#status property to get the current connection status.

Besides the above connection events, there are several other custom events:

Event Description
select emits when the database changed. The argument is the new db number.

Offline Queue

When a command can't be processed by Redis (being sent before the ready event), by default, it's added to the offline queue and will be executed when it can be processed. You can disable this feature by setting the enableOfflineQueue option to false:

const redis = new Redis({ enableOfflineQueue: false });

TLS Options

Redis doesn't support TLS natively, however if the redis server you want to connect to is hosted behind a TLS proxy (e.g. stunnel) or is offered by a PaaS service that supports TLS connection (e.g. Redis Labs), you can set the tls option:

const redis = new Redis({
  host: "localhost",
  tls: {
    // Refer to `tls.connect()` section in
    // https://nodejs.org/api/tls.html
    // for all supported options
    ca: fs.readFileSync("cert.pem"),
  },
});

Alternatively, specify the connection through a rediss:// URL.

const redis = new Redis("rediss://redis.my-service.com");

Sentinel

ioredis supports Sentinel out of the box. It works transparently as all features that work when you connect to a single node also work when you connect to a sentinel group. Make sure to run Redis >= 2.8.12 if you want to use this feature. Sentinels have a default port of 26379.

To connect using Sentinel, use:

const redis = new Redis({
  sentinels: [
    { host: "localhost", port: 26379 },
    { host: "localhost", port: 26380 },
  ],
  name: "mymaster",
});

redis.set("foo", "bar");

The arguments passed to the constructor are different from the ones you use to connect to a single node, where:

  • name identifies a group of Redis instances composed of a master and one or more slaves (mymaster in the example);
  • sentinelPassword (optional) password for Sentinel instances.
  • sentinels are a list of sentinels to connect to. The list does not need to enumerate all your sentinel instances, but a few so that if one is down the client will try the next one.
  • role (optional) with a value of slave will return a random slave from the Sentinel group.
  • preferredSlaves (optional) can be used to prefer a particular slave or set of slaves based on priority. It accepts a function or array.

ioredis guarantees that the node you connected to is always a master even after a failover. When a failover happens, instead of trying to reconnect to the failed node (which will be demoted to slave when it's available again), ioredis will ask sentinels for the new master node and connect to it. All commands sent during the failover are queued and will be executed when the new connection is established so that none of the commands will be lost.

It's possible to connect to a slave instead of a master by specifying the option role with the value of slave and ioredis will try to connect to a random slave of the specified master, with the guarantee that the connected node is always a slave. If the current node is promoted to master due to a failover, ioredis will disconnect from it and ask the sentinels for another slave node to connect to.

If you specify the option preferredSlaves along with role: 'slave' ioredis will attempt to use this value when selecting the slave from the pool of available slaves. The value of preferredSlaves should either be a function that accepts an array of available slaves and returns a single result, or an array of slave values priorities by the lowest prio value first with a default value of 1.

// available slaves format
const availableSlaves = [{ ip: "127.0.0.1", port: "31231", flags: "slave" }];

// preferredSlaves array format
let preferredSlaves = [
  { ip: "127.0.0.1", port: "31231", prio: 1 },
  { ip: "127.0.0.1", port: "31232", prio: 2 },
];

// preferredSlaves function format
preferredSlaves = function (availableSlaves) {
  for (let i = 0; i < availableSlaves.length; i++) {
    const slave = availableSlaves[i];
    if (slave.ip === "127.0.0.1") {
      if (slave.port === "31234") {
        return slave;
      }
    }
  }
  // if no preferred slaves are available a random one is used
  return false;
};

const redis = new Redis({
  sentinels: [
    { host: "127.0.0.1", port: 26379 },
    { host: "127.0.0.1", port: 26380 },
  ],
  name: "mymaster",
  role: "slave",
  preferredSlaves: preferredSlaves,
});

Besides the retryStrategy option, there's also a sentinelRetryStrategy in Sentinel mode which will be invoked when all the sentinel nodes are unreachable during connecting. If sentinelRetryStrategy returns a valid delay time, ioredis will try to reconnect from scratch. The default value of sentinelRetryStrategy is:

function (times) {
  const delay = Math.min(times * 10, 1000);
  return delay;
}

Cluster

Redis Cluster provides a way to run a Redis installation where data is automatically sharded across multiple Redis nodes. You can connect to a Redis Cluster like this:

const Redis = require("ioredis");

const cluster = new Redis.Cluster([
  {
    port: 6380,
    host: "127.0.0.1",
  },
  {
    port: 6381,
    host: "127.0.0.1",
  },
]);

cluster.set("foo", "bar");
cluster.get("foo", (err, res) => {
  // res === 'bar'
});

Cluster constructor accepts two arguments, where:

  1. The first argument is a list of nodes of the cluster you want to connect to. Just like Sentinel, the list does not need to enumerate all your cluster nodes, but a few so that if one is unreachable the client will try the next one, and the client will discover other nodes automatically when at least one node is connected.

  2. The second argument is the options, where:

    • clusterRetryStrategy: When none of the startup nodes are reachable, clusterRetryStrategy will be invoked. When a number is returned, ioredis will try to reconnect to the startup nodes from scratch after the specified delay (in ms). Otherwise, an error of "None of startup nodes is available" will be returned. The default value of this option is:

      function (times) {
        const delay = Math.min(100 + times * 2, 2000);
        return delay;
      }

      It's possible to modify the startupNodes property in order to switch to another set of nodes here:

      function (times) {
        this.startupNodes = [{ port: 6790, host: '127.0.0.1' }];
        return Math.min(100 + times * 2, 2000);
      }
    • dnsLookup: Alternative DNS lookup function (dns.lookup() is used by default). It may be useful to override this in special cases, such as when AWS ElastiCache used with TLS enabled.

    • enableOfflineQueue: Similar to the enableOfflineQueue option of Redis class.

    • enableReadyCheck: When enabled, "ready" event will only be emitted when CLUSTER INFO command reporting the cluster is ready for handling commands. Otherwise, it will be emitted immediately after "connect" is emitted.

    • scaleReads: Config where to send the read queries. See below for more details.

    • maxRedirections: When a cluster related error (e.g. MOVED, ASK and CLUSTERDOWN etc.) is received, the client will redirect the command to another node. This option limits the max redirections allowed when sending a command. The default value is 16.

    • retryDelayOnFailover: If the target node is disconnected when sending a command, ioredis will retry after the specified delay. The default value is 100. You should make sure retryDelayOnFailover * maxRedirections > cluster-node-timeout to insure that no command will fail during a failover.

    • retryDelayOnClusterDown: When a cluster is down, all commands will be rejected with the error of CLUSTERDOWN. If this option is a number (by default, it is 100), the client will resend the commands after the specified time (in ms).

    • retryDelayOnTryAgain: If this option is a number (by default, it is 100), the client will resend the commands rejected with TRYAGAIN error after the specified time (in ms).

    • retryDelayOnMoved: By default, this value is 0 (in ms), which means when a MOVED error is received, the client will resend the command instantly to the node returned together with the MOVED error. However, sometimes it takes time for a cluster to become state stabilized after a failover, so adding a delay before resending can prevent a ping pong effect.

    • redisOptions: Default options passed to the constructor of Redis when connecting to a node.

    • slotsRefreshTimeout: Milliseconds before a timeout occurs while refreshing slots from the cluster (default 1000).

    • slotsRefreshInterval: Milliseconds between every automatic slots refresh (default 5000).

Read-write splitting

A typical redis cluster contains three or more masters and several slaves for each master. It's possible to scale out redis cluster by sending read queries to slaves and write queries to masters by setting the scaleReads option.

scaleReads is "master" by default, which means ioredis will never send any queries to slaves. There are other three available options:

  1. "all": Send write queries to masters and read queries to masters or slaves randomly.
  2. "slave": Send write queries to masters and read queries to slaves.
  3. a custom function(nodes, command): node: Will choose the custom function to select to which node to send read queries (write queries keep being sent to master). The first node in nodes is always the master serving the relevant slots. If the function returns an array of nodes, a random node of that list will be selected.

For example:

const cluster = new Redis.Cluster(
  [
    /* nodes */
  ],
  {
    scaleReads: "slave",
  }
);
cluster.set("foo", "bar"); // This query will be sent to one of the masters.
cluster.get("foo", (err, res) => {
  // This query will be sent to one of the slaves.
});

NB In the code snippet above, the res may not be equal to "bar" because of the lag of replication between the master and slaves.

Running commands to multiple nodes

Every command will be sent to exactly one node. For commands containing keys, (e.g. GET, SET and HGETALL), ioredis sends them to the node that serving the keys, and for other commands not containing keys, (e.g. INFO, KEYS and FLUSHDB), ioredis sends them to a random node.

Sometimes you may want to send a command to multiple nodes (masters or slaves) of the cluster, you can get the nodes via Cluster#nodes() method.

Cluster#nodes() accepts a parameter role, which can be "master", "slave" and "all" (default), and returns an array of Redis instance. For example:

// Send `FLUSHDB` command to all slaves:
const slaves = cluster.nodes("slave");
Promise.all(slaves.map((node) => node.flushdb()));

// Get keys of all the masters:
const masters = cluster.nodes("master");
Promise.all(
  masters
    .map((node) => node.keys())
    .then((keys) => {
      // keys: [['key1', 'key2'], ['key3', 'key4']]
    })
);

NAT Mapping

Sometimes the cluster is hosted within a internal network that can only be accessed via a NAT (Network Address Translation) instance. See Accessing ElastiCache from outside AWS as an example.

You can specify nat mapping rules via natMap option:

const cluster = new Redis.Cluster(
  [
    {
      host: "203.0.113.73",
      port: 30001,
    },
  ],
  {
    natMap: {
      "10.0.1.230:30001": { host: "203.0.113.73", port: 30001 },
      "10.0.1.231:30001": { host: "203.0.113.73", port: 30002 },
      "10.0.1.232:30001": { host: "203.0.113.73", port: 30003 },
    },
  }
);

This option is also useful when the cluster is running inside a Docker container.

Transaction and pipeline in Cluster mode

Almost all features that are supported by Redis are also supported by Redis.Cluster, e.g. custom commands, transaction and pipeline. However there are some differences when using transaction and pipeline in Cluster mode:

  1. All keys in a pipeline should belong to slots served by the same node, since ioredis sends all commands in a pipeline to the same node.
  2. You can't use multi without pipeline (aka cluster.multi({ pipeline: false })). This is because when you call cluster.multi({ pipeline: false }), ioredis doesn't know which node the multi command should be sent to.

When any commands in a pipeline receives a MOVED or ASK error, ioredis will resend the whole pipeline to the specified node automatically if all of the following conditions are satisfied:

  1. All errors received in the pipeline are the same. For example, we won't resend the pipeline if we got two MOVED errors pointing to different nodes.
  2. All commands executed successfully are readonly commands. This makes sure that resending the pipeline won't have side effects.

Pub/Sub

Pub/Sub in cluster mode works exactly as the same as in standalone mode. Internally, when a node of the cluster receives a message, it will broadcast the message to the other nodes. ioredis makes sure that each message will only be received once by strictly subscribing one node at the same time.

const nodes = [
  /* nodes */
];
const pub = new Redis.Cluster(nodes);
const sub = new Redis.Cluster(nodes);
sub.on("message", (channel, message) => {
  console.log(channel, message);
});

sub.subscribe("news", () => {
  pub.publish("news", "highlights");
});

Events

Event Description
connect emits when a connection is established to the Redis server.
ready emits when CLUSTER INFO reporting the cluster is able to receive commands (if enableReadyCheck is true) or immediately after connect event (if enableReadyCheck is false).
error emits when an error occurs while connecting with a property of lastNodeError representing the last node error received. This event is emitted silently (only emitting if there's at least one listener).
close emits when an established Redis server connection has closed.
reconnecting emits after close when a reconnection will be made. The argument of the event is the time (in ms) before reconnecting.
end emits after close when no more reconnections will be made.
+node emits when a new node is connected.
-node emits when a node is disconnected.
node error emits when an error occurs when connecting to a node. The second argument indicates the address of the node.

Password

Setting the password option to access password-protected clusters:

const Redis = require("ioredis");
const cluster = new Redis.Cluster(nodes, {
  redisOptions: {
    password: "your-cluster-password",
  },
});

If some of nodes in the cluster using a different password, you should specify them in the first parameter:

const Redis = require("ioredis");
const cluster = new Redis.Cluster(
  [
    // Use password "password-for-30001" for 30001
    { port: 30001, password: "password-for-30001" },
    // Don't use password when accessing 30002
    { port: 30002, password: null },
    // Other nodes will use "fallback-password"
  ],
  {
    redisOptions: {
      password: "fallback-password",
    },
  }
);

Special note: AWS ElastiCache Clusters with TLS

AWS ElastiCache for Redis (Clustered Mode) supports TLS encryption. If you use this, you may encounter errors with invalid certificates. To resolve this issue, construct the Cluster with the dnsLookup option as follows:

const cluster = new Redis.Cluster(
  [
    {
      host: "clustercfg.myCluster.abcdefg.xyz.cache.amazonaws.com",
      port: 6379,
    },
  ],
  {
    dnsLookup: (address, callback) => callback(null, address),
    redisOptions: {
      tls: {},
    },
  }
);

Autopipelining

In standard mode, when you issue multiple commands, ioredis sends them to the server one by one. As described in Redis pipeline documentation, this is a suboptimal use of the network link, especially when such link is not very performant.

The TCP and network overhead negatively affects performance. Commands are stuck in the send queue until the previous ones are correctly delivered to the server. This is a problem known as Head-Of-Line blocking (HOL).

ioredis supports a feature called “auto pipelining”. It can be enabled by setting the option enableAutoPipelining to true. No other code change is necessary.

In auto pipelining mode, all commands issued during an event loop are enqueued in a pipeline automatically managed by ioredis. At the end of the iteration, the pipeline is executed and thus all commands are sent to the server at the same time.

This feature can dramatically improve throughput and avoids HOL blocking. In our benchmarks, the improvement was between 35% and 50%.

While an automatic pipeline is executing, all new commands will be enqueued in a new pipeline which will be executed as soon as the previous finishes.

When using Redis Cluster, one pipeline per node is created. Commands are assigned to pipelines according to which node serves the slot.

A pipeline will thus contain commands using different slots but that ultimately are assigned to the same node.

Note that the same slot limitation within a single command still holds, as it is a Redis limitation.

Example of automatic pipeline enqueuing

This sample code uses ioredis with automatic pipeline enabled.

const Redis = require("./built");
const http = require("http");

const db = new Redis({ enableAutoPipelining: true });

const server = http.createServer((request, response) => {
  const key = new URL(request.url, "https://localhost:3000/").searchParams.get(
    "key"
  );

  db.get(key, (err, value) => {
    response.writeHead(200, { "Content-Type": "text/plain" });
    response.end(value);
  });
});

server.listen(3000);

When Node receives requests, it schedules them to be processed in one or more iterations of the events loop.

All commands issued by requests processing during one iteration of the loop will be wrapped in a pipeline automatically created by ioredis.

In the example above, the pipeline will have the following contents:

GET key1
GET key2
GET key3
...
GET keyN

When all events in the current loop have been processed, the pipeline is executed and thus all commands are sent to the server at the same time.

While waiting for pipeline response from Redis, Node will still be able to process requests. All commands issued by request handler will be enqueued in a new automatically created pipeline. This pipeline will not be sent to the server yet.

As soon as a previous automatic pipeline has received all responses from the server, the new pipeline is immediately sent without waiting for the events loop iteration to finish.

This approach increases the utilization of the network link, reduces the TCP overhead and idle times and therefore improves throughput.

Benchmarks

Here's some of the results of our tests for a single node.

Each iteration of the test runs 1000 random commands on the server.

Samples Result Tolerance
default 1000 174.62 op/sec ± 0.45 %
enableAutoPipelining=true 1500 233.33 op/sec ± 0.88 %

And here's the same test for a cluster of 3 masters and 3 replicas:

Samples Result Tolerance
default 1000 164.05 op/sec ± 0.42 %
enableAutoPipelining=true 3000 235.31 op/sec ± 0.94 %

Error Handling

All the errors returned by the Redis server are instances of ReplyError, which can be accessed via Redis:

const Redis = require("ioredis");
const redis = new Redis();
// This command causes a reply error since the SET command requires two arguments.
redis.set("foo", (err) => {
  err instanceof Redis.ReplyError;
});

This is the error stack of the ReplyError:

ReplyError: ERR wrong number of arguments for 'set' command
    at ReplyParser._parseResult (/app/node_modules/ioredis/lib/parsers/javascript.js:60:14)
    at ReplyParser.execute (/app/node_modules/ioredis/lib/parsers/javascript.js:178:20)
    at Socket.<anonymous> (/app/node_modules/ioredis/lib/redis/event_handler.js:99:22)
    at Socket.emit (events.js:97:17)
    at readableAddChunk (_stream_readable.js:143:16)
    at Socket.Readable.push (_stream_readable.js:106:10)
    at TCP.onread (net.js:509:20)

By default, the error stack doesn't make any sense because the whole stack happens in the ioredis module itself, not in your code. So it's not easy to find out where the error happens in your code. ioredis provides an option showFriendlyErrorStack to solve the problem. When you enable showFriendlyErrorStack, ioredis will optimize the error stack for you:

const Redis = require("ioredis");
const redis = new Redis({ showFriendlyErrorStack: true });
redis.set("foo");

And the output will be:

ReplyError: ERR wrong number of arguments for 'set' command
    at Object.<anonymous> (/app/index.js:3:7)
    at Module._compile (module.js:446:26)
    at Object.Module._extensions..js (module.js:464:10)
    at Module.load (module.js:341:32)
    at Function.Module._load (module.js:296:12)
    at Function.Module.runMain (module.js:487:10)
    at startup (node.js:111:16)
    at node.js:799:3

This time the stack tells you that the error happens on the third line in your code. Pretty sweet! However, it would decrease the performance significantly to optimize the error stack. So by default, this option is disabled and can only be used for debugging purposes. You shouldn't use this feature in a production environment.

Plugging in your own Promises Library

If you're an advanced user, you may want to plug in your own promise library like bluebird. Just set Redis.Promise to your favorite ES6-style promise constructor and ioredis will use it.

const Redis = require("ioredis");
Redis.Promise = require("bluebird");

const redis = new Redis();

// Use bluebird
assert.equal(redis.get().constructor, require("bluebird"));

// You can change the Promise implementation at any time:
Redis.Promise = global.Promise;
assert.equal(redis.get().constructor, global.Promise);

Running tests

Start a Redis server on 127.0.0.1:6379, and then:

$ npm test

FLUSH ALL will be invoked after each test, so make sure there's no valuable data in it before running tests.

If your testing environment does not let you spin up a Redis server ioredis-mock is a drop-in replacement you can use in your tests. It aims to behave identically to ioredis connected to a Redis server so that your integration tests is easier to write and of better quality.

Debug

You can set the DEBUG env to ioredis:* to print debug info:

$ DEBUG=ioredis:* node app.js

Join in!

I'm happy to receive bug reports, fixes, documentation enhancements, and any other improvements.

And since I'm not a native English speaker, if you find any grammar mistakes in the documentation, please also let me know. :)

Become a Sponsor

Open source is hard and time-consuming. If you want to invest in ioredis's future you can become a sponsor and make us spend more time on this library's improvements and new features.

Thank you for using ioredis :-)

Contributors

This project exists thanks to all the people who contribute:

License

MIT

FOSSA Status

Comments
  • Failed to refresh slots cache

    Failed to refresh slots cache

    Hi,

    We are running ioredis 4.0.0 against an AWS ElastiCache replication group with cluster mode on (2 nodes, 1 shard) and using the cluster configuration address to connect to the cluster.

    client = new Redis.Cluster([config.redis]);
    

    and the config part:

      redis: Config({
        host: {
          env: 'REDIS_HOST',
          ssm: '/elasticache/redis/host'
        },
        port: {
          env: 'REDIS_PORT',
          ssm: '/elasticache/redis/port'
        }
      }),
    

    Every time we start the application the logs shows us:

    {
        "stack": "Error: Failed to refresh slots cache.\n    at tryNode (/app/node_modules/ioredis/built/cluster/index.js:371:25)\n    at /app/node_modules/ioredis/built/cluster/index.js:383:17\n    at Timeout.<anonymous> (/app/node_modules/ioredis/built/cluster/index.js:594:20)\n    at Timeout.run (/app/node_modules/ioredis/built/utils/index.js:144:22)\n    at ontimeout (timers.js:486:15)\n    at tryOnTimeout (timers.js:317:5)\n    at Timer.listOnTimeout (timers.js:277:5)",
        "message": "Failed to refresh slots cache.",
        "lastNodeError": {
            "stack": "Error: timeout\n    at Object.exports.timeout (/app/node_modules/ioredis/built/utils/index.js:147:38)\n    at Cluster.getInfoFromNode (/app/node_modules/ioredis/built/cluster/index.js:591:34)\n    at tryNode (/app/node_modules/ioredis/built/cluster/index.js:376:15)\n    at Cluster.refreshSlotsCache (/app/node_modules/ioredis/built/cluster/index.js:391:5)\n    at Cluster.<anonymous> (/app/node_modules/ioredis/built/cluster/index.js:171:14)\n    at new Promise (<anonymous>)\n    at Cluster.connect (/app/node_modules/ioredis/built/cluster/index.js:125:12)\n    at new Cluster (/app/node_modules/ioredis/built/cluster/index.js:81:14)\n    at Object.<anonymous> (/app/node_modules/@myapp/myapp-core/core/redis.js:10:12)\n    at Module._compile (module.js:652:30)",
            "message": "timeout"
        },
        "level": "error"
    }
    

    What more information do you need so we can get this fixed?

    screenshot 2018-09-28 at 16 08 57
    opened by tvb 62
  • ioredis 2.0

    ioredis 2.0

    • [x] upgrade Bluebird -> 3.x
    • [x] upgrade Lodash -> 4.x
    • [x] use redis-parser module
    • [x] use redis-commands module
    • [x] [cluster] support TRYAGAIN error
    • [x] [cluster] read-write splitting
    • [x] [cluster] fix ready event #225
    • [x] multi support hgetall
    • [x] add examples
    • [x] Cluster#setStartupNodes() or something similar to update startup nodes dynamically
    • [x] emit authError when redis requires a password #258
    // Read-write splitting:
    var cluster = new Cluster([/* nodes */], {
      splitReads: 'masters' // 'slaves', 'all'
    });
    
    // Get slaves:
    cluster.nodes('slave');
    
    // Get masters:
    cluster.nodes('master');
    
    // Send command to all masters:
    Promise.all(cluster.nodes('master').map(function (node) {
      return node.flushdb();
    }));
    
    // Get all:
    cluster.nodes(); // or cluster.nodes('all');
    
    opened by luin 53
  •  after upgraded ioredis from 4.10.0  to 4.11.1 Error: connect ETIMEDOUT

    after upgraded ioredis from 4.10.0 to 4.11.1 Error: connect ETIMEDOUT

    error:

    Jul 02 21:23:28 server boot[8665]: [2019/07/02 21:23:28.994] [MASTER] [PID: 008665]  [ERROR] [CORE] [SERVICE] [REDIS] error
    Jul 02 21:23:28 server boot[8665]: [2019/07/02 21:23:28.996] [MASTER] [PID: 008665]  [ERROR] 7/2/2019, 9:23:28 PM unhandledRejection Error: connect ETIMEDOUT
    Jul 02 21:23:28 server boot[8665]:     at Socket.<anonymous> (/var/p3x/server.patrikx3.com/node_modules/ioredis/built/redis/index.js:270:31)
    Jul 02 21:23:28 server boot[8665]:     at Object.onceWrapper (events.js:288:20)
    Jul 02 21:23:28 server boot[8665]:     at Socket.emit (events.js:200:13)
    Jul 02 21:23:28 server boot[8665]:     at Socket._onTimeout (net.js:434:8)
    Jul 02 21:23:28 server boot[8665]:     at listOnTimeout (internal/timers.js:531:17)
    Jul 02 21:23:28 server boot[8665]:     at processTimers (internal/timers.js:475:7) {
    Jul 02 21:23:28 server boot[8665]:   errorno: 'ETIMEDOUT',
    Jul 02 21:23:28 server boot[8665]:   code: 'ETIMEDOUT',
    Jul 02 21:23:28 server boot[8665]:   syscall: 'connect'
    Jul 02 21:23:28 server boot[8665]: } Promise {
    Jul 02 21:23:28 server boot[8665]:   <rejected> Error: connect ETIMEDOUT
    Jul 02 21:23:28 server boot[8665]:       at Socket.<anonymous> (/var/p3x/server.patrikx3.com/node_modules/ioredis/built/redis/index.js:270:31)
    Jul 02 21:23:28 server boot[8665]:       at Object.onceWrapper (events.js:288:20)
    Jul 02 21:23:28 server boot[8665]:       at Socket.emit (events.js:200:13)
    Jul 02 21:23:28 server boot[8665]:       at Socket._onTimeout (net.js:434:8)
    Jul 02 21:23:28 server boot[8665]:       at listOnTimeout (internal/timers.js:531:17)
    Jul 02 21:23:28 server boot[8665]:       at processTimers (internal/timers.js:475:7) {
    Jul 02 21:23:28 server boot[8665]:     errorno: 'ETIMEDOUT',
    Jul 02 21:23:28 server boot[8665]:     code: 'ETIMEDOUT',
    Jul 02 21:23:28 server boot[8665]:     syscall: 'connect'
    Jul 02 21:23:28 server boot[8665]:   }
    Jul 02 21:23:28 server boot[8665]: }
    

    With 4.10.0 it works.

    How I connect:

    const settings = {
       "url2": "redis://:[email protected]:6379/0",
       "url": "redis+unix://:password@/var/run/redis/redis-server.sock?db=0"
    }
    return new Redis(settings.url);
    

    with 4.10.0 i can connect either url, with 4.11.0 i get timeout.

    bug released 
    opened by p3x-robot 46
  • Retries per request limit

    Retries per request limit

    I'm migrating to ioredis from node_redis and cannot find max_attempts feature analog, is this about me bad in searching? It's limit for retries per each request after which it will just fail.

    I can implement it on my own as a wrapper but I need to stop requests so that they will not continue to try requesting and this feature is also missing.

    discussion released 
    opened by Jabher 36
  • Chaining custom commands in cluster mode

    Chaining custom commands in cluster mode

    According to the documentation "Chaining custom commands in the pipeline is not supported in Cluster mode.". I am wondering, is this a limitation of ioredis or of redis itself? and do you have any information or link on why this limitation exists?

    pinned released 
    opened by manast 31
  • All of a sudden, I'm receiving this error

    All of a sudden, I'm receiving this error

    [Error: Too many Cluster redirections. Last error: ReplyError: MOVED 6686 10.240.100.31:7000]
    

    I have a 6 nodes setup, I saw this in the log of a node:

    Oct 31 19:04:54 aidax-redis-2 redis-server[1501]: 1501:M 31 Oct 19:04:54.996 * Marking node bd1251b171bf467313c4300d761d92417cbb586f as failing (quorum reached).
    Oct 31 19:04:55 aidax-redis-2 redis-server[1501]: 1501:M 31 Oct 19:04:55.439 * Clear FAIL state for node bd1251b171bf467313c4300d761d92417cbb586f: slave is reachable again.
    

    I think ioredis is not recovering well alongside the redis cluster(3.2)

    opened by thelinuxlich 31
  • How to avoid CLUSTERDOWN and UNBLOCKED?

    How to avoid CLUSTERDOWN and UNBLOCKED?

    Revisiting this problem, I asked on the redis google group about it and here it is what @antirez said:

    Hello,
    
    CLUSTERDOWN is a transient error that happens when at least one master
    node is down. If you want the partial portion of the cluster which is
    still up to run regardless of a set of hash slots not covered, there
    is an option inside the example "redis.conf" file, doing exactly this.
    
    UNBLOCKED is unavoidable since it is delivered to clients that are
    blocked into lists that are moved from a different master because of
    resharding. We don't want them to wait forever for something that will
    never happen, since those lists are not moved into a different master.
    
    So CLUSTERDOWN should be handled by the application and or at client
    level directly by retrying. UNBLOCKED should be handled rescanning the
    config with CLUSTER SLOTS and connecting to the right node.
    
    Cheers,
    Salvatore
    

    Configuration-wise, I've set my cluster with "cluster-require-full-coverage" to "no" so I just need to know how to cover this on the application side

    opened by thelinuxlich 30
  • Fails to connect to redis, when running inside of docker container

    Fails to connect to redis, when running inside of docker container

    Hey, the library works like a charm, thanks a lot. My application is a microservice, which connects to a redis database, which is running inside of docker. However, I can not connect to redis, when my application is running inside of container. I can still connect to redis remotely via cli on other host and it clearly works. I can also run my application outside of docker (directly on my host machine) and it would still connect. But when I build and run the image, it says:

    [ioredis] Unhandled error event: Error: connect ECONNREFUSED 127.0.0.1:6379
        at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1085:14)
    

    I also tried to provision my application to docker swarm with compose file on the same network as redis

    version: "3"
    services:
      myapp:
        image: user/app:latest
        deploy:
          restart_policy:
            condition: on-failure
        ports:
          - "5000:5000"
        networks:
          - webnet
    
      redis:
        image: redis
        ports:
          - "6379:6379"
        volumes:
          - "./data:/data"
        command: redis-server --appendonly yes
        networks:
          - webnet
          
    networks:
      webnet:
    

    But it still wouldn't connect

    Here is the code, I use in my application:

    const redis = require('ioredis')
    const appdb = new redis()
    
    module.exports = { db }
    

    Thank you in advance.

    opened by mishushakov 28
  • Catch ECONNREFUSED exceptions

    Catch ECONNREFUSED exceptions

    Hi, I want to test what happens to my application when redis goes down. So after starting the server I manually stop the redis daemon that's running on my machine, and I expect to have the errors reported on my error callback/promise. Instead, I get uncaught exceptions all over the place.

    I've tried using a custom retryStrategy, I've tried to set Redis.Promise.onPossiblyUnhandledRejection as well... all with no luck. Is there something I'm missing here? How am I supposed to test what happens to my server if for any reason redis stops working? Thanks

    help wanted 
    opened by neslinesli93 23
  • fix: always allow selecting a new node for cluster mode subscriptions when the current one fails

    fix: always allow selecting a new node for cluster mode subscriptions when the current one fails

    We ran into an issue where some of our redis clients would miss messages from the pubsub bus following a network issue / crash in the redis cluster. This PR changes the reconnect logic in the ClusterSubscriber such that it can pick to connect to a different node when the current connection closes. The idea being that if a single node is having issues, the subscriber can connect immediately to another member of the cluster so it doesn't miss as many messages.

    released 
    opened by headlessme 21
  • Unhandled error event: Error: read ECONNRESET at TCP.onStreamRead

    Unhandled error event: Error: read ECONNRESET at TCP.onStreamRead

    Hi, I am getting below error sometimes. Redis connection gets disconnected sometime. Out of 10 I am facing this issue 2 time. It takes time to reconnect the server and api response time increases from 50-80 msec to 1-2 mins.

    Error : Unhandled error event: Error: read ECONNRESET at TCP.onStreamRead

    Ioredis client configuration as below: var redisMasterClient = new IORedis({ host: host , connectTimeout: 1000, password: "password, keepAlive : 1000, retryStrategy: function(times) { var delay = Math.min(times * 10, 2000); return delay; }, maxRetriesPerRequest: 1 });

    Please help. This is urgent issue on production.

    opened by sysopsnw18 21
  • chore(deps): bump json5 from 2.2.0 to 2.2.3

    chore(deps): bump json5 from 2.2.0 to 2.2.3

    Bumps json5 from 2.2.0 to 2.2.3.

    Release notes

    Sourced from json5's releases.

    v2.2.3

    v2.2.2

    • Fix: Properties with the name __proto__ are added to objects and arrays. (#199) This also fixes a prototype pollution vulnerability reported by Jonathan Gregson! (#295).

    v2.2.1

    • Fix: Removed dependence on minimist to patch CVE-2021-44906. (#266)
    Changelog

    Sourced from json5's changelog.

    v2.2.3 [code, diff]

    v2.2.2 [code, diff]

    • Fix: Properties with the name __proto__ are added to objects and arrays. (#199) This also fixes a prototype pollution vulnerability reported by Jonathan Gregson! (#295).

    v2.2.1 [code, diff]

    • Fix: Removed dependence on minimist to patch CVE-2021-44906. (#266)
    Commits
    • c3a7524 2.2.3
    • 94fd06d docs: update CHANGELOG for v2.2.3
    • 3b8cebf docs(security): use GitHub security advisories
    • f0fd9e1 docs: publish a security policy
    • 6a91a05 docs(template): bug -> bug report
    • 14f8cb1 2.2.2
    • 10cc7ca docs: update CHANGELOG for v2.2.2
    • 7774c10 fix: add proto to objects and arrays
    • edde30a Readme: slight tweak to intro
    • 97286f8 Improve example in readme
    • Additional commits viewable in compare view

    Dependabot compatibility score

    Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


    Dependabot commands and options

    You can trigger Dependabot actions by commenting on this PR:

    • @dependabot rebase will rebase this PR
    • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
    • @dependabot merge will merge this PR after your CI passes on it
    • @dependabot squash and merge will squash and merge this PR after your CI passes on it
    • @dependabot cancel merge will cancel a previously requested merge and block automerging
    • @dependabot reopen will reopen this PR if it is closed
    • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
    • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
    • @dependabot use these labels will set the current labels as the default for future PRs for this repo and language
    • @dependabot use these reviewers will set the current reviewers as the default for future PRs for this repo and language
    • @dependabot use these assignees will set the current assignees as the default for future PRs for this repo and language
    • @dependabot use this milestone will set the current milestone as the default for future PRs for this repo and language

    You can disable automated security fix PRs for this repo from the Security Alerts page.

    dependencies 
    opened by dependabot[bot] 0
  • Reconnecting after network outage

    Reconnecting after network outage

    When I develop locally and put my laptop to sleep, or when I just disable the wifi for a minute, then it seems that the redis connection is not being re-established. I'm afraid that this would be fatal for live environments in case such a network outage happens at night. Is there a way to configure the redis client in a way that it's reconnecting automatically? I tried different reconnect strategies, different parameters etc. but never succeeded in re-establishing the connection. This is an example of a configuration that causes the problem:

        const redisClient = new Redis({
            host: process.env.REDIS_HOST, username: process.env.REDIS_USERNAME, password: process.env.REDIS_PASSWORD, port: Number(process.env.REDIS_PORT), tls: {},
            reconnectOnError(err) {
                console.log('The following Redis connect error occured:', err, 'trying to reconnect...')
                return true
            }
        })
    
        redisClient.on('error', function (e) {
            console.error(`Redis error occurred "${e?.message}".`)
        })
        redisClient.on('connect', function () {
            console.error(`Redis connected to server.`)
        })
        redisClient.on('reconnecting', function () {
            console.error(`Redis reconnected to server.`)
        })
        redisClient.on('closed', function (e) {
            console.error(`Redis reconnection closed "${e?.message}".`)
        })
        redisClient.on('closed', function () {
            console.error(`Redis is ready`)
        })
    

    I'm using version 6 (also tried version 4) of Redis Cache for Azure.

    opened by flashtheman 0
  • Can't resolve 'tls', 'net', and 'dns' when connecting to redis host

    Can't resolve 'tls', 'net', and 'dns' when connecting to redis host

    According to the discussion that follows, build failures prevented me from using the following code.

    https://github.com/vercel/next.js/discussions/44435

      const handleApiTokenChange = async (e) => {
        // Set the value of the textarea element in the component's state
        setApiToken(e.target.value);
    
        // Set the value of the 'apiToken' key in Redis
        const redis = new Redis({
          host: 'redis', // Redis host
          port: '6379', // Redis port
        });
    
        await redis.set('apiToken', e.target.value);
      };
    

    Errors:

    build: ./node_modules/.pnpm/[email protected]/node_modules/ioredis/built/cluster/ClusterOptions.js
    build: Module not found: Can't resolve 'dns' in
    build: ./node_modules/.pnpm/[email protected]/node_modules/ioredis/built/connectors/SentinelConnector/index.js
    build: ./node_modules/.pnpm/[email protected]/node_modules/ioredis/built/cluster/util.js
    build: Module not found: Can't resolve 'net' in 
    build: Module not found: Can't resolve 'tls' in
    

    What is the proper method to put this up, since I believe I did this incorrectly?

    opened by NorkzYT 0
  • cant test redis database on integrations test using jest and supertest

    cant test redis database on integrations test using jest and supertest

    I have an express app that uses redis througth ioredis lib and it works fine on all environment but the test environment.

    I put it in the simplest form possible. Using JS, just a app.js file, with a second file where a connect to redis and export the client that is used in app. app.js

    const express = require('express');
    const ioredis = require('./database/ioredis');
    // const redis = require('./database/redis');;
    
    const app = express();
    
    app.use("/", async (req, res) => {
      await ioredis.set("ioredis", "test")
      
      // await redis.connect();
      // await redis.set('redis', 'value');
      // const value = await redis.get('redis');
      // await redis.disconnect();
      res.status(200).send({ message: "Hello" })
    })
    
    module.exports = app
    

    database/ioredis.js

    const Redis = require('ioredis');
    
    const ioredis = new Redis({
      host: "localhost",
      port: 6379,
      db: 2
    })
    
    module.exports = ioredis
    

    test.js

    const supertest = require('supertest');
    const app = require('../app');
    
    describe("Testing Redis on supertest", () => {
      it("should run supertest", async () => {
        const { status, body } = await supertest(app).post("/")
    
        expect(status).toBe(200)
        expect(body).toEqual({ message: "Hello" })
      })
    })
    

    When run the test jest gives the following message

    Jest has detected the following 1 open handles potentially keeping Jest from exiting:
    ●  TCPWRAP
    
          1 | import Redis from 'ioredis'
          2 |
        > 3 | const ioredis = new Redis({
            |                 ^
          4 |   host: "localhost",
          5 |   port: 6379,
          6 |   db: 2
    
          at ../../node_modules/ioredis/built/connectors/StandaloneConnector.js:44:21
          at Object.<anonymous> (../database/ioredis.ts:3:17)
          at Object.<anonymous> (../app.ts:2:1)
          at Object.<anonymous> (supertest.ts:2:1)
    

    It's possible to see I'm doing tests with redis lib... and since they connect and disconnect in each operations, it worked fine, but if I comment the diconnect line I got same problem as well.

    opened by danilomourelle 0
  • Redis connection errors using gateway server / load balancer.

    Redis connection errors using gateway server / load balancer. "Please report this"

    I'm trying to connect IORedis v5.2.4 to a redis server behind a gateway (Caddy v2.5.1). All seems to work fine without SSL/TLS but IORedis can't connect when using either a "redis://" schema or with tls config options.

    rediss:// schema attempt:

    process.env.NODE_TLS_REJECT_UNAUTHORIZED = '0';
    const redis = new IORedis(`rediss://redis-admin:abc123@localhost:6321`);
    await redis.ping();
    

    ...results in:

    Redis connection error Error: Client network socket disconnected before secure TLS connection was established
        at connResetException (node:internal/errors:692:14)
        at TLSSocket.onConnectEnd (node:_tls_wrap:1587:19)
        at TLSSocket.emit (node:events:539:35)
        at TLSSocket.emit (node:domain:475:12)
        at endReadableNT (node:internal/streams/readable:1345:12)
        at processTicksAndRejections (node:internal/process/task_queues:83:21) {
      code: 'ECONNRESET',
      path: undefined,
      host: 'localhost',
      port: 6321,
      localAddress: undefined
    }
    

    ....with strange TLS handshake problems reported by the gateway:

    {"level":"debug","ts":1672441488.2447333,"logger":"tls.handshake","msg":"no matching certificates and no custom selection logic","identifier":"172.25.0.2"}
    {"level":"debug","ts":1672441488.2447736,"logger":"tls.handshake","msg":"all external certificate managers yielded no certificates and no errors","sni":""}
    {"level":"debug","ts":1672441488.2448027,"logger":"tls.handshake","msg":"no certificate matching TLS ClientHello","server_name":"","remote":"172.25.0.1:35082","identifier":"172.25.0.2","cipher_suites":[4866,4867,4865,49199,49195,49200,49196,158,49191,103,49192,107,163,159,52393,52392,52394,49327,49325,49315,49311,49245,49249,49239,49235,162,49326,49324,49314,49310,49244,49248,49238,49234,49188,106,49187,64,49162,49172,57,56,49161,49171,51,50,157,49313,49309,49233,156,49312,49308,49232,61,60,53,47,255],"cert_cache_fill":0.0001,"load_if_necessary":true,"obtain_if_necessary":true,"on_demand":false}
    {"level":"debug","ts":1672441488.2449312,"logger":"http.stdlib","msg":"http: TLS handshake error from 172.25.0.1:35082: no certificate available for '172.25.0.2'"}
    

    TLS-options attempt:

    const redis = new IORedis({
      host: 'localhost',
      port: 6321,
      username: 'redis-admin',
      password: 'abc123',
      tls: {
        rejectUnauthorized: false,
        servername: 'localhost',    
      }
    });
    await redis.ping();
    

    ...results in:

    Redis connection error ParserError: Protocol error, got "H" as reply type byte. Please report this.
        at handleError (/home/ferbs/repos/repos-plurr/plurr/node_modules/.pnpm/[email protected]/node_modules/redis-parser/lib/parser.js:190:15)
        at parseType (/home/ferbs/repos/repos-plurr/plurr/node_modules/.pnpm/[email protected]/node_modules/redis-parser/lib/parser.js:304:14) {
      offset: 1,
      buffer: '{"type":"Buffer","data":[72,84,84,80,47,49,46,49,32,52,48,48,32,66,97,100,32,82,101,113,117,101,115,116,13,10,67,111,110,116,101,110,116,45,84,121,112,101,58,32,116,101,120,116,47,112,108,97,105,110,59,32,99,104,97,114,115,101,116,61,117,116,102,45,56,13,10,67,111,110,110,101,99,116,105,111,110,58,32,99,108,111,115,101,13,10,13,10,52,48,48,32,66,97,100,32,82,101,113,117,101,115,116]}'
    }
    

    ...but with no TLS problems reported by the gateway:

    {"level":"debug","ts":1672441703.3973467,"logger":"tls.handshake","msg":"choosing certificate","identifier":"localhost","num_choices":1}
    {"level":"debug","ts":1672441703.3973958,"logger":"tls.handshake","msg":"default certificate selection results","identifier":"localhost","subjects":["localhost"],"managed":true,"issuer_key":"local","hash":"a7d0d4c9d08ddb0d3417b1e5f655a55b1c03b44df52d5d3a1a8ff0708d0bc704"}
    {"level":"debug","ts":1672441703.397411,"logger":"tls.handshake","msg":"matched certificate in cache","subjects":["localhost"],"managed":true,"expiration":1672466287,"hash":"a7d0d4c9d08ddb0d3417b1e5f655a55b1c03b44df52d5d3a1a8ff0708d0bc704"}
    
    A tcpdump confirms traffic is ciphertext 17:44:18.959090 lo In IP 127.0.0.1.55234 > 127.0.0.1.6321: Flags [S], seq 1717281641, win 65495, options [mss 65495,sackOK,TS val 1324065157 ecr 0,nop,wscale 7], length 0 E..<.9@[email protected][.i.........0......... N........... 17:44:18.959101 lo In IP 127.0.0.1.6321 > 127.0.0.1.55234: Flags [S.], seq 2087445893, ack 1717281642, win 65483, options [mss 65495,sackOK,TS val 1324065157 ecr 1324065157,nop,wscale 7], length 0 E..<..@.@.<.............|k..f[.j.....0......... N...N....... 17:44:18.959108 lo In IP 127.0.0.1.55234 > 127.0.0.1.6321: Flags [.], ack 1, win 512, options [nop,nop,TS val 1324065157 ecr 1324065157], length 0 E..4.:@[email protected][.j|k.......(..... N...N... 17:44:18.959311 lo In IP 127.0.0.1.55234 > 127.0.0.1.6321: Flags [P.], seq 1:364, ack 1, win 512, options [nop,nop,TS val 1324065157 ecr 1324065157], length 363 E....;@[email protected][.j|k............. N...N.......f...b..C"F...HX(.LQ.Y&..v...X..O _.O? $ e>.j.i..%V...RP]..%...3\..y,.U'..v......./.+.0.,...'.g.(.k...................].a.W.S...........\.`.V.R.$.j.#.@. ...9.8. ...3.2.......Q.......P.=.<.5./.............. localhost......... ... ...........#.............0............. . .................................+........-.....3.&.$... ....\..VQ^ |.fH(...!.+e9.{.e...k 17:44:18.959316 lo In IP 127.0.0.1.6321 > 127.0.0.1.55234: Flags [.], ack 364, win 509, options [nop,nop,TS val 1324065157 ecr 1324065157], length 0 E..4Na@.@..`............|k..f[.......(..... N...N... 17:44:18.959762 lo In IP 127.0.0.1.6321 > 127.0.0.1.55234: Flags [P.], seq 1:1423, ack 364, win 512, options [nop,nop,TS val 1324065158 ecr 1324065157], length 1422 E...Nb@.@...............|k..f[............. N...N.......z...v..nf6.9.{.......I...S........q.m.. e>.j.i..%V...RP]..%...3\..y,.U'.......+.....3.$... 8.\.P.; @.qc..W.M....d....Uf...]............{..{.k..8..6.. cLNW..=.......bFxL.O?_.b{.....5@._4....a..$on....an....'O..:.9........S}....W...@........{.... .......9.2....>xp....P.#W_U;!BT......,<&}.5... ......(..[].o......uj....wr...^:5%.....x.cs.D.. .;..#....4........Z..y.TL.......x......IG....tZ.O..C........*z.n..i...-. Q.v..S|gq....`J.eA....X.|E..=.i...[dn.I..~...BY..<.....v.C.t..Y.h.[>... ..0.......l...$... ...9.."b^.Ss...-.$R<..f.^[email protected].).T..<.D!..mif.....98.|.Nf. T`.z.D....7.|.=l...J.{S.C.B...=.`rK..`.....cCB[ID.6.lI..........f...1.3...22...!.......:m..)..[.n.C.7E...0h..V.. .Zw^.A4..:........G#.Z...zI..E..........j:... ^.., ........2....F...-... [email protected]...>.[qn.z.pE.....%l**[...:.+4!...3.~.'...0..aD{.s....Y...`+M..F..3M...q*..H....p..7.D..e..k.zr.l.Z....^zQ.}....OE ...S.... >.......xQ...q....KO..A...k.J%/....5+s..z.U.z~M...d.m.(8.0.s.:R.L...O.>%s}.~U.7.,t q.d.C}......|.2r`.k#.R#bf,3..b.>..(.8>.%D<.I....?z....(3.}0.s .Q......W......C.s..........K..30..........E.Y5. ....dx.F<... [n...0......`....!.....2....q..... 17:44:18.959768 lo In IP 127.0.0.1.55234 > 127.0.0.1.6321: Flags [.], ack 1423, win 502, options [nop,nop,TS val 1324065158 ecr 1324065158], length 0 E..4.<@[email protected][..|k.......(..... N...N... 17:44:18.960477 lo In IP 127.0.0.1.55234 > 127.0.0.1.6321: Flags [P.], seq 364:513, ack 1423, win 512, options [nop,nop,TS val 1324065158 ecr 1324065158], length 149 E....=@[email protected][..|k............. N...N.............5..(S$8.d.m..L.v......>.}..V.....{Y.E}*....p...J=...%.....Pqo>kK..7d..p...|i. f....xFtx...E.....~........Rj....c....P..I....'.j.Z.q........ 17:44:18.960481 lo In IP 127.0.0.1.6321 > 127.0.0.1.55234: Flags [.], ack 513, win 511, options [nop,nop,TS val 1324065158 ecr 1324065158], length 0 E..4Nc@.@..^............|k..f[.j.....(..... N...N... 17:44:18.960726 lo In IP 127.0.0.1.6321 > 127.0.0.1.55234: Flags [P.], seq 1423:1572, ack 513, win 512, options [nop,nop,TS val 1324065159 ecr 1324065158], length 149 E...Nd@.@...............|k..f[.j........... N...N.......xm..K.e.f.pjP....d.J.!{..R..{[email protected]......... 89....@...~*....io...+.2AC..]1<.&.....u.c.q.Y.g...=i..k..y....u;.e........X.V...:8._..(5#. 17:44:18.960729 lo In IP 127.0.0.1.55234 > 127.0.0.1.6321: Flags [.], ack 1572, win 511, options [nop,nop,TS val 1324065159 ecr 1324065159], length 0 E..4.>@[email protected][.j|k.......(..... N...N... 17:44:18.960746 lo In IP 127.0.0.1.6321 > 127.0.0.1.55234: Flags [F.], seq 1572, ack 513, win 512, options [nop,nop,TS val 1324065159 ecr 1324065159], length 0 E..4Ne@.@..\............|k..f[.j.....(..... N...N... 17:44:18.960983 lo In IP 127.0.0.1.55234 > 127.0.0.1.6321: Flags [P.], seq 513:549, ack 1573, win 511, options [nop,nop,TS val 1324065159 ecr 1324065159], length 36 E..X.?@[email protected]^............f[.j|k.......L..... N...N........1G+.&P..$.1.9.U...}..^.be.....9 17:44:18.960989 lo In IP 127.0.0.1.6321 > 127.0.0.1.55234: Flags [.], ack 549, win 512, options [nop,nop,TS val 1324065159 ecr 1324065159], length 0 E..4Nf@.@..[............|k..f[.......(..... N...N... 17:44:18.963402 lo In IP 127.0.0.1.55234 > 127.0.0.1.6321: Flags [P.], seq 549:573, ack 1573, win 512, options [nop,nop,TS val 1324065161 ecr 1324065159], length 24 E..L.@@[email protected][..|k.......@..... N...N........z....=....&h....... 17:44:18.963407 lo In IP 127.0.0.1.6321 > 127.0.0.1.55234: Flags [.], ack 573, win 512, options [nop,nop,TS val 1324065161 ecr 1324065161], length 0 E..4Ng@[email protected]............|k..f[.......(..... N...N... 17:44:18.964098 lo In IP 127.0.0.1.55234 > 127.0.0.1.6321: Flags [F.], seq 573, ack 1573, win 512, options [nop,nop,TS val 1324065162 ecr 1324065161], length 0 E..4.A@[email protected][..|k.......(..... N...N... 17:44:18.964102 lo In IP 127.0.0.1.6321 > 127.0.0.1.55234: Flags [.], ack 574, win 512, options [nop,nop,TS val 1324065162 ecr 1324065162], length 0 E..4..@.@.<.............|k..f[......1B..... N...N... 17:44:19.018231 lo In IP 127.0.0.1.55242 > 127.0.0.1.6321: Flags [S], seq 1764005864, win 65495, options [mss 65495,sackOK,TS val 1324065216 ecr 0,nop,wscale 7], length 0 E..<..@.@.\.............i$...........0......... N........... 17:44:19.018250 lo In IP 127.0.0.1.6321 > 127.0.0.1.55242: Flags [S.], seq 1117529082, ack 1764005865, win 65483, options [mss 65495,sackOK,TS val 1324065216 ecr 1324065216,nop,wscale 7], length 0 E..<..@.@.<.............B.#.i$.......0......... N...N....... 17:44:19.018264 lo In IP 127.0.0.1.55242 > 127.0.0.1.6321: Flags [.], ack 1, win 512, options [nop,nop,TS val 1324065216 ecr 1324065216], length 0 E..4..@.@.\.............i$..B.#......(..... N...N... 17:44:19.018496 lo In IP 127.0.0.1.55242 > 127.0.0.1.6321: Flags [P.], seq 1:364, ack 1, win 512, options [nop,nop,TS val 1324065216 ecr 1324065216], length 363 E.....@.@.[z............i$..B.#............ N...N.......f...b..jNt....8Yz|.s.vx.....w...i.[\... &.x.!..FA.0H8}#..Y.d9t...y..j..[.v......./.+.0.,...'.g.(.k...................].a.W.S...........\.`.V.R.$.j.#.@. ...9.8. ...3.2.......Q.......P.=.<.5./.............. localhost......... ... ...........#.............0............. . .................................+........-.....3.&.$... 9<.7.nq........n..i;sQ~g3t..m.K{ 17:44:19.018509 lo In IP 127.0.0.1.6321 > 127.0.0.1.55242: Flags [.], ack 364, win 509, options [nop,nop,TS val 1324065216 ecr 1324065216], length 0 E..4|.@[email protected].#.i$.T.....(..... N...N... 17:44:19.019476 lo In IP 127.0.0.1.6321 > 127.0.0.1.55242: Flags [P.], seq 1:1425, ack 364, win 512, options [nop,nop,TS val 1324065217 ecr 1324065216], length 1424 E...|.@[email protected].#.i$.T........... N...N.......z...v..P......Z.......t.,.U&rg..C...9#. &.x.!..FA.0H8}#..Y.d9t...y..j..[......+.....3.$... ...[....[-OD.D0.*F....... ...'SY...............?F^.'y.|N...%^.0.O........j..+.....A.;Y...<[........3B.l.M..s....r.K...sO.....w...w...QT.0D..P._.H..k..Yy.!k.......+.[Q.:......V....{.6.E...W.....<-Z.a2...Pc....`.Z.<...\.....>EF._a..b.S./..CKxb...n.O=.b...3 F6.?...n.c-4....jQT.M...u....v......Z...@.".(c...+R..^....<.x.Y.....GjA0.<.V..p.V.K0`R"..Yt.6b.....).=hV.......8..F6......t..'.n.4o...C.1.M.0.......MG.0UGg..Vy.F.A)>6.^7d..GQ..|#.S...s>...}...n.Q9c..9 ..0W75....._k.....t-......5".....)...Z...5Yb..^.J../.q....fC..f=CE...O9#.z..8O..`...[......fg.."C....Z...l...Q>#....%$eT......T&'.t>.]C...7..\...e..0..t.].Rt:yK.|2 l.RL.%..8.a. .T.5...I.F.w.w...t.^|.M+.?..4a{+.C.....E....Hl.F....jd.....H1.....#.ry..:.m..Idq.......!h5.tN;....oz*IO..WB..M.B.\.A.vl.v.(.Q.\..B{.....s......?...a.^..3.R...@..,x.U8"........Q...(..[..L....m..!."[email protected].... .{.....2X`..1F?=.....[,=..w..&[.-'.g..A...u& 8X.s...n.k..[.N....97...l._....u...=........`n.....0.p.&-$...84P;..:.2.^@G.*t...i..)7#*.....4CKjq....h....hE,[.8>k . .Tp+.....a.a...:..{.#6...6...s...E .....s#.BsT....^....vt.......X.*.Y..xB.c....BfS.V..tw~.0...".T..r..Ng..Y....53 .....S.B.....S.4`l..63ro...k.....j}......0.<......d...... 127.0.0.1.6321: Flags [.], ack 1425, win 502, options [nop,nop,TS val 1324065217 ecr 1324065217], length 0 E..4..@.@.\.............i$.TB.)......(..... N...N... 17:44:19.020624 lo In IP 127.0.0.1.55242 > 127.0.0.1.6321: Flags [P.], seq 364:513, ack 1425, win 512, options [nop,nop,TS val 1324065219 ecr 1324065217], length 149 E.....@.@.\N............i$.TB.)............ N...N.............5.&.....m.... Y.I/0_u._. 2.j.y3....tYU.Pl9..E.7O...<.S....P...k.>..m..z.{.~x.MY..61.s9.rv.r...3X.............-J..s ..o...u.rv.F...c..@.,cg. 17:44:19.020642 lo In IP 127.0.0.1.6321 > 127.0.0.1.55242: Flags [.], ack 513, win 511, options [nop,nop,TS val 1324065219 ecr 1324065219], length 0 E..4|.@[email protected].).i$.......(..... N...N... 17:44:19.020986 lo In IP 127.0.0.1.55242 > 127.0.0.1.6321: Flags [P.], seq 513:549, ack 1425, win 512, options [nop,nop,TS val 1324065219 ecr 1324065219], length 36 E..X..@.@.\.............i$..B.)......L..... N...N........ . ....D.y..0.D.._v;[.....m!3W. 17:44:19.020991 lo In IP 127.0.0.1.6321 > 127.0.0.1.55242: Flags [.], ack 549, win 511, options [nop,nop,TS val 1324065219 ecr 1324065219], length 0 E..4|.@[email protected].).i$.......(..... N...N... 17:44:19.021097 lo In IP 127.0.0.1.6321 > 127.0.0.1.55242: Flags [P.], seq 1425:1574, ack 549, win 511, options [nop,nop,TS val 1324065219 ecr 1324065219], length 149 E...|.@[email protected].).i$............. N...N.......x.{GQ....fD..f.....2...D9T.#3..6......#Z.{.#.F...W.....v7'./..Y..p%...FN_H.1. .I6Hm..89.qvW!}..bA...);...7.d.....".l.(..f.......36....[..B4....E 17:44:19.021110 lo In IP 127.0.0.1.55242 > 127.0.0.1.6321: Flags [.], ack 1574, win 511, options [nop,nop,TS val 1324065219 ecr 1324065219], length 0 E..4..@.@.\.............i$..B.* .....(..... N...N... 17:44:19.021135 lo In IP 127.0.0.1.6321 > 127.0.0.1.55242: Flags [F.], seq 1574, ack 549, win 511, options [nop,nop,TS val 1324065219 ecr 1324065219], length 0 E..4|.@[email protected].* i$.......(..... N...N... 17:44:19.021999 lo In IP 127.0.0.1.55242 > 127.0.0.1.6321: Flags [P.], seq 549:573, ack 1575, win 511, options [nop,nop,TS val 1324065220 ecr 1324065219], length 24 E..L..@.@.\.............i$..B.*!.....@..... N...N........,Fj\.FBi..*...K.... 17:44:19.022015 lo In IP 127.0.0.1.6321 > 127.0.0.1.55242: Flags [.], ack 573, win 511, options [nop,nop,TS val 1324065220 ecr 1324065220], length 0 E..4|.@[email protected].*!i$.%.....(..... N...N... 17:44:19.022552 lo In IP 127.0.0.1.55242 > 127.0.0.1.6321: Flags [F.], seq 573, ack 1575, win 512, options [nop,nop,TS val 1324065220 ecr 1324065220], length 0 E..4..@.@.\.............i$.%B.*!.....(..... N...N... 17:44:19.022567 lo In IP 127.0.0.1.6321 > 127.0.0.1.55242: Flags [.], ack 574, win 511, options [nop,nop,TS val 1324065220 ecr 1324065220], length 0 E..4..@.@.<.............B.*!i$.&....4...... N...N... 17:44:19.128045 lo In IP 127.0.0.1.55256 > 127.0.0.1.6321: Flags [S], seq 3916421631, win 65495, options [mss 65495,sackOK,TS val 1324065326 ecr 0,nop,wscale 7], length 0 E..<3.@[email protected]......... N........... 17:44:19.128071 lo In IP 127.0.0.1.6321 > 127.0.0.1.55256: Flags [S.], seq 411690038, ack 3916421632, win 65483, options [mss 65495,sackOK,TS val 1324065326 ecr 1324065326,nop,wscale 7], length 0 E..<..@.@.<................6.o.......0......... N...N....... 17:44:19.128093 lo In IP 127.0.0.1.55256 > 127.0.0.1.6321: Flags [.], ack 1, win 512, options [nop,nop,TS val 1324065326 ecr 1324065326], length 0 E..43.@[email protected].....(..... N...N... 17:44:19.128505 lo In IP 127.0.0.1.55256 > 127.0.0.1.6321: Flags [P.], seq 1:364, ack 1, win 512, options [nop,nop,TS val 1324065326 ecr 1324065326], length 363 E...3.@[email protected]........... N...N.......f...b...+j^........0J...........H.<.... ...2..O....`)6...{.S.t.`......r..v......./.+.0.,...'.g.(.k...................].a.W.S...........\.`.V.R.$.j.#.@. ...9.8. ...3.2.......Q.......P.=.<.5./.............. localhost......... ... ...........#.............0............. . .................................+........-.....3.&.$... .g...R..;....IP..E..yc.c-.FD.P?. 17:44:19.128525 lo In IP 127.0.0.1.6321 > 127.0.0.1.55256: Flags [.], ack 364, win 509, options [nop,nop,TS val 1324065326 ecr 1324065326], length 0 E..4=]@[email protected].....(..... N...N... 17:44:19.129992 lo In IP 127.0.0.1.6321 > 127.0.0.1.55256: Flags [P.], seq 1:1425, ack 364, win 512, options [nop,nop,TS val 1324065328 ecr 1324065326], length 1424 E...=^@[email protected]........... N..0N.......z...v..f.~..P.!.i...~PW....A1.......... ...2..O....`)6...{.S.t.`......r.......+.....3.$... ....V.~.. .$...up6...u.....$$..0...........#.1.K$..k.L...I...S...................+>..i..<.X.7o..~...OX.)..xg..z..z.8.C..@.\{9}.Io....H,......V.....{.n...C....T.,[email protected]^~b4.....Ip.]IP}.pAV..\"..ah`:....seA.P.p.^.C....L7 .Ts....(.u..-.Csv..:.)]..Vv...q.n a...7q0..y#.......x..p>om..It.q._....u>x.w...{.|......z.sW...{_...$A.0...L..r.....^.0y....Xr}v..zs..h.8....... ...R....7.Z.#..a..`|....E...j...^[email protected][......o...ql...6.........)H6S.!GcOjv.o)...`B.$.x.4.S.........o].....\P....'.6u9]... 7.my.&...W.xKX.......].....>..@.'......~..Mp.........BG.,[email protected].......=..#.&.#A..X.,..h.......f.<...b...I./..~.........`...c..h4.Mz.{owK.&..]...,.x. +.;........Y....nz2..e......O.E...>.@!.C4.d.r.....e.L.....Yl.i....CKH..... .....f.&....*...$.6b.CF....*...R#...S.(.\>.}...n....qv.?l...,...........q a...}P....N.v.S..Ar7.%2..v......."j......K.5.kj.E...7L.*...D..+...kK...t|....o..$ ..Cb...T-..1N......(.....v.K]u.5.........k".Hz.s....r...sr......a.........|W.)P;.Z..-:......6]f9.T..C.\.x.% .....63........2p.#v.^..(.....jR. [email protected]:`......^7.l........r0.i...%(...F..t.h..I.....Q../ ..%.L..<..W/;.B'...O.. -}..z...|.V..V9~....->.X...t..#Y.a [email protected].....}.;....4..d..f.G)1...$.%..A(..... 17:44:19.130011 lo In IP 127.0.0.1.55256 > 127.0.0.1.6321: Flags [.], ack 1425, win 502, options [nop,nop,TS val 1324065328 ecr 1324065328], length 0 E..43.@[email protected].........(..... N..0N..0 17:44:19.131678 lo In IP 127.0.0.1.55256 > 127.0.0.1.6321: Flags [P.], seq 364:513, ack 1425, win 512, options [nop,nop,TS val 1324065330 ecr 1324065328], length 149 E...3.@.@..<.............o.k............... N..2N..0..........5sv_.tt..o..E....x.Y ....&_...... ...{.B._..b!.w..........PK.N..v...AO.......Q8.P>|-...]s../K...i...."..nH_!.m".....f......p.[Eg.=.......JD 17:44:19.131704 lo In IP 127.0.0.1.6321 > 127.0.0.1.55256: Flags [.], ack 513, win 511, options [nop,nop,TS val 1324065330 ecr 1324065330], length 0 E..4=_@[email protected].......(..... N..2N..2 17:44:19.132121 lo In IP 127.0.0.1.55256 > 127.0.0.1.6321: Flags [P.], seq 513:549, ack 1425, win 512, options [nop,nop,TS val 1324065330 ecr 1324065330], length 36 E..X3.@[email protected]..... N..2N..2........6.2.M..^-.....v...x....V/-!. 17:44:19.132129 lo In IP 127.0.0.1.6321 > 127.0.0.1.55256: Flags [.], ack 549, win 511, options [nop,nop,TS val 1324065330 ecr 1324065330], length 0 E..4=`@[email protected].$.....(..... N..2N..2 17:44:19.132399 lo In IP 127.0.0.1.6321 > 127.0.0.1.55256: Flags [P.], seq 1425:1574, ack 549, win 512, options [nop,nop,TS val 1324065330 ecr 1324065330], length 149 E...=a@[email protected].$........... N..2N..2....x.h..<...p..].r.*....wvK.f.....]S...K.8...%:..._...g.Y.3..*7Q..948"...z.W.....G.nn....u.X7..5"n.8X8{.f.4.....i.C7].....g........ v{.....0.KuD.g.. 17:44:19.132421 lo In IP 127.0.0.1.55256 > 127.0.0.1.6321: Flags [.], ack 1574, win 511, options [nop,nop,TS val 1324065330 ecr 1324065330], length 0 E..43.@[email protected].$...\.....(..... N..2N..2 17:44:19.132455 lo In IP 127.0.0.1.6321 > 127.0.0.1.55256: Flags [F.], seq 1574, ack 549, win 512, options [nop,nop,TS val 1324065330 ecr 1324065330], length 0 E..4=b@.@.._...............\.o.$.....(..... N..2N..2 17:44:19.134089 lo In IP 127.0.0.1.55256 > 127.0.0.1.6321: Flags [P.], seq 549:573, ack 1575, win 512, options [nop,nop,TS val 1324065332 ecr 1324065330], length 24 E..L3.@[email protected].$...].....@..... N..4N..2.......mX...J..n./JN..._ 17:44:19.134117 lo In IP 127.0.0.1.6321 > 127.0.0.1.55256: Flags [.], ack 573, win 512, options [nop,nop,TS val 1324065332 ecr 1324065332], length 0 E..4=c@.@..^...............].o.<.....(..... N..4N..4 17:44:19.135356 lo In IP 127.0.0.1.55256 > 127.0.0.1.6321: Flags [F.], seq 573, ack 1575, win 512, options [nop,nop,TS val 1324065333 ecr 1324065332], length 0 E..43.@[email protected].<...].....(..... N..5N..4 17:44:19.135373 lo In IP 127.0.0.1.6321 > 127.0.0.1.55256: Flags [.], ack 574, win 512, options [nop,nop,TS val 1324065333 ecr 1324065333], length 0 E..4..@.@.<................].o.=.....Z..... N..5N..5 17:44:19.290744 lo In IP 127.0.0.1.55272 > 127.0.0.1.6321: Flags [S], seq 1136915761, win 65495, options [mss 65495,sackOK,TS val 1324065489 ecr 0,nop,wscale 7], length 0 E..<..@.@.?.............C..1.........0......... N........... 17:44:19.290771 lo In IP 127.0.0.1.6321 > 127.0.0.1.55272: Flags [S.], seq 394292416, ack 1136915762, win 65483, options [mss 65495,sackOK,TS val 1324065489 ecr 1324065489,nop,wscale 7], length 0 E..<..@.@.<...............l.C..2.....0......... N...N....... 17:44:19.290794 lo In IP 127.0.0.1.55272 > 127.0.0.1.6321: Flags [.], ack 1, win 512, options [nop,nop,TS val 1324065489 ecr 1324065489], length 0 E..4. @.@.?.............C..2..l......(..... N...N... 17:44:19.291210 lo In IP 127.0.0.1.55272 > 127.0.0.1.6321: Flags [P.], seq 1:364, ack 1, win 512, options [nop,nop,TS val 1324065489 ecr 1324065489], length 363 E....!@.@.>5............C..2..l............ N...N.......f...b..A.Ie...1.\U.....egh.E...{x].$1.. ..{......&..*O.r.>...U...R.h.....v......./.+.0.,...'.g.(.k...................].a.W.S...........\.`.V.R.$.j.#.@. ...9.8. ...3.2.......Q.......P.=.<.5./.............. localhost......... ... ...........#.............0............. . .................................+........-.....3.&.$... .0...G......){......6..SN?..u..D 17:44:19.291236 lo In IP 127.0.0.1.6321 > 127.0.0.1.55272: Flags [.], ack 364, win 509, options [nop,nop,TS val 1324065489 ecr 1324065489], length 0 E..4n^@[email protected]........(..... N...N... 17:44:19.292732 lo In IP 127.0.0.1.6321 > 127.0.0.1.55272: Flags [P.], seq 1:1425, ack 364, win 512, options [nop,nop,TS val 1324065491 ecr 1324065489], length 1424 E...n_@[email protected].............. N...N.......z...v...i.........fp. 0x[u5}.m..1`..[^. ..{......&..*O.r.>...U...R.h..........+.....3.$... q..wd..a.3Hn.Re.l..#.......B0..`.................h.:...q..cp`."........O.uL....e^Z..U...Es9B.......YPY..~!4...........P3....J....z..j.o"@...z}J8).......,.L,...H.M.Ca_.?..].....D_..X.. ..>}..{.o..Y.......- [email protected]. .........vcXs...k.O....4....fI`v..3Y|8.NW ..Y..2. [email protected]@t.p.....f...j._..,/.t.3g...1.2....Y.1`A..M......w....]..-!..1#7.....o6C...x.....NlY8..=..> -q..m. J.>..3l..Z...eVZ.W.(.......q..sld{'Dt.h...\.......y{....e..Q5mU..%.........%<.......L..S....(vD.......k.i+27A..}.....Q..`....3qk.w......v..<.N.m..p...=...(W...|c.}.+q.O/....&.n.?...9[sD..:...-..oF.o...E...<.'...v...O..../......3.mm.).ZLq...@.....$.V?(.._.......K.4 .vk.....^2.._.....e....-.Y....1......./...\...G..;.|.........f3N......."....+>.Q.Pq.....GY;.1..5)..t..%..1h..E..v.v......w2...s../.;..2.......Y.p.....BU..r.:/.bWW... ..../B..g...y|....J"[email protected].......[.@euM.=.tg.......;,[email protected].....^p1."[email protected]....`..gw.FP.K...A..w.R48a.W.)U0.>.Hh.$I.......+..v...(x<..K........S.....VU..IZIL.1...N..p.,.....a..f._/............TW..S....=K....uT..;.dCbx".y+[M,..J.u...R...6..\.....L.. .t..>p(..vgD>_.[.J}%......54..gg..}......vw..l.......e|.]3.0.....BG.... ..s..D.......r.n...'[email protected]..(k|%......l<.....7...pJ. [email protected]..".v04)w.0K. 127.0.0.1.6321: Flags [.], ack 1425, win 502, options [nop,nop,TS val 1324065491 ecr 1324065491], length 0 E..4."@.@.?.............C.....rQ.....(..... N...N... 17:44:19.294487 lo In IP 127.0.0.1.55272 > 127.0.0.1.6321: Flags [P.], seq 364:513, ack 1425, win 512, options [nop,nop,TS val 1324065492 ecr 1324065491], length 149 E....#@.@.? ............C.....rQ........... N...N.............5^C.._.$mlrs.,.=..0.[...a.M....,.4B...E.ND7sv.+..Fl.[~....PO....\..[. A.fp4. .x..=.rq...I...U.Uc........m....A..F.!(!.....A..l.nq.nT....... 17:44:19.294511 lo In IP 127.0.0.1.6321 > 127.0.0.1.55272: Flags [.], ack 513, win 511, options [nop,nop,TS val 1324065492 ecr 1324065492], length 0 E..4n`@[email protected].....(..... N...N... 17:44:19.294921 lo In IP 127.0.0.1.6321 > 127.0.0.1.55272: Flags [P.], seq 1425:1550, ack 513, win 512, options [nop,nop,TS val 1324065493 ecr 1324065492], length 125 E...na@[email protected]........... N...N.......x.m}.S.U.uD.o.....~...hy...$d..PkYG..__..+.unF......E.^..uO..\ ....&Rc.(f[....#...fv.+(...NC._I.._Z...J.a....?b...\-..x.. 17:44:19.294930 lo In IP 127.0.0.1.55272 > 127.0.0.1.6321: Flags [.], ack 1550, win 512, options [nop,nop,TS val 1324065493 ecr 1324065493], length 0 E..4.$@.@.?.............C..2..r......(..... N...N... 17:44:19.294945 lo In IP 127.0.0.1.6321 > 127.0.0.1.55272: Flags [P.], seq 1550:1574, ack 513, win 512, options [nop,nop,TS val 1324065493 ecr 1324065493], length 24 E..Lnb@[email protected].....@..... N...N........... .*=.J7......EE9 17:44:19.294950 lo In IP 127.0.0.1.55272 > 127.0.0.1.6321: Flags [.], ack 1574, win 512, options [nop,nop,TS val 1324065493 ecr 1324065493], length 0 E..4.%@.@.?.............C..2..r......(..... N...N... 17:44:19.295050 lo In IP 127.0.0.1.6321 > 127.0.0.1.55272: Flags [F.], seq 1574, ack 513, win 512, options [nop,nop,TS val 1324065493 ecr 1324065493], length 0 E..4nc@.@..^..............r.C..2.....(..... N...N... 17:44:19.295124 lo In IP 127.0.0.1.55272 > 127.0.0.1.6321: Flags [P.], seq 513:549, ack 1575, win 512, options [nop,nop,TS val 1324065493 ecr 1324065493], length 36 E..X.&@.@.?w............C..2..r......L..... N...N........%A...E...f..L..}..'2+..od....~l 17:44:19.295144 lo In IP 127.0.0.1.6321 > 127.0.0.1.55272: Flags [.], ack 549, win 512, options [nop,nop,TS val 1324065493 ecr 1324065493], length 0 E..4nd@.@..]..............r.C..V.....(..... N...N... 17:44:19.296636 lo In IP 127.0.0.1.55272 > 127.0.0.1.6321: Flags [P.], seq 549:573, ack 1575, win 512, options [nop,nop,TS val 1324065495 ecr 1324065493], length 24 E..L.'@.@.?.............C..V..r......@..... N...N........Ts...V.., . ..d.... 17:44:19.296656 lo In IP 127.0.0.1.6321 > 127.0.0.1.55272: Flags [.], ack 573, win 512, options [nop,nop,TS val 1324065495 ecr 1324065495], length 0 E..4ne@.@..\..............r.C..n.....(..... N...N... 17:44:19.297397 lo In IP 127.0.0.1.55272 > 127.0.0.1.6321: Flags [F.], seq 573, ack 1575, win 512, options [nop,nop,TS val 1324065495 ecr 1324065495], length 0 E..4.(@.@.?.............C..n..r......(..... N...N... 17:44:19.297414 lo In IP 127.0.0.1.6321 > 127.0.0.1.55272: Flags [.], ack 574, win 512, options [nop,nop,TS val 1324065495 ecr 1324065495], length 0 E..4..@.@.<...............r.C..o........... N...N... 17:44:19.502867 lo In IP 127.0.0.1.55284 > 127.0.0.1.6321: Flags [S], seq 3365681196, win 65495, options [mss 65495,sackOK,TS val 1324065701 ecr 0,nop,wscale 7], length 0 E..<..@[email protected],.........0......... N........... 17:44:19.502895 lo In IP 127.0.0.1.6321 > 127.0.0.1.55284: Flags [S.], seq 3964310087, ack 3365681197, win 65483, options [mss 65495,sackOK,TS val 1324065701 ecr 1324065701,nop,wscale 7], length 0 E..<..@.@.<..............J.G..8-.....0......... N...N....... 17:44:19.502917 lo In IP 127.0.0.1.55284 > 127.0.0.1.6321: Flags [.], ack 1, win 512, options [nop,nop,TS val 1324065701 ecr 1324065701], length 0 E..4..@[email protected].....(..... N...N... 17:44:19.503334 lo In IP 127.0.0.1.55284 > 127.0.0.1.6321: Flags [P.], seq 1:364, ack 1, win 512, options [nop,nop,TS val 1324065701 ecr 1324065701], length 363 E.....@[email protected]........... N...N.......f...b......A%>.=./~.v.. ..p(wA..VE~.. Q .........,ON_...)....J....{......v......./.+.0.,...'.g.(.k...................].a.W.S...........\.`.V.R.$.j.#.@. ...9.8. ...3.2.......Q.......P.=.<.5./.............. localhost......... ... ...........#.............0............. . .................................+........-.....3.&.$... .~X.yb7`:.+r.B@.+..p?....C.u.... 17:44:19.503348 lo In IP 127.0.0.1.6321 > 127.0.0.1.55284: Flags [.], ack 364, win 509, options [nop,nop,TS val 1324065701 ecr 1324065701], length 0 E..4,.@.@..=.............J.H..9......(..... N...N... 17:44:19.504791 lo In IP 127.0.0.1.6321 > 127.0.0.1.55284: Flags [P.], seq 1:1425, ack 364, win 512, options [nop,nop,TS val 1324065703 ecr 1324065701], length 1424 E...,.@.@. ..............J.H..9............ N...N.......z...v....4.tD..]..}[email protected]?. .........,ON_...)....J....{...........+.....3.$... ...T...u ..A!r.."%....q.h.i.~..K...........U.).K....G....Js.|;..5........}f3..>..o.h..9....=P..O[....C...[.....$.,."..j,)_........>.......G.D.8.. ..E.a....-.C...O.Y.zo....3...g.]NB.......;......."s.>k.}.....3"...V.].g..=...UN.0nd.P&.8...6...2d%=.Qp.8.09..v...c!]o.".-.Y..n.v.|.s.....Eh..:...w`u.&`E 8B...|....e....=1{.....2- .[..P..\g..x....6.q.% ...!...$.Q.*...t..l.W.... .s..J.c....#.Sx.X.}5....O.\...F..I..16h...k..l{....xb...;.Q>.."Y.>x. C....6..~`V4/.g=..9F..T.6gM.........C.AC .A.\y.....pP............... ZB. ....;...:[email protected]&.r.......9.....fW...p.../... 0}u.~.X.#.#..jB7.._..&..*.L_.......{_. e.A.6G.....D........w..2E\IEx.&791.#..L.Z....i......[H. .dGO.5....N.bO9b..!....9.....w..z.......28.oq}..(..w.3.|.D.Y^......[.....15....!...L.G,q..Cf(@.... ....}.$....Z._n...9O...T.....u........x;K....+.TP..]w......+T.ne....G1 ..Vn/.'j.x..P.Y.... Iu7....A.R..^n=F]q..6F....Z..JQcIJ...... Gj..? !.....sj....4.....s..(*..QG.>..2....*t.=2Y.. ..%u_w..C.#....W|.i....(!..V.].,.@..}S...:.0.......3=/.......L"VA.8'....a....nP.bQ2...|.D..&{5k'.=...:^)...6...LGb..5.......Q...11.(.V..{.....,+..>..A..7D#j........U.{.......5... ......O.4...}......)....4W.\57s..x.6d.i6.z...............-.,.|{y...z.I.w.6....M+..cG...Pthv...%.\.`.T...P%..7............2+.cws.nf.7.. [email protected];b.K.L.P.D.b9.~.(.........,.?R.......n..UED..>"w./,..|\.i.o'\m 17:44:19.504813 lo In IP 127.0.0.1.55284 > 127.0.0.1.6321: Flags [.], ack 1425, win 502, options [nop,nop,TS val 1324065703 ecr 1324065703], length 0 E..4..@[email protected].......(..... N...N... 17:44:19.506477 lo In IP 127.0.0.1.55284 > 127.0.0.1.6321: Flags [P.], seq 364:513, ack 1425, win 512, options [nop,nop,TS val 1324065704 ecr 1324065703], length 149 E.....@[email protected]............. N...N.............5...q=..b..`.....N.83.~V...!2..9..D...ojD.....l.R. .......Py........&+t=:...Y..x$......--K.....~..$....D......5[...q:_#.X..P.UvG.`U...J.... 17:44:19.506502 lo In IP 127.0.0.1.6321 > 127.0.0.1.55284: Flags [.], ack 513, win 511, options [nop,nop,TS val 1324065704 ecr 1324065704], length 0 E..4,.@.@..;.............J....:-.....(..... N...N... 17:44:19.507006 lo In IP 127.0.0.1.6321 > 127.0.0.1.55284: Flags [P.], seq 1425:1550, ack 513, win 512, options [nop,nop,TS val 1324065705 ecr 1324065704], length 125 E...,.@[email protected]....:-........... [email protected].=...DT....C..p=.zm..nL...Q...I."'!Y]...yag.....g..H..Q....s-TuC.0.+.|I.G.H`w......%....H.U....:...1.e. 17:44:19.507014 lo In IP 127.0.0.1.55284 > 127.0.0.1.6321: Flags [.], ack 1550, win 512, options [nop,nop,TS val 1324065705 ecr 1324065705], length 0 E..4..@.@.................:-.J.U.....(..... N...N... 17:44:19.507140 lo In IP 127.0.0.1.55284 > 127.0.0.1.6321: Flags [P.], seq 513:549, ack 1550, win 512, options [nop,nop,TS val 1324065705 ecr 1324065705], length 36 E..X..@.@.................:-.J.U.....L..... N...N........T..GK.....$...*...Q..."y.../~_. 17:44:19.507149 lo In IP 127.0.0.1.6321 > 127.0.0.1.55284: Flags [.], ack 549, win 512, options [nop,nop,TS val 1324065705 ecr 1324065705], length 0 E..4,.@[email protected]..:Q.....(..... N...N... 17:44:19.507180 lo In IP 127.0.0.1.6321 > 127.0.0.1.55284: Flags [P.], seq 1550:1574, ack 549, win 512, options [nop,nop,TS val 1324065705 ecr 1324065705], length 24 E..L,.@.@.. .............J.U..:Q.....@..... N...N........<....wQ.w.x ......r 17:44:19.507193 lo In IP 127.0.0.1.55284 > 127.0.0.1.6321: Flags [.], ack 1574, win 512, options [nop,nop,TS val 1324065705 ecr 1324065705], length 0 E..4..@.@.................:Q.J.m.....(..... N...N... 17:44:19.507220 lo In IP 127.0.0.1.6321 > 127.0.0.1.55284: Flags [F.], seq 1574, ack 549, win 512, options [nop,nop,TS val 1324065705 ecr 1324065705], length 0 E..4,.@[email protected]..:Q.....(..... N...N... 17:44:19.508642 lo In IP 127.0.0.1.55284 > 127.0.0.1.6321: Flags [P.], seq 549:573, ack 1575, win 512, options [nop,nop,TS val 1324065707 ecr 1324065705], length 24 E..L..@.@.................:Q.J.n.....@..... [email protected].*. 17:44:19.508666 lo In IP 127.0.0.1.6321 > 127.0.0.1.55284: Flags [.], ack 573, win 512, options [nop,nop,TS val 1324065707 ecr 1324065707], length 0 E..4,.@[email protected]..:i.....(..... N...N... 17:44:19.509482 lo In IP 127.0.0.1.55284 > 127.0.0.1.6321: Flags [F.], seq 573, ack 1575, win 512, options [nop,nop,TS val 1324065707 ecr 1324065707], length 0 E..4..@.@.................:i.J.n.....(..... N...N... 17:44:19.509499 lo In IP 127.0.0.1.6321 > 127.0.0.1.55284: Flags [.], ack 574, win 512, options [nop,nop,TS val 1324065707 ecr 1324065707], length 0 E..4..@.@.<..............J.n..:j.....'..... N...N...

    I confirmed regular https traffic is fine using a similar gateway config on localhost.

    Any suggestions?

    opened by ferbs 0
  • fix: add named export to support ESM imports in Typescript

    fix: add named export to support ESM imports in Typescript

    Currently getting a "has no construct signatures" error with the following in Typescript 4.9.4, Node 18.12.1, type: module, module: node16, moduleResolution: node16:

    import Redis from 'ioredis'
    
    const redis = new Redis()
    

    Changing the ioredis package with this change allows:

    import { Redis } from 'ioredis'
    
    const redis = new Redis()
    

    without any error, and with full type information.

    opened by SCG82 0
Releases(v5.2.4)
Owner
Zihua Li
Web developer and designer, technical book author. I build tools that help people do things better.
Zihua Li
A node.js locks library with support of Redis and MongoDB

locco A small and simple library to deal with race conditions in distributed systems by applying locks on resources. Currently, supports locking via R

Bohdan 5 Dec 13, 2022
Fastify is a web framework highly focused on providing the best developer experience with the least overhead and a powerful plugin architecture, inspired by Hapi and Express.

Fastify is a web framework highly focused on providing the best developer experience with the least overhead and a powerful plugin architecture, inspired by Hapi and Express.

Jared Hanson 5 Oct 11, 2022
A Full Stack Amazon Clone which created using ReactJS with full E-Commerce Functionality!!

Amazon Clone with ReactJS A small web app that tries to imitate the desktop web version of amazon site, you can add items to the basket, delete them,

Özge Coşkun Gürsucu 50 Oct 3, 2022
Execute one command (or mount one Node.js middleware) and get an instant high-performance GraphQL API for your PostgreSQL database!

PostGraphile Instant lightning-fast GraphQL API backed primarily by your PostgreSQL database. Highly customisable and extensible thanks to incredibly

Graphile 11.7k Jan 4, 2023
A high performance MongoDB ORM for Node.js

Iridium A High Performance, IDE Friendly ODM for MongoDB Iridium is designed to offer a high performance, easy to use and above all, editor friendly O

Sierra Softworks 570 Dec 14, 2022
NodeJS PostgreSQL database performance insights. Locks, index usage, buffer cache hit ratios, vacuum stats and more.

Node Postgres Extras NodeJS port of Heroku PG Extras with several additions and improvements. The goal of this project is to provide powerful insights

Paweł Urbanek 68 Nov 14, 2022
PostgreSQL client for node.js.

node-postgres Non-blocking PostgreSQL client for Node.js. Pure JavaScript and optional native libpq bindings. Monorepo This repo is a monorepo which c

Brian C 10.9k Jan 9, 2023
A pure node.js JavaScript Client implementing the MySQL protocol.

mysql Table of Contents Install Introduction Contributors Sponsors Community Establishing connections Connection options SSL options Connection flags

null 17.6k Jan 1, 2023
Microsoft SQL Server client for Node.js

node-mssql Microsoft SQL Server client for Node.js Supported TDS drivers: Tedious (pure JavaScript - Windows/macOS/Linux, default) Microsoft / Contrib

null 2.1k Jan 4, 2023
Couchbase Node.js Client Library (Official)

Couchbase Node.js Client The Node.js SDK library allows you to connect to a Couchbase cluster from Node.js. It is a native Node.js module and uses the

null 460 Nov 13, 2022
Node.js client for the Aerospike database

Aerospike Node.js Client An Aerospike add-on module for Node.js. The client is compatible with Node.js v8.x, v10.x (LTS), v12.x (LTS), and v14.x (LTS)

Aerospike 198 Dec 30, 2022
Pulsar Flex is a modern Apache Pulsar client for Node.js, developed to be independent of C++.

PulsarFlex Apache Pulsar® client for Node.js Report Bug · Request Feature About the project Features Usage Contributing About PulsarFlex is a modern A

null 43 Aug 19, 2022
Firebase Extension to automatically push Firestore documents to Typesense for full-text search with typo tolerance, faceting, and more

Firestore / Firebase Typesense Search Extension ⚡ ?? A Firebase extension to sync data from your Firestore collection to Typesense, to be able to do f

Typesense 101 Dec 28, 2022
A service worker that buffers a full video, so when the video tag ask for ranges, these can be satisfied. Play + pause = buffer the whole video.

Full Video Buffer with Service Workers The specification of the preload attribute on a Video element won't allow you to fully buffer a video. This rep

Tito 51 Nov 2, 2022
A typesafe database ORM that exposes the full power of handwritten sql statements to the developer.

TORM A typesafe database ORM that exposes the full power of handwritten sql statements to the developer. import { torm, z } from 'https://deno.land/x/

Andrew Kaiser 15 Dec 22, 2022
A PostgreSQL client with strict types, detailed logging and assertions.

Slonik A battle-tested PostgreSQL client with strict types, detailed logging and assertions. (The above GIF shows Slonik producing query logs. Slonik

Gajus Kuizinas 3.6k Jan 3, 2023
curl for GraphQL with autocomplete, subscriptions and GraphiQL. Also a dead-simple universal javascript GraphQL client.

graphqurl graphqurl is a curl like CLI for GraphQL. It's features include: CLI for making GraphQL queries. It also provisions queries with autocomplet

Hasura 3.2k Jan 3, 2023
Starter template for NestJS 😻 includes GraphQL with Prisma Client, Passport-JWT authentication, Swagger Api and Docker

Instructions Starter template for ?? NestJS and Prisma. Checkout NestJS Prisma Schematics to automatically add Prisma support to your Nest application

notiz.dev 1.6k Jan 4, 2023