Redis.jl

Redis.jl copied to clipboard

redis-server can use only UNIX sockets (i.e. no TCP sockets) by setting port to 0 and unixsocket to the pathname of a UNIX socket. Redis.jl only supports TCP sockets currently so it cannot access such a server. Not a big problem if one can configure the server to also bind to a TCP port on localhost, but a very big problem if one does not control the redis-server configuration.

Are you familiar with how the Julia networking libraries work in the current version of the standard lib? I took a quick look at it seems a bit odd that connect has an overload that returns PipeEndpoint instead of TCPSocket, but the documentation on what one can actually do with that endpoint is severely lacking (or I am looking in the wrong place).

Hmm, I didn't realize Redis.jl did its own socket management. I had assumed (uh-oh!) that it was using a C client under the covers.

It looks like Base.PipeEndpoint and Sockets.TCPSocket are both subtypes of Base.LibuvStream. Once can use methodswith(Base.PipeEndpoint) to see that it doesn't have any special methods. TCPSocket has a few methods, but most (all?) of the interesting stuff shows up in methodswith(Base.LibuvStream).

Yep, this is a pure Julia implementation (for better or for worse 😉). In that case we may just be able to change the types in connection.jl and everything should work itself out (or blow up if somehow we are dependent on tcp, but I doubt it).

On Mon, Nov 1, 2021, 6:36 PM david-macmahon @.***> wrote:

Hmm, I didn't realize Redis.jl did its own socket management. I had assumed (uh-oh!) that it was using a C client under the covers.

It looks like Base.PipeEndpoint and Sockets.TCPSocket are both subtypes of Base.LibuvStream. Once can use methodswith(Base.PipeEndpoint) to see that it doesn't have any special methods. TCPSocket has a few methods, but most (all?) of the interesting stuff shows up in methodswith(Base.LibuvStream).

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/JuliaDatabases/Redis.jl/issues/84#issuecomment-956999959, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA7FL7H44VG6XCZEVAHAYSTUJ4W77ANCNFSM5HFDYCPQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

I think RedisConnection might need a new RedisConnection(; unixsocket) (or similar) method, but I think that would effectively be the same as the RedisConnection(;host, port, ...) method since the kwargs don't count towards dispatch. Might have to roll the new keyword into the existing method and somehow discern what the caller wants.

Yeah, you're right. I thought the two connect methods accepted the same argument, but it makes more sense that they don't. Either way should not be difficult to do.

On Mon, Nov 1, 2021 at 6:47 PM david-macmahon @.***> wrote:

I think RedisConnection might need a new RedisConnection(; unixsocket) (or similar) method, but I think that would effectively be the same as the RedisConnection(;host, port, ...) method since the kwargs don't count towards dispatch. Might have to roll the new keyword into the existing method and somehow discern what the caller wants.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/JuliaDatabases/Redis.jl/issues/84#issuecomment-957004229, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA7FL7HC3QAXDIEB5FOJXILUJ4YKDANCNFSM5HFDYCPQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

I guess one could use RedisConnection(; host="localhost", port=6379, unixsocket="") and then use unixsocket if it is not empty, otherwise use host/port. Maybe just name it socket rather than unixsocket so it doesn't sound so strange for non-unix systems? I don't know what the windows equivalent it called.