Fixes #366 (I think).

Once merged, additional tags need to be added to the repo:

• redis/v3.0.0
• redisx/v3.0.0

This will make this repo support go modules, and follows the official guidance of bumping the major version when there are released tags that are not actually for go mod.

It maybe worth considering not having the redis and redisx modules in the same repo. Before taking this change might be a good opportunity to do that since consumers will have to change the import path, anyway.

At the very least, it may be worthwhile to move the redisx package out of this repo, since it's intended to be experimental and should probably remain v0.

I got a lot of errors , which are 'ERR :0' or 'ERR :1', I got them from my log file. cmds and errors:

log.2015-01-24.001:2015/01/24 11:26:35 [EE] db.go:59 handleDBQueue(): [asyncDB {233 0xc208f28980 HSET [user:233:accepted_quest:254 step 8]} ERR :0]
log.2015-01-24.001:2015/01/24 14:07:49 [EE] db.go:59 handleDBQueue(): [asyncDB {301 0xc208386ec0 HSET [user:301:baseInfo shenshou_curr 23]} ERR :0]
log.2015-01-24.001:2015/01/24 21:13:14 [EE] db.go:59 handleDBQueue(): [asyncDB {557 0xc208fa3a80 HSET [user:557:guides drawcard 999]} ERR :0]
log.2015-01-25.001:2015/01/25 08:27:21 [EE] db.go:59 handleDBQueue(): [asyncDB {150 0xc208f7ee40 HSET [user:150:baseInfo exp 293]} ERR :0]
log.2015-01-25.001:2015/01/25 13:10:19 [EE] db.go:59 handleDBQueue(): [asyncDB {63 0xc208880d40 HSET [user:63:guanqiaDetail:69 simpleCanWipe 1]} ERR :1]
log.2015-01-25.001:2015/01/25 13:25:01 [EE] db.go:59 handleDBQueue(): [asyncDB {688 0xc208d21500 HSET [user:688:guides employ 999]} ERR :1]
log.2015-01-25.001:2015/01/25 17:37:42 [EE] db.go:59 handleDBQueue(): [asyncDB {752 0xc208f9c700 HSET [user:752:baseInfo shenshou_curr 0]} ERR :1]
log.2015-01-25.001:2015/01/25 19:31:19 [EE] db.go:59 handleDBQueue(): [asyncDB {0 <nil> LPUSH [opcode:133 2927603]} ERR :178]
log.2015-01-25.001:2015/01/25 19:31:19 [EE] db.go:59 handleDBQueue(): [asyncDB {679 0xc208742c80 HSET [user:679:accepted_quest:5 step 1]} ERR :0]
log.2015-01-26.001:2015/01/26 02:29:02 [EE] db.go:59 handleDBQueue(): [asyncDB {0 <nil> LPUSH [opcode:9 2915959]} ERR :8805]
log.2015-01-26.001:2015/01/26 02:29:05 [EE] db.go:59 handleDBQueue(): [asyncDB {11 0xc2091b80c0 HSET [user:11:accepted_quest:175 step 4]} ERR :0]
log.2015-01-26.001:2015/01/26 07:42:15 [EE] db.go:59 handleDBQueue(): [asyncDB {0 <nil> LPUSH [opcode:16 8901047]} ERR :415]
log.2015-01-26.001:2015/01/26 11:30:00 [EE] db.go:59 handleDBQueue(): [asyncDB {0 <nil> LPUSH [opcode:108 6737109]} ERR :874]
log.2015-01-27.001:2015/01/27 01:59:51 [EE] db.go:59 handleDBQueue(): [asyncDB {0 <nil> LPUSH [opcode:134 8056353]} ERR :1041]
log.2015-01-27.001:2015/01/27 09:35:45 [EE] db.go:59 handleDBQueue(): [asyncDB {945 0xc208537280 HSET [user:945:baseInfo exp 318]} ERR :0]
log.2015-01-27.001:2015/01/27 15:52:24 [EE] db.go:59 handleDBQueue(): [asyncDB {218 0xc20870b400 HSET [user:218:accepted_quest:119 finish 1]} ERR :0]
log.2015-01-28.001:2015/01/28 00:42:08 [EE] db.go:59 handleDBQueue(): [asyncDB {1034 0xc2086737c0 HSET [user:1034:baseInfo armUpgradeStone 76]} ERR :0]
log.2015-01-28.001:2015/01/28 02:24:20 [EE] db.go:59 handleDBQueue(): [asyncDB {1070 0xc208838b40 HSET [user:1070:baseInfo login_arm 0]} ERR :0]
log.2015-01-28.001:2015/01/28 10:51:24 [EE] db.go:59 handleDBQueue(): [asyncDB {205 0xc20d31f140 HSET [user:205:baseInfo power 16]} ERR :0]
log.2015-01-28.001:2015/01/28 15:06:34 [EE] db.go:59 handleDBQueue(): [asyncDB {614 0xc208838ec0 HSET [user:614:accepted_quest:142 step 6]} ERR :0]
log.2015-01-28.001:2015/01/28 18:33:58 [EE] db.go:59 handleDBQueue(): [asyncDB {105 0xc208e129c0 SADD [user:105:arms 432]} ERR :1]
log.2015-01-28.001:2015/01/28 22:06:15 [EE] db.go:59 handleDBQueue(): [asyncDB {1134 0xc208c8d040 HSET [user:1134:guides drawcard 999]} ERR :0]
log.2015-01-29.001:2015/01/29 14:09:00 [EE] db.go:59 handleDBQueue(): [asyncDB {124 0xc208556b40 HSET [user:124:baseInfo pkCount 5]} ERR :0]
log.2015-01-29.001:2015/01/29 18:28:22 [EE] db.go:59 handleDBQueue(): [asyncDB {0 <nil> LPUSH [opcode:6 10966403]} ERR :21811]

