Skip to content
Commits on Jun 14, 2010
  1. @fictorial

    Bump version.

    fictorial committed Jun 14, 2010
  2. @fictorial

    Update to-do list.

    fictorial committed Jun 14, 2010
  3. @fictorial
Commits on May 25, 2010
  1. @fictorial
  2. @fictorial
  3. @fictorial
  4. @fictorial

    Handle exception thrown from callback.

    Thanks to Alberto Piai for the tip.
    fictorial committed May 25, 2010
Commits on May 10, 2010
  1. @isaacs @fictorial
  2. @isaacs @fictorial
Commits on May 7, 2010
  1. @fictorial
Commits on May 6, 2010
  1. @fictorial
Commits on May 4, 2010
  1. @fictorial
Commits on May 3, 2010
  1. @fictorial

    updated compatibility info

    fictorial committed May 2, 2010
  2. @fictorial

    bump version to 0.3.2

    fictorial committed May 2, 2010
  3. @fictorial
  4. @fictorial
Commits on May 1, 2010
  1. @fictorial

    tabs -> spaces

    fictorial committed Apr 30, 2010
  2. @fictorial

    bump version to 0.3.1

    fictorial committed Apr 30, 2010
  3. @fictorial
  4. @tautologistics @fictorial
Commits on Apr 26, 2010
  1. @fictorial

    fix copyright structure

    fictorial committed Apr 26, 2010
