iuioiua / r2d2 Goto Github PK

For example, readBulkString. They should just use the iterator.

I have values of about 100kb each, but they're split and or not saved/read properly.

Any idea what the issue can be? Does the TCP buffer size need to be increased?

I check the Deno docs about the Deno.connect but it doesn't mention anything about this.

This module should have a really dope demo that shows how fast this module is. This could probably be achieved with an extensive yet interesting dataset and a simple "live" search bar and using RediSearch. I'm open to ideas. One could start looking at this directory of Redis datasets.

Mostly around JSDoc blocks.

would you consider publishing to JSR for this package?

Was confused why connections would stall/hang when reading many keys async.

It's because when using 1 connection, redis needs a queue.

As you can see in the older driver here:
https://github.com/search?q=repo%3Adenodrivers%2Fredis%20queue&type=code

Something like this maybe (untested):

// Command queue
const commandQueue: Command[] = [];
let isProcessingQueue = false;

// Function to process command queue
async function processQueue(redisConn: Deno.Conn) {
  if (isProcessingQueue) return;
  isProcessingQueue = true;

  while (commandQueue.length > 0) {
    const command = commandQueue.shift();
    if (command) {
      try {
        await writeCommand(redisConn, command);
        const reply = await readReply(readDelim(redisConn, CRLF_RAW));
        console.log(reply); // handle reply as needed
      } catch (error) {
        console.error(error); // handle error as needed
      }
    }
  }

  isProcessingQueue = false;
}

// Updated sendCommand to use command queue
export async function sendCommand(
  redisConn: Deno.Conn,
  command: Command,
  raw = false,
): Promise<void> {
  commandQueue.push(command);
  processQueue(redisConn);
}

This module currently uses Deno's Reader and Writer interfaces. These interfaces are slowly being phased out, along with functions within the Standard Library that rely on these interfaces, such as writeAll() and readDelim(), which are deprecated.

We must move to using the Web Streams API as simply as possible.

Since Redis itself is a serial protocol, we're limited to 1 command at a time, having a connection pool would solve this issue and drastically improve performance (Especially on multi-threaded redis like KeyDB).

I suggest a number by default to open multiple connections to the same port and an array of connections for custom hosts and ports (ex. for clusters).

Rename it to readReplies and maybe use instead of readNReplies.

Such as prefix constants, etc.

See https://github.com/oslabs-beta/Deno-Redlock

Fixed by #121.

The current implementation breaks if redis is restarted due to broken pipe causing a panic/throw.

Reconnecting with exponential back-off would be extremely helpful, with the new queue in place no work would be lost either.

This should be done as the repo approaches a larger size.

See https://deno.land/[email protected]/async/mod.ts?s=retry

From https://redis.io/docs/manual/programmability/functions-intro/:

redis> FUNCTION LOAD "#!lua name=mylib\nredis.register_function('knockknock', function() return 'Who\\'s there?' end)"
mylib
redis> FCALL knockknock 0
"Who's there?"

See https://github.com/xstevenyung/fresh-session#cookie-session-based-on-redis