what does this mean? where does it come from ? It happend sometimes and I couldn't get it in my test.

This PR provides support for SLOWLOG GET command results. A new struct SlowLog has been added which contains the details of the SlowLogs obtained by calling the helper SlowLog

// SlowLog represents a redis SlowLog
// slowLogID - A unique progressive identifier for every slow log entry.
// unixTimeStamp - The unix timestamp at which the logged command was processed.
// executionTime - The amount of time needed for its execution, in microseconds.
// args - The array composing the arguments of the command.
// clientIPAddressAndPort - Client IP address and port (4.0 only).
// clientName - Client name if set via the CLIENT SETNAME command (4.0 only).
type SlowLog struct {
	SlowLogID              int64
	UnixTimeStamp          int64
	ExecutionTime          int64
	Args                   []string
	ClientIPAddressAndPort string
	ClientName             string
}

Addresses: #405

Briefly, the SentinelClient supplied by sentinel.go represents a connection to a bundle of sentinels. While only one connection is active at a time, the SentinelClient will failover its internal connection to all configured sentinels before failing any individual operation.

The SentinelClient has a Dial method, which connects to the sentinel, and DialMaster and DialSlave methods, which connect to the named master or slaves of the named master, respectively.

The SentinelAwarePool supplied in pool.go is extremely simple. I wanted to avoid an overly-complex implementation here, because I don't have a lot of operational experience with the Pool. The only differences are the addition of a TestOnReturn entry point, which is designed to test returned connections for role changes, and a method to update the internal accounting of the master's address. (Role detection and test wrappers are supplied in sentinel.go). The only meaningful operational difference to the SentinelAwarePool is the ability to purge all idle connections if the master's configuration changes. (active connections will be handled by TestOnReturn).

An example of usage of the SentinelAwarePool is supplied in pool.go.

I believe I have supplied sufficient capability here for a barebones but fully capable sentinel configuration, and enough tools and flexibility for a user to build a more complex setup (including using Sentinel pubsub, which is not included here.)

I've tested this (both pool and standalone connections) on a new 2.8 cluster and an older 2.6-era cluster which does not have CLIENT kill. I would appreciate additional testing and validation if possible, especially on the new 3.0 cluster which I do not have access to.

This repo was moved from here from garyburd/redigo. At the time of the move, I made some minor breaking changes to the API and tagged a v2.0.0 release.

The v2.0.0 release turned out to be a problem when Go Modules were introduced. It's now clear that I should have deleted previous v1.x.x releases from the repo and tagged a new v1.0.0 release.

I was my intent that this repo have one major semantic version until the next breaking API change is made. Let's call the major semantic version as of today as version N.

~~It's possible that users who employ a dependency management tool are using the tags copied over from garyburd/redigo. These users are on major version N-1.~~ Edit: These versions do not compile because they have a package import comment for garyburd/redigo. It's safe to assume that there are no users of these versions.

Users of Go 1.5+ who do not employ a dependency management tool should continue to get the latest of major version N. This works today and should continue to be supported until Go Modules is widely adopted.

Users who opt into Go Modules should not need to change their code.

Because I expect Go Modules to be widely adopted before major version N+1 of this package is created, it's acceptable to require a dependency management tool to get version N+1.

