Jean Boussier

Just wanted to update on this. Today I updated our capistrano recipe to use all the improvements we did so far (including the yet unreleased #330) and as far as...

I really don't think this is a good idea. Even with scan the client side performance is pretty much unpredictable.

Yes. This could take a very long time to run. Also to give you a bit of context, we're just making sure `redis-namespace` somewhat keep working, but I really don't...

Looks like our code might be incorrect: https://github.com/redis/redis-rb/blob/72bd3a33cb254dda96f01c9bb5410450c419b58e/lib/redis/connection/ruby.rb#L149-L165 The documentation for `connect_nonblock` explictly handle `IO::WaitWritable` https://ruby-doc.org/stdlib-2.7.0/libdoc/socket/rdoc/Socket.html#method-i-connect_nonblock ``` begin # emulate blocking connect socket.connect_nonblock(sockaddr) rescue IO::WaitWritable IO.select(nil, [socket]) # wait 3-way...

Hum, actually: ``` >> IO::EINPROGRESSWaitWritable < Errno::EINPROGRESS => true ``` So we should enter the `rescue` and `wait_writable`. 🤔

> It seems that the following logic should be called if we use SSL/TLS connection The provided backtrace says line 192, so it's a regular TCPSocket. Based on the code...

> I'm unclear what a `EINPROGRESSWaitWritable` is even, From `socket.c` ```c /* :nodoc: */ static VALUE sock_connect_nonblock(VALUE sock, VALUE addr, VALUE ex) { VALUE rai; rb_io_t *fptr; int n; SockAddrStringValueWithAddrinfo(addr,...

I'll try to find some time to review this this week end, but I'm wondering if I shouldn't simply kickstart using `redis-client` in `redis-rb` rather than duplicate this code.

Closing as the master branch now use `redis-client` under the hood. I'll publish a 5.0 beta tomorrow.

This is changed in 5.0, we rely on `redis-client`, it returns strings as `Encoding::BINARY` if respecting `Encoding.default_external` results in invalid encoding.