Commits on Apr 21, 2010
  1. @fictorial

    Reconnection handling. Client will now always callback when it cannot…

    … connect or reconnect.
    
    Node.js fails to emit 'error' when Redis is killed.  Thus, we use `.expectClose` on the client as a workaround.
    
    A test script:
    
        var sys = require('sys');
        var redis = require("../lib/redis-client");
        redis.debugMode = true;
        var client = redis.createClient(redis.DEFAULT_PORT, redis.DEFAULT_HOST, { maxReconnectionAttempts: 2 });
        client.set('test:foo', 'bar', function (err, data){
          if (err) sys.log("set test:foo: " + err);
          else     sys.log("set test:foo: " + data);
        });
        setTimeout(function() {
          sys.log("timeout fired");
          client.get('test:foo', function (err, data) {
              if (err) sys.log("get test:foo: " + err);
              else     sys.log("get test:foo: " + data);
    
              sys.log("closing client");
              client.close();
          })}, 5000);
    
    When Redis is down the entire time:
    
        DEBUG: [ENQUEUE] Not connected. Request queued. There are 1 requests queued.
        DEBUG: [NO CONNECTION]
        21 Apr 17:40:22 - set test:foo: Error: failed to establish a connection to Redis
        21 Apr 17:40:27 - timeout fired
        21 Apr 17:40:27 - get test:foo: Error: failed to establish a connection to Redis
        21 Apr 17:40:27 - closing client
    
    When Redis is up the entire time:
    
        ~/projects/redis-node-client(master)  node test/phillip.js
        DEBUG: [ENQUEUE] Not connected. Request queued. There are 1 requests queued.
        DEBUG: [CONNECT]
        DEBUG: [FLUSH QUEUE] 1 queued request buffers.
        DEBUG: [DEQUEUE/SEND] *3<CRLF>$3<CRLF>set<CRLF>$8<CRLF>test:foo<CRLF>$3<CRLF>bar<CRLF>. queued buffers remaining = 0
        DEBUG: [RECV] +OK<CRLF>
        21 Apr 17:42:40 - set test:foo: true
        21 Apr 17:42:43 - timeout fired
        DEBUG: [SEND] *2<CRLF>$3<CRLF>get<CRLF>$8<CRLF>test:foo<CRLF> originalCommands = 1
        DEBUG: [RECV] $3<CRLF>bar<CRLF>
        21 Apr 17:42:43 - get test:foo: bar
        21 Apr 17:42:43 - closing client
        DEBUG: [NO CONNECTION]
    
    When Redis is up initially, then killed.
    
        ~/projects/redis-node-client(master)  node test/phillip.js
        DEBUG: [ENQUEUE] Not connected. Request queued. There are 1 requests queued.
        DEBUG: [CONNECT]
        DEBUG: [FLUSH QUEUE] 1 queued request buffers.
        DEBUG: [DEQUEUE/SEND] *3<CRLF>$3<CRLF>set<CRLF>$8<CRLF>test:foo<CRLF>$3<CRLF>bar<CRLF>. queued buffers remaining = 0
        ^[[CDEBUG: [RECV] +OK<CRLF>
        21 Apr 17:37:10 - set test:foo: true
        DEBUG: [NO CONNECTION]
        DEBUG: [RECONNECTING 1/2]
        DEBUG: [WAIT 1000 ms]
        DEBUG: [NO CONNECTION]
        DEBUG: [RECONNECTING 2/2]
        DEBUG: [WAIT 2000 ms]
        DEBUG: [NO CONNECTION]
        21 Apr 17:37:14 - timeout fired
        21 Apr 17:37:14 - get test:foo: Error: failed to establish a connection to Redis
        21 Apr 17:37:14 - closing client
    
    When Redis is up initially, then killed, then brought back up immediately.
    
        ~/projects/redis-node-client(master)  node test/phillip.js
        DEBUG: [ENQUEUE] Not connected. Request queued. There are 1 requests queued.
        DEBUG: [CONNECT]
        DEBUG: [FLUSH QUEUE] 1 queued request buffers.
        DEBUG: [DEQUEUE/SEND] *3<CRLF>$3<CRLF>set<CRLF>$8<CRLF>test:foo<CRLF>$3<CRLF>bar<CRLF>. queued buffers remaining = 0
        DEBUG: [RECV] +OK<CRLF>
        21 Apr 17:43:17 - set test:foo: true
        DEBUG: [NO CONNECTION]
        DEBUG: [RECONNECTING 1/2]
        DEBUG: [WAIT 1000 ms]
        DEBUG: [CONNECT]
        21 Apr 17:43:22 - timeout fired
        DEBUG: [SEND] *2<CRLF>$3<CRLF>get<CRLF>$8<CRLF>test:foo<CRLF> originalCommands = 1
        DEBUG: [RECV] $3<CRLF>bar<CRLF>
        21 Apr 17:43:22 - get test:foo: bar
        21 Apr 17:43:22 - closing client
        DEBUG: [NO CONNECTION]
    fictorial committed Apr 21, 2010
  2. @fictorial
Commits on Apr 20, 2010
  1. @fictorial

    Solidify reconnection handling, and associated queueing, etc.

    Reconnections to Redis should be transparent to the user of redis-node-client.
    
    The user can just call command methods (e.g. lpush) even when not connected to
    Redis. The commands will be submitted to Redis when a connection to Redis is
    established. For commands that were submitted and the connection to Redis lost
    before receiving a reply, the reply will never come, and we have no knowledge
    of which submitted commands were processed by Redis. In this case, submitted
    commands will have their callbacks called with an err of an Error object whose
    .message is "IO Error" and whose .originalCommand is an Array containing the
    original command at index 0 and arguments thereafter. It is up to the caller to
    attempt to retry the call but the original callback is removed as the reply
    will never come for that submitted command.
    
    The user should be notified when a connection cannot be established (or a
    reconnection reestablished). If a connection to Redis fails and cannot be
    reestablished, the client emits noconnection. No reconnections will be
    attempted if the first connection attempt fails.
    
    The user should be notified when an attempt is made to reconnect to Redis after
    the initial or subsequent established connection is lost. The client emits
    reconnecting upon a reconnection attempt, and reconnected if the connection was
    reestablished.
    
    The user should be notified when a connection is established. The client emits
    a connected event when first connected, and reconnected when a connection is
    later reestablished automatically.
    fictorial committed Apr 20, 2010
  2. @fictorial

    Not using NPM ATM FYI

    fictorial committed Apr 20, 2010
  3. @fictorial

    actually, it's INCR not GET

    fictorial committed Apr 20, 2010
  4. @fictorial

    Updated README

    fictorial committed Apr 20, 2010
  5. @fictorial

    Remove autoReconnect option (just set maxReconn...=0). Dealing with u…

    …ncertain number of commands processed when Redis is brought down and we try to reconnect and resend anything queued. Works fine still when Redis is up of course.
    fictorial committed Apr 20, 2010
  6. @fictorial

    Updated simple PUBSUB example given that we no longer require one to …

    …wait for the client to connect to redis before issuing commands
    fictorial committed Apr 19, 2010
  7. @fictorial

    Fixed this; TODO updated

    fictorial committed Apr 19, 2010
  8. @fictorial

    Queue commands when not connected; auto-reconnect works; emits events…

    … 'connected', 'reconnecting', and 'noconnection' now; (thanks to pilif for motivating me to fix these)
    fictorial committed Apr 19, 2010
Commits on Apr 19, 2010
  1. @fictorial
  2. @fictorial
  3. @fictorial
  4. @fictorial
Something went wrong with that request. Please try again.