Adding a go.mod file to a v2.x.x release changes the path of the package to github.com/gomodule/redigo/v2. This requires a change to all importers of the packages and does not work for users on Go 1.8 and earlier.

See previous discussion in #365 and #363.

The use of context.Context is recommended for cancellation and deadlines. It would be helpful if redigo could support context.Context and be able to cancel early when needed.

I am stepping down as maintainer of of Redigo on May 1st. Use this issue to suggest and discuss new maintainers for the project. I want to have some consensus on the new maintainers before handing the project off.

build command-line-arguments: cannot load github.com/gomodule/redigo: module github.com/gomodule/[email protected] found (v2.0.0+incompatible), but does not contain package github.com/gomodule/redigo

can anyone help? go version 1.13.11

#480 broke compatibility with Heroku Redis. Before 1.8.2 I was able to connect to Heroku Redis by using the DialURL method. I guess #480 broke this because I started seeing this error after upgrading redigo to 1.8.2: ERR wrong number of arguments for 'auth' command. This is just an assumption but yeah... Will investigate further if I have a bit more time on my hands.

Similar to the ConnWithTimeout interface that implements the Do/Receive methods with an extra time.Duration parameter, I think it would be useful to add in a ConnWithContext interface that takes an extra context.Context parameter. Many other Golang libraries are starting to adopt context.Context usage for cancellation since it was put into the standard library. Additionally, this proposed change shouldn't make any breaking changes to this package's public API. I am happy to implement this feature if I get the green light from whoever maintains this package - I just wanted to start up a discussion first per https://github.com/gomodule/redigo/blob/master/.github/CONTRIBUTING.md.

Presently, if a connection from a pool is requested with pool.Get() and the number of connections active has reached MaxActive then Get() will return the error errPoolClosed.

I feel its more expected by the application developer to always get a connection when calling pool.Get() -- unless the server is down or something. If a function needs to get/set data to redis, then it needs to do that, if the pool is exhausted because of high load on the application, then should it just keep looping asking for a connection until it's not exhausted anymore?

Perhaps having an async (as it is now) and sync Get() for requesting a connection.. like: pool.Get() to be synchronous and pool.GetOrFail() as async. Perhaps the sync Get() should also return an error after X time of waiting. pool.Get(&redis.Wait{5}) .. and a default config option on the pool struct.

I wonder how application developers are using redigo's Pool{} stuff, I can imagine most are leaving MaxActive as 0 and just hoping the max number of connections on their system or server never hits. Considering that, there should be a default for MaxActive, not infinity. And MaxIdle should be some reasonable number as well. I wonder how other database drivers do it...? ie. database/sql.

I think it keeps it much simpler and expected for the app developer. At least for me..

The new DialContext() function currently does not respect the ctx timeouts when configuring auth/clientName/db during connection creation. If the Redis server is unresponsive, this can cause DialContext() to run for a very long time (instead of cancelling when the deadline is exceeded). DoContext should be used for these cmds.

Repro steps:

1. Make Redis unresponsive: CLIENT PAUSE 36000000 ALL
2. Attempt to DialContext() with a 1sec timeout
3. Command is unexpectedly blocked for a long time

Redis Latency Monitor is very useful tool for performance investigations with Redis. We needed an ability to parse results of LATENCY LATEST and LATENCY HISTORY commands to build a monitoring tool for Redis.

Please review an attached PR https://github.com/gomodule/redigo/pull/614. We've already implemented this functionality at our client side, but it makes more sense to share it with wider community via this patch.

Ask questions at https://stackoverflow.com/questions/ask?tags=go+redis

We have specific use case where we are using redis-graph which uses redigo connections underlying. We are using redigo Pools for achieving concurrency. However, seems for every Close() call for the redigo connection, connections are NOT getting returned back to the Pool.

As, per documentation of redigo API reference, the application shall close() the redigo connection, once usage is done. This behavior seems to re-create the new underlying network level connection with redis server in the even though from the Pool().

Redigo Pool implementation does NOT provide a way to return the used redigo connections back to Pool, so that next time those can be reused.

In the same way as seen on the OpenTelemetry instrumentation forgo-redis it would be extremely beneficial to create a similar package for redigo. Not only we can track the overhead of the client code, but we can also precisely trace errors/latency spikes/timeouts/etc...

Some further info:

• Small example of goredis manual instrumentation
• Full example of HTTP service + Redis backed (with client instrumentation)

Important Note: Semantic conventions to follow while preparing a package for manual instrumentation.

While this is not mandatory, we should aim for standardization across clients/languages/DBs. Here's the spec on DB semantic conventions:

https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/trace/semantic_conventions/database.md

PS: will gladly contribute to this